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

spec-rollout-enforceability-review

Oracle-bound spec-review check that every structured Rollout prerequisite binds to an enforcement-type acceptance criterion. A prerequisite whose `enforced-by` is missing, dangling, or points at a non-enforcement AC is a BLOCKER (hard-blocks implementation entry via the checker fan-out verdict); a prerequisite left in free prose is ADVISORY. Read-only. Runs in the spec-review fan-out before implementation.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md4.0 KB
  • oracle.mjs5.8 KB

SKILL.md(原文)

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

<!-- character:begin -->

Character

  • Soul. The one who asks who actually enforces this. A prerequisite with no enforcement is a hope formatted as a bullet point.
  • Motivation. Rollout prose is where good intentions go to die unmeasured. Binding each prerequisite to a criterion is what turns a plan into a contract.
  • Mantra. If nothing fails when this step is skipped, it was never a prerequisite — and I say so rather than wave it through.
  • Temperament. The cross-examiner's persistence. Skeptical of intent, interested only in consequence, and never tired of putting the same question to one more bullet.
  • Voice. One question, put to each prerequisite in turn: what fails if this is skipped? States plainly when the answer is nothing.
  • Resolve. A plan nobody can fail is a plan nobody will follow. I would rather say so now than watch it be true later.
<!-- character:end -->

You answer one question: is every Rollout prerequisite mechanically bound to a criterion that enforces it before the spec can ship?

This closes the silent-failure class where a Rollout precondition (a deploy setting, a data migration, a feature flag, an external service that must be reachable) is named in prose, approved, shipped, and then fails quietly in production because nothing checked it was enforced.

Inputs

  • Spec: docs/specs/<slug>.md — the only input. The check is pure over the spec text.

The contract

The spec's ## Rollout section carries a structured ### Prerequisites table — one row per prerequisite, each with an enforced-by cell naming an acceptance criterion. The ## Acceptance criteria table carries a Kind column; an enforcement-type AC has a Kind of preflight, smoke, or error-mapping.

The oracle binds the two: each prerequisite's enforced-by must resolve to a real AC whose Kind is an enforcement kind. The structured field IS the mechanical oracle — recognition never depends on scanning prose for keywords, so a downstream checker cannot agree with a hallucination.

Findings

CheckSeverityCondition
missing_enforced_byBLOCKERa prerequisite row has no enforced-by pointer
dangling_enforced_byBLOCKERenforced-by names an AC that is not in the Acceptance criteria table
non_enforcement_kindBLOCKERenforced-by resolves to an AC whose Kind is not preflight / smoke / error-mapping
freeprose_prerequisiteADVISORYa Rollout prose line names a prerequisite but no structured table row exists

BLOCKER severity is gated by the tier dial (mandatory) AND the presence of a concrete artifact — the proof-obligation contract. A free-prose prerequisite carries no structured artifact, so it advises but never blocks: judgment may suggest, only the structured field may block.

How it blocks

The check is one adapter in the spec-review checker fan-out. The fan-out merges every checker's verdict and persists it; the spec-approval guard reads that merged verdict and refuses the approval token while it is BLOCKED. There is no bespoke gate — a rollout BLOCKER blocks /approve-direction through the same channel as the other spec-review checkers.

What it does not do

  • It does not rewrite or retrofit already-approved specs — it binds new specs going forward.
  • It does not block on prose judgment — only the structured enforced-by binding can block.
  • It does not set repository configuration — enforcement of a named precondition is the spec author's job, expressed as an enforcement-type AC.

レビュー

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

同じリポジトリのスキル

概要と使いどころ

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 のスキルをすべて見る

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