跳到正文
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(原文)

安装前可以查看交给 AI 代理的指令内容。

<!-- 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.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

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年10月13日 更新

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年10月13日 更新

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年10月13日 更新

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年10月13日 更新

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年10月13日 更新

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年10月13日 更新

查看 friedbotstudio 的全部技能

报告此技能的问题