ワンクリックで
checkpoint-summary
Summarize artifacts produced by §BRAND_BINARY_NAME§ agents for human checkpoint review
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Summarize artifacts produced by §BRAND_BINARY_NAME§ agents for human checkpoint review
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | checkpoint-summary |
| description | Summarize artifacts produced by §BRAND_BINARY_NAME§ agents for human checkpoint review |
| mode | pairing |
After agents complete a planning or writing phase (epic planning, story writing, spec generation), summarize their output so a human can efficiently review what was decided, what remains open, and where their attention is needed.
This skill answers: "What did the agents produce, what did they decide, and what do I need to weigh in on?"
The agents already did the work — planning, reviewing, approving. This skill reads their outputs and distills them into a checkpoint summary that respects the human's time.
Distinct from spec-review: spec-review audits spec quality. This skill summarizes what was already reviewed and approved, surfacing only what needs human judgment.
Use this skill when:
The single entry point is §BRAND_PROJECT_DIRNAME§/state.yaml — the source of truth for all §BRAND_NAME_TITLE§ state.
From state.yaml, the skill reads:
goal.spec_ref: the upstream source document the agents worked fromtasks[]: each task with its scope, status, output capabilities, approvals, and historytasks[].plan_ref / tasks[].arch_ref — task-level planning and architecture artifactstasks[].output[].plan_ref / tasks[].output[].arch_ref — output-entry artifactstasks[].spec_ref — task-level spec (may differ from goal.spec_ref)tasks[].approvals[]: review verdicts with provider/diversity context (canonical);
fall back to tasks[].approved_by if approvals[] is absenttasks[].history[]: full event timeline (claimed, checkpoint, submitted, approved, merged)sprint.status and sprint.checkpoint_trigger: why the checkpoint was triggeredNo other discovery is needed. Read every artifact file referenced by the ref fields above.
Read the upstream source (goal.spec_ref). Everything else is in the state file itself.
Read §BRAND_PROJECT_DIRNAME§/state.yaml to understand the full pipeline state: goal, tasks, agents,
sprint status, and checkpoint trigger.
Read the upstream source (goal.spec_ref) to understand what the agents were working
from — entities, decisions, constraints, interactions, scope boundaries.
Read all produced artifacts referenced by task-level refs (plan_ref, arch_ref)
and output-entry refs (output[].plan_ref, output[].arch_ref). Skip entries where
no ref field points to a file. For each artifact read:
tasks[].approvals[]; fall back to approved_by)tasks[].history[] (rejections, re-reviews, anomalies)From the artifacts and agent outputs, extract three categories:
Choices the agents made that the upstream source left open. For each:
Items that remain unresolved after the agent work:
Implementation risks the artifacts create or carry forward:
Not everything needs human attention. Classify each item:
| Priority | Meaning | Action needed |
|---|---|---|
| Decide | Human must make a choice before next phase starts | Present the decision with options |
| Confirm | Agents made a reasonable choice — human should validate | Present the decision, default is accept |
| Note | Worth knowing, no action needed | Include in summary, don't interrupt for it |
Prioritization heuristics:
Present in this format. Decide items first, then Confirm, then Notes.
# Checkpoint Summary: [Phase Name]
## Status
| Artifact | Scope | Verdict |
|----------|-------|---------|
| [name] | [one-line scope] | [Approved / Rejected / Conditional] |
> N decisions needing input · M items to confirm · K notes
## Decisions Needing Human Input
Items where the human must choose before the next phase starts.
### [Decision Title]
- **Context:** [What the upstream says or doesn't say]
- **Agent decision:** [What the agents chose]
- **Why it needs you:** [What makes this non-obvious — departure from upstream,
irreversible, low confidence, or gap]
- **Options:** [If applicable — confirm agent choice, override with X, or defer]
## Decisions to Confirm
Agents made reasonable choices. Confirm or override.
### [Decision Title]
- **Agent decision:** [What was chosen]
- **Rationale:** [Why it's reasonable]
- **Override if:** [When the human might want something different]
## Open Points
Unresolved items carried forward.
### [Item Title]
- **What's open:** [Description]
- **Impact:** [What's affected if unresolved]
- **Where it surfaces:** [Which artifacts reference this]
## Risks
### [Risk Title]
- **What could go wrong:** [Description]
- **Which artifacts:** [Where this risk lives]
- **Mitigation:** [If any exists in the plans, or "none specified"]
## Notes
Brief items worth knowing but not requiring action.
- [Item]: [One-line description]
| Skill | Relationship |
|---|---|
| epic-writing | Upstream producer. Summarize epic plans at the planning checkpoint. |
| user-story-writing | Upstream producer. Summarize stories at the story-writing checkpoint. |
| spec-review | Complementary. spec-review finds spec defects; this summarizes agent decisions. Different purposes, can run on the same artifacts. |
Pairing mode: Present the summary interactively. Walk through "Decide" items one at a time, collecting the human's decision before moving to the next. For "Confirm" items, present as a batch — the human can scan and override selectively. End with a count of decisions made and items still open.
§BRAND_NAME_TITLE§ mode: Checkpoint Summary operates autonomously within task scope. Write the
report to the worktree (e.g. docs/checkpoint-summary.md) and submit for review.
If any "Decide" items exist, mark BLOCKED with blocked_reason summarizing the
decisions needed and blocked_questions listing each one — the human must resolve
them before the next phase starts. If only "Confirm" and "Note" items exist, submit
normally.
| Pairing Prompt | §BRAND_NAME_TITLE§ Behavior |
|---|---|
| "N decisions need your input — walk through them?" | Mark BLOCKED; report in worktree |
| "Agents made N decisions — all look reasonable. Confirm?" | Submit for review; report in worktree |
| "No open points — ready for next phase" | Submit for review; report in worktree |
Generate and curate Claude-oriented bash-policy project rules. Use to run bash-policy export/report, review .bash-policy-candidates.yaml from Claude settings, update .bash-policy.yaml, normalize command-shape identities, or validate bash-policy configuration.
Assess whether an input document is ready for a specific §BRAND_NAME_TITLE§ MAS entry point. Use when a user asks whether a goal, functional spec, detailed spec, technical spec, PRD, story bundle, architecture plan, or other source document is solid enough to run through §BRAND_BINARY_NAME§ with `--entry-point general-objective`, `functional-spec`, `detailed-spec`, or `technical-spec`; when deciding which entry point fits a document; or before `§BRAND_BINARY_NAME§ init --spec`.
Coordinate Pairing-mode doer/reviewer sessions through a Markdown blackboard. Use when the user invokes /adversarial-pairing with role and blackboard-path arguments or asks multiple pairing agents to coordinate plan review, implementation, staged code review, and follow-up review rounds without §BRAND_NAME_TITLE§ multi-agent mode.
Define component boundaries, interfaces, and structural decisions for a change
Pre-commit Clean Code refactoring
Quantitative and qualitative code quality assessment with prioritized refactoring recommendations