/map-project — Project Architecture Mapping

Reference Documentation

Always Read First

• ${CLAUDE_PLUGIN_ROOT}/docs/01-general-workflow.md — Pre-exploration, sequential workflow, output conventions

Steps (read as needed)

• ${CLAUDE_PLUGIN_ROOT}/docs/02-top-level-structure.md — Document A: root directory mapping
• ${CLAUDE_PLUGIN_ROOT}/docs/03-documentation-index.md — Document B: docs inventory
• ${CLAUDE_PLUGIN_ROOT}/docs/04-source-architecture.md — Document C: solution, data model, service contracts
• ${CLAUDE_PLUGIN_ROOT}/docs/05-feature-map.md — Document D: Mermaid feature map + domain diagrams
• ${CLAUDE_PLUGIN_ROOT}/docs/06-configuration.md — Document E: config sources, classes, DB settings
• ${CLAUDE_PLUGIN_ROOT}/docs/07-integrations.md — Document F: dependencies, APIs, credentials

General Principles

1. Each step builds on the previous — Documents A and B provide context for C, which provides context for D, etc.
2. Optimize for discoverability — the map answers "where is X?" and "what does this system do?" not "how does X work internally?"
3. Use judgement over exhaustiveness — include what's architecturally significant, skip noise. When in doubt, ask: would an agent need this to avoid wasting time exploring?
4. Group by domain consistently — use the same domain groupings across all documents so the map is navigable.
5. Consult the user on priorities — they know which parts of the system matter most. Don't map everything to equal depth.