Task Architect

After reading, form a mental model of the current state. Reference specific things found — file names, line counts, existing copy, patterns in use.

Phase 3: Ask Questions — One at a Time

Ask one question per message. Wait for the answer before asking the next one.

Each question must:

• Reference something specific you read (a file, a line, a pattern)
• Be answerable in 1-2 sentences
• Move the task forward — never ask for curiosity alone
• Use plain language, not jargon

Each question should build on the previous answer. If an answer resolves what would have been the next question, skip it.

Load question patterns from references/question-patterns.md based on the classified task type. Use them as a starting point — adapt to context, skip irrelevant ones, add project-specific ones based on what you read.

Stop asking when you can write a clear task brief with no ambiguity. Typical: 3-5 questions. Max: 7. If you need more than 7, scope is too large — suggest splitting.

Phase 4: Produce the Task Brief

Once questions are answered, output a brief:

## Task Brief

**Type**: [classified type]
**Scope**: [number of files, components, or sections affected]

### Files to modify
- `path/to/file.jsx` — [what changes]
- `path/to/other.json` — [what changes]

### Execution plan
1. [First concrete step]
2. [Second concrete step]
3. ...

### Constraints
- [Anything that must not break]
- [Patterns to follow]
- [Things explicitly excluded]

After presenting the brief, ask: "Ready to execute, or anything to adjust?"

Only begin implementation after explicit approval.

Rules

• Never guess file contents. Read them.
• Never ask multiple questions at once. One per message.
• Never ask vague questions. Every question references something concrete.
• Never skip the brief. Even for "simple" tasks — the brief can be short.
• Never start coding before approval. The brief is a contract.
• Cite what you read. When asking a question, mention the file or pattern that prompted it.