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"