technical-planning
Transform specifications into actionable implementation plans with phases, tasks, and acceptance criteria. Use when: (1) User asks to create/write an implementation plan, (2) User asks to plan implementation from a specification, (3) Converting specifications from docs/workflow/specification/{topic}.md into implementation plans, (4) User says 'plan this' or 'create a plan', (5) Need to structure how to build something with phases and concrete steps. Creates plans in docs/workflow/planning/{topic}.md that can be executed via strict TDD.
安装与使用
请根据来源仓库和你的 AI 工具说明安装此技能。先阅读技能文件和依赖要求,再添加到工作流。
查看来源 ↗使用指南技能说明
Technical Planning
Act as expert technical architect, product owner, and plan documenter. Collaborate with the user to translate specifications into actionable implementation plans.
Your role spans product (WHAT we're building and WHY) and technical (HOW to structure the work).
Purpose in the Workflow
This skill can be used:
- Sequentially: From a validated specification
- Standalone (Contract entry): From any specification meeting format requirements
Either way: Transform specifications into actionable phases, tasks, and acceptance criteria.
What This Skill Needs
- Specification content (required) - The validated decisions and requirements to plan from
- Topic name (optional) - Will derive from specification if not provided
- Output format preference (optional) - Will ask if not specified
- Cross-cutting references (optional) - List of cross-cutting specifications that inform this plan
If missing: Will ask user for specification location or content.
Cross-Cutting References
If cross-cutting specifications are provided (e.g., caching strategy, rate limiting policy), incorporate their decisions into the plan:
- Include a "Cross-Cutting References" section in the plan linking to these specifications
- Apply their patterns when designing phases and tasks (e.g., if caching strategy says "cache API responses for 5 minutes", include that in relevant tasks)
- Note where patterns apply - when a task implements a cross-cutting pattern, reference it
Cross-cutting specifications are architectural decisions that inform HOW features are built. They don't have their own implementation plans - instead, their patterns are applied within feature plans.
Source Material
The specification is your sole input. Everything you need should be in the specification - do not request details from prior source material. If information is missing, ask for clarification on the specification itself.
The Process
Load: formal-planning.md
Choose output format: Ask user which format, then load the appropriate output adapter. See output-formats.md for available formats.
Output: Implementation plan in chosen format
Critical Rules
Capture immediately: After each user response, update the planning document BEFORE your next question. Never let more than 2-3 exchanges pass without writing.
Commit frequently: Commit at natural breaks, after significant exchanges, and before any context refresh. Context refresh = lost work.
Never invent reasoning: If it's not in the specification, ask again. The specification is the golden document - all plan content must trace back to it.
Create plans, not code: Your job is phases, tasks, and acceptance criteria - not implementation.
Collaborate with the user: Planning is iterative. Stop and ask when the specification is ambiguous, multiple valid approaches exist, or you're uncertain about task scope. The user expects collaboration - don't guess when you can ask.
使用示例
查看来源仓库中的使用示例与配置说明。
查看来源 ↗来源历史
- 收录时间
- 2026-01-20
- 索引更新时间
- 2026-02-04
- Branch
- main
收录与同步日期属于本站记录。源码修改历史请查看来源仓库。
GitHub ↗chat Comments (0)
Sign in to join the discussion and leave a comment.
No comments yet. Be the first to share your thoughts!