bmad-checkpoint-preview
LLM-assisted human-in-the-loop review. Make sense of a change, focus attention where it matters, test. Use when the user says "checkpoint", "human review", or "walk me through this change".
- License 许可
- MIT
- 最近更新
- 2026-08-19
- Stars
- ★ 4
- Forks
- 0
01 前言 Front Matter
- name
- bmad-checkpoint-preview
- description
- LLM-assisted human-in-the-loop review. Make sense of a change, focus attention where it matters, test. Use when the user says "checkpoint", "human review", or "walk me through this change".
02 资源文件 7
- 其他customize.toml1.6 KB
- 参考文档generate-trail.md1.9 KB
- 参考文档step-01-orientation.md4.9 KB
- 参考文档step-02-walkthrough.md4.1 KB
- 参考文档step-03-detail-pass.md4.9 KB
- 参考文档step-04-testing.md2.6 KB
- 参考文档step-05-wrapup.md1.5 KB
03 SKILL.md 正文
Checkpoint Review Workflow
Goal: Guide a human through reviewing a change — from purpose and context into details.
Your Role: You are assisting the user in reviewing a change.
Conventions
- Bare paths (e.g.
step-01-orientation.md) resolve from the skill root. {skill-root}resolves to this skill's installed directory (wherecustomize.tomllives).{project-root}-prefixed paths resolve from the project working directory.{skill-name}resolves to the skill directory's basename.
On Activation
Step 1: Resolve the Workflow Block
Run: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow
If the script fails, resolve the workflow block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
{skill-root}/customize.toml— defaults{project-root}/_bmad/custom/{skill-name}.toml— team overrides{project-root}/_bmad/custom/{skill-name}.user.toml— personal overrides
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by code or id replace matching entries and append new entries, and all other arrays append.
Step 2: Execute Prepend Steps
Execute each entry in {workflow.activation_steps_prepend} in order before proceeding.
Step 3: Load Persistent Facts
Treat every entry in {workflow.persistent_facts} as foundational context you carry for the rest of the workflow run. Entries prefixed file: are paths or globs under {project-root} — load the referenced contents as facts. All other entries are facts verbatim.
Step 4: Load Config
Load config from {project-root}/_bmad/bmm/config.yaml and resolve:
implementation_artifactsplanning_artifactscommunication_languagedocument_output_language
Step 5: Greet the User
Greet the user, speaking in {communication_language}.
Step 6: Execute Append Steps
Execute each entry in {workflow.activation_steps_append} in order.
Activation is complete. Begin the workflow below.
Global Step Rules (apply to every step)
- Path:line format — Every code reference must use CWD-relative
path:lineformat (no leading/) so it is clickable in IDE-embedded terminals (e.g.,src/auth/middleware.ts:42). - Front-load then shut up — Present the entire output for the current step in a single coherent message. Do not ask questions mid-step, do not drip-feed, do not pause between sections.
- Language — Speak in
{communication_language}. Write any file output in{document_output_language}.
FIRST STEP
Read fully and follow ./step-01-orientation.md to begin.
04 同仓库更多 Skills
help
Fixture help skill
verification-before-completion
Use when checking fixes, phase exits, completion evidence, or mock-heavy tests before claiming success.
triage
Use when a large feature should be decomposed into dependency-aware specs.
tasks
Use when a spec has design.md and needs implementation tasks.
switch
Use when changing the active spec by name or path.
status
Use when inspecting curdx-flow specs, active state, progress, or index status.