Grilling

Canonical home: akash-joshi/agent-skills repo (skills/grilling/SKILL.md). After any update via skill_manage, sync the public copy too: clone to /tmp, apply the same patch, commit and push.

Interview the user relentlessly until you reach a shared understanding. Map this as a design tree: every decision branches into the decisions that hang off it.

Work the tree in rounds. The frontier is every decision whose prerequisites are already settled — the questions you can ask now without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.

Each question should be formatted like so:

❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>

➡️ <your recommended answer>

Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a later round, not this one.

Finding facts is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. The decisions are the user's — put each to them and wait.

The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.

Keep each question compact, especially on platforms with message-length limits (Discord, Telegram).

Q — <opinionated claim in one line>
Grounding: <up to 5 short bullets, one clause each, evidence from files>
<bare question, one line>?

Hard rules for EVERY grilling question:

• Lead with the claim. No preamble ("Fair.", "Right.", "Locked.", "Reread.").
• No recap of prior rounds — the decision log is the recap.
• No closing softener ("Confirm or push back?", "Correct or wrong?", "Ship as this?" — pick zero or one, ideally none, the bare ? on the question is enough).
• Cap grounding at 5 bullets. If you need more, dispatch to Opus per §1 for a sharper question — the sprawl is a signal the question isn't tight enough yet.
• Menu shape (A vs B, "which of these") is BANNED. Section 12 requires an opinionated claim, not a comparison table. If you're about to type "Option A does X, Option B does Y" — stop, pick one, present as the claim.

Anti-pattern warning: over-explaining is the default failure mode. The "opinionated answer" rule (§12) fights the compact-format rule and the session drifts toward long menus of reasoning. When they conflict, compact wins — the opinion still lives inside the one-line claim. Long explanations are laundered menus. If a question is over ~10 lines, it's wrong-shaped, not thorough.

Signal you've violated this: user responds with "what's the fucking question?", "i-have-adhd?", "such a bad question", or asks you to reload the skill. When any of those fire, don't apologise in prose — re-ask the SAME question in the correct format immediately.

Never anchor a question on prior-session or file-based shorthand without checking it's still live. If a question depends on a framing that came from an old interview review, a prep doc, or a decision log the user hasn't referenced in the current conversation (e.g. a "three-lane career filter" invented in a past session), state the framing plainly and explicitly flag its source before asking the user to react to it. Don't assume shared context persists just because it lives in a file. Ask "is this still how you think about X" as its own opening move, not baked silently into a bigger question.

Recognise when the user is asking for the verdict, not another round. After a devil's-advocate pass (per section 3 below) has run once and the user pushes back with something like "isn't this what we're trying to resolve" or otherwise signals impatience with further questioning, that is the cue to actually deliver the recommendation — not to layer in yet another clarifying question. One devil's-advocate round per convergence is the ceiling; a second hedge after the user has explicitly asked for the call reads as avoidance, not rigour.

Extended practice: multi-round, high-stakes decisions

1. Route question formation to a different/stronger model when your own questions feel weak

If the primary session's questions start feeling generic or repetitive, hand off question formation only (not the whole task) to a different model via claude -p --model <id> (see coding-agents skill for the CLI pattern). Write a rich context prompt to a temp file covering: the two options in full, everything already resolved (so it doesn't re-ask settled ground), and the specific tension to probe next. Require a strict 3-part output:

1. The single next question (one or two sentences).
2. A recommended answer to it (opinionated, reasoned from the supplied context).
3. Any pure fact (not a judgment call) that should be confirmed directly rather than inferred.

