agentsclimarketplace

Specify and plan

Skill Jed-Tech/spar-kit/Research/research/example skills/specify_and_plan

Turns a change idea into a stable <change-name>_spec.md and actionable plan.md under Docs/<scope>/Specs/<change-name>/. Opens with a fixed prompt for goals/context, then conversationally resolves scope and naming; proceeds through workflow steps in order. Tone: concise, cheerful, inquisitive. Does not create the Specs folder, <change-name>_spec.md, or plan.md until scope and change-name are confirmed. Use when planning a feature or refactor, defining scope before coding, producing a written spec and task list, or running the plan phase before implementation.From its SKILL.md

Install
npx -y skills add Jed-Tech/spar-kit --skill specify_and_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

  • 17 stars17 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.0 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Plan change

Mandatory first turn

Start by asking — use this wording (or trivially equivalent):

I see you would like to start ideation and planning for a change. Can you provide me with some context or your goals for the change?

If the user already dropped hints in the same thread (e.g. a working title), add at most one short acknowledging clause, then still use the prompt above so goals stay explicit.

Do not create files, do not draft <change-name>_spec.md or plan.md, and do not interrogate for scope, folder name, or success criteria in full — save that for after they reply.

Until scope and change name are confirmed or clearly settled: do not create Docs/<scope>/Specs/<change-name>/ or write <change-name>_spec.md / plan.md. A response that creates files or fabricates spec or Implementation Plan content before that does not follow this skill.

Voice

Be concise, cheerful, and inquisitive — like a helpful teammate, not a form or checklist read aloud.

Convert discussion into durable context and a clear execution plan.

Conversation flow

After the user responds

  1. Clarify intent and naming (workflow §1): refine <change-name> as needed through dialogue.
  2. Resolve scope (workflow §2): conversationally confirm xp_stream | saturation_regen | _Repo if still unclear; only ask what is missing.
  3. Then proceed sequentially through workflow §3 onward (create folder → context → ideate → spec → …). Do not skip ahead (e.g. no plan.md before <change-name>_spec.md is stable).

Outputs

Create:

Docs/<scope>/Specs/<change-name>/

  • <change-name>_spec.md — intent, constraints, decisions (not step-by-step)
  • plan.md (Implementation Plan) — ordered, concrete, verifiable execution steps

Scope must be one of: xp_stream, saturation_regen, _Repo. If unclear, stop and ask.


Workflow

1. Clarify intent and naming

  • Understand the goal from discussion; help refine <change-name>.
  • Do not create files yet. (See Mandatory first turn and Conversation flow for opener and sequencing.)

2. Resolve scope

Target: xp_stream | saturation_regen | _Repo. If ambiguous after the user’s first substantive reply, resolve conversationally before §3.

3. Create change folder

When scope and name are fixed:

  1. Create Docs/<scope>/Specs/<change-name>/
  2. Create empty <change-name>_spec.md and plan.md, then populate in later steps.

4. Context gathering

Review relevant code and docs; use Context7 MCP (preferred) or web research when helpful.

5. Ideate

Explore approaches, pick a direction, note risks and unknowns.

6. Draft <change-name>_spec.md

Use this structure:

# <change-name>

## Summary
## Problem
## Goal
## Scope
## Non-Goals
## Constraints
## Success Criteria
## Open Questions
## Decisions
## Documentation Impact

7. Surface unknowns

List gaps; ask the user where needed.

8. Finalize <change-name>_spec.md

Incorporate user input. Ensure intent is clear, scope is correct, and success criteria are testable. Treat the spec as stable after this step.

9. Create plan.md (Implementation Plan)

Only after <change-name>_spec.md is stable. Use:

# Implementation Plan - <change-name>

## Summary
- High-level approach
- Major steps or phases
- Key sequencing or constraints

## Tasks
- [ ] Task 1
- [ ] Task 2
- [ ] Task 3

## Notes
- Validation ideas
- Risks
- Follow-ups

Task rules: ordered, concrete, verifiable; avoid vague items. Keep both files lightweight.


Stop conditions

Stop and ask if:

  • Scope is unclear
  • Requirements are too vague for reliable tasks

Completion

Plan phase is complete when:

  • <change-name>_spec.md is stable
  • plan.md is actionable
  • No critical unknowns remain

Then:

  1. Summarize: scope, spec status, tasks readiness, remaining questions.
  2. Ask: Proceed to implementation?
  3. If yes: begin the implement-change skill. If not using that skill, execute plan.md following repo conventions.

Rules (summary)

ArtifactContains
<change-name>_spec.mdIntent, constraints, decisions — not step-by-step
plan.md (Implementation Plan)Execution steps only — after spec is stable

Do not generate plan.md until <change-name>_spec.md is finalized.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

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.