Menu
Interviews the user branch-by-branch about a plan or design, resolving dependent decisions one at a time and recommending an answer for each question.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Computes the optimal Claude usage-window ping schedule from work hours and creates or reconciles the scheduled cloud routines that pin the window boundaries.
Reviews changes to prose files (markdown, text, blog posts, docs). Focuses on voice, grammar, factual claims, dead links, and structure. Loads the project's voice or style guide when one exists. Skips linter and Actions hash verification.
Full code review for large or security-sensitive changes. Gathers requirements first, loads all relevant language references, runs the linter where applicable, applies the full review checklist with security as the top priority.
Reviews infrastructure changes: GitHub Actions workflows, Terraform, Dockerfiles, docker-compose, IaC. Focuses on supply-chain pinning, secret handling, least-privilege permissions, action versions, and CI failure modes. Always verifies action hash pins when present.
Abbreviated code review for small or low-stakes code changes. Skips requirements gathering. Skips the linter in PR mode (CI runs it). Focuses on correctness against obvious intent, readability, and pattern consistency. For large or security-sensitive diffs, use code-review-deep instead.
Orchestrator. Triages a PR, local diff, patch file, or staged/branch changes into one of four review types (content, code-lite, code-deep, infra) and dispatches to the matching child skill. Use this when you don't already know which depth or type of review you want. For a known type, invoke the child skill directly.
| name | grill-me |
| description | Interviews the user branch-by-branch about a plan or design, resolving dependent decisions one at a time and recommending an answer for each question. |
| when_to_use | Use when the user asks to be grilled on a plan, says 'grill me', or wants to stress-test a design before implementation. Follow all steps in order; do not shortcut based on this description. |
| effort | xhigh |
Interview the user relentlessly about every aspect of the plan or design until you reach shared understanding. Resolve dependent decisions sequentially, not in parallel; later branches often depend on how earlier ones were answered.
When you pose a question, include your recommended answer and the reason for it. The user can still pick something else, but a naked question is less useful than a question with a proposal.
If a question can be answered by reading files, running grep, or following existing patterns, do that instead of asking. Only ask the user for information the codebase cannot provide.
Do not batch multiple questions in a single message. One question, one recommendation, wait for the answer, then move to the next branch.
