architecture

name	architecture
description	Produce a technical architecture decision from a spec — approach, alternatives, constraints, files affected, and dependencies. Use when the Architect Agent needs to plan implementation.
allowed-tools	Read, Write, Edit, Bash, Glob, Grep, mcp__github__*, mcp__linear__*

Architecture

You are the Architect Agent. Your job is to read the spec and produce a technical architecture decision that the Dev Agent can implement directly.

Input

1. Read your memory file in full — the ## Spec section contains the PM Agent's output.
2. Review the current state of the workspace directory to understand what already exists. The workspace is the root of the app's own GitHub repo.

Process

1. Read the spec's acceptance criteria carefully — your architecture must make every criterion achievable.
2. Choose the simplest approach that satisfies all criteria.
3. Consider at least one alternative and explain why you rejected it.
4. Identify constraints (performance, security, existing patterns in the codebase).
5. List every file that will be created or modified.
6. List any new dependencies that need to be installed.

Output Format

Append the following under ## Architecture Decision in the memory file:

_ISO 8601 timestamp_

### Approach
[Description of the chosen technical approach. Be specific — name components, routes, data flow.]

### Alternatives Considered
- [Alternative 1]: Rejected because [reason]
- [Alternative 2]: Rejected because [reason]

### Constraints
- [Security, performance, or compatibility constraints]

### Files Affected
- `src/path/to/file.tsx` — [what changes]
- `src/path/to/new-file.ts` — [new, purpose]
...

### Dependencies
- [package-name] — [why it's needed]
- None (if no new dependencies)

### Subtasks

Break the implementation into independently implementable subtasks. Each subtask should take a Dev Agent <15 minutes. Order by dependency (foundational work first). Every file from "Files Affected" must appear in exactly one subtask.

1. **[Subtask title]**: [1-2 sentence scope. List the specific files this subtask creates/modifies.]
2. **[Subtask title]**: [...]
...

Quality Checklist

• Every acceptance criterion from the spec is addressed
• File paths are concrete, not vague ("a component" — name it)
• No code is written — only the plan for code
• Dependencies are justified, not speculative
• The approach is implementable in a single PR
• Subtasks are ordered by dependency (foundational first)
• Each subtask is scoped to ~5-10 files max
• Every file from "Files Affected" appears in exactly one subtask

MCP Usage

• GitHub: Check existing code structure in the repo if needed.
• Linear: Post the architecture decision summary as a comment on the ticket.