Add 5 pi extensions: pi-subagents, pi-crew, rpiv-pi, pi-interactive-shell, pi-intercom

extensions/rpiv-pi/skills/annotate-guidance/templates/root-architecture.md

@@ -0,0 +1,46 @@
+```markdown
+# Project Overview
+{1-2 sentences: what it is, tech stack}
+
+# Architecture
+{monorepo structure tree + dependency flow diagram}
+{process architecture if applicable}
+
+# Commands
+{key commands table — always bare, never wrapped in <important if>}
+
+# Business Context
+{1-2 sentences if applicable}
+```
+
+The sections above (Overview, Architecture, Commands, Business Context) are foundational — they stay bare because they're relevant to virtually every task.
+
+Cross-cutting patterns and domain-specific conventions go in `<important if>` blocks with narrow, action-specific conditions. Do NOT group unrelated rules under a single broad condition like "you are writing or modifying code". Instead, shard by trigger.
+
+Root conditional blocks are for **cross-cutting conventions that don't belong to any single layer**. Layer-specific recipes (like "adding a new controller" or "adding a new repository") belong in the subfolder architecture.md, not the root.
+
+**Deduplication rule:** If a layer has its own subfolder architecture.md, do NOT add a root conditional block summarizing that layer's conventions. The subfolder file is the authoritative guide — it provides detailed layer-specific documentation in `.rpiv/guidance/`. Root conditionals that mirror subfolder content waste attention budget and create staleness risk.
+
+Root MAY include cross-layer vertical-slice checklists (e.g., "adding a new domain entity end-to-end") that reference multiple subfolder architecture.md files — but each step should point to the relevant subfolder for details, not inline them.
+
+Good root conditions — things that span multiple layers:
+
+```markdown
+<important if="you are writing or modifying tests">
+- Unit: xUnit + NSubstitute / Jest + Testing Library
+- Integration: WebApplicationFactory / Supertest
+- Test fixtures in `__fixtures__/` or `tests/Fixtures/`
+</important>
+
+<important if="you are adding or modifying database migrations">
+- Never modify existing migrations — always create new ones
+- Run `dotnet ef migrations add` / `turbo db:migrate` after schema changes
+</important>
+
+<important if="you are adding or modifying environment configuration">
+- All config via `IOptions<T>` pattern / environment variables
+- Secrets in user-secrets locally, Key Vault in production
+</important>
+```
+
+Each block should contain only rules that share the same trigger condition. If a codebase has 3 distinct convention areas, that's 3 blocks — not 1 block with a broad condition. Layer-specific checklists (adding a controller, adding a repository) go in the subfolder architecture.md using `<important if="you are adding a new {entity} to this layer">`.

extensions/rpiv-pi/skills/annotate-guidance/templates/subfolder-architecture.md

@@ -0,0 +1,57 @@
+```markdown
+# {Layer/Component Name}
+
+## Responsibility
+{1-2 sentences: what this layer does, where it sits in architecture}
+
+## Dependencies
+{List only architectural dependencies — frameworks and libraries that shape how you write code in this layer.
+Do NOT list utility libraries discoverable from package.json/imports (e.g., lodash, moment, xlsx).
+A dependency is worth listing if it imposes patterns, constraints, or conventions on the code.}
+- **{dep}**: Why it's used
+
+## Consumers
+- **{consumer}**: How it uses this layer
+
+## Module Structure
+{Compact directory tree — aim for 4-7 top-level entries, not 15.
+Group related files on one line (e.g., "Service.ts, Handler.ts").
+Use architectural annotations for directories (e.g., "# One repo per entity", "# Domain schemas").
+DO NOT enumerate individual files inside directories — describe the convention.
+When a layer has many directories (10+), group related concerns on one line
+(e.g., "guards/, interceptors/, pipes/ — infrastructure plumbing") rather than listing each separately.
+The structure must stay valid when non-architectural files are added.}
+
+## {Pattern Name} ({Key Constraint or Characterization})
+{Each distinct pattern gets its own H2 section — NOT a generic "## Key Patterns" umbrella.
+Include a fenced code block with an idiomatic, generalized example showing:
+- Constructor / dependencies
+- Key method signatures and return types
+- Error handling / wrapping conventions
+- Inline comments for important conventions (e.g., "// throws on error — service wraps in Result")
+If a pattern spans a layer boundary, show both sides briefly.
+Multiple patterns = multiple H2 sections.}
+
+## {Additional Pattern Name}
+{Second pattern with code block if applicable}
+
+## Architectural Boundaries
+- **NO {X}**: {Why}
+- **NO {Y}**: {Why}
+
+<important if="you are adding a new {entity type} to this layer">
+## Adding a New {Entity Type}
+{Step-by-step checklist inferred from existing code:
+1. Create file following naming convention
+2. Extend/implement base class or interface
+3. Register in factory/container/index
+4. Add related artifacts (schema, test, migration)}
+</important>
+
+<important if="you are writing or modifying tests for this layer">
+## Testing Conventions
+{Test patterns, helpers, fixture locations, mocking approach — if detectable from code}
+</important>
+```
+
+Conditional sections are OPTIONAL — only include them if the pattern-finder skill detects testable patterns or clear "add new entity" workflows. Conditions must be narrow and action-specific. These sections contain checklists/recipes, not code examples (those stay in the unconditional pattern sections). Conditional sections do NOT count toward the 100-line budget for unconditional content.