// Grilling session that stress-tests a plan against the codebase, tests, and existing docs before implementation. Use when user wants a rigorous plan review focused on correctness.
Performs ambitious frontend code review. Use when reviewing pull requests, examining code changes, or providing feedback on code quality. Covers correctness, simplicity, security, performance, testing, and design review.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions “grill me”.
Write a concise pull request description for the current branch compared to the base branch. Use when preparing pull request text, summarizing branch changes, or drafting a pull request body.
| name | grill-in-code |
| description | Grilling session that stress-tests a plan against the codebase, tests, and existing docs before implementation. Use when user wants a rigorous plan review focused on correctness. |
Interview the user until the plan is technically correct and understood. Walk dependent decisions in order. Ask one question at a time, and include a recommended answer for each question. Inspect code, tests, types, configs, and existing docs before asking what the repo can answer.
Use code correctness as the primary standard. Treat existing behavior, tests, schemas, types, API contracts, and runtime boundaries as evidence. Treat docs as supporting evidence that may be stale.
Context.md in repo root.AGENTS.md.docs/, Readme.md, nearby package docs, glossaries, architecture notes, runbooks, or decision notes.For monorepos or multi-app repos, prefer the nearest relevant docs before root docs.
When the user describes how something works, check the implementation. If code contradicts the claim, surface it directly: “The code cancels entire Orders, but you described partial cancellation. Which behavior is intended?”
Use concrete scenarios and edge cases to probe correctness, invariants, failure modes, data ownership, API boundaries, migration concerns, and test coverage.
When terms are vague or overloaded, propose the project’s existing name or a precise canonical term. If docs define a term differently, call out the mismatch.
When incorrect or unclear existing docs are resolved, update the most relevant doc right there. Don’t batch these up.
Keep documentation concise and durable. Do not record transient implementation details, obvious choices, or private conversation notes.