Agent-Skills.md

Agent Skills: Technical Review

Validate completed implementation against plan tasks and acceptance criteria. Sixth phase of research-discussion-specification-plan-implement-review workflow. Use when: (1) Implementation phase 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.

quality-gatescode-qualitypull-requestacceptance-criteriaimplementation-validation
reviewID: leeovery/claude-technical-workflows/technical-review

Repository

leeovery/claude-technical-workflows
leeoveryLicense: MIT
9

Install this agent skill to your local

pnpm dlx add-skill https://github.com/leeovery/claude-technical-workflows/tree/HEAD/skills/technical-review

Skill Files

Browse the full folder contents for technical-review.

Download Skill

Loading file tree…

skills/technical-review/SKILL.md

Skill Metadata

Name
technical-review

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.

If no plan provided

Output the next fenced block as a code block:

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

STOP. Wait for user response.

If plan references a specification that can't be found

Output the next fenced block as a code block:

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.

STOP. Wait for user response.

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

If review mode is "analysis-only"

Analysis of existing review findings was requested. The review has already been completed.

→ Proceed to Step 6.

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

Output the next fenced block as a code block:

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: Produce Review

Load produce-review.md and follow its instructions as written.

→ Proceed to Step 5.

Step 5: Review Actions

Load review-actions-loop.md and follow its instructions.