菜单
Run the dev-spec-kit learning loop — capture lessons after a feature/incident into .dev-spec-kit/learnings.md, propose promotions into the laws, and turn fixed bugs into permanent regression checks. Use after completing a feature, after any surprising failure, or when the user says retro.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | dev-spec-kit-retro |
| description | Run the dev-spec-kit learning loop — capture lessons after a feature/incident into .dev-spec-kit/learnings.md, propose promotions into the laws, and turn fixed bugs into permanent regression checks. Use after completing a feature, after any surprising failure, or when the user says retro. |
A lesson only counts once it is PROMOTED (into the laws) or HARDENED (into a permanent check). Logged-but-unpromoted lessons recur — that is the failure mode this loop exists to kill.
.dev-spec-kit/learnings.md — append-only, data not code)## <YYYY-MM-DD> <short title>
- Trigger: <what happened — one line, concrete>
- Lesson: <what we now know>
- Confidence: low | medium | high (evidence-based: how often observed, was it reproduced?)
- Scope: project | global (global only after the pattern recurs in 2+ projects)
- Promoted to: laws#<section> | check:<ref> | OPEN
Instinct mechanics: a lesson starts Confidence: low, Scope: project. Reproduction or recurrence
raises confidence; recurrence in a SECOND project earns Scope: global (move/copy it to the
personal default rules so every project inherits it). Confidence is evidence, not feeling — and
confidence is not approval: promotion still requires the human gate, and a promoted rule must
beat the incumbent behavior, not merely sound right.
.dev-spec-kit/laws.md (quote the exact wording).@check to the relevant
requirement so it joins the graph forever. A bug that can come back silently was never fixed..dev-spec-kit/config.json) — never a code change to the tool.OPEN until promoted; strike through (learnings.md for OPEN entries and warn when the
current task pattern-matches a known mistake (the repeat-warning).learning.share); do not export without being asked.Build, refresh, and read dev-spec-kit's Verified Traceability Graph — provider-agnostic. Keep it fresh with the build wrapper, read blast radius / implements-edges / drift to answer "what breaks if this changes?", and run the staleness re-prove dance. For choosing and configuring the code-graph engine itself, see the dev-spec-kit-revitify and dev-spec-kit-graphify skills.
dev-spec-kit's optional code-graph provider — the external Python graphify tool (multi-modal: indexes PDFs, images, and video alongside code). Opt-in only. Use to decide when graphify is worth its install over the bundled revitify default, how to install and configure it, and how dev-spec-kit verifies and falls back when it is absent. For the build/read loop itself, see dev-spec-kit-graph.
dev-spec-kit's default code-graph provider — the bundled revitify engine (native TypeScript, tree-sitter multi-language). Zero install, zero API key, always available. Use to understand when revitify is the right provider, how it is configured, what it can and cannot index, and how it feeds the Verified Traceability Graph. For the build/read loop itself, see dev-spec-kit-graph.
Drive spec-driven development with dev-spec-kit — route the request, write EARS specs with @check bindings, derive evidence-bound tasks, TDD, prove checks with real test runs, build the Verified Traceability Graph, record approvals, and generate graph-derived PR bodies. Use whenever the user asks to build/change code in a dev-spec-kit-initialized project (.dev-spec-kit/ present) or mentions rivet, specs, EARS, or traceability.
Score each requirement's complexity 1–10 and recommend a subtask breakdown, then expand the over-scoped ones into bound sub-criteria. Use after a spec is drafted and before implementation, to catch requirements that are too big to prove as a single unit.
Turn approved requirements into a thin high-level design and the Architecture Decision Records (ADRs) that justify the non-obvious choices. Use after requirements are clarified and before implementation, or when a change makes a load-bearing architectural decision.