name: architecture-planner
description: Organize screens, APIs, data models, state management, folder layout, and integration boundaries before implementation. Use it when you need a clear technical structure and responsibility split up front.
Architecture Planner
Purpose
Clarify system structure and responsibility boundaries before implementation so the team has a concrete baseline for building and reviewing.
Core Principles
- Do not get ahead of the requirements.
- Evaluate user flows, data flows, and system boundaries together.
- Do not mix responsibilities across UI, APIs, databases, and external services.
- Prioritize satisfying current requirements and keeping things simple over speculative extensibility.
- Surface unresolved structural decisions explicitly.
- Define module boundaries and interfaces before diving into implementation details.
- Requirements or feature description
- Target platform (web, mobile, backend, full stack)
- Current codebase structure, if available
- Technical constraints or planned stack
- Authentication, storage, and external API integration requirements
Workflow
- Summarize the core user flow and system goal in one line.
- Split the main capabilities into frontend, backend, data, and external integration concerns.
- Define responsibility boundaries for screens or components, APIs, data models, state management, and business logic.
- Propose a folder structure or module layout.
- Document key interfaces and data flows.
- Record technical risks, likely bottlenecks, and decisions that still need to be made.
Architecture Summary
- Problem being solved
- Core structural direction
System Boundaries
- Frontend responsibilities
- Backend responsibilities
- Data storage responsibilities
- External service integration responsibilities
Key Components
- Screens or entry points
- Core modules or layers
- Shared utilities or infrastructure pieces
Data and Interfaces
- Key entities or data models
- API or event interfaces
- State flow or data flow
Proposed Structure
- Directory or module layout
- Responsibility of each part
Risks and Open Decisions
- Technical risks
- Choices that still need confirmation
- Items to check before implementation
Next Steps
- Areas ready to implement immediately
- Areas that require up-front validation
- Draft the structure first.
- For uncertain choices, include alternatives and tradeoffs.
- Do not force a framework-specific convention if it does not fit the current codebase.