Project Architecture Analyzer - Capture the Architecture (Deliberate)

You are the architect seat for this run: you build the project's architecture picture by reasoning over cheap digests, and you record it as three committed artifacts - docs/architecture/ARCHITECTURE.md (the neutral structure map, deep-dives under docs/architecture/references/), docs/architecture/ASSESSMENT.md (the reasoned, tiered evaluation), and .claude/rules/baseline-project-architecture.md (the generated always-on awareness rule: a micro-summary plus the trigger to read the map, so every session and subagent knows the docs exist without hand-maintained pointers). The reading is delegated - code-analyzer characterizes one module per dispatch and returns a compact digest - but the judgment is NOT: you aggregate, reconcile, and evaluate in-session, then write the docs yourself. Architecture judgment is the expensive kind, so the frontmatter pins this skill's turn to opus/xhigh. The pin lasts the invoking turn only - a run that pauses for user input resumes on the session model - so a run you expect to interrupt still wants an Opus session.

This is capture only: it documents and evaluates, it fixes nothing and produces no implementation steps. Working the weaknesses is project-architecture-quality-loop, which runs this capture as its ANALYZE step and routes fixes by tier. The per-change fit verdict (extend / refactor first / isolate) is the domain solution-designers', reading the map this skill writes.

Read references/doc-shapes.md (the two docs' required shape) and references/hazards.md (the stack-keyed hazard catalog you hunt) before AGGREGATE - they are this skill's contract, not suggestions.

Execution modes

DELEGATED vs INLINE - the shared policy project-task-flow owns. Pick once, hold for the run:

• DELEGATED (dispatch available) - dispatch code-analyzer per module as below; reasoning and writing stay here.
• INLINE (no dispatch: Cursor) - characterize the modules yourself, serena-first and bounded (a module inventory pass, then located reads - never whole-file slurps), and continue at AGGREGATE identically.

The run

1. ORIENT

Read docs/architecture/ARCHITECTURE.md and docs/architecture/ASSESSMENT.md if they exist - a claim to verify, not ground truth - and note which docs/architecture/references/ files are yours versus user-authored. Read the config/manifest files for framework and package facts. Build the module inventory (get_symbols_overview / directory listing) - the list of areas to characterize. Scope it if the user did (one bounded context or module subtree on a large codebase); whole project otherwise.