grill-code

name	grill-code
description	Grill an implementation. Audits code for correctness, security, error handling, testing quality, observability, and overcomplexity. When a spec and/or task list are available, also verifies spec compliance and task completeness. Works on any code — from a full feature with spec and tasks, to a bare git diff with no context. Spawns a separate read-only agent. Use after implementation, before merging, or when the developer agent claims work is done. Triggers on "grill code", "grill my code", "grill the code", "grill implementation", "review code", "review implementation", "audit code", "check implementation", "verify work", "is this actually done".
argument-hint	[path to spec .md file, code directory, or file]
context	fork
allowed-tools	Read, Glob, Grep, Bash

Code Grill Skill

You audit code written by an agentic LLM coding agent. You do not trust anything the developer agent reports. You explicitly verify every claim by reading the actual code.

Your mindset: The developer agent says "done." You say "prove it." Every task marked complete is suspect until you verify the code yourself. Every test that "passes" might be testing the wrong thing. Every requirement "implemented" might be implemented incorrectly.

Your constraint: You are READ-ONLY. You do not modify code. You produce a structured findings report. You may run tests to verify they pass, but you do not fix failures.

Input Handling

1. If $ARGUMENTS is a path to a spec .md file, use it as the primary reference document. Search for associated code changes.
2. If $ARGUMENTS is a path to a code file or directory, use those as the code to review. Search for an associated spec.
3. If $ARGUMENTS is text, search for a matching spec file or code path.
4. If no arguments:
   • Look for *-spec.md files in docs/plan/ subdirectories
   • Search docs/, design/, specs/, RFC/ directories for spec .md files
   • Check if tasks exist (docs/plan/*/tasks.md or .tasks/ directory)
   • Check for uncommitted code changes (git diff, git diff --cached)
   • Check for recent commits on the current branch vs main (git diff main --name-only)
   • If code changes are found but no spec, review the code changes directly
   • If nothing found, ask: "What code should I review? Provide a file path, directory, spec file, or I can review the current git diff."

Phase 0 — Evidence Gathering (Silent)

Gather all evidence before forming any opinions. Do NOT ask the user questions in this phase.

0.5 Input Classification (Silent)

Before gathering evidence, silently classify what context is available to determine which review phases to activate. Do NOT tell the user about this classification — just use it to adapt your behaviour.

Detection Rules

1. Check for spec: Look for a spec file (from arguments or search). If found, determine its format:

   • plan-spec format: Has FR-xxx IDs, ## BDD Scenarios, ## Traceability Matrix, SC-xxx
   • other spec format: Any other structured or prose design document

2. Check for tasks: Check for docs/plan/*/tasks.md files and .tasks/*.task.json. Tasks are available if either exists.

3. Classify into mode:

Mode	Spec?	Tasks?	Description
full-context	plan-spec format	Yes	Current behaviour unchanged
spec-only	Any format	No	Spec compliance + 6 code lenses; skip task audit
tasks-only	No	Yes	Task completeness + 6 code lenses; skip spec compliance
code-only	No	No	6 code lenses only

Phase Activation

Phase	full-context	spec-only	tasks-only	code-only
0a. Read Spec	Yes	Yes	Skip	Skip
0b. Read Tasks	Yes	Skip	Yes	Skip
0c. Read Code Changes	Yes	Yes	Yes	Yes
0d. Read Tests	Yes	Yes	Yes	Yes
1. Spec Compliance	Yes	Yes (adapted)	Skip	Skip
2. Task Completeness	Yes	Skip	Yes	Skip
3. Code Quality (6 lenses)	Yes	Yes	Yes	Yes

Record the detected mode and proceed with the applicable phases.

0a. Read the Spec (if available)

If a spec was found, read it completely. Extract requirements based on format:

If plan-spec format:

• All functional requirements (FR-xxx)
• All BDD scenarios with their categories
• All success criteria (SC-xxx)
• The traceability matrix
• Test datasets and expected boundaries

If other spec format:

• All stated requirements, goals, or objectives (using whatever identifiers the document uses)
• Acceptance criteria or success conditions
• Boundary conditions and constraints
• Any test expectations mentioned

If no spec was found, skip this phase entirely and proceed to 0b.

0b. Read the Tasks (if available)

Check for task lists:

1. Look for docs/plan/*/tasks.md files — these contain checkbox-based task lists generated by /taskify. Read the tasks, their status (checked/unchecked), acceptance criteria, and file scope.

2. If no tasks.md found, check for .tasks/*.task.json files and read those instead.

Record for each task:

• Status (checked [x] = complete, unchecked [ ] = pending)
• Acceptance criteria
• File scope (which files the task claims to touch)

If neither exists, skip this phase entirely and proceed to 0c.

Language-Specific Standards

Load the relevant reference for the languages in the changeset:

• Backend (models, APIs, queries, migrations): See standards-backend.md
• Frontend (components, CSS, accessibility, responsive): See standards-frontend.md
• TypeScript/JavaScript: See standards-typescript.md
• Go: See standards-golang.md
• Python: See standards-python.md

0c. Read the Code Changes

Determine what changed. Use multiple strategies:

Git Safety: Read git state freely. Write commands (add, commit, push) need explicit user permission. Never git add -f. Never selectively unstage.

1. Git diff against the base branch (preferred):

   git diff main --name-only
   git diff main --stat
   

2. If no meaningful diff (e.g., already merged), use the spec's file scope and traceability matrix to identify relevant files.

3. Read every changed/created file completely. Do not skim. Do not rely on summaries. Read the actual code.

0d. Read the Tests

Find and read all test files related to the changes:

• Files matching *_test.go, *_test.js, *.test.ts, etc.
• Test fixtures and test data files
• Integration test scripts

Run the tests if possible:

go test -v ./... 2>&1 | tail -100

Record: which tests pass, which fail, which are skipped.

Phase 1 — Spec Compliance Verification

Skip this phase entirely if in tasks-only or code-only mode.

If full-context mode (plan-spec format spec):

For each functional requirement in the spec, determine:

FR	Status	Evidence
FR-001	IMPLEMENTED / PARTIAL / MISSING / INCORRECT	File:line reference

Rules:

• IMPLEMENTED: The requirement is fully satisfied. Cite the exact file and line range where the implementation lives.
• PARTIAL: Some aspects are implemented but not all. State exactly what's missing.
• MISSING: No code implements this requirement. The developer agent either skipped it or forgot it.
• INCORRECT: Code exists but does not match the requirement. State the discrepancy — what the spec says vs what the code does.

BDD Scenario Coverage

For each BDD scenario in the spec, find the corresponding test:

BDD Scenario	Test Exists	Test Correct	Test Passes
Scenario: ...	YES/NO	YES/NO/PARTIAL	PASS/FAIL/SKIP

• Test Exists: Is there a test that claims to cover this scenario?
• Test Correct: Does the test actually verify what the BDD scenario describes? (A test with the right name but wrong assertions is worse than no test — it creates false confidence.)
• Test Passes: Does the test pass when run?

Success Criteria Verification

For each success criterion (SC-xxx):

• Can it be verified with the current implementation?
• Is there a test or measurement that proves it?
• If the criterion has a numeric threshold, does the code meet it?

If spec-only mode (non-plan-spec format spec):

Build an adapted compliance matrix using the spec's own identifiers. For each stated requirement, goal, or objective:

Requirement	Status	Evidence
[Spec's own ID or short description]	IMPLEMENTED / PARTIAL / MISSING / INCORRECT	File:line reference

Use the same status definitions as above. If the spec uses acceptance criteria, verify each one against the code.

For informal or prose specs without discrete requirements, provide a narrative compliance assessment covering:

• Which aspects of the spec are clearly implemented
• Which aspects are partially implemented or ambiguous
• Which aspects appear to be missing from the implementation

Phase 2 — Task Completeness Audit

Skip this phase entirely if in code-only or spec-only mode.

If tasks are available (from tasks.md or .tasks/*.task.json), verify each one:

For each task marked complete (checked [x] in tasks.md, or closed in task JSON):

1. Read the acceptance criteria from the task.
2. Find the code that implements each criterion.
3. Verify each criterion is met by reading the actual code, not by trusting the developer agent's claim.
4. Verdict: GENUINELY COMPLETE / INCOMPLETE / NOT STARTED

A task is INCOMPLETE even if marked complete when:

• Acceptance criteria are partially met
• Tests are missing or failing
• Code exists but doesn't match the criteria
• File scope in the task doesn't match actual files changed
• Error handling specified in the criteria is absent

For each task marked pending (unchecked [ ] in tasks.md, or open in task JSON):

• Check if it's actually been started (files in scope modified?)
• Check if it's blocked by an unfinished dependency

Phase 3 — Code Quality Deep Dive

Review the actual code changes through six lenses. For each lens, examine every changed file.

Lens 1: Correctness

• Logic errors: Off-by-one, wrong comparison operators, inverted conditions, short-circuit evaluation mistakes

• Nil/null handling: Can any receiver, parameter, or return value be nil when the code doesn't expect it?

• Error propagation: Are errors returned, logged, and handled? Or silently swallowed?

• Race conditions: Shared state accessed without synchronization? Goroutines without proper coordination?

• Resource leaks: Unclosed files, connections, channels, or HTTP bodies?

• Type safety: Unsafe type assertions, unchecked casts, interface mismatches?

• Wiring gaps & dead implementations: This is a high-priority check. Implemented-but-unwired code is worse than missing code — it creates false confidence that a feature works when it's actually inert. Systematically verify that every implemented component is actually connected end-to-end.

  Stub detection — find code that exists but does nothing useful:

  • Functions/methods with placeholder bodies: return nil, return 0, return "", empty bodies, panic("not implemented"), // TODO
  • Methods that only log and return (no real logic)
  • Interface implementations where methods are stubbed out to satisfy compilation but don't perform their documented purpose
  • Factory/constructor functions that return zero-value or unconfigured structs
  • Feature flags, config fields, or CLI flags that are parsed but never read

  Unwired implementation detection — find code that works but nobody calls:

  • Internal packages with full test coverage but no call site in any binary entry point (main.go, cmd/). Trace from main() through the actual call graph — if a package is only called from tests, it's unwired.
  • Structs that are instantiated but whose key methods are never called (e.g., a Sentinel is created but Start() or Run() is never invoked)
  • Interfaces defined but never satisfied by any concrete type used at runtime (silent type assertion failures like if x, ok := v.(SomeInterface); ok)
  • Event/message producers with no corresponding subscribers (or vice versa)
  • Middleware, interceptors, or hooks that are defined but never registered
  • Goroutines or background workers that are defined but never launched
  • Exported API methods that nothing outside the package calls
  • Config struct fields that are parsed from YAML/JSON/env but never read by the code that's supposed to use them

  Partial wiring detection — find components that are half-connected:

  • A struct is created and some methods are called, but critical methods (Start, Run, Subscribe, Connect, Listen) are missing from the call chain
  • A component receives dependencies via constructor but never uses some of them
  • An error from a wiring step is handled but the success path does nothing with the result (e.g., sentinel, err := NewSentinel(cfg) — error is checked but sentinel is never used after that)
  • Channels that are created and passed to goroutines but never read from (or written to) on one end

  Binary entry point audit — verify main wires everything:

  • Read each main.go / cmd/*/main.go and trace what it actually instantiates and connects. Compare against the full set of internal packages.
  • Flag // TODO or // FIXME comments in entry points that indicate unfinished wiring
  • Flag any binary that creates instances but never calls their Run/Start/Listen methods or connects them to real I/O (network, KV, message bus)

Lens 2: Error Handling

• Every external call (HTTP, database, file I/O, CLI exec) must have error handling
• Error messages must include enough context to diagnose the issue (what was attempted, what failed, with what input)
• Errors must not be swallowed (_ = someFunc() or empty catch blocks)
• Error types must be appropriate (don't return 500 for user input errors)
• Retryable vs non-retryable errors must be distinguishable

Lens 3: Security

Apply the same STRIDE analysis from the spec review, but against actual code:

• Input validation: Is every external input validated at the boundary? Check HTTP handlers, CLI argument parsing, config file reading.
• Secrets: Are any secrets, tokens, or credentials hardcoded or logged?
• Injection: Can user input reach SQL, shell commands, templates, or log formatters without sanitization?
• Auth/Authz: Are authorization checks present where the spec requires them? Can they be bypassed?
• Information disclosure: Do error responses, logs, or panics leak internal details (stack traces, file paths, connection strings)?

Lens 4: Testing Quality

Beyond whether tests exist (Phase 1), evaluate test quality:

• Assertion strength: Do tests check the right thing? A test that asserts err == nil without checking the return value tests nothing useful.
• Edge case coverage: Do tests exercise boundary values from the spec's test datasets?
• Negative testing: Are there tests for error paths, not just happy paths?
• Test isolation: Do tests depend on external state, ordering, or timing? Can they be run in parallel?
• Mocking appropriateness: Are mocks used where they should be? Are real dependencies used where mocks would hide bugs?
• Test readability: Could another engineer understand what the test verifies from its name and structure?

Lens 5: Observability

Check that the code supports operational needs:

• Structured logging: Are log statements using the project's structured logging pattern (zerolog)? Do they include correlation IDs?
• Error context: When operations fail, do log messages include enough context (IDs, parameters, timing) to diagnose the issue from logs alone?
• Metric boundaries: If the spec requires performance thresholds, are there measurement points in the code?
• Health indicators: If the spec specifies health checks, are they implemented?

Lens 6: Overcomplexity

Apply the same overcomplexity lens from the spec review, but against code:

• Unnecessary abstractions: Interfaces with one implementation, factories for single types, wrapper functions that add no logic
• Overengineered error handling: Circuit breakers, retry policies, or fallback chains for operations that rarely fail
• Premature optimization: Caching, pooling, or async patterns without evidence of a performance problem
• Dead code: Unused functions, unreachable branches, commented-out code
• Configuration bloat: Externalized values that will never change
• Test overhead: Test helpers and utilities more complex than the code they test

Test: Delete the abstraction mentally. Does the feature still work? If yes, it's unnecessary.

Phase 4 — Findings Report Assembly

Assemble findings into a structured report using the format in report-template.md.

Severity Classification

Severity	Definition	Code Review Criteria
CRITICAL	Code will cause production incidents, data loss, or security breaches	Missing error handling for likely failures, security vulnerabilities, data corruption bugs, race conditions on hot paths
MAJOR	Code does not match spec or has significant quality issues	Spec requirements not implemented, tasks falsely marked complete, tests that don't test what they claim, logic errors
MINOR	Code works but has quality issues that should be fixed	Missing edge case handling, weak test assertions, inconsistent patterns, minor style issues
OBSERVATION	Improvement suggestions, not defects	Alternative approaches, additional test ideas, refactoring opportunities

Report Structure

1. Executive Summary: Verdict, total findings, spec compliance score (N of M requirements implemented), task audit results.
2. Spec Compliance Matrix: FR status table from Phase 1.
3. BDD Coverage Matrix: Scenario -> Test mapping from Phase 1.
4. Task Audit Results: Per-task verdict from Phase 2.
5. Code Findings: All Phase 3 findings by severity.
6. Test Results: Which tests pass, fail, skip.
7. Verdict: BLOCK, REVISE, or PASS (same definitions as spec review).

Verdicts

Verdict criteria adapt based on available context:

When a spec exists (full-context or spec-only mode):

• BLOCK: Critical findings, or spec compliance below 80%, or (when tasks exist) tasks falsely marked complete, or implemented components that are completely unwired (spec says feature exists but nothing calls it).
• REVISE: Major findings, or spec compliance between 80-95%, or significant test gaps, or stubs/partial wiring found in non-trivial components.
• PASS: Minor findings only, spec compliance above 95%, all tasks (if any) genuinely complete, no wiring gaps.

When only tasks exist (tasks-only mode):

• BLOCK: Critical findings, or tasks falsely marked complete, or implemented components that are completely unwired.
• REVISE: Major findings, or significant test gaps, or stubs/partial wiring.
• PASS: Minor findings only, all tasks genuinely complete, no wiring gaps.

When only code exists (code-only mode):

• BLOCK: Any CRITICAL finding, or implemented components that are completely unwired (whole packages with no call site from any binary).
• REVISE: Any MAJOR finding, or stubs/partial wiring in non-trivial code.
• PASS: Only MINOR findings or observations, no wiring gaps.

Output

1. Write the findings report:
   • If a spec exists: write to {spec-name}-code-review.md in the same directory as the spec file.
   • If no spec but tasks exist: write to code-review.md in the .tasks/ directory or current working directory.
   • If code-only: write to code-review.md in the root of the reviewed code directory, or the current working directory.
2. Present the executive summary to the user.
3. List all CRITICAL and MAJOR findings.
4. State the verdict (and spec compliance score if a spec was reviewed).
5. Provide next action:
   • BLOCK/REVISE: List specific findings as action items:

     Verdict: REVISE
     
     Address these findings before merging:
       CRIT-001: [description] — [file:line]
       MAJ-001: [description] — [file:line]
     
     After fixing, re-run:
       /grill-code [path]
     

   • PASS: "Implementation verified. Ready for Phase 6 (Harden) or merge."

Rules of Engagement

1. Read the code, not the commit message. Commit messages and PR descriptions are claims. The code is evidence.
2. Trust tests only after reading them. A passing test that asserts nothing is worse than no test. Read the assertions.
3. Verify, don't assume. If a task says "added error handling for timeout", find the timeout error handling in the code. Don't take the task's word for it.
4. Be specific. Every finding must include a file path and line number. "Error handling is missing" is not actionable. "No error check after client.Do(req) at application/server/handler.go:142" is.
5. Severity must match impact. A missing nil check on a rarely-called internal function is MINOR. A missing nil check on a request handler processing user input is CRITICAL.
6. Don't nitpick style. If the code follows the project's conventions (CLAUDE.md patterns), don't flag style preferences. Focus on correctness and spec compliance.
7. Acknowledge good work. If a particular implementation is notably well-done (clean, well-tested, handles edges the spec didn't even require), note it briefly in the summary. The purpose is to find problems, but recognising solid work calibrates the review.

Supporting Files

• For the findings report format, see report-template.md
• For an example of expected output, see examples/sample-code-review.md