goalpost:review

/goalpost:review ""

You are handling the /goalpost:review slash command. The operator wants a goal-grounded review of a specific target.

Your job

1. Extract the target from the operator's invocation. The target may be:

   • A file path (e.g., packages/api/lib/auth.ts)
   • A directory (e.g., apps/app/components/)
   • A PR number (e.g., #1234)
   • A commit range (e.g., HEAD~5..HEAD)
   • Any other scope description the operator provides

   If no target is given, ask the operator for one. Do NOT default to "the whole repo" — the review must be scoped to make Step 1 (goal trace) tractable.

2. Run the helper script to compose the dispatch prompt:

   "${CLAUDE_PLUGIN_ROOT}/scripts/skill-review.sh" "<target>"
   

   This script does NOT require GOALPOST_SKILL_ACTIVE=1 — it is read-only.

3. Handle the script's exit code:

   • Exit 1, "no goal set": report this to the operator and stop. The skill cannot run without an active goal. Suggest /goalpost:set "<goal>" first.
   • Exit 1, "goal already complete": report this and stop. Suggest /goalpost:set "<new goal>" to begin a new task before reviewing.
   • Exit 2: usage error (missing or empty target). Report and ask for a target.
   • Exit 0: the script wrote the structured dispatch prompt to stdout. Capture this output exactly.

4. Dispatch a subagent via the Agent tool:

   • Use subagent_type: general-purpose
   • Use the captured stdout (the structured prompt) as the prompt parameter verbatim
   • Use a descriptive description like "goal-grounded review of "
   • Wait for the subagent's result before responding to the operator.

5. Report the subagent's findings to the operator verbatim. Do NOT summarize or paraphrase. The structured Goal Trace + Findings + Verdict format is the deliverable.

Rules

• Do not skip the helper script. The dispatch prompt is composed by the script so the protocol stays consistent across reviews.
• Do not modify the dispatch prompt. Feed it to the Agent tool verbatim. Modifying it defeats the goal-grounded protocol.
• Do not perform the review yourself. This skill is a dispatcher, not a reviewer. The fresh-context subagent does the review. Reviewing it yourself in the current session defeats the entire premise (per catalog P-025: writer cannot review their own artifact, applied here at the session level).
• Do not summarize the findings. The classification schema (FIX | QUALITY | NONE) and the per-step trace are the operator's evidence. Summarizing loses information.
• Do not approve based on the subagent's verdict. Reporting "subagent says approved" is fine. Saying "I agree, looks good" without your own evidence is exactly the sycophancy framing this skill exists to break.

Why this skill exists

Code review traditionally asks "is this code good?" — a sycophancy-inviting framing where the reviewer pattern-matches positive examples from training data. This skill asks "does this code complete the user's stated goal end-to-end, and where does it fall short of the engineering rubric?" — a falsifiable framing where the answer is either "yes with these citations" or "no with these specific gaps."

The two-step order is load-bearing: goal trace BEFORE rubric grading. A codebase that fails to complete the goal has bigger problems than rubric violations. A codebase that meets the rubric but doesn't complete the goal is solving the wrong problem cleanly. Step 1 catches the latter; Step 2 catches everything else.

The fresh-context dispatch is non-negotiable per the same logic — the current session has already accumulated bias toward "this work is on track." The fresh agent has no such bias.