agentsclimarketplace

Speq plan

Skill marconae/speq-skill/.claude/skills/speq-plan

Plan a feature or change through a clarifying interview, producing spec deltas, plan.md, and decision-log.md via planner-agent with adversarial review. Use when the user asks to plan, spec, design, or scope a new feature, a change or removal of existing behavior, a refactor, or a fix — before any implementation.From its SKILL.md

Install
npx -y skills add marconae/speq-skill --skill speq-plan

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • runs commandsInstructs the agent to run 4 commands, including `speq domain list` and 3 more.

SKILL.md

6.6 KB, ~1.5k tokens by cl100k_base, as published. Nobody here has run it

Spec Planner (Orchestrator)

This skill is a thin orchestrator: it conducts the clarifying interview, collects context, and delegates the heavy planning work (spec delta authoring, test mapping, task decomposition) to the planner-agent sub-agent. Orchestration is cheap; reasoning is expensive — the split concentrates reasoning where defects compound.

Required Skills (for the orchestrator)

Invoke before starting:

  • /speq-cli — Spec discovery and search

planner-agent and plan-reviewer invoke their own required skills.

Workflow

0. Load Project Hook (orchestrator)

Check for .speq/plan-hook.md in the repo root.

  • Present: read it. Announce "Loaded project hook: .speq/plan-hook.md". Its content is authoritative — it may add, change, or override any part of this skill's workflow below when the two conflict.
  • Absent: continue normally, no mention.

1. Discovery (orchestrator)

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.

2. Clarifying Interview (orchestrator)

Apply the Socratic Method via AskUserQuestion — never assume. Decompose the problem space using MECE partitioning:

  • Probe — surface hidden assumptions with open-ended questions
  • Partition — present alternative solutions as MECE options
  • Challenge — test design tradeoffs through guided counterexamples

Record answers in a concise interview summary to pass to the sub-agent.

3. Plan Name (orchestrator)

Pattern: <verb>-<feature-scope>[-<qualifier>]

VerbWhen
addNew feature
changeModify existing
removeDeprecate/delete
refactorRestructure, same behavior
fixBug or spec mismatch

4. Delegate to planner-agent

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.

5. Review planner-agent output (orchestrator)

When the sub-agent returns:

  1. Confirm speq plan validate <plan-name> passed (re-run if uncertain)
  2. List all created files
  3. If the sub-agent escalated a question back to you, resolve it with the user and respawn with the clarification

6. Adversarial Plan Review (orchestrator)

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:

  1. Respawn 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.
  2. Respawn plan-reviewer for round 2, passing the round-1 BLOCKER list so it confirms each is actually resolved before checking for new ones.
  3. Do not loop a third time, even if round 2 surfaces new BLOCKERs.

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.

7. Explain next steps (orchestrator)

  • Inform the user that the plan is created and ready for review
  • List all created files
  • Report any ADVISORY findings from step 6 so the user sees them before implementing
  • Inform the user to call /speq-implement <plan-name> to continue
  • Inform the user to call /clear to start implementing with a fresh context window
  • If Claude Code is in "plan mode", call ExitPlanMode and ask to proceed with cleared context

Spec Hierarchy (reference)

specs/
├── <domain>/<feature>/spec.md     # Permanent
├── _plans/<plan-name>/            # Active
└── _recorded/<plan-name>/         # Archived

Work Split (reference)

StepPerformed byWhy
Discovery, interview, coordinationThis skill (pins Sonnet)Conversational, tool-call heavy
Spec delta authoring, ADR, task decompositionplanner-agent sub-agentReasoning-heavy; defect here compounds through implementation
Adversarial review, revision loopplan-reviewer sub-agentCatches 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.

Anti-Patterns

PatternWhy Wrong
Authoring plan.md or spec deltas in the orchestratorplanner-agent owns all plan authoring
Skipping the clarifying interviewContent comes from user answers, never assumptions
A third review roundReview is bounded to 2 rounds — after that, the user decides
Persisting ADVISORY findings or looping on themReport-only; they never gate
Embedding spec content in plan.mdPlans reference delta files

What ships with it: 5 files

8.5 KB alongside SKILL.md

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.