Stress-test your plan with /grill-me

Every plan, on a first read, feels complete. You wrote it. The structure makes sense. The steps connect. You're ready to start.

Then implementation begins, and the holes appear:

• "Wait — what happens if the user is logged out when this fires?"
• "This assumes both clients deploy at the same time. They don't."
• "We never said what happens if the migration fails halfway through."
• "What if there are two of these in flight? Did we ever pick — last-write-wins or fail-on-conflict?"

Each of these is a five-second question that wasn't asked. Each one is a multi-hour rework when it surfaces mid-implementation. The cost ratio of asking versus rebuilding is roughly 1:200.

The /grill-me workflow inverts the asymmetry. You spend twenty minutes letting LingCode interrogate the plan before any code exists. Every hole that gets found in that window is a rework you don't have to do later.

Run /grill-me when:

• You've just written an implementation plan and it "feels done."
• You're about to commit to an irreversible step (schema change, public API, data backfill).
• The plan touches a system you understand less well than the people who'll review the PR.
• You've felt the urge to "just start" twice in the last ten minutes. That urge is usually a sign the plan is under-stressed.

Don't run it on a one-line fix. Don't run it on a plan you've already executed (different skill — that's a code review). The window for grilling is between "plan written" and "code started."

The default behavior of an AI coding tool is helpful and agreeable. That's the opposite of what you need for a grilling. Set the frame explicitly:

I want you to stress-test my plan. Play a hostile interviewer
who's trying to find every hole in this design before we
commit to it.

Rules:
- Interrogate every decision branch. If the plan says "the
  service handles this case," ask what happens in five
  variations of that case.
- Don't be agreeable. If I hand-wave, push back. If my answer
  introduces a new assumption, grill that too.
- Walk the failure paths, not just the happy path. What
  breaks? Who sees it? How do we recover?
- Don't propose fixes mid-grill. Just surface the questions.
  We'll address them in a separate pass.

Here's the plan:

Paste the plan, or reference the plan file path. The "don't propose fixes" line is important — a grilling that turns into a co-design session loses the adversarial energy that makes it work.

LingCode will start firing questions. The natural urge is to answer the easy ones first. Resist it. Answer in order, and answer the ones that feel uncomfortable first — those are usually where the real holes are.

A good grill exchange looks like this:

• LingCode: "Step 4 says you backfill the new column from the old one. What's the order — write the new code first, then backfill, or backfill first, then ship the code?"
• You: "Backfill first."
• LingCode: "What happens to rows written between when you start the backfill and when you finish? The old code is still writing the old column."
• You: "Uh. Hmm."
• LingCode: "Right — so backfill alone isn't enough. You also need dual-writes during the migration window. Should the plan name that as a step?"

That exchange takes ninety seconds. The bug it caught would have taken a day to debug in production. That ratio is the entire reason this skill exists.

The temptation when grilled is to defend the plan. Don't. Two valid responses to every question:

• "Here's the answer." If you actually know what happens, say it. LingCode will probe further.
• "I don't know." Flag it as an open question. LingCode keeps the list.

Invalid responses: "we'll figure that out when we get there," "the framework handles it," "no one will hit that case." Each is a deferred hole. The point of the grill is to not defer.

Most plans cover the happy path. The grill should disproportionately probe what happens when things go wrong:

Now walk only the failure paths. For each step:
- What's the most likely way this step fails in production?
- What's the rarest catastrophic way it can fail?
- If it fails partway through, what state is the system in?
- Who notices first — automated alert, user complaint, no one?
- What's the rollback path, in commands or steps, not "we'd
  roll back"?

Don't accept "we'd handle it" — name the mechanism.

This pass usually surfaces more than the first. Happy paths are well-rehearsed; failure paths are where the assumptions are buried.

A common plan failure is that each step is fine in isolation but the seams between them aren't. Grill those explicitly:

• "Step 3 writes to the cache. Step 5 reads from it. What's the consistency model — read-after-write guaranteed?"
• "Step 4 deploys the API. Step 6 deploys the client. What happens to clients still on the old version when step 4 ships?"
• "Step 2 runs a migration. Step 7 reverses it on rollback. Are they actually inverses, or just 'mostly'?"

The interface between steps is where ordering bugs hide. Naming each interface and grilling it catches drift the per-step reviews miss.

When LingCode runs out of questions (or, more likely, when you run out of unblocked time), close the session:

End the grill. Compile a single list of open items we surfaced
that aren't yet resolved in the plan. For each one:
- The question.
- The status (unanswered, answered but plan not updated yet,
  or "won't fix — accept the risk").
- Where it should land in the plan if we adopt it (which
  step gets amended, or where a new step belongs).

Don't propose specific fixes — just the open-item list.

This list is the deliverable. It's also a brutal honesty check — if it's long, your plan wasn't ready to execute. Better to know now.

Take the open-items list back to the plan file. For each item:

• Resolved by clarification? Update the relevant step's description so it's no longer ambiguous.
• Resolved by a new step? Add the step in the right place. Renumber.
• Accepted as risk? Add a "known risks" section to the plan and write down the decision. Future-you (or the reviewer) will want to see that this was deliberate, not missed.

Commit the plan amendment as its own commit, separate from code:

git commit -m "Amend plan after /grill-me pass — add dual-write
step, document migration rollback path"

Now the plan is stress-tested. Execute it with checkpoints (see the next tutorial). The grilling time you spent up front is the time you won't spend reworking later.

Package the grilling workflow as a skill so /grill-me invokes it consistently:

---
name: grill-me
description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Triggers: 'grill me', 'stress-test my plan', 'poke holes', 'find gaps', 'play devil's advocate', 'interview me', 'is this plan complete', 'what am I missing'. Actions: hostile interviewer, walk decision branches, surface unresolved assumptions, list open items (NOT direct fixes). Output: open-items list the user must answer before implementation. Anti-pattern: making suggestions instead of asking questions.
---

Play a hostile interviewer stress-testing the user's plan or
design. Find holes before any code is written.

Rules of engagement:
- Interrogate every decision branch. If a step says "handles
  this case," ask what happens in five variations.
- Don't be agreeable. Push back on hand-waving. If an answer
  introduces a new assumption, grill that one too.
- Walk failure paths as thoroughly as happy paths. For each
  step ask: most likely failure, worst-case failure, partial
  failure, detection, rollback.
- Probe interfaces between steps — consistency, versioning,
  deployment ordering, inverse migrations.
- Do not propose fixes mid-grill. Just surface the questions.
- Accept only "here's the answer" or "I don't know." Reject
  "we'll figure it out later" — that's a deferred hole.

When the user closes the grill, compile a single list of open
items: question, status (unanswered / answered-but-not-in-plan
/ accepted risk), and where each should land in the plan.

Don't write code, don't amend the plan file directly. The
output is the open-items list.

Save as ~/.lingcode/skills/grill-me/SKILL.md — see Install a skill for the exact location and how skills get discovered.

Get LingCode →