Critic Skill

Self-review at every task lifecycle phase. Invoked via /critic.

---

Phase Inference

The collector has full session context — it can see what commands were just run, what task is being discussed, and what the user asked for. It also uses filesystem/git state for robustness.

Algorithm

1. Run git branch --show-current to get the current branch name

2. If branch matches feature/task-<N>-*:

   • Extract task ID <N>
   • Read .tasks/*/N/task.md to get current status
   • Check git diff --name-only HEAD for uncommitted changes
   • Check git diff --name-only main...HEAD for all branch changes
   • Map to phase:
     • Status implementing + uncommitted changes → Phase 6: During implementation
     • Status implementing + no uncommitted changes + git diff --name-only main...HEAD has non-.tasks/ files → Phase 6 (between changes)
     • Status implementing + no uncommitted changes + only .tasks/ files changed → Phase 5: Starting implementation
     • Status reviewing → Phase 7: Submitting for review

3. If branch is main:

   • Check session context for which task is being discussed (most reliable signal)
   • Check git log --oneline -5 for recent task transitions
   • Scan active status directories (0-inbox/, 1-speccing/, 2-planning/, 3-plan-review/, 4-implementing/, 5-reviewing/) for tasks
   • Cross-reference all signals
   • If task in 4-implementing/ while on main → soft warning (S9): suggest switching to feature branch
   • If exactly one active task → use it, infer phase from status directory
   • If multiple active tasks and signals don't disambiguate → ask the user
   • If no active tasks → ask the user
   • If task is in 0-inbox/ → not a critic phase — return immediately with no output (inbox operations don't trigger critic)
   • If task is in 1-speccing/ → not a critic phase during interactive solicitation — return immediately with no output. Exception: when /tasks plan is invoked on a speccing task, run Phase 1 (speccing exit gate) checks
   • Status-to-phase: 1-speccing (via /tasks plan) → Phase 1, 2-planning → Phase 2/3/4, 3-plan-review → Phase 4, 4-implementing → Phase 5/6, 5-reviewing → Phase 7/8

4. Disambiguating planning sub-phases (2, 3, 4):

   • Task in 2-planning/ with empty plan.md skeleton → Phase 2 (starting planning)
   • Task in 2-planning/ with plan.md content, uncommitted changes → Phase 3 (writing a plan)
   • Task in 2-planning/ with plan.md content, no uncommitted changes → Phase 4 (presenting plan for review)

5. If ambiguous at any step → ask the user. Never guess.

---

Collector Checks (Session-Aware)

These checks are only possible in-context because they require session visibility.

Anti-Grep Check

Review the conversation history. For each file central to the current work, determine: was it opened with the Read tool (full file), or only found via Grep/Glob? Build a list of files-read and files-only-grepped. Any file being modified that was only grepped is a hard block (H11).

Counter-Sycophancy Check

Review the conversation for pushback — did the user disagree with an approach? If so, check: did Claude evaluate the feedback against evidence, or did it just agree? If Claude immediately agreed without defending the original with evidence, flag it (S10). The reverse: did the user suggest something that contradicts CLAUDE.md or the plan? If so, was it flagged? Silence is not compliance.

Evidence Gathering

Search the conversation for build/test command outputs. For TypeScript changes: was npm test, npm run typecheck:plugin, or npm run build:plugin actually executed? For prompt-only changes (.md files): were structural checks done (file exists, under 500 lines, frontmatter valid)? Collect the actual outputs. "I think it works" is not evidence.

Degradation Detection

Look for signs of context window exhaustion: placeholder code (// TODO: implement), sparse implementations, ... or /* rest unchanged */ comments, repeated similar errors, retrying the same approach. If detected, flag as soft warning (S8) and recommend context reset.

Confidence Calibration

For each finding, rate confidence based on what was actually verified (read the file, ran the command) vs assumed (inferred from patterns, didn't check). Low-confidence findings are explicitly flagged to the user.

---

Brief Generation

After running collector checks, write a structured brief to .temp/<datetime>-critic-brief-<task-id>.md (e.g., .temp/2026-02-13-1530-critic-brief-107.md). Get the datetime by running date -u +"%Y-%m-%d-%H%M" — never guess or fabricate timestamps.

## Critic Brief

**Task:** #<id> — <title>
**Phase:** N — <phase name>
**Branch:** <branch name>
**Plan file:** <path to plan.md>
**Task file:** <path to task.md>

### Session Signals

**Files fully read:** [list of paths opened with Read tool]
**Files only grepped:** [list of paths only found via Grep, not fully read]
**User pushback:** [yes/no — if yes, summary of what was challenged and how resolved]
**Build/test evidence:** [command outputs collected, or "not run"]
**Uncommitted changes:** [yes/no]

### Collector Findings

[Anti-grep violations, sycophancy signals, degradation signals, evidence gaps]

### Phase-Specific Review Request

[What the reviewer should focus on for this phase]

### Learned Patterns

[Relevant rules from .critic/ files for this phase]

---

Launching the Reviewer

After writing the brief, launch the forked reviewer. Inject the actual brief file path into the reviewer prompt:

Task(
  subagent_type: "general-purpose",
  description: "Critic reviewer — fresh-context code review",
  prompt: [contents of resources/reviewer-prompt.md with actual brief path injected,
           e.g. replace the placeholder with ".temp/2026-02-13-1530-critic-brief-107.md"]
)

The reviewer runs with fresh context — no conversation history, no confirmation bias. It reads the brief, the code, the plan, and the diff, then produces a structured report.

If the reviewer fails or times out: Present the collector's own findings with a note that the reviewer was unavailable.

---

Combined Output

After the reviewer returns its report, combine both into a single output:

## Critic Self-Review — Phase N: [Phase Name]

**Task:** #<id> — <title>

### Session Checks (collector — in-context)

- [x] Anti-grep: 5 of 5 files fully read ✓
- [!] Counter-sycophancy: User pushed back on X, Claude agreed without evidence — verify
- [x] Build evidence: npm test output captured ✓

### Code Review (reviewer — fresh context)

#### Hard Blocks (must resolve before proceeding)

1. **[Finding title]** [H-ID] [CONFIDENCE: high/medium/low]
   - What: [specific finding]
   - Evidence: [what was checked]
   - Action: [what must happen]

#### Soft Warnings (noted, not blocking)

1. **[Finding title]** [S-ID] [CONFIDENCE: high/medium/low]
   - What: [specific finding]
   - Note: [suggestion]

### Checks Passed

- [x] [Check description] — [brief evidence]

### Learned Patterns Applied (from .critic/)

- Applied rule from `.critic/planning.md`: "[rule text]"

If there are hard blocks: "BLOCKED — resolve the above before proceeding." If no hard blocks: "CLEAR — proceed with noted warnings."

Challenge Prompt

Always end the critic output with a single ready-to-use challenge prompt the user can throw back at Claude to force deeper verification. This is a prompt the user gives TO Claude — it challenges Claude's work, not the user's judgement.

The prompt should be a single block of text covering as many points as needed — every finding, every area of low confidence, every unverified claim. Don't split it into separate prompts. One prompt, all the pressure.

Format: Present the challenge prompt inside a fenced code block (triple backticks) so the user gets a copy-to-clipboard button in the IDE. Do NOT use blockquotes — use a code block.

Generate the prompt tailored to the current phase, findings, and areas of low confidence. Example:

Are you sure you're done? Walk me through every acceptance criterion and show me evidence — not assertions — that each one is met. Did you actually read [specific file] or are you assuming you know what's in it? Show me the part that confirms [specific claim]. The plan says to modify [file list] — show me exactly what changed and why each change is justified. You said [check] passed — prove it, what command did you run and what was the output? What would break if I reverted [specific file]? If nothing, why did you change it? Did you miss anything? Did you break anything? Verify.

Don't generate a generic prompt. Reference actual files, acceptance criteria, and specific areas where the critic had medium or low confidence.

Critical rule: The critic NEVER auto-fixes. All findings go to the human for decision.

---

.critic/ Integration

After inferring the phase, read the .critic/ file matching the current status and include relevant rules in the brief for the reviewer:

Phase	.critic/ file
1 (speccing exit)	speccing.md
2-4 (planning)	planning.md
5-6 (implementing)	implementation.md
7 (review)	review.md
8 (completion)	completion.md

---

Thought Depth Escalation

Not all checks need the same level of analysis:

• Quick — surface-level structural checks. File exists? Frontmatter valid? Line count under limit? Branch name correct?
• Standard — routine checks requiring modest reasoning. Diff audit file list comparison, plan coverage check.
• Deep (think hard) — potential hard blocks, multi-file cross-referencing. Standards contradiction analysis, acceptance criteria verification.
• Ultra (think harder) — architectural decisions, plan-vs-implementation semantic comparison. Reserved for Phase 4 (full plan review), Phase 7 (pre-review audit), and low-confidence high-stakes findings.

The escalation matrix in escalation.md annotates each check with its default depth. Escalate when a lower-depth check surfaces something suspicious.

---

Resource Files

• reviewer-prompt.md — Prompt for the forked reviewer subagent
• phases.md — Detailed checks for all lifecycle phases
• escalation.md — Hard block vs soft warning classification criteria
• feedback-loop.md — Rules for maintaining the .critic/ learning directory