Sigil: Architecture Pattern Inventory

• creating a new architecture inventory package,
• refreshing an existing architecture package from code evidence,
• extracting reusable implementation patterns,
• documenting layer and dependency rules,
• creating concept and relationship cards,
• aligning architecture guidance with testing and observability expectations,
• preparing a codebase for agentic implementation with selective context loading.

• repository root,
• existing architecture docs,
• source directories,
• tests,
• build or dependency configuration,
• routing or module boundaries,
• known architectural constraints,
• desired output path,
• whether existing package files should be updated or preserved.

architecture/

inside the target repository.

Recommended mapper roles:

1. Structure mapper: identifies top-level folders, applications, packages, modules, and ownership boundaries.
2. Layer mapper: identifies layers, dependency direction, allowed and forbidden imports, and boundary seams.
3. Pattern inventorist: identifies repeated concepts, implementation motifs, naming conventions, and reusable cards.
4. Testing mapper: identifies how architectural units are verified and where gaps exist.
5. Observability mapper: identifies logs, metrics, traces, events, health checks, and operational signals tied to architecture.

Each mapper must return findings with evidence. The main agent synthesizes; mapper agents do not decide canonical package contents independently.

• produce a navigable architecture package with an index and pattern-library entrypoint,
• ground layer and pattern claims in repository evidence,
• separate observed architecture from recommended architecture,
• include dependency rules, testing alignment, and observability alignment,
• make concept and relationship cards selectively loadable,
• preserve existing package content unless update scope is explicit,
• identify unresolved gaps rather than inventing missing architecture.

• copying a generic architecture model over a repository without evidence,
• treating folder names as architecture without checking usage and dependencies,
• mixing product-specific terminology into a reusable package unless it is truly local to the target repo,
• creating one giant architecture document when selective context files are needed,
• letting mapper subagents write canonical files without synthesis,
• documenting ideal rules as if they are currently enforced,
• ignoring tests and observability when mapping implementation patterns.

## Architecture Pattern Inventory Result

- Repository: <path>
- Package path: <path>
- Mode: created | updated
- Mapper pass: subagents | local fallback
- Layers mapped: <summary>
- Patterns inventoried: <count and categories>
- Relationships inventoried: <count and categories>
- Files changed: <paths>
- Gaps deferred: <summary>
- Validation: <checks performed>
- Next refresh trigger: <condition>