git:20260822.c65a69b to git:20260830.88b96b1

3 added, 3 removed. Audit A to A.

---

name: grill-intent

description: Adversarial review of an existing intent spec. Walk the spec field-by-field and pressure-test the weakest claims before code gets written against them. Use when an intent feels "done" but the user wants to stress-test it, or before handing it to an implementation agent.

---

<what-to-do>

- Load the active intent. If a `PATHMODE_API_KEY` is set, call `get_current_intent` (Pathmode MCP). Otherwise read `intent.md` from the project root.

+ Load the active intent from `intent.md` in the project root first. That file is bound to this repository and remains the content authority even when `PATHMODE_API_KEY` is set. Only call `get_current_intent` when no local file exists. If the file carries a cloud id, use that id for any team-only note call below.

Walk the spec field-by-field — objective, outcomes, edge cases, constraints. For each field, find the weakest claim and pressure-test it. Ask ONE pointed question at a time. For each question, propose your best-guess answer based on the spec and the codebase.

- When a weakness is confirmed, edit the spec. In team mode, call `log_implementation_note` to record the change. In local mode, write back to `intent.md`.

+ When a weakness is confirmed, edit the spec itself — not a note about it. Write the change back to `intent.md` and save with `intent_save` (it preserves the file's identity and syncs in team mode; use `update_intent` only when no local file exists). Then, in team mode, call `log_implementation_note` to record WHY the change was made: the note reaches the next agent's prompt, the spec carries the change.

Stop when all five dimensions below pass, or the user explicitly accepts a known weakness.

</what-to-do>

<supporting-info>

## The five dimensions

1. **Objective** — Does it name who is harmed? Is it specific enough to disqualify other interpretations?

2. **Outcomes** — Are they observable state changes, not activities? Could someone verify this in 5 minutes without asking the spec author?

3. **Edge cases** — Are they real edge cases, or restatements of the outcome failing?

4. **Constraints** — What must NEVER happen? An intent with zero constraints has no teeth.

5. **Contradictions** — Do any two fields imply opposite things?

## Stop conditions

- All five dimensions pass — the spec is agent-ready

- - The user explicitly accepts a known weakness — record it with `log_implementation_note` so it's visible to future agents

+ - The user explicitly accepts a known weakness — record that acceptance as a decision in the spec with `intent_save`; when a cloud id is available, one consolidated `log_implementation_note` may preserve rationale that does not fit the decision field

- More than 6 turns without surfacing new issues — the spec is settled

## Difference from compile-intent

- `compile-intent` BUILDS a spec from a vague problem

- `grill-intent` BREAKS an existing spec to find weaknesses

Run grill before treating a spec as agent-ready. If you compile a spec and immediately hand it to an implementation agent, you're trusting your first draft — and first drafts are wishful.

## Codebase grounding

When proposing answers, look at the actual code. If the spec says "users see a spinner during payment" but the codebase has no spinner component on the payment path, that's a gap worth surfacing. The point isn't to be right — it's to be specific enough that the user can correct you.

</supporting-info>