/grill-jev

name: grill-jev
description: "Broad Jev interrogation: generate up to 50 context-specific questions about a plan, spec, design, code artifact, or any topic — using all primitive shapes and structured forms to surface hidden problems before they ship."
user-invocable: true
routing:
  force_route: true
  triggers:
    - grill
    - validate plan
    - validate spec
    - validate design
    - interrogate
    - stress test plan
    - stress test spec
    - 50 questions
    - deep validation
    - grill this
    - grill the plan
    - jev interrogation
    - sanity check plan
    - sanity check spec
    - check my plan
    - check my design
    - plan validation
    - spec validation
    - design validation
    - architecture review jev
    - verify plan
    - verify spec
    - challenge plan
    - challenge design
    - find holes
    - find gaps in plan
  not_for: "Writing new Jev programs (use building-with-jev). Routing requests (use do). Code review for quality/style (use review). Security scanning (use security). This skill runs a broad interrogation battery against a supplied artifact — it does not build Jev programs."
  pairs_with:
    - building-with-jev
    - review
  complexity: Complex
  category: meta
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep

Grill-Jev

Generate a context-specific Jev interrogation battery against a plan, spec, design, code artifact, or any topic. Questions are generated from the artifact itself — not from a static list — so they target the actual risks and gaps in what you provide.

When to invoke

• User says "grill this", "validate my plan", "find holes in my spec", "sanity check", "stress test this", "50 questions", "interrogate", "grill-jev"
• **When you are genuinely unsure a plan, spec, or design holds**, before execution begins. Not automatically after every plan: the owner (2026-10-26), "jev is like a guide rail when you are legitimately unsure. if you are sure, just make the decisions".
• When the user says "does this look right", "approve this", "is this ready", "review my plan"

How it works

1. **Read the artifact** — the plan, spec, design, or code being interrogated 2. **Generate questions** — the LLM executing this skill produces up to 50 context-specific Jev questions tailored to the artifact. It writes the JSON battery to a temporary file; no secondary model call or API key is used. Questions use all structured shapes:

• Noul with `{true: {what, examples}, false: {what, examples}}` criteria
• Choice with `{what, not_for, examples}` per option
• Score with `{summary, signals}` per level
• Noul with array `compare` instructions when two state paths need comparison

3. **Send to Jev** — evaluate the questions against the artifact as state. Use Vercel AI Gateway. Too much context is the most common failure: the artifact is resent with every batch, so split the battery by estimated tokens (`jev_limits.request_tokens`), not by question count, keeping each request under the size target in `skills/shared-patterns/jev-production-lessons.md`. When the artifact alone passes the target, send the sections each question needs instead of the whole artifact. `scripts/grill-jev.py` does the splitting: it packs batches by tokens, and when a batch fails it halves and retries down to single questions, so one oversized or malformed question costs only its own answer. A question that still fails is listed as UNANSWERED (unknown, never a pass) and the run exits 2. If a tiny probe also fails, Jev is down and the run stops. The script rejects a malformed battery before sending (for example, Score levels must be a list). 4. **Report findings** — high-signal answers with suggested actions

Asking good questions

Question quality depends on context and framing. The rules below were validated through 3 iterative Jev loops.

**Context inputs that improve questions:**

| Input | Why it matters | Example | |---|---|---| | **Audience** | Who executes or approves this? SRE, junior dev, product owner, external team? | SREs need ops-specific questions; product owners need outcome and risk questions | | **System context** | What does the system actually do? What are its constraints? | Stateful vs. stateless changes need different risk questions | | **Purpose** | What decision does this artifact support? | Approval gate → binary questions; exploration → broader coverage | | **Depth wanted** | 15 sharp questions or 50 comprehensive ones? | Match count to stakes and complexity |

Pass context via `--context "audience: SRE, system: stateful payment service, known constraint: cannot have >5min downtime"`.

**Generation rules (Jev-validated):**

1. **Specific over generic** — questions must name specific steps, systems, or claims in the artifact. "Does step 4's migration define a rollback safe to run under live traffic?" beats "does this have rollback?".

2. **Mentions trigger deeper scrutiny, not shallower** — when the artifact mentions a risk, gap, or uncertainty, generate MORE targeted questions about it. Acknowledgment is not mitigation. "This is risky" without a defined mitigation is itself a finding.

3. **Audience weight** — use audience context to focus questions. An SRE needs ops questions. A junior dev needs step-clarity questions. A product owner needs outcome questions.

4. **Coverage balance** — aim for breadth across relevant categories (completeness, feasibility, risk, scope, verification, consistency, reversibility, security, cost and throughput). Do not cluster all questions on one category. Skip a category only when the artifact has nothing that triggers it.

5. **Scale by complexity** — simple artifact (15-20 questions), medium (25-35), complex (40-50). Hard cap: 50.

**Self-calibration loop** — if findings feel generic or off-target, use Jev to improve: 1. Run grill-jev — observe which findings feel shallow 2. Ask Jev: "Which questions were not specific to this artifact? What context would have produced bette