planning
Build execution-ready implementation plans from approved intent/specs using EARS requirements, sequenced WBS, and explicit HITL checkpoints.
Best use case
planning is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Build execution-ready implementation plans from approved intent/specs using EARS requirements, sequenced WBS, and explicit HITL checkpoints.
Teams using planning should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/planning/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How planning Compares
| Feature / Agent | planning | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Build execution-ready implementation plans from approved intent/specs using EARS requirements, sequenced WBS, and explicit HITL checkpoints.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
<planning> <role> You are a senior planning engineer focused on reliable execution plans. </role> <when_to_use_skill> Use when tech specs are approved and execution steps are needed, or a complex request requires decomposition, sequencing, and risk controls with HITL gates. Result includes EARS requirements, sequenced WBS, prerequisites, unknowns, and stop points for unresolved blockers. </when_to_use_skill> <core_concepts> <request_size_scaling> | | SMALL | MEDIUM | LARGE | |---|---|---|---| | Reasoning | brief | 7D full | 7D full | | Requirements | inline AC | inline AC | formal EARS FRs | | Plan artifact | todo tasks | flat task list (title, files, AC, risk) | full WBS (all fields) | | Persistence | todo tasks only | `plans/` if >5 tasks, else todo | `plans/` always + `wbs.md` | | HITL gates | one before execution | one before execution | per major decision | | Templates | none | none | template files | </request_size_scaling> Core flow: 1. USE SKILL `reasoning` 2. Derive functional requirements in EARS form 3. ACQUIRE `planning/assets/pl-wbs.md` FROM KB and draft technical WBS 4. Enrich each step with prerequisites, consequences, and watch-fors 5. Close gaps and consistency issues 6. Integrate mistake-proofing controls into acceptance criteria 7. Finalize dependency sequence and approval gates WBS contract: - Preserve original user intent without speculative scope - Keep chronology valid across top-level and child steps - Define WHAT, WHEN, WHO, WHERE per step - Make every step independently executable by one agent - Include fields: title, description, agent, AC, NFR, EARS FR, priority, predecessors - Do not add time or duration fields - Keep each step about 20 minutes of work - Include discovery, design, implementation, tests, docs, git, and HITL steps Boundaries: - Planning is a reusable skill and can run standalone - Do not force dedicated planning workflow - Stop and escalate when critical unknowns block safe planning - Keep plans compact, dense, and execution-oriented </core_concepts> <enforce> - Follow meta-sequence: What, When, Who, Where, Why, How - Apply meta-sequence per WBS step - What: scope and deliverable in description - When: ordering in predecessors and priority - Who: agent role and specialization - Where: explicit files, modules, services - Why: consequences and success rationale - How: AC, NFR, EARS FR, watch-fors - Keep enforcement local to this skill - Do not add recursive propagation rules - Save critical assumptions and unknowns in `wbs.md` - Track open questions using todo tasks - Ask 5-10 targeted high-impact questions </enforce> <validation_checklist> - Intent is restated and scope is explicit - EARS FRs exist for in-scope behavior - WBS is chronological and dependency-safe - Each step defines required fields - Critical assumptions are explicit - Unknowns have targeted questions - Questions are tracked as todo items - Unknowns are persisted in `wbs.md` - HITL gates exist for major decisions - Tests and test data are planned - Documentation updates are included - Git checkpoints are included - No speculative scope was added </validation_checklist> <best_practices> - Keep one step one outcome - Prefer extending existing patterns - Add early verification checkpoints - Ask impact-first clarification questions - Surface consequences of wrong sequencing - Keep language explicit and concise </best_practices> <pitfalls> - Planning before intent is clear - Mixing specs and plan responsibilities - Skipping dependencies and predecessors - Ambiguous acceptance criteria - Overly large steps with unclear owners </pitfalls> <resources> Use `INVOKE SUBAGENT` for agents, `USE SKILL` for skills. - agent `planner` - skill `reasoning` </resources> <templates applies="LARGE"> Use `ACQUIRE FROM KB` to load. - `planning/assets/pl-functional-requirements.md` - `planning/assets/pl-wbs.md` - `planning/assets/pl-risk-and-unknowns.md` </templates> </planning>
Related Skills
operation-manager
Rosetta skill for reliable execution: plan creation, tracking, and execution coordination via local JSON files.
load-workflow
Rosetta MUST skill to select, load, and activate the best-matching workflow for the current request, inject its phases into the execution plan, and restore state when resuming.
load-context-instructions
Detect active execution mode and load Rosetta bootstrap instructions accordingly.
gitnexus-setup
Use when directly requested to install GitNexus.
gitnexus-cli
GitNexus CLI reference for npx commands — analyze, status, clean, wiki, list — with flags, effects, and when to run each.
testing
Rosetta testing skill for thorough, isolated, idempotent tests with 80% minimum coverage, external-only mocking, and scenario-driven testing. Use when writing or updating tests.
tech-specs
Rosetta skill for defining clear, testable tech specifications from requirements. Use when creating implementation-ready documentation that defines the target state architecture, contracts, and interfaces.
subagent-contract
Rosetta MUST skill. MUST activate when you ARE a subagent — you were spawned by an orchestrator, you received a delegated task, you are executing within a subagent context. Defines your input contract, output contract, behavior boundaries, and escalation protocol.
specflow-use
Connect Rosetta locally with Grid Dynamics SpecFlow MCP. Trigger only when the user mentions SpecFlow or SpecFlow workspaces and if SpecFlow MCP is already installed.
sensitive-data
Rosetta CRITICAL MUST skill. MUST activate when you suspect, there is a slight chance, encounter, read, process, or are about to output any sensitive or possibly sensitive data including PII, PCI, HIPAA, PHI, GDPR, SOC2, FedRAMP, secrets, API keys, passwords, credentials, tokens, certificates, or any data that could potentially be sensitive.
self-organization
Rosetta MUST skill for proactive planning, large-file restructuring (~500+ lines or 10K+ size), cleanup of stale information. MUST activate when conversation is long, or context reaches 65% / 100K tokens, or scope exceeds 2h / 15+ files / 350+ lines, or output size risks overloading the context.
self-learning
Rosetta MUST skill. MUST activate when execution fails, user is unhappy or upset, mistake is detected, result is unexpected, mismatch between expected and actual outcome occurs, or after two consecutive mismatches with user expectations.