check-completion（检查完成情况）

Check Completion

Two-phase skill. Phase 1 — Audit: scan the execution history, classify every task into one of 22 statuses, deliver a markdown audit table with evidence per row. Phase 2 — Remediate: execute against the audit until every in-scope task reaches a terminal status — Implemented for work finished, or one of the deliberate-stop statuses (Deferred to Human, Deprioritized, Cancelled, Out of Scope, Superseded with replacement verified, or Blocked — unresolvable with a concrete next step). No mid-task pauses. No defaulting to Implemented on faith.

Trigger boundary

Use this skill when the task is to:

• audit what's been done vs. what was claimed done at the end of a session, a plan, or a branch of work
• produce a status-report on a project / sprint / multi-step task, with evidence per item
• convert a casual "are we done?" question into a rigorous completion audit
• catch silent gaps — tasks that were started, assumed complete, deferred, or forgotten
• recover from a crashed / interrupted / half-finished execution by enumerating what remains

Prefer another skill when:

• verifying a single claim before making it → verification-before-completion pattern (inlined here for audit gates, but for a per-commit gate use that style directly)
• evaluating external review feedback (not internal audit) → evaluate-code-review
• planning upcoming work → plan-*, run-issue-tree, or the obra writing-plans pattern
• reviewing someone else's PR → do-review

Non-negotiable rules (discipline)

1. Two phases, not one. The audit table is produced first, as a discrete artifact. Remediation starts only after the table exists. Do not quietly fix things while auditing — that defeats the audit.
2. Never default to Implemented. If there is any doubt, the task is not Implemented. Pick the most-pessimistic applicable status from references/status-taxonomy.md.
3. Assumed Complete is not safe. Treat it as suspect. Every Assumed Complete row requires a follow-up verification or a status downgrade.
4. Every non-Implemented row has a concrete action required. Vague follow-ups ("revisit later") are failures. State what to run, what to check, what to decide.
5. Evidence before status. Each Implemented row names the specific evidence (test output, commit SHA, file state, observed behavior). No evidence → no Implemented.
6. Remediation order is blockers → broken → missing → untested. Not the order the tasks were written.
7. Remediation does not pause mid-task for confirmation. The only halt conditions: (a) the work is complete, (b) a blocker is genuinely unresolvable and has been documented with a concrete next step.
8. Terminal state is total coverage. Every in-scope task ends at a terminal status per status-taxonomy.md: Implemented (work done with evidence), Deferred to Human / Deprioritized / Cancelled / Out of Scope (deliberate stop with rationale), Superseded (replacement verified Implemented), or Blocked — unresolvable (with concrete next step per blocker-handling.md). Rows left at non-terminal statuses (e.g., Partially Implemented, Stalled) are a failure of this skill.

The 22-status taxonomy

Every task gets exactly one status from this list. Full definitions + detection rules + evidence patterns are in references/status-taxonomy.md.

If tempted to invent a status: don't. Pick the closest existing one and explain the borderline in the Evidence column.

Required workflow

Phase 1 — Audit

1. Disambiguate scope

Before enumerating tasks, state clearly what "in scope" means for this audit. See references/scope-disambiguation.md.

Options:

• Session scope — everything this conversation has been asked to do
• Plan scope — the tasks in a specific plan file or TodoList
• Branch scope — everything on the current git branch since it diverged
• PR scope — the commits + TODO comments + linked issues on an open PR
• Custom scope — an explicit list the user provided

If the user did not name a scope, pick the most comprehensive one that still produces a finite task list, and state the choice.

2. Enumerate tasks from all sources

Scan the six audit sources. See references/audit-sources.md for extraction recipes per source.

Combine the extractions into a deduplicated flat list. Do not skip any source — silent sources become silent gaps.

3. Classify each task

For each task, run the Gate Function (adapted from obra/verification-before-completion):

For status = `Implemented`:
  1. IDENTIFY what evidence would prove this task is complete
  2. RUN the verification (or locate the existing evidence in this session)
  3. READ the output / diff / state
  4. VERIFY the evidence matches the task
  5. ONLY THEN assign `Implemented`

For any other status:
  - Pick the most-pessimistic applicable status
  - Cite the specific evidence that rules out `Implemented`

See references/evidence-patterns.md for what "real evidence" looks like per status class. See references/ruthless-auditing.md for the discipline of distrust.

4. Deliver the audit table

Output format:

## Audit

Scope: <which scope + source list>
Sources scanned: <6 sources with one-line summary each>

| # | Task | Status | Evidence | Blocking? | Action Required |
|---|------|--------|----------|-----------|-----------------|
| 1 | <task> | `Implemented` | <evidence citation> | No | — |
| 2 | <task> | `Implemented but Broken` | <evidence + what broke> | No | Fix <specific failure>; re-run <command> |
| 3 | <task> | `Blocked` | <what's blocking> | Yes | <concrete next step to unblock> |
| … | … | … | … | … | … |

Every non-Implemented row MUST have an Action Required. Blocking tasks (Yes in Blocking column) rise to the top of Phase 2.

See references/output-format.md for full formatting rules.

Phase 2 — Remediate

5. Execute in priority order

1. Blockers — resolve, or document why unresolvable
2. `Implemented but Broken` / `Implemented but Outdated` — fix regressions
3. `Incorrectly Implemented` — correct misunderstandings
4. `Stalled` / `Crashed` / `Timed Out` — re-spawn and complete
5. `Partially Implemented` — finish edge cases, error handling, sub-steps
6. `Forgotten` / `Not Planned` (relevant) / `Planned / Queued` — implement
7. `Implemented but Untested` / `Assumed Complete` — verify (retest, re-run, confirm)
8. `Skipped` (no valid reason) — either implement or change status to `Out of Scope` with rationale
9. `Ambiguous` — resolve the ambiguity (ask or pick with justification) then execute
10. `Duplicate` — verify the canonical version is `Implemented`; mark the duplicate as `Superseded` with the canonical reference
11. `Superseded` — verify replacement is `Implemented`; if not, recurse on the replacement
12. `Deferred to Human` / `Deprioritized` / `Cancelled` — document and leave as terminal

See references/remediation-workflow.md for the full order + one-at-a-time discipline.

6. Handle blockers surgically

A blocker that cannot be resolved does not justify halting remediation. Document it, then continue with everything else.

See references/blocker-handling.md for the blocker-documentation format and how to judge "genuinely unresolvable" vs. "I just don't want to deal with it."

7. Deliver the completion report

After remediation, produce the completion report — the audit table with every row updated to its terminal status.

## Completion Report

Started: <N tasks audited, M needing remediation>
Finished: <X now Implemented, Y unresolvable (documented), Z out of scope>

| # | Task | Started | Ended | Evidence |
|---|------|---------|-------|----------|
| 1 | <task> | `Implemented but Broken` | `Implemented` | <test output showing green> |
| 2 | <task> | `Blocked` | `Blocked — unresolvable` | <next step documented> |
| … | … | … | … | … |

Every row ends at a terminal status: Implemented, or explicit-unresolvable-with-next-step.

Output contract

Produce artifacts in this order — no batching, no skipping:

1. Scope declaration (after Step 1)
2. Source-scan summary (after Step 2) — one line per source with counts or "no results"
3. Phase 1 audit table (after Step 4) — the full markdown table, delivered as a discrete artifact before any remediation begins
4. Remediation log (during Step 5-6) — per-task "Fixed X by Y, evidence: Z" entries
5. Blocker documentation (as they arise in Step 6)
6. Phase 2 completion report (after Step 7) — the final table with every row at its terminal status

Phase 1 (artifact 3) and Phase 2 (artifact 6) are the two headline deliverables. Everything else is supporting.

Rationalizations to counter (RED baseline, abridged)

Agents under pressure default to Implemented. The counters:

Full table + pressure scenarios: references/rationalizations.md.

Do this, not that

Guardrails and recovery

• Do not deliver the completion report without the audit table preceding it.
• Do not claim Implemented without running the specific verification this message.
• Do not default Assumed Complete rows to Implemented when retesting — pick the actual terminal state.
• Do not leave rows at non-terminal statuses (Partially Implemented, Stalled, etc.) in the completion report.
• Do not pause mid-Phase-2 for confirmation; resolve blockers or document and continue.

Recovery moves:

• Source scan is taking too long — set a budget (e.g., 10 minutes per source). If a source is producing noise with no signal, document and move on.
• Too many tasks (100+) — re-disambiguate scope; split into sub-audits if truly that many.
• Audit revealed the scope itself was wrong — pause once, re-scope, restart Phase 1.
• Remediation keeps surfacing new tasks — each new task gets added as a new row in the audit table with a status; then continues through remediation. Do not let scope creep silently.

Reference routing

Final checks

Before declaring done, confirm:

• scope declared and matches the user's ask
• all 6 audit sources scanned (or explicitly marked unavailable)
• audit table delivered as a discrete artifact before any remediation
• every row has exactly one of the 22 statuses (no invented statuses, no multi-status cells)
• every non-Implemented row has a concrete Action Required
• every Implemented row cites specific evidence (command output, commit SHA, file state, observable behavior)
• blockers documented with concrete next steps; remediation did not halt on first blocker
• completion report shows every row at a terminal status
• zero forbidden phrases in the report (grep-checked)
• rationalizations table consulted before declaring "everything looks done"