本文へ移動
cccskills
無料GitHub で公開

sprint-plan

Decompose an MVP vision into a sprint manifest — a prioritized feature list where every feature carries explicit done-criteria (a done-record reference, named edge tests, and a wiring test). Produces the sprint manifest that `sprint-oracle` checks for completeness. Use when planning a sprint of parallel work (Slice A of the sprint-mode epic). Not a workflow phase; the manifest it writes is the completeness contract a sprint is held to.

インストール方法を見る

含まれるファイル(3)

  • SKILL.md3.6 KB
  • template-manifest.json342 B
  • validate-manifest.mjs4.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

sprint-plan — author a sprint manifest with per-feature done-criteria

sprint-plan turns an MVP vision into a sprint manifest: a prioritized list of features, each carrying the done-criteria that make "done" mechanically checkable. The manifest is the input contract for sprint-oracle, which fails a sprint until every feature meets its criteria. This is Slice A of the mvp-sprint-parallel-cycles epic — the completeness half of the parallel-sprint goal (a sprint can be fast yet provably not partial).

What the manifest is

A JSON document (template-manifest.json is the shape). Each feature declares three done-criteria dimensions so completeness is a grep, not a judgment call:

  • done_record — a reference proving the feature is specified (a spec AC id, e.g. AC-012). Non-empty.
  • edge_tests — names of tests covering error / empty / edge states. A non-empty array.
  • wiring_test — the name of one integration test exercising the feature end-to-end.
{
  "sprint": "<sprint name>",
  "features": [
    {
      "id": "search",
      "priority": "P0",
      "done_record": "AC-012",
      "edge_tests": ["search_empty_query", "search_unicode"],
      "wiring_test": "search_end_to_end"
    }
  ]
}

The test-tag convention (how sprint-oracle resolves the names)

A named test counts toward a feature only when the test file tags it. Immediately above the test('<name>', …) call, place:

// @sprint-feature:<feature-id> @kind:edge|wiring|happy
test('<name>', () => { /* … */ });

sprint-oracle builds a map of testName → {feature, kind} from these tags and resolves each manifest reference against it. A test tagged @kind:happy does not satisfy an edge or wiring requirement — that is the deliberate, mechanical line (no script can prove a test is semantically an edge case; the tag is the author's crisp claim, and the oracle verifies the claim resolves).

How to use

  1. Decompose the MVP vision into features. Decide priority (P0/P1/…) per feature — scoping, not implementation.

  2. For each feature, name its done_record (the spec AC it traces to), the edge_tests it must carry, and its wiring_test.

  3. Write the manifest (default location: .claude/state/sprint/<sprint>/manifest.json, gitignored runtime state).

  4. Validate the shape before handing it to the oracle:

    node .claude/skills/sprint-plan/validate-manifest.mjs validate <manifest-path>   # wraps validate-manifest.mjs -> validateManifest
    

    validateManifest(obj) returns {valid, errors:[{feature, field, reason}]} — it flags missing required fields per feature and duplicate feature ids. It checks shape, not completeness; completeness is sprint-oracle's job.

Constraints

  • The manifest is a scoping artifact, not a design. sprint-plan decides what features and which done-criteria, never how a feature is built.
  • Decisions live in main context (Article II). This skill is invoked there; it delegates nothing to a subagent.
  • Completeness is enforced by sprint-oracle, not here — keep the two concerns separate.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

archive

無料

Phase 10.5 — move the slug's workflow artifacts (intake, scout, research, spec, approvals, swarm state, security reports, rendered diagrams) to docs/archive/<YYYY-MM-DD>/<slug>/. Runs before /commit so the committed tree is clean of work-in-flight files. workflow.json stays live and gets archived as the first step of /commit.

日本語の概要は準備中です。原文の説明を表示しています。

friedbotstudio/baseline142026年9月9日 更新

Drift check between the baseline implementation on disk and the claims in `docs/init/seed.md` + cross-references in CLAUDE.md, README.md, and the rendered docs site. Verifies hook/agent/skill/command names + counts, settings.json wiring, project.json key presence, .mcp.json servers, vendored license files, and helper script presence. Exit 0 PASS / 1 FAIL — suitable for CI. Read-only; safe to invoke any time.

日本語の概要は準備中です。原文の説明を表示しています。

friedbotstudio/baseline142026年9月9日 更新

PM-mode brainstorm helper. Captures the requirement via Socratic dialogue before any entry phase (`/intake`, `/spec`, `/tdd`) drafts its artifact. Stage 0 skip-check, Stage 1 gap-analysis, Stage 2 probe-loop, Stage 3 confirm-and-persist. Output lives at `docs/brief/<slug>.md`. Never proposes solutions — Stage 2 dialogue discipline is structurally enforced via `discipline.mjs`.

日本語の概要は準備中です。原文の説明を表示しています。

friedbotstudio/baseline142026年9月9日 更新

brd

無料

Draft a Business Requirements Document (BRD) for cross-functional or stakeholder-heavy work that needs more structure than an intake. Use after `/intake` when the request spans multiple systems/teams, carries regulatory weight, or needs formal sign-off. Output lives at `docs/brd/<slug>.md`.

日本語の概要は準備中です。原文の説明を表示しています。

friedbotstudio/baseline142026年9月9日 更新

chore

無料

Workflow track for tasks that need no TDD — documentation edits, governance count bumps, vendored-skill content updates, configuration tweaks, formatting, typo fixes, dependency bumps where no project code changes. Skips `/scenario` and `/implement` (no failing test to drive) and runs the work directly. `archive`, `memory-sync`, `/grant-commit`, and `/commit` remain mandatory. `verify`, `simplify`, `integrate`, and `document` are conditional — required when the diff hits one of the listed triggers, optional otherwise. `verify` is skipped only when the diff is pure-docs/prose AND `project.json → test.kind` is `behavior` (absent/invalid `test.kind` → `structural` → verify runs). Chore is a stripped-down pipeline, not a bypass; never silently skip a conditional phase whose triggers apply.

日本語の概要は準備中です。原文の説明を表示しています。

friedbotstudio/baseline142026年9月9日 更新

Analyze a codebase and recommend Claude Code automations (hooks, subagents, skills, plugins, MCP servers). Use when user asks for automation recommendations, wants to optimize their Claude Code setup, mentions improving Claude Code workflows, asks how to first set up Claude Code for a project, or wants to know what Claude Code features they should use.

日本語の概要は準備中です。原文の説明を表示しています。

friedbotstudio/baseline142026年9月9日 更新

friedbotstudio のスキルをすべて見る

このスキルの問題を報告する