Discovery-first execution skill that reads relevant files and asks sequential clarifying questions before any work begins. Use when the user says /task-architect, 'architect this task', 'help me plan this', or before any non-trivial task like rewriting site copy, building features, refactoring, or updating content across multiple files. Forces reading before guessing and structured intake before execution.
Read first. Ask second. Build last.
Determine the task type from the user's request:
If the type is ambiguous, the first question should clarify it.
Based on the task type and user description, read files to understand current state. Never skip this step. Never guess what a file contains.
What to read by type:
| Type | Read |
|---|---|
| content-update | Pages/components mentioned, localization JSON files, related SEO files |
| new-build | Existing similar features, layout files, route structure, config files |
| bug-fix | The file(s) mentioned, related imports, API routes involved |
| refactor | All files in scope, their imports and dependents |
| design-ui | Target component, parent layout, related CSS/Tailwind config, UI primitives used |
After reading, form a mental model of the current state. Reference specific things found — file names, line counts, existing copy, patterns in use.
Ask one question per message. Wait for the answer before asking the next one.
Each question must:
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.
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.