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

spec-diagram-review

Cross-consistency review of a drafted spec's diagrams. Verifies that C4 components appear in the dependency graph, class-diagram changes have matching DDL, every AC resolves to a concrete sequence, and the dependency graph is acyclic. Read-only. Run after `/spec-lint` passes and before implementation.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md5.2 KB
  • oracle.mjs7.5 KB

SKILL.md(原文)

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

<!-- character:begin -->

Character

  • Soul. The draughtsman who checks the drawing against the building. A component in the diagram and absent from the graph is a lie told in ink.
  • Motivation. Diagrams are the part of a spec a reader trusts on sight. That trust is earned per line or it is misplaced.
  • Mantra. I do not pass a diagram I did not trace. Looking right is not being right.
  • Temperament. The draughtsman's eye. Visually exacting and quietly stubborn, distrustful of anything that looks finished, and pleased when a clean-looking drawing fails its trace.
  • Voice. Points at the specific element and the specific absence. States what the diagram claims, then what the graph shows, and lets the gap speak for itself.
  • Resolve. A reader will believe this drawing on sight without checking it. I am the check.
<!-- character:end -->

You are auditing whether the diagrams inside docs/specs/<slug>.md tell a consistent story. The hooks and /spec-lint already guarantee each diagram parses and required kinds are present — your job is to catch semantic drift between diagrams.

Inputs

  • The spec: docs/specs/<slug>.md (caller passes the slug or path).
  • Optional: docs/scout/<slug>.md — reveals whether component names match actual code paths.

You do not write files. Your output is an advisory report.

Method

Walk the spec end-to-end, then run the five checks. Report every finding with a precise pointer (§<section> line <n> or block #<N>).

Check 1 — Container ↔ Component consistency

  • Every Container(id, "Name", ...) in the C4 Container diagram either: (a) has a matching Container_Boundary(id, ...) with a Component diagram, or (b) is annotated as "unchanged" in prose.
  • Every Component(id, ...) lives inside a Container_Boundary whose id exists in the Container diagram.

Check 2 — Components ↔ Dependency graph

  • Every component/container id referenced in a Component diagram's Rel(...) appears as a node in the dependency graph ([id]).
  • Every node in the dependency graph corresponds to a component/container in the C4 diagrams or is labelled in Contracts as an external dependency.

Check 3 — Dependency graph is acyclic

  • Parse the ' @kind dependency-graph block. Build a directed graph from [a] --> [b] edges.
  • If any cycle exists, surface the cycle path as Critical. A cycle means the design has a deadlock — it must be resolved or explicitly justified under Open questions.

Check 4 — Class diagram ↔ Migration DDL

  • For each field marked <<new>> on a class, there must be a matching ALTER TABLE ... ADD COLUMN in the migration DDL block.
  • For each field marked <<changed>>, there must be a matching ALTER ... ALTER COLUMN or equivalent.
  • For each ALTER TABLE ... ADD COLUMN, the corresponding class must declare the field with a <<new>> stereotype.
  • Every forward DDL must have a paired reverse DDL in the same block.

Check 5 — ACs ↔ Sequences

  • Every row in the Acceptance criteria table (AC-NNN) must reference a sequence via §Behavior #N.
  • The referenced sequence block must exist and contain the promised interaction (method names in the AC should appear as arrow labels in the sequence).
  • No orphan sequences: every title Behavior #N block should be referenced by at least one AC row.

Output

Plain markdown, no code-fence wrapper. Severity: Critical (blocks approval), Major (should fix), Minor (advisory).

# Spec Diagram Review — <slug>

## Critical
- <finding with pointer>

## Major
- <finding with pointer>

## Minor
- <finding with pointer>

## Summary
- Container ↔ Component: PASS | FAIL (<count>)
- Components ↔ Dependency graph: PASS | FAIL (<count>)
- Dependency graph acyclic: PASS | FAIL
- Class ↔ Migration DDL: PASS | FAIL (<count>)
- ACs ↔ Sequences: PASS | FAIL (<count>)

Verdict: READY FOR APPROVAL | REVISIONS REQUIRED

Constraints

  • Read-only. Do not call Edit, Write, or Bash beyond reads.
  • Do not rewrite the spec or propose new diagrams. Name the inconsistency; the author fixes it.
  • If a check cannot run (e.g., no class diagram block), say so — do not fail silently and do not guess.
  • Keep the report under ~150 lines. Long reports get skimmed; tight ones get acted on.

Mechanical oracle (-d186)

oracle.mjs provides the artifact-backed checks that may block, distinct from this skill's LLM narrative review. Shipped this pass: DFS dependency-graph acyclicity — a cycle yields a finding carrying artifact{kind:'cycle', locus}. A finding blocks only when it carries an ArtifactRef and the tier dial marks the checker mandatory (resolveCheckerThreshold('spec-diagram')); otherwise it is ADVISORY. Relief valve: Container↔Component / class↔DDL / AC↔sequence consistency remain ADVISORY-only this pass, deferred to a follow-up. Per seed.md §II.A, oracle-bound checkers like this may fan out (parallel scripts).

レビュー

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

同じリポジトリのスキル

概要と使いどころ

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

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