Plan
⚠️ CRITICAL RULES - READ FIRST
- •
DETECT MODE: Determine if input is an existing task reference or a new requirement description
- •If input looks like
story-user-api Task 1orstandalone-fix-auth Task 2: MODE A - •If input is a new requirement (e.g., "Add user authentication"): MODE B
- •If input looks like
- •
MODE A - Enhance Existing Task:
- •Read the task file from
docs/reference/backend/tasks/ - •User must specify task number (e.g., "Task 1", "Task 2")
- •Add or update the "Implementation Steps" section for that specific task
- •Keep all other sections intact
- •Save back to the same file
- •Read the task file from
- •
MODE B - Create Standalone Task File:
- •Analyze the requirement - is it simple (1 task) or complex (multiple tasks)?
- •If complex, break into multiple tasks (like task-breakdown does)
- •Use filename:
standalone-{requirement-name}.md(kebab-case) - •Save to
docs/reference/backend/tasks/ - •File format: same as story-based (multiple task sections)
- •
READ CONSTRAINTS FIRST:
- •Must read
docs/reference/backend/design-system.mdfor design tokens - •Must read
docs/reference/backend/constraints.mdfor tech stack - •If task references a design, read from
docs/reference/backend/designs/
- •Must read
Language Configuration
Before generating any content, check aico.json in project root for language field to determine the output language. If not set, default to English.
MODE A: Enhance Existing Task
Process
- •Read task file: Get task details from
docs/reference/backend/tasks/{task-file}.md - •Read design (if referenced): Load related design from
docs/reference/backend/designs/ - •Read design system: Load
docs/reference/backend/design-system.mdfor design tokens - •Read constraints: Load
docs/reference/backend/constraints.md - •Break into atomic steps:
- •Start with file creation/setup
- •One section/feature per step
- •Include verification for each step
- •Do NOT include commit step (that happens during execution)
- •Keep steps atomic: One action per step
- •Update task file: Add/replace "Implementation Steps" section
- •Present summary: Show file location and what was added
Example
# Input: User runs /backend.plan story-user-profile-2-header # Output: ✓ Read task: docs/reference/backend/tasks/story-user-profile-2-header.md ✓ Added 4 implementation steps to task file Steps added: 1. Create component file 2. Implement header layout 3. Add responsive styles 4. Add unit tests Task ready for implementation. Use aico-backend-implement to execute.
MODE B: Create Standalone Task
Process
- •
Ask user for details:
- •Task type: feature | bugfix | improvement
- •Confirm task name (auto-generate from description)
- •
Read constraints:
- •Read design system and technical constraints
- •If user mentions a component, check existing code
- •
Generate complete task file:
- •All metadata (type, source, created, status)
- •Description
- •Context
- •Acceptance Criteria
- •Scope
- •Implementation Steps (detailed, atomic)
- •Notes
- •
Save task file: Write to
docs/reference/backend/tasks/standalone-{task-name}.md - •
Present summary: Show created file and next steps
Example
# Input: User runs /backend.plan "Fix login button hover state" # Interactive: # Type: [feature | bugfix | improvement] → bugfix # Task name: fix-login-button-hover (auto-generated, confirm?) # Output: ✓ Created standalone task: standalone-fix-login-button-hover.md Task includes: - Description and context - 2 acceptance criteria - 3 implementation steps - Test verification Next: Use aico-backend-implement to execute this task
Implementation Steps Format
Both modes use the same step format:
## Implementation Steps ### Step 1: [Action] **Files**: - Create: `src/components/[Name].tsx` - Modify: `src/pages/[Page].tsx:L10-L20` **Action**: [Exact code or action to take] **Verify**: ```bash [verification command] ```
Expected: [expected output]
Step 2: [Next Action]
...
## Step Granularity Each step = ONE atomic action: | Good Steps | Bad Steps | |------------|-----------| | Create component file with imports | Create component with all logic | | Add component skeleton (empty return) | Implement entire component | | Implement single section | Implement all sections | | Write one test case | Write all tests | ## Step Types ### Setup Step ```markdown **Files**: Create: `src/components/ProfileCard.tsx` **Action**: Create file with basic structure **Verify**: `npx tsc --noEmit` → No errors
Implementation Step
**Files**: Modify: `src/components/ProfileCard.tsx:L8-L10` **Action**: Implement header section with Avatar and name **Verify**: `npm run dev` → Component renders correctly
Test Step
**Files**: Create: `src/components/__tests__/ProfileCard.test.tsx` **Action**: Write unit test for profile name rendering **Verify**: `npm test ProfileCard` → 1 test passed
Standalone Task File Template
For MODE B, see Task File Template for complete structure.
Use the same format as story-based tasks, just with:
- •Filename:
standalone-{requirement-name}.md - •Header:
# Standalone Tasks: [Requirement Name] - •No
> **Story**: ...line
Note: For simple requirements, file may contain only 1 task. For complex requirements, break into multiple tasks.
Key Rules
- •ALWAYS include verification command for each step
- •MUST keep steps to 2-5 minutes of work
- •MUST save to docs/reference/backend/tasks/ directory
- •NEVER combine multiple actions into one step
- •Do NOT include commit step in plan (commits happen during execution)
- •MODE A: Preserve all existing content, only add/update steps
- •MODE B: Generate complete, self-contained task file
Common Mistakes
- •❌ Steps too large → ✅ One action per step
- •❌ Skip verification → ✅ Every step has verify command
- •❌ Vague actions → ✅ Include exact code
- •❌ Not saving to file → ✅ Always save task file
- •❌ Including commit in steps → ✅ Commits happen during execution, not planning
- •❌ MODE A: Overwriting existing content → ✅ Only update Implementation Steps section
- •❌ MODE B: Missing metadata → ✅ Include all template sections