Agent skill
intent-plan
Transform approved Intent into executable phased plan with strict TDD. Each step requires tests first (happy/bad/edge/security cases), then implementation. Use after /intent-review when ready to start development.
Install this agent skill to your Project
npx add-skill https://github.com/ArcBlock/idd/tree/main/skills/intent-plan
SKILL.md
Intent Plan
Transform an approved Intent into a structured, executable development plan with strict TDD discipline.
Output is TaskSwarm-compatible: The generated plan.md can be directly executed by /swarm run.
Core Principles
- Test First, Always: Every implementation step starts with writing tests
- Phased Execution: Break work into phases with clear deliverables (0-indexed)
- Verification Gates: Each phase ends with e2e validation
- Automation Priority: Prefer CLI/script testing over manual/browser testing
- Checkbox Tracking: All tests use
- [ ]format for progress tracking
Plan Structure
## Phase 0: [Phase Name]
├── ### Description
├── ### Tests
│ ├── #### Happy Path
│ │ └── - [ ] test case 1
│ ├── #### Bad Path (详尽列举)
│ │ └── - [ ] error case 1
│ ├── #### Edge Cases
│ │ └── - [ ] boundary case 1
│ ├── #### Security
│ │ └── - [ ] vulnerability test 1
│ ├── #### Data Leak
│ │ └── - [ ] leak prevention test 1
│ └── #### Data Damage
│ └── - [ ] integrity test 1
├── ### E2E Gate
│ └── CLI/Script 验证命令
└── ### Acceptance Criteria
└── - [ ] criterion 1
## Phase 1: [Phase Name]
└── ...
Test Categories (6 Required)
Every phase MUST include tests from ALL 6 categories:
| Category | Description | Examples |
|---|---|---|
| Happy Path | Normal expected usage | Valid inputs, correct sequences |
| Bad Path | Invalid inputs, error conditions | Wrong types, missing required fields, invalid states |
| Edge Cases | Boundary conditions | Empty inputs, max values, concurrent access |
| Security | Vulnerability prevention | Injection attacks, auth bypass, privilege escalation |
| Data Leak | Information exposure | Sensitive data in logs, error messages, API responses |
| Data Damage | Data integrity protection | Partial writes, corruption, race conditions |
Bad cases must be detailed and comprehensive. A good test suite has more failure tests than success tests.
Test Writing Discipline
- Tests First: Write ALL tests before any implementation
- Red-Green-Refactor: Run tests expecting failure, implement, verify pass
- No Skip: Every category must have at least one test case
Phase Gates: E2E Verification (Required)
Each phase MUST end with E2E verification. This is the gate that proves the phase is truly complete.
E2E Gate Requirements
- Automatable: Must be runnable via CLI/script, no manual steps
- Independent: Can run without human intervention
- Reproducible: Same inputs produce same outputs
- Fast Feedback: Fails quickly when something is wrong
Preferred: CLI/Script Testing
# Example: API verification
curl -X POST http://localhost:3000/api/resource \
-H "Content-Type: application/json" \
-d '{"field": "value"}' | jq .
# Example: Database state check
psql -c "SELECT * FROM table WHERE condition"
# Example: File system verification
diff expected_output.json actual_output.json
# Example: Unit test suite
pnpm test -- --coverage
For Web Projects: Automation-Friendly Design
DO:
- Provide health check endpoints
- Return machine-parseable responses (JSON)
- Include test mode / seed data endpoints
- Design idempotent operations
DON'T:
- Require browser interaction for verification
- Depend on visual inspection
- Need manual clicking through UI
When Browser Testing is Unavoidable
If browser/headless testing is truly necessary:
- Use Playwright/Puppeteer with script automation
- Create dedicated test endpoints
- Prefer API calls over UI interaction
Pre-Plan Gates (Mandatory)
Before generating any plan, ALL gates must pass. No exceptions.
/intent-plan
↓
┌─────────────────────────────────────┐
│ Gate 1: Interview Check │
│ ✗ → "先跑 /intent-interview" │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ Gate 2: Critique Check │
│ ✗ → "先跑 /intent-critique" │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ Gate 3: Dependency Check │
│ ✗ → "前置任务未完成,无法 plan" │
└─────────────────────────────────────┘
↓
✓ All gates passed → Generate plan.md
Gate 1: Interview Check
Verify the Intent has been properly interviewed:
| Check | How to Verify | If Failed |
|---|---|---|
| INTENT.md exists | File exists in intent directory | Run /intent-interview |
| Anchor exists | First blockquote after title starts with > |
Add anchor statement |
| Within budget | wc -l INTENT.md ≤ 500 (warning at 300) |
Run /intent-critique to reduce if > 500 |
| Structure complete | Has Responsibilities, Structure, API sections | Run /intent-interview |
| Not a stub | Content is substantial, not placeholder text | Run /intent-interview |
Output if failed:
❌ Gate 1 Failed: Interview Incomplete
INTENT.md is missing or incomplete:
- [ ] Responsibilities section missing
- [ ] Structure diagram missing
Action required: Run /intent-interview first.
Gate 2: Critique Check
Verify the Intent has been critiqued for over-engineering:
| Check | How to Verify | If Failed |
|---|---|---|
| Critique done | Look for critique markers or changelog | Run /intent-critique |
| Post-modification | If INTENT.md modified after last critique | Run /intent-critique again |
| AI assessment | Ask AI if another critique round is needed | Run /intent-critique if yes |
Critique markers to look for:
<!-- critique: {date} -->comment in INTENT.mdcritique.mdorCRITIQUE.mdin same directory- Changelog entry mentioning critique
Post-modification detection:
- Compare INTENT.md mtime with critique marker date
- If INTENT.md is newer AND has substantial changes → re-critique required
AI Assessment prompt:
"Based on this Intent, is there any sign of over-engineering, premature abstraction, or YAGNI violation that warrants another critique round?"
Output if failed:
❌ Gate 2 Failed: Critique Required
Intent has not been critiqued, or was modified after critique:
- Last critique: 2026-01-15
- INTENT.md modified: 2026-01-20 (substantial changes detected)
Action required: Run /intent-critique to review for over-engineering.
Gate 3: Dependency Check
Verify all prerequisites are satisfied:
| Check | How to Verify | If Failed |
|---|---|---|
| Internal deps | Referenced intents have status: done in TASK.yaml |
List blocking intents |
| External deps | Required packages/services exist | List missing dependencies |
| Environment | Required env vars, credentials, access | List missing setup |
How to find dependencies:
- Parse
## Prerequisitesor## Dependenciesin INTENT.md - Look for
depends_on:in TASK.yaml (if exists) - Scan for references like
intent/other-feature/or@package/name
Dependency states:
intent/auth/ → TASK.yaml status: done ✓ OK
intent/database/ → TASK.yaml status: review ✗ Blocked (not done)
intent/api/ → No TASK.yaml ? Assume not started
@aigne/afs → Check packages/ or deps ✓/✗
Output if failed:
❌ Gate 3 Failed: Dependencies Not Ready
This Intent cannot be planned because prerequisites are incomplete:
Blocking Intents:
- intent/auth-module/ → status: in_progress (need: done)
- intent/database-setup/ → status: ready (need: done)
Missing External Dependencies:
- @aigne/session-protocol → not found in packages/
Action required: Complete blocking tasks first, or remove dependencies from INTENT.md if not actually needed.
Gate Pass Output
When all gates pass:
✓ Gate 1: Interview complete
✓ Gate 2: Critique done (2026-01-20), no re-critique needed
✓ Gate 3: All 2 dependencies satisfied
Proceeding to generate plan...
Workflow
/intent-plan
↓
Gate 1: Interview Check ──→ ✗ → Stop, require /intent-interview
↓ ✓
Gate 2: Critique Check ───→ ✗ → Stop, require /intent-critique
↓ ✓
Gate 3: Dependency Check ─→ ✗ → Stop, list blockers
↓ ✓
Read Intent file
↓
Analyze scope and complexity
↓
Identify logical phases (0-indexed)
↓
For each phase, define:
- Description
- Tests (6 categories)
- E2E Gate
- Acceptance Criteria
↓
Present plan for approval
↓
User confirms or adjusts
↓
Save to plan.md (same directory as INTENT.md)
↓
Create TASK.yaml (status: ready)
Output Files
1. plan.md (Required)
# Execution Plan: {task_name}
## Overview
简要说明这个任务要做什么。
## Prerequisites
- 前置条件
- 依赖的其他任务
- 需要的权限或资源
## Phase 0: {Phase Name}
### Description
这个阶段要完成什么,交付什么。
### Tests
#### Happy Path
- [ ] 测试正常流程 1: {具体描述}
- [ ] 测试正常流程 2: {具体描述}
#### Bad Path
- [ ] 无效输入: {具体场景}
- [ ] 缺失必填字段: {具体场景}
- [ ] 错误状态: {具体场景}
- [ ] 类型错误: {具体场景}
#### Edge Cases
- [ ] 空输入处理
- [ ] 最大值边界
- [ ] 并发访问
#### Security
- [ ] 注入攻击防护: {具体场景}
- [ ] 权限绕过防护: {具体场景}
- [ ] 输入验证: {具体场景}
#### Data Leak
- [ ] 错误信息不泄露敏感数据
- [ ] 日志不包含敏感信息
- [ ] API 响应不过度暴露
#### Data Damage
- [ ] 部分写入恢复
- [ ] 竞态条件处理
- [ ] 事务完整性
### E2E Gate
```bash
# Phase 完成验证脚本
{CLI commands to verify phase completion}
Acceptance Criteria
- 所有 6 类测试通过
- E2E Gate 验证通过
- 代码已提交并 push
Phase 1: {Phase Name}
Description
下一阶段要完成什么。
Tests
Happy Path
- 测试正常流程
Bad Path
- 测试错误处理 1
- 测试错误处理 2
Edge Cases
- 边界条件处理
Security
- 安全测试
Data Leak
- 泄露防护测试
Data Damage
- 数据完整性测试
E2E Gate
# Phase 1 验证脚本
Acceptance Criteria
- 所有测试通过
- E2E Gate 验证通过
Final E2E Verification
# 全系统端到端验证脚本
# 验证所有 Phase 的功能协同工作
Risk Mitigation
| Risk | Mitigation | Contingency |
|---|---|---|
| [风险 1] | [预防措施] | [发生时的应对] |
References
- 相关 Intent
- 详细规格 (如果存在)
- 设计文档 (如果存在)
### 2. TASK.yaml (Required)
```yaml
status: ready
owner: null
assignee: null
phase: 0/{total_phases}
updated: {UTC_ISO_TIMESTAMP}
heartbeat: null
Important: {total_phases} is the number of phases in plan.md (0-indexed counting).
Integration with IDD & TaskSwarm
IDD Flow:
/intent-interview # Create Intent (Gate 1 requirement)
↓
/intent-critique # Review for over-engineering (Gate 2 requirement)
↓
/intent-review # Approve Intent (optional but recommended)
↓
/intent-plan # Gate checks → Generate plan.md + TASK.yaml (THIS SKILL)
↓
TaskSwarm Flow:
/swarm run # Execute plan (TDD cycles)
↓
/swarm approve # Human review
↓
/intent-sync # Write back confirmed details
Gate enforcement ensures quality:
- No plan without proper interview → avoids vague/incomplete specs
- No plan without critique → avoids over-engineered designs
- No plan with missing deps → avoids unexecutable plans
Tips for Good Plans
Format (TaskSwarm Compatible)
- 0-indexed phases: Phase 0, Phase 1, Phase 2...
- Checkbox format: All tests use
- [ ]for progress tracking - E2E Gate per phase: Each phase must have runnable verification
Test Quality
- All 6 categories required: Happy/Bad/Edge/Security/Data Leak/Data Damage
- Bad Path > Happy Path: More failure tests than success tests
- Specific test cases: "Test error handling" ✗ → "returns 404 when resource not found" ✓
- Security by default: Include even if not explicitly requested
Phase Design
- Right-size phases: Each phase completable in 1-3 days
- Clear dependencies: Note when phases depend on previous phases
- Automatable gates: E2E Gate must be runnable via CLI, no manual steps
Example: Complete Output
For an Intent at intent/session-protocol/INTENT.md:
Creates: intent/session-protocol/plan.md
# Execution Plan: session-protocol
## Overview
实现 Session Protocol 的 Frame 编解码功能。
## Prerequisites
- @aigne/afs 包已存在
- TypeScript 环境配置完成
## Phase 0: Frame Encoding
### Description
实现 Frame 的编码函数,将结构化数据转换为二进制格式。
### Tests
#### Happy Path
- [ ] encodes empty frame correctly
- [ ] encodes frame with JSON payload
- [ ] encodes frame with binary payload
- [ ] preserves ReqId across encode/decode
#### Bad Path
- [ ] throws on invalid frame type
- [ ] throws on payload exceeding max size
- [ ] throws on null payload when required
- [ ] throws on negative ReqId
- [ ] throws on non-integer frame type
#### Edge Cases
- [ ] handles empty string payload
- [ ] handles maximum allowed payload size (64KB)
- [ ] handles unicode in JSON payload
- [ ] handles zero-length binary payload
#### Security
- [ ] rejects frames with potential injection patterns
- [ ] validates frame type bounds (0-255)
- [ ] sanitizes string inputs before encoding
#### Data Leak
- [ ] error messages don't expose internal structure
- [ ] stack traces not included in thrown errors
#### Data Damage
- [ ] atomic write: partial encode doesn't corrupt buffer
- [ ] buffer overflow protection
### E2E Gate
```bash
# Verify encoding works end-to-end
pnpm test -- --grep "Frame Encoding"
pnpm test:e2e -- --grep "encode"
Acceptance Criteria
- 所有 6 类测试通过
- E2E Gate 验证通过
- 100% 分支覆盖率
- 代码已提交
Phase 1: Frame Decoding
Description
实现 Frame 的解码函数,将二进制数据解析为结构化对象。
Tests
Happy Path
- decodes valid frame correctly
- handles streaming decode
- decodes all frame types
Bad Path
- throws on truncated frame
- throws on corrupted header
- throws on invalid magic bytes
- throws on unsupported version
Edge Cases
- handles minimum valid frame
- handles maximum valid frame
- handles back-to-back frames in stream
Security
- validates frame length before allocation
- rejects oversized frames (DoS protection)
Data Leak
- doesn't expose raw bytes in error messages
Data Damage
- partial decode doesn't advance stream position
- corrupted frame doesn't affect subsequent frames
E2E Gate
# Verify full roundtrip
pnpm test -- --grep "Frame"
echo '{"test":1}' | node scripts/encode-decode-test.js
Acceptance Criteria
- 所有测试通过
- E2E roundtrip 验证通过
- 代码已提交
Final E2E Verification
# Full integration test
pnpm test
pnpm test:e2e
References
- Intent
- Spec
**Creates**: `intent/session-protocol/TASK.yaml`
```yaml
status: ready
owner: null
assignee: null
phase: 0/2
updated: 2026-01-27T10:00:00Z
heartbeat: null
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
intent-build-now
Start implementation from Intent. Validates Intent completeness, then either delegates to TaskSwarm (if available) or executes TDD phases directly. Use when you have an Intent ready and want to start building.
intent-story
Share your IDD adoption story. Through structured interviewing, create blog posts about Intent-Driven Development experiences, lessons learned, and best practices. Supports multiple languages and formats.
intent-critique
Critical review of Intent design quality. Checks for over-engineering, YAGNI violations, premature abstraction, and simplification opportunities. Uses interactive discussion to refine design decisions.
intent-changes
Manage structured change proposals for design documents with PR-like review experience. Use /intent-changes start <file> to begin, /intent-changes propose to suggest changes, /intent-changes accept/reject to decide, /intent-changes finalize to apply.
intent-assess
Assess if IDD fits your project and learn about Intent-Driven Development. Use /intent-assess to evaluate project suitability or /intent-assess --learn for IDD education.
intent-interview
Didn't find tool you were looking for?