agentsclimarketplace

Spec planning

Skill byerlikaya/claude-starter-kit/plugin/skills/spec-planning

Enterprise engineering workflow for Claude Code — not just prompts. AI agents that plan, build, audit, and ship with security gates, privacy checks, and approval-controlled commits. Safely adopt it into new or existing repositories.

Install
npx -y skills add byerlikaya/claude-starter-kit --skill spec-planning

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

  • 20 stars20 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.

What its author says it does

Copied from the file, not written here

Spec-first planning: task breakdown, measurable acceptance criteria, dependency order, risk priority. planner-csk applies it; the plan goes to docs/PLAN.md. Trigger phrases: "plan", "spec", "task breakdown", "acceptance criteria", "roadmap", "how do we split this"

SKILL.md

2.9 KB, 622 tokens by cl100k_base, as published. Nobody here has run it

Spec-First Planning

Before writing code: what will be done, how it counts as "done", and in what order to proceed become clear.

Steps

  1. Purpose & scope: the problem being solved in a single sentence; also write the out-of-scope explicitly (prevent scope creep).
  2. Split into vertical slices: the smallest end-to-end working pieces (not horizontal layers). Each slice delivers value on its own.
  3. A contract for every task: input · output · measurable acceptance criterion (testable) · estimated risk.
  4. Dependency graph: which task waits on what; no cycles. Bring the riskiest/most-unknown to the front (fail-fast).
  5. Uncertainties: assumption list + open questions; do not fill ambiguous spots with a guess, ask with explicit options.

Output (docs/PLAN.md)

# <Feature> — Plan
## Acceptance criteria
- [ ] <measurable outcome>
## Tasks (order)
1. <task> — criterion: <...> — dependency: <none/#n> — risk: <low/medium/high>
## Assumptions / Open questions
- ...

Mark what you do not know — do not fill it in

Where a requirement admits more than one reading, write the marker [NEEDS CLARIFICATION: <the question>] at that exact spot in the plan. Do not resolve it with the likeliest interpretation and move on.

This is the difference between a discipline and a hope. "Stop and ask when unsure" (§1) depends on noticing the uncertainty in the moment; a marker survives into the artifact, where the user, a reviewer and a later session can all see it. A plausible assumption silently written into a spec is indistinguishable from a decision, and that is exactly how the wrong feature gets built correctly.

Rules that keep it honest:

  • The marker carries the question, not the label. [NEEDS CLARIFICATION: does an expired invite count as used, or can it be re-sent?] is actionable; [NEEDS CLARIFICATION: invites] is noise.
  • A plan may ship with markers — that is the point. It may not ship with a marker inside an acceptance criterion: a criterion nobody can evaluate is not a criterion.
  • Resolve by asking, never by choosing. When the user answers, replace the marker with the answer and record which reading was rejected — the alternative is what a future reader needs.
  • Zero markers on a genuinely ambiguous brief is a smell, not a win.

DoD (this skill's contribution)

  • Every task's "done" is testable; ordering and dependencies are visible; the riskiest work has been brought to the front.
  • Every unresolved ambiguity carries a [NEEDS CLARIFICATION: …] marker; no acceptance criterion contains one.

What ships with it

Read from the repository

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

Gives 0 of the 12 instructions most plan spec skills give in 622 tokens

Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07

  • Ask one question at a timein 51 of 1099
  • Break plans into vertical slicesin 29 of 1099, across 11 files
  • Publish issues in dependency orderin 27 of 1099, across 9 files
  • Iterate until user approves the breakdownin 25 of 1099, across 7 files
  • Explore the repository to understand the codebase statein 24 of 1099, across 7 files
  • Use domain glossary vocabularyin 23 of 1099, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1099, across 5 files
  • Prefer AFK slices over HITLin 22 of 1099, across 7 files
  • Write a specification before writing any codein 22 of 1099, across 14 files
  • Write failing tests before implementation codein 22 of 1099, across 20 files
  • Ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
  • Respect existing architecture decision recordsin 20 of 1099, across 5 files

Said here and by no other author read

  • state problem and out-of-scope items
  • define measurable acceptance criteria for tasks
  • record rejected alternatives when clarifying

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. 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.