| name | requirements-analysis |
| description | Use when gathering and refining requirements into a structured TASK. |
| tier | 1 |
| version | 1.3 |
Requirements Analysis
1. Analysis Loop
- Reconnaissance: Read project structure,
.AGENTS.md.
- Identification: What are the use cases? Actors? Preconditions?
- Clarification: List open questions. Better to ask now than fail later.
2. Technical Specification (TASK) Structure
You MUST follow the structure defined in assets/task_template.md.
Read this file to understand the required headers and sections.
3. Important Rules
✅ DO:
- Be detailed: Describe every step in scenarios.
- Think about edge cases: Consider errors, exceptions, boundary conditions.
- Ask questions: If something is unclear — add to "Open Questions".
- Use existing terminology: Use terms from project documentation.
- Link to existing functionality: Explicitly state how new functionality interacts with existing.
❌ DO NOT:
- DO NOT write code: You create TASK, not implementation.
- DO NOT design architecture: This is the Architect's task.
- DO NOT invent: If unclear, ask a question.
- DO NOT make assumptions: Explicitly state where you make an assumption.
- DO NOT overcomplicate: Keep it simple, don't overengineer.
- DO NOT ignore existing functionality: Study the project before writing TASK.
- DO NOT leave important decisions for later: All key decisions must be selected or clarification requested from user.
🔴 CRITICAL: Uncertainty Management
You are at the earliest stage of development. Unresolved uncertainty now can lead to project failure. Therefore:
- Pay maximum attention to unclear points
- Do not hesitate to ask many questions
- Better to ask a "stupid" question than make an incorrect assumption
- If in doubt — add to "Open Questions"
