AgentSkillsCN

technical-review

根据计划任务与验收标准，对已完成的实施进行验证。在以下情况时使用此功能：(1) 实施已完成；(2) 用户希望在合并或交付前进行验证；(3) 实施完成后需要进行质量门检查。对计划的所有任务进行审查，确保实施的正确性、测试的充分性以及代码的质量。生成结构化的反馈意见（批准、要求修改或提出建议）——但不会直接修复代码。

SKILL.md
--- frontmatter
name: technical-review
description: "Validate completed implementation against plan tasks and acceptance criteria. Use when: (1) Implementation is complete, (2) User wants validation before merging/shipping, (3) Quality gate check needed after implementation. Reviews ALL plan tasks for implementation correctness, test adequacy, and code quality. Produces structured feedback (approve, request changes, or comments) - does NOT fix code."
user-invocable: false

Technical Review

Act as a senior software architect with deep experience in code review. You haven't seen this code before. Your job is to verify that every plan task was implemented correctly, tested adequately, and meets professional quality standards — then assess the product holistically.

Purpose in the Workflow

This skill can be used:

  • •Sequentially: After implementation of a planned feature
  • •Standalone (Contract entry): To review any implementation against a plan

Either way: Verify plan tasks were implemented, tested adequately, and meet quality standards — then assess the product holistically.

What This Skill Needs

  • •Review scope (required) - single, multi, or all
  • •Plan content (required) - Tasks and acceptance criteria to verify against (one or more plans)
  • •Specification content (optional) - Context for design decisions

Before proceeding, verify the required input is available. If anything is missing, STOP — do not proceed until resolved.

  • •

    No plan provided?

    "I need the implementation plan to review against. Could you point me to the plan file (e.g., docs/workflow/planning/{topic}.md)?"

  • •

    Plan references a specification that can't be found?

    "The plan references a specification but I can't locate it at the expected path. Could you confirm where the specification is? I can proceed without it, but having it provides better context for the review."

The specification is optional — the review can proceed with just the plan.

Resuming After Context Refresh

Context refresh (compaction) summarizes the conversation, losing procedural detail. When you detect a context refresh has occurred — the conversation feels abruptly shorter, you lack memory of recent steps, or a summary precedes this message — follow this recovery protocol:

  1. •Re-read this skill file completely. Do not rely on your summary of it. The full process, steps, and rules must be reloaded.
  2. •Read all tracking and state files for the current topic — plan index files, review tracking files, implementation tracking files, or any working documents this skill creates. These are your source of truth for progress.
  3. •Check git state. Run git status and git log --oneline -10 to see recent commits. Commit messages follow a conventional pattern that reveals what was completed.
  4. •Announce your position to the user before continuing: what step you believe you're at, what's been completed, and what comes next. Wait for confirmation.

Do not guess at progress or continue from memory. The files on disk and git history are authoritative — your recollection is not.

Hard Rules

  1. •Review ALL tasks — Don't sample; verify every planned task
  2. •Don't fix code — Identify problems, don't solve them
  3. •Don't re-implement — You're reviewing, not building
  4. •Be specific — "Test doesn't cover X" not "tests need work"
  5. •Reference artifacts — Link findings to plan/spec with file:line references
  6. •Balanced test review — Flag both under-testing AND over-testing
  7. •Fresh perspective — You haven't seen this code before; question everything

Output Formatting

When announcing a new step, output ── ── ── ── ── on its own line before the step heading.

Step 1: Read Plan(s) and Specification(s)

Read all plan(s) provided for the selected scope.

For each plan:

  1. •Read the plan — understand phases, tasks, and acceptance criteria
  2. •Read the linked specification if available — load design context
  3. •Extract all tasks across all phases

If no specification exists, the plan is the sole source of truth for design decisions.

→ Proceed to Step 2.

Step 2: Project Skills Discovery

If .claude/skills/ does not exist or is empty

code
No project skills found. Proceeding without project-specific conventions.

→ Proceed to Step 3.

If project skills exist

Scan .claude/skills/ for project-specific skill directories. Note which are relevant to the review (framework guidelines, code style, architecture patterns).

→ Proceed to Step 3.

Step 3: QA Verification

Load invoke-task-verifiers.md and follow its instructions as written.

STOP. Do not proceed until ALL task verifiers have returned and findings are aggregated.

→ Proceed to Step 4.

Step 4: Product Assessment

Load invoke-product-assessor.md and follow its instructions as written.

STOP. Do not proceed until the product assessor has returned.

→ Proceed to Step 5.

Step 5: Produce Review

Aggregate findings from both stages into a review document using the template.md.

Write the review to docs/workflow/review/{topic}.md (single) or docs/workflow/review/{scope-description}.md (multi/all).

QA Verdict (from Step 3):

  • •Approve — All acceptance criteria met, no blocking issues
  • •Request Changes — Missing requirements, broken functionality, inadequate tests
  • •Comments Only — Minor suggestions, non-blocking observations

Product Assessment (from Step 4) — always advisory, presented alongside the verdict.

Commit: review({topic}): complete review

Present the review to the user.

Your review feedback can be:

  • •Addressed by implementation (same or new session)
  • •Delegated to an agent for fixes
  • •Overridden by user ("ship it anyway")

You produce feedback. User decides what to do with it.

References