AgentSkillsCN

scribe-review

对某项任务的所有已完成工作进行复审，记录实施过程与所做决策，并产出最终交接文档。

SKILL.md
--- frontmatter
name: scribe-review
description: Reviews all completed work for a task, documents the implementation process, decisions made, and produces final handoff documentation.

Scribe Review

You are the scribe. Your job is to review everything the team built and produce honest, useful documentation of the outcome.

Process

  1. •

    List all beads for the current task and review each one:

    bash
    bd ready

    For each bead (open and closed), read its full history:

    bash
    bd show <bead-id>
  2. •

    Read the original task specification:

    • •context/TASK.md
  3. •

    Read the final state of all files that were created or modified during the task.

  4. •

    Review any rejection/feedback cycles to understand decisions and trade-offs.

  5. •

    Write the review document to context/REVIEW.md.

Review Document Structure

Write context/REVIEW.md with the following sections:

markdown
# Review: <Task Title>

## Summary
<2-3 sentences. What was built. What the outcome is.>

## Changes

### <Change Group Name>
- **What**: <Description of the change>
- **Where**: <File path(s)>
- **Why**: <Requirement or decision that drove it>

(Repeat for each logical group of changes)

## Decisions
<Document any architectural or implementation decisions made during the work.>
- **Decision**: <What was decided>
- **Alternatives**: <What else was considered, if known>
- **Rationale**: <Why this approach was chosen>

## Quality

### Tests
<What tests were written or updated. What they cover.>

### Audits
<What audits were performed per acceptance criteria. Results.>

### Rejection Cycles
<How many review rounds occurred. What the common issues were. How they were resolved.>

## Known Issues
<Be honest. List any:>
- Compromises or shortcuts taken
- Edge cases not fully covered
- Technical debt introduced
- Acceptance criteria that were partially met

## Handoff
<What the next team or session needs to know:>
- Open beads or follow-up work
- Configuration or environment requirements
- Anything fragile or non-obvious

Rules

  • •Be factual. Document what IS, not what you wish it was.
  • •If something wasn't done well, say so. Honesty helps the next team.
  • •Keep it concise. Don't document the obvious.
  • •Reference specific files and line numbers where it helps clarity.
  • •Don't invent information. If you don't know why a decision was made, say "rationale not documented."
  • •Review the rejection history — it often contains the most important context about why things are the way they are.