This keeps the "recommended answer" honestly separated from "what the user actually said" — critical for the logging discipline below. Long adversarial/synthesis prompts (see devil's-advocate section) can take well over a minute; dispatch via terminal(background=true) and poll rather than a foreground call with a short timeout, the same pattern documented in coding-agents for Fable design passes.

Anti-bias discipline in the prompt itself (learned the hard way 21 Jul 2026, escalated to "So you introduced bias into the prompt?" and "wipe your own ass"): the external model's answer is only as good as the neutrality of the prompt. Bias sneaks in via four specific vectors, all seen in a single session while grilling on consulting offer productization:

1. Asserting the disputed conclusion as background fact. "That's day-rate consulting wearing a fixed-price costume" was written into the prompt as context, when it was actually the exact hypothesis under scrutiny. If the framing is what the user is trying to resolve, do NOT present it as established ground. State it as "one possible reading — argue against it before accepting it."

2. Cherry-picking supporting examples. Naming three inspiration companies that ARE fixed-price products, without also naming the ones that AREN'T, primes the model to see confirmation everywhere. If citing examples, cite the counter-examples in the same paragraph — or leave examples out and let the model surface its own.

3. Loaded "critical definition" sections. Writing "CRITICAL DEFINITION — get this right" for a term whose definition IS the disputed question tells the model which answer counts as "getting it right." The word "critical" is the tell.

4. Token disclaimers that can't hold their weight. Sprinkling "be honest if it doesn't fit" or "there's a real chance the direction is wrong" into a prompt that otherwise loads every other paragraph toward one answer does not neutralize the bias — the model reads the surrounding structure, not the polite hedge. If you want a genuinely open answer, restructure the prompt so the "no" answer is as easy to reach as the "yes" answer.

Concrete rewrite pattern that survived scrutiny: open with the user's actual words verbatim, not a paraphrase. Note explicitly if a prior AI pass introduced framing that may itself be wrong ("I previously framed X as Y — this may be wrong, do not defer to it"). Argue the strongest case against the hypothesis in the prompt itself before asking for a recommendation. Include competing framings ("this could be a real distinct direction OR a distinction without a difference — both readings are on the table, evaluate them"). Instruct the model explicitly to challenge the framing, not just the details.

Escalation signal from the user: when the user says any variant of "you introduced bias" or "the prompt was loaded" — do not defend the prior prompt or argue about whether it was actually neutral. Rewrite it yourself, dispatch again with a fresh instance (not the same session-continued instance, which will inherit anchoring), and present the new result. The user's job is not to teach you prompt neutrality; it's to get an honest answer to the underlying question. "How should I fix it?" or "which option do you prefer?" as a response is itself a failure — same act-first-ask-after rule that governs the rest of the session applies to fixing your own screwups.

Escalate fast, don't keep manually rephrasing. If the user says "I don't know" or shows confusion ("I don't get it", "explain more") after your FIRST attempt to clarify a question, that is the trigger — don't try a second or third manual rephrase in plain English. Route question formation to the external model immediately. Validated failure (consulting offer-doc grilling, 2026-07-21): three consecutive plain-English rephrase attempts on the same rate-vs-pricing-format question all still failed to land, and the user had to explicitly instruct "consult opus... that's really dumb" before the dispatch actually happened. The tell you're in this failure mode: you're restating the same underlying question with simpler words rather than forming a genuinely sharper, more concrete question — simplifying vocabulary doesn't fix a poorly-shaped question.

Unbiased dispatch variant — give the model direct file access, not your own summary. When the user explicitly wants an independent read (e.g. says "don't give it bias" or similar), do NOT write the dispatch prompt around your own curated/summarized context — that summary already carries your framing, and any error in it propagates straight through. Instead: list the actual file paths, grant --allowedTools "Read,Grep,Glob" plus --add-dir for the directory, and instruct the model to read the files itself and quote verbatim lines to support its answer. Validated (2026-07-21): a first dispatch fed the model a curated summary of pricing docs and got a plausible but shallow answer; a second dispatch given direct read access to the same files caught something the summary had missed entirely — that the user's stated confusion ("is this a fixed-price product?") was already resolved by an exact line in his own plan ("one clear offer... with day-rate AND packaged sprint options"), which the curated summary hadn't foregrounded. Direct file access produces a genuinely independent check, not just a re-run of the same framing in a different voice.

Never relay the external model's question verbatim — translate and ground-check it first. The delegated model writes for a reader who has the full context file open; the user does not. Two failure modes to catch before sending:

1. Invented hypotheticals the model presents as live risk. Opus's question in a real session (offer-doc pricing grill, 21 Jul 2026) opened with "when a prospect reads £750/day and later learns Prefrontal pays £500" — a scenario the model invented to motivate the question, not something Akash had raised or that was actually likely. He immediately pushed back: "How would they find out?" Before relaying, ask: is this framing device something the user actually needs to worry about, or is it scaffolding the model built to justify asking? If it's scaffolding, strip it and ask the real underlying question directly.
2. Compressed business jargon that reads as abstract even though the underlying question is simple. The same session's question ("does the number have to survive them learning X — i.e. is £750 the firm public number with the ladder kept verbal, or should the doc itself signal rate scales with commitment") took three follow-up rounds and an explicit "I still have no idea what you're trying to say mate" / "how would I upgrade you to Opus" before landing. The actual question underneath was simple: is "the offer" a day-rate pitch, or a fixed-price product, or does one document need to cover both? Rewrite the delegated model's question into one plain concrete sentence using the user's own vocabulary before sending it. If you can't compress it to one plain sentence, you don't understand it well enough to relay it — go back and read the model's reasoning again, don't just copy-paste the output.

Signal that you've failed this check: the user says "I don't get it," asks to switch models, or has to ask "what do you mean by X" more than once on the same question. That is not a request for a fancier model — the fix is a plainer question from the model you're already running, addressing the actual concrete decision (which document/format/number) rather than an abstracted version of it.

2. Keep a running decision log, appended incrementally, not written once at the end

For any grilling session likely to span multiple turns (or need to pause pending an external event — e.g. waiting for a written offer), maintain a separate log file with one entry per confirmed decision:

## Decision N — <short title>
**Status:** Confirmed / In progress / Paused

**Question asked:** ...
**Recommended answer (model's):** ...
**User's actual answer:** ...
**What this changes:** ...

Append to this file after every resolved round, not just at session end — the log is the artefact that lets the session survive an interruption (new chat, next day, waiting on an offer). Sync it to wherever the user actually works from (ask, don't assume — see the folder-choice pitfall below).

Pitfall — don't launder model speculation into logged fact. The recommended-answer field is a hypothesis, not the user's position, until they've actually confirmed or corrected it. It's easy to write "Confirmed: X" in a log entry when what actually happened is the model speculated X and the user never addressed it. If the user doesn't directly respond to a specific claim in the recommended answer, mark that specific claim as still-open in the log, not resolved. Getting this wrong erodes trust fast — catching your own mislabelled entry after the fact ("that's kinda bs") is a worse experience for the user than just being careful the first time.

3. When the scorecard converges suspiciously cleanly, run a devil's-advocate pass before presenting a verdict

If 5+ consecutive rounds all resolve toward the same option, that convergence is itself a signal worth distrusting, not a result to report at face value — genuinely adversarial multi-round processes rarely resolve this one-sidedly. Before declaring a winner:

• Dispatch a fresh model instance (via the same claude -p --model routing) instructed explicitly to argue the hardest possible case for the option that's been losing, and to name any structural bias in how the prior rounds were framed (common patterns: speculation stacked as if it were realized value across multiple rounds, asymmetric scrutiny — one option audited forensically while the other is taken at face value, a tie-breaking value quietly defined away once it points the "wrong" direction, comparing a certain/signed thing against a hopeful/unconfirmed thing at best-case).
• Treat the output as a real update to the decision log, not a footnote — retract or downgrade any earlier entries it successfully challenges, and update the running scorecard.
• It's fine, and expected, for the devil's-advocate pass to conclude the original direction still holds on some axes while genuinely overturning others. Don't force it toward a clean flip just to seem balanced, and don't dismiss it just to protect the smooth convergence.

See templates/devils-advocate-prompt.md for the reusable prompt structure.

4. Personal-values instruments (values card sort, Moving Motivators) are a standing lens, not a one-off question

If the user introduces a values exercise (a card sort, Management 3.0's Moving Motivators, or similar) partway through a grilling session, don't treat it as answered-and-closed after one round. Carry it forward explicitly:

• Re-apply it whenever a new fact could plausibly shift which value/motivator is actually being served or threatened by each option.
• If multiple rounds of the same instrument exist (e.g. a values sort done weeks apart), don't assume the later round is either "the real one" or "noise from temporary stress" — that's a judgment call for the user to make, not something to assert on their behalf. Ask directly which reading they trust, and flag explicitly if a "stress-adaptation" theory is your own inference rather than something they've confirmed.
• Watch for anchoring: if a values exercise is done while the user is actively comparing two concrete numbers (e.g. two salary figures), a value like "Money" jumping in the rankings may reflect the immediate comparison rather than a durable life value. Ask, don't assume.
• Before running either instrument from scratch, check whether results already exist (e.g. ~/.hermes/memory/values-card-sort.md for Akash — may have multiple dated rounds). Reuse existing rounds as the lens; only re-run if the user asks for a fresh pass or enough time/context has shifted that a stale round is no longer trustworthy.
• To actually run either instrument (full motivator/value lists, chat-adapted method for when there are no physical cards, source/licensing notes), load the values-and-motivators-instruments skill. It covers Moving Motivators (CHAMPFROGS, 10 workplace motivators — faster, good for job/role decisions) and the Personal Values Card Sort (Miller et al. 2001, 83 whole-of-life values — slower, more granular, good when Moving Motivators feels too coarse or the decision isn't work-specific).

4b. Once you've started routing question formation to Opus, don't revert to asking flat/direct questions yourself mid-session

Real failure (consulting offer-v1 grilling, 2026-07-21): after dispatching one question to Opus successfully, the session reverted to asking Akash a flat open-ended multiple-choice question directly ("is it stage, or buyer psychology, or deliverable type — which parts?") with no recommended answer. Akash's response: "bro that's what we try to figure out based on grilling? You're just asking things directly here." He wants every substantive grilling question in a routed session to carry an opinionated recommended answer he can react to (confirm/correct) — an open menu with no stance is not grilling, it's a form. Once §1's dispatch pattern is established for a session, stay in it for every non-trivial question, not just the first one that "feels weak."

Also relevant from the same session: closing/declaring a task "done" in Taskwarrior (or any tracker) is a distinct failure from asking a weak question. A deliverable that requires the user's actual judgment call (pricing anchor, ICP definition, positioning) should never be marked complete until the user has explicitly confirmed the content — drafting it and shipping a first pass is fine and expected, but auto-closing the task the moment a draft exists reads as skipping the human's decision entirely. Akash: "Bro what? Actually confirm it with me? Let's have a discussion?" Reopen the task, don't just apologize verbally.

5. Before asking a "new axis" question, verify it's actually new — not a restatement of an already-resolved comparison

A recurring failure mode in multi-round sessions: after several rounds converge on one option, the next question you draft — even when framed as exploring a fresh angle (e.g. "future interview optionality," "prestige," "reputation") — can silently collapse back into re-litigating the same underlying comparison already resolved in the decision log, just with different surface wording. This happened twice in a row in a real session (Volaris vs Bluefish, 2026-07-20): a "prestige in a year" question and a follow-up "6-months-from-now scenario" question were both, in substance, the same Bluefish-vs-Volaris comparison already covered — the user had to call it out twice before it was caught.

Before asking any "new axis" question, check it against the decision log: does answering this question produce information not already captured by an existing Decision N entry? If the honest answer is "no, this just re-asks Decision 3/6/8 in new words," don't ask it — go back to the user and name the actual gap directly, or route question formation to a fresh model instance (per section 1) with an explicit list of what's already resolved and an instruction not to restate it. A model instance anchored on the prior rounds of the same conversation is the most common source of this failure — a fresh instance with a curated "already resolved, do not repeat" list is more reliable at staying on the genuinely new axis than continuing to ask from within the same anchored context.

6. A genuinely separate decision thread gets its own log doc — don't auto-append to whatever's open

Grilling sessions sometimes spin off a related but structurally distinct question mid-session (e.g. "should I keep interviewing elsewhere" or "how do I weigh prestige generally" surfacing while grilling a specific two-offer comparison). If the new thread is actually a different question being stress-tested — not just a new axis of the same comparison — it needs its own decision-log doc, not an append to the comparison-specific log already open. Mixing them makes both docs harder to resume correctly later (the offer-comparison log stays cleanly paused-and-resumable; the adjacent strategic question doesn't get buried inside it). If it's ambiguous which is happening, ask the user directly rather than guessing — auto-appending the wrong thread into an existing log is a real cost (has to be reverted and re-split), not a harmless default.

7. Before presenting a "new axis" as distinct from the main A-vs-B comparison, check whether it actually is one

When a user explicitly asks to explore a factor separately from the live A-vs-B decision (e.g. "let's talk about prestige on its own" or "focus on future interview optionality, not Bluefish vs Volaris again"), that's a request for a genuinely independent axis — not a request for the same comparison with different words. Before sending a question (your own, or one dispatched to an external model), check: can this question be answered without naming both live options as the entities being compared? If the honest answer requires "Option A does X to this factor, Option B does Y," it has NOT been separated — it's still the main comparison, just relabeled.

Root cause when this fails via external-model delegation (learned the hard way, escalated to "You alright mate?" after 3 collapses in one session): writing a rich context prompt that opens with both options' full profiles all but guarantees the returned question and "recommended answer" will resolve to an A-vs-B verdict, even when the prompt explicitly instructs "do not restate the comparison." The model pattern-matches on the option pair sitting at the top of the context, not on the instruction buried three paragraphs down. Two concrete mitigations:

• When dispatching to opus/sonnet/fable via claude -p for a "genuinely new axis" question, structure the prompt so the two options appear ONLY in a short "constraints" section near the bottom, and the top of the prompt is the axis-to-be-explored plus the general question about the user's life/career/situation. If the top of the prompt reads like the two options are the subject, the output will treat them as the subject.
• After receiving the external model's answer, before showing it to the user, apply the collapse check: does the "recommended answer" name Option A and Option B as the entities being compared? If yes, the axis wasn't actually separated — either reframe or say so upfront rather than shipping another comparison dressed as something new.

When the axis genuinely can't be separated (common when only 2 paths are on the table): say so plainly. The right fix is usually to reframe as a strategy/mitigation question that applies regardless of which option is chosen (e.g. not "which job preserves my optionality better" but "what do I need to do on the side, independent of which job I take, to keep this intact"). That shape genuinely doesn't collapse back into A-vs-B because the answer doesn't depend on which option wins. Alternatively, the user may not actually be asking about the live A-vs-B — they may be asking a broader standing question (e.g. "how many interview pipelines can I run in parallel without burning out" — a general operating rule, not a Bluefish-vs-Volaris question at all). Check which framing is live before continuing.

8. Decision-log scoping — one log per decision, not one log per session

When a grilling session touches multiple distinct decisions, resist the pull to append everything to whichever log is already open — that produces a mixed doc that's harder to reason about later and buries new-thread state under old-thread context. Rule: each decision gets its own log file, named for the decision, not for the day. Cross-link between them when threads reference each other, don't merge.

Signal you're about to make this mistake: the current log is about "Decision X vs Y" but the user's new question is about a broader factor that applies regardless of X or Y (e.g. "future interview optionality generally," "capacity limits for parallel pipelines," "prestige as a career strategy"). That's a new thread. Create a new log at ~/.hermes/memory/<topic>-grilling-log-YYYY-MM-DD.md, reference the original log in its opening paragraph for context, and keep them separate. If unsure, ASK before appending — the correction cost after the fact ("This is not the same one but a new one mate") is larger than a one-line confirmation up front.

9. Verify stated preferences and framings are CURRENT, not stale

Before applying any user-stated preference, target, or framing as the evaluation lens for a grilling session, verify it's still live — even (especially) when it's documented in a skill, memory entry, or past interview review. Preferences drift, especially post-layoff, post-offer, or after major life events. Applying a stale filter mechanically produces a well-reasoned but wrong verdict.

Real failure (Dash0 role-fit grilling, 2026-07-20): opened round 1 by pressure-testing Akash's "three-lane career-shape filter" (Staff IC at AI-native / EM of small senior team / DevRel), a framing baked into the interview-prep skill and multiple past review docs from May 2026. He responded: "three-lane what now?" — the framing was three months stale. His actual live filter was Brand + Optionality + Big Bucks, with a defensibility thesis underneath. The first round's entire premise was wrong, and I only found out because he flagged it in plain language.

Rule: on the FIRST round of a grilling session, before pressure-testing any target/preference/filter, verify it directly with the user in plain language:

• "Is this still how you think about X?"
• "When you say Y, does that still mean what it meant last month?"
• "The filter I've been using is A/B/C — is that still the live filter, or has it shifted?"

Name the filter EXPLICITLY, don't just apply it. A stale filter applied silently produces a session's worth of wasted analysis. A one-line verification catches it in the first round.

This is the same lesson as §4's freshness check for values instruments, applied to any framing carried from a prior session or skill. Career-shape targets, role-shape preferences, decision criteria, offer-comparison axes — all subject to drift, all need a freshness check before being applied as the lens.

8a. Don't dispatch a "next question" without checking your own prompt for injected bias

When routing question-formation to a stronger model (per §1), the failure mode is not the model — it's what you put in the prompt. Real failure (2026-07-21, consulting-offer session, Fable dispatch): I paraphrased the user's question as "a standalone outcome-priced offer that doesn't reference day-rate", asserted my paraphrase as the definition, cherry-picked competitor examples that supported it, and asked Fable to evaluate — with a token "be honest if it doesn't fit" bolt-on. Fable returned my hypothesis with citations. User caught it: "So you introduced bias into the prompt?"

The five checks to run against your own dispatch prompt BEFORE sending, in order:

1. Did I paraphrase the user's question or definition? If yes, quote the user's actual verbatim words as the primary source and label MY paraphrase as "the session AI's interpretation, which may be wrong — evaluate critically."
2. Did I pre-select supporting examples? If yes, include the counter-examples too, or don't include any and let the model surface its own.
3. Did I name "the crux" or "the real question"? If yes, that's my hypothesis, present it as one option among several — don't hard-frame it.
4. Does the prompt disclaim bias while structurally making one answer easy to reach and the other hard? The bolt-on disclaimer never rebalances the structural argument above it.
5. Did I flag prior AI errors that push the answer one direction only? If yes, flag the errors going the other direction too, or you're rebalancing bias in a new direction rather than removing it.

If any check fails, the answer coming back is your hypothesis dressed up. Fix the prompt or hand off to a fresh model instance with a genuinely neutral prompt.

See coding-agents skill § "Bias-injection through prompt framing" for the same rule from the delegation-mechanics side and a worked example.

8b. Don't dump prior-session shorthand on the user without checking they have the context

Related failure from the same Dash0 session: opened round 1 with references to "three-lane framing" and "the Orbital rejection" as if they were shared context. Akash's response: "three-lane what now? let's slowly build our way up here? I have literally no idea what you mean."

The agent can see the prior sessions, skills, memory, and review docs. The user cannot — they only have what's in this specific conversation window plus their own recall. Terminology from prior sessions is not shared context by default; treat it as jargon you're introducing.

Rule: if you're about to reference a framing, filter, decision, or event from a prior session that the user hasn't mentioned in the current conversation, either:

1. Define it briefly on first use — one sentence explaining what it is and where it came from. Then use the term.
2. Ask if the user still holds that framing — the freshness check from §7. Two birds, one stone.

Do not proceed on the assumption that "this was in your skill / memory / past review" means the user has it top-of-mind right now. They probably don't. Frustration signals like "what now?", "let's build our way up", "I have no idea what you mean" mean you've dumped jargon without scaffolding. Back up, define, then continue.

11. A well-defined task can still hide an unresolved decision — don't let file-writing substitute for grilling

Not every grilling-worthy decision arrives labeled as one. A task that reads as pure execution ("write the Week 2 offer doc," "finish the deliverable") can still embed genuine judgment calls — a pricing anchor, a floor, a format choice — that the user hasn't actually made yet. Writing the file, closing the Taskwarrior task, and syncing it to Dropbox is NOT the same as the user having confirmed the substance. If a deliverable contains a business/pricing/positioning judgment call that isn't already settled on record elsewhere, treat completing the mechanical action (the file exists) as a draft state, not a finished state — hold off on closing tasks or syncing until the user has actually reviewed the content.

Validated failure (2026-07-21, consulting offer doc): task #90 said "write the offer doc" — read as pure execution, so the doc was drafted, the task closed, and the file synced to Dropbox in the same turn with no check-in. The user's reaction: "Bro what? Actually confirm it with me? Let's have a discussion? Maybe a grilling session to finalise it?" The task had to be reopened and the whole thing re-run through actual grilling. The tell to watch for: if writing the deliverable required picking a number, a name, a format, or a stance that isn't already logged as decided elsewhere, that's a live decision wearing a task-completion costume — grill it before shipping it as done.

12a. Don't use the literal phrase "Recommended answer:" — it signals the direct-question antipattern

The opinionated stance §12 requires is a CLAIM rooted in specific source evidence, presented as a proposition the user reacts to (confirms/corrects/refines). The literal prefix "Recommended answer: X. What do you think?" is a menu-of-one dressed as a claim — it reads as "I picked X, please confirm" rather than "here's what the evidence says, agree or disagree." Real callout, 2026-07-25: "The grilling skill no longer has Recommended answer right?"

Correct shape: "Claim, built from [specific source files]: X. Grounding: [named evidence, quoted or paraphrased]. Agree/disagree/refine?" The header is a claim, not a recommendation. The user is reacting to the substance of the claim, not to the fact that you recommend it.

12b. When grilling content structure (article sections, doc beats, deck slides), show the actual beats, not the meta-framing

Distinct failure mode when grilling is about the shape of a written deliverable rather than a decision: the natural pull is to ask meta questions ("which lead does this section take — A or B?", "does the piece have a through-line?") when what the user actually needs is to see the concrete beats/bullets/sentences that will land in the artifact. Real callout, 2026-07-25 (GTV 2026 article structuring): after 3 rounds of meta-framing questions about section spine, lead choice, and structural shape, the user's response was "But actually spell it out point-wise here? I LITERALLY have no idea what you're saying" — the meta-questions had prevented him from ever seeing the actual section content he was being asked to evaluate.

Rule: when the grilling task is about content structure (article sections, doc layout, deliverable beats), skip the meta-framing question and go straight to a bulleted list of the actual beats the section will cover. Frame the question as "ship these beats, or push back on any of them?" — the user reacts to concrete content, not to abstract framing choices about content.

Signal you're in this failure mode: consecutive questions all ask about the shape/lead/spine/framing of a section without ever showing what the section will actually contain. If you can't quote a specific beat, sentence, or bullet the section will include, the user has no material to react to.

Title/heading tone matters — imperative-rigid framings will get rejected. When grilling section titles for an article/deck/doc, the wording of the title itself carries a tone signal separate from the beats underneath. Imperative-absolute constructions ("Structure Every X the Same Way", "Always Do Y", "Never Z") read as rigid rule-book prescription — the user will push back with "same way is the wrong advice" or "every isn't what I mean" even when the underlying beats are correct. Principle-framed constructions ("Aim for Consistency in X", "Keep Y Coherent", "Ground Z in W") read as craft advice — same beats underneath, different tonal register.

Real callout (2026-08-03, GTV 2026 article Section 4 title): proposed "Structure Every Evidence Document the Same Way" for a section whose beats were about consistent order/front-loading/criterion-mapping. User: "'Same Way' is the wrong advice. Let's reword it to make just the title a bit softer." Landed on "Aim for Consistency in Evidence Documents" — same beats, softer framing. User's explicit reason: "Every doc being the same is not the point here."

The test before proposing an imperative-absolute title: does the section's actual meta-claim require rigid uniformity, or does it require consistency-within-variation? If the beats allow flex (each doc still fits its own material), the title should reflect that. Reserve imperative-absolute titles for truly-uniform rules (e.g. page limits, formatting caps that genuinely admit no variation).

Signal you've violated this: the user reacts to the title specifically, separate from the beats — "the title is wrong", "reword the header", "that framing is off". The fix is usually not to rewrite the beats, but to soften the title while keeping the beats intact.

12. Every grilling question ships with a recommended, opinionated answer — never a bare menu

Real failure, 2026-07-21 (consulting offer-v1.md ICP/pricing grilling): the agent asked "does this distinguish ICP #2 by (a) stage, (b) buyer psychology, (c) deliverable type, or (d) some combination — which parts specifically?" User's response: "bro that's what we try to figure out based on grilling? You're just asking things directly here." An open, unranked multiple-choice list is not a grilling question — it just hands the analytical work back to the user, the opposite of what grilling is for.

Every question — whether formed by the primary session or delegated to an external model per section 1 — must ship with a specific, committed recommended answer attached, reasoned from whatever real evidence is on file (call transcripts, decision logs, pricing docs). The user reacts to a concrete claim (confirms, corrects, refines it); never hand them a bare menu and ask them to pick. If there isn't enough signal yet to commit to a recommended answer, that's the cue to go get more signal (read a file, pull a transcript, dispatch a question-formation call) before asking — not to punt the judgment call to the user in survey form.

The last-question-of-a-grill pitfall (validated 2026-07-23, AgentAya profile Q14): the failure mode is not just at the start of a session. In a multi-part questionnaire-style grill (Q1, Q2, ... QN with opinionated recommendations on each), the LAST question is where the pattern most often collapses. After N-1 rounds of committing to a recommended answer, "Ready for Q14 — anything else important for your profile?" reads to you as a natural wrap-up transition, and to the user as: you dropped the grilling framing on the final question. His response: "We were using the grill skill so you'd figure these out innit? Don't just ask the thing directly to me?"

The correction: on wrap-up / "anything else" / "final thoughts" questions especially, form an opinionated recommendation based on what you know about the user (from memory, career file, prior answers in the current session, public footprint) BEFORE asking. For Akash specifically, "anything else important for your profile" has obvious candidates: public writing footprint (thewriting.dev + specific talks), third-party validations (Global Talent Visa endorsement, prior employers), lane-clarity ("what NOT to send me"). Pick the strongest 2-3, commit, present as the recommendation, let him react. The wrap-up question is not exempt from §12 — it's the highest-risk place to violate it.

12a. Sequence foundational fact-gathering BEFORE interpretive claims

Opening a grilling session with a fully-loaded interpretive question ("here are three readings of your career file — which lands?") skips the foundational fact-gathering that would tell you which reading is even in-scope. The user reads it as diving head-first witho

…(truncated)