critic

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

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

1. If branch is main:
2. Check session context for which task is being discussed (most reliable signal)
3. Check git log --oneline -5 for recent task transitions
4. Scan active status directories (0-inbox/, 1-speccing/, 2-planning/, 3-plan-review/, 4-implementing/, 5-reviewing/) for tasks
5. Cross-reference all signals
6. If task in 4-implementing/ while on main → soft warning (S9): suggest switching to feature branch
7. If exactly one active task → use it, infer phase from status directory
8. If multiple active tasks and signals don't disambiguate → ask the user
9. If no active tasks → ask the user
10. If task is in 0-inbox/ → not a critic phase — return immediately with no output (inbox operations don't trigger critic)
11. 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
12. 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

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

1. 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-clip