ワンクリックで
speq-plan
Plan and create spec deltas for new features or changes to existing features.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Plan and create spec deltas for new features or changes to existing features.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Audit a speq project's health — spec-library structure, feature/decision-log/plan validation, mission-to-spec sync, unrecorded plans, and gitignore hygiene — then guide fixes. Use when the user asks to audit, health-check, doctor, lint, or sanity-check the specs or repo, or after cloning or inheriting a speq project.
Code review tag taxonomy and findings output format — guardrail violations, dead code, obsolete tests, bad comments, optimizations, YAGNI/over-engineering. Triggered by code-reviewer.
Headless follow-up to speq-plan-pr. Continues on a plan's feat/plan-name branch, runs speq-implement, bumps the version, runs the real test suites, records only if green, then pushes and opens/updates a PR. Arg: plan name, PR number, or branch name.
Orchestrate implementation of reviewed plans according to the spec deltas. Arg: <plan-name>.
Create specs/mission.md via interactive interview. Detects brownfield vs greenfield.
Headless, non-interactive version of speq-plan. Plans a feature without a live interview, commits the result to a feat/plan-name branch, and opens a PR. If a decision genuinely needs a human, it persists the partial plan and open questions and asks in a PR comment instead of blocking. Arg — plan name, feature intent text, PR number, or branch name.
| name | speq-plan |
| description | Plan and create spec deltas for new features or changes to existing features. |
| model | sonnet |
This skill is a thin orchestrator. It conducts the clarifying interview, collects context, and then delegates the heavy planning work (spec delta authoring, test mapping, task decomposition) to the planner-agent sub-agent.
Why this split: Orchestration (asking questions, reading a few files, shepherding the workflow) does not need expensive reasoning. The actual planning — architectural tradeoffs, MECE decomposition, ADR authoring — does. Splitting the work concentrates reasoning on the step that benefits from it.
Invoke before starting:
/speq-cli — Spec discovery and searchThe planner-agent sub-agent invokes /speq-planning, /speq-code-tools, /speq-ext-research, and /speq-cli itself; plan-reviewer invokes /speq-plan-review.
Check for .speq/plan-hook.md in the repo root.
Use speq CLI to understand what exists:
speq domain list
speq feature list
speq search query "<relevant terms>"
This is lightweight — enough context to ask good clarifying questions, not a full exploration.
Apply the Socratic Method via AskUserQuestion — never assume. Decompose the problem space using MECE partitioning:
Record answers in a concise interview summary to pass to the sub-agent.
Pattern: <verb>-<feature-scope>[-<qualifier>]
| Verb | When |
|---|---|
add | New feature |
change | Modify existing |
remove | Deprecate/delete |
refactor | Restructure, same behavior |
fix | Bug or spec mismatch |
Spawn the planner sub-agent with everything it needs:
Delegate to planner-agent — Plan <plan-name>
## Plan Name
<plan-name>
## User Intent
<1-3 sentence summary of what the user wants>
## Clarifying Interview Results
<verbatim Q&A from the AskUserQuestion exchanges>
## Existing Context
<output of relevant `speq search` / `speq feature get` calls>
## External Research
<any research already conducted, or "none — agent to research as needed">
## Project Hook
<if active: note ".speq/plan-hook.md — read it and apply it" — otherwise omit this section>
## Your Task
Produce spec deltas and plan.md per the `planner-agent` workflow. Tag tasks requiring deep reasoning with [expert] so the implementer orchestrator can route them to implementer-expert-agent.
Return the list of files created and the validation result.
When the sub-agent returns:
speq plan validate <plan-name> passed (re-run if uncertain)planner-agent is both author and, until now, sole judge. Before handing the plan off, spawn plan-reviewer — a diabolus advocatus — to challenge it. Bounded to 2 rounds total.
Round 1:
Delegate to plan-reviewer — Review <plan-name> (round 1)
## Plan Name
<plan-name>
## User Intent
<verbatim original request>
## Clarifying Interview Results
<verbatim Q&A>
## Plan Artifacts
plan.md, decision-log.md, and every specs/_plans/<plan-name>/**/spec.md delta
## Project Hook
<if active: note ".speq/plan-hook.md — read it and apply it" — otherwise omit this section>
If BLOCKER findings exist:
planner-agent with only the BLOCKER list, instructing it to revise the specific plan/spec-delta content addressing each one, log each resolved blocker as a ## Review Findings entry in decision-log.md ([plan-review] title prefix), and re-run speq plan validate.plan-reviewer for round 2, passing the round-1 BLOCKER list so it confirms each is actually resolved before checking for new ones.If BLOCKERs remain after round 2 — use AskUserQuestion: present the remaining blockers, let the user accept the risk and proceed, or give guidance and respawn planner-agent manually.
ADVISORY findings are never looped on or persisted — carry them into step 7's report so the user sees them before implementing.
/speq-implement <plan-name> to continue/clear to start implementing with a fresh context windowExitPlanMode and ask to proceed with cleared contextspecs/
├── <domain>/<feature>/spec.md # Permanent
├── _plans/<plan-name>/ # Active
└── _recorded/<plan-name>/ # Archived
| Step | Performed by | Why |
|---|---|---|
| Discovery, interview, coordination | This skill (pins Sonnet) | Conversational, tool-call heavy |
| Spec delta authoring, ADR, task decomposition | planner-agent sub-agent | Reasoning-heavy; defect here compounds through implementation |
| Adversarial review, revision loop | plan-reviewer sub-agent | Catches intent drift, infeasibility, and ambiguity before implementation, not after |
Each sub-agent pins its own model and effort in its frontmatter, so planning quality is independent of the parent session's configuration.