Irac Prompt Stephane Boghossian

IRAC Prompt

A lawyer doesn't hand an associate "go look into the housing thing." They write a memo: here's the issue, here are the rules that govern it, here's the analysis of how they apply, here's the conclusion I want. That same structure is the single biggest lever on frontier-model output quality. This skill turns a vague ask into that brief.

When to use

• The user has a fuzzy build/research/drafting task and wants a good prompt, not a guess.
• Before kicking off a non-trivial vibecode task (pairs naturally before /grill-me and /yalla).
• Repackaging a task to hand to a sub-agent or to HAQQ's Justinian.

The method

Take the user's raw ask and rewrite it into four labelled blocks. Lead with the issue, end with the conclusion — models weight the top and bottom of a prompt most.

I — Issue (top)

One or two sentences: what exactly are we trying to do, and for whom. The single problem statement. If the user gave three problems, pick the one that matters or split into three prompts. *No problem, no solution, no value.*

R — Rule (constraints)

The governing facts the model must respect:

• Hard constraints (stack, language, libraries, file paths, output format).
• Domain rules (for legal: the statute/clause/jurisdiction; for code: the API contract, existing patterns to match).
• Non-goals — what NOT to do. Lawyers specify what they don't want; do the same.
• Definition of done / what "good" looks like, ideally measurable.

A — Analysis (the reasoning the model should do)

• Why this matters and who the real user is.
• The known hard part / where prior attempts or weaker models failed.
• The approach or first principles to apply (or explicitly: "figure out the approach, here are the inputs").
• Edge cases to handle: empty state, auth failure, network error, malformed input.

C — Conclusion (the ask)

The concrete deliverable, restated crisply. What artifact, in what shape, verified how.

Output contract

Emit the rewritten prompt inside a fenced block the user can copy verbatim, with the four headers (Issue / Rule / Analysis / Conclusion). Then, below the fence, a 2–3 line note on what you inferred or assumed, and any gap worth a /grill-me pass. Don't pad — if a block is genuinely empty (rare), say so rather than inventing constraints.

Modifiers (the user can ask for any of these)

--adversarial — append a three-agent split so no agent grades its own homework (Mike's core trick: *"you don't ask the associate if they double-checked it; you give it to someone else"*):

> Run this as three roles. Planner: produce a step plan from the Issue/Rule, no code.

> Executor: implement the plan against the Rule constraints. Tester: adversarially

> verify the Executor's output against the definition-of-done and edge cases; report failures,

> do not fix. Loop Executor↔Tester until the Tester passes. (Maps to /grill-me + /lecun-world-model.)

--budget — prepend a context-budget directive (Mike: performance "drops off a cliff" as context fills):

> Treat the context window as a budget, not a dumpster. Keep this prompt lean. Use parallel

> sub-agents with narrow jobs and fresh context rather than one bloated agent. Compact or start

> a new conversation between phases. Load only the Skills/files each step needs.

--voice — the user dictated this; tolerate disfluency, infer structure, don't nitpick phrasing.

--legal — Issue/Rule/Analysis/Conclusion map literally to IRAC. Rule = the statute/clause + jurisdiction; Analysis = application to facts; flag anything JUDGMENT-BOUND (hand to /law-as-code-audit). Never assert a legal conclusion the source text doesn't support.

Worked example

Raw ask: "make something that checks if building permits are gonna get rejected"

Output:

ISSUE
Build a tool that, given a set of ADU building-permit blueprints, flags the corrections a California city plan-reviewer will require — before submission — for the builder filing the permit.

RULE
- Inputs: multi-page blueprint PDFs, table-sized, with dense margin annotations.
- Constraint: OCR alone strips annotations from the wall/element they reference —
  preserve visual context (which wall a "thickness" note belongs to).
- Stack: Anthropic SDK, parallel sub-agents, Skills for the ruleset. No paralegal in the loop.
- Done = ≥70% agreement with the city's real correction letters on a held-out set.
- Non-goal: do not auto-submit or give legal advice; output is an action plan a human files.

ANALYSIS
Prior generation models can't do this — that's the point. The hard part is grounding each rule check in the right region of the blueprint. Chunk the blueprint, pass each chunk + the relevant rules, ask "what's wrong here," then aggregate. Handle: missing pages, illegible scans, blueprints with no annotations.

CONCLUSION
A pipeline that ingests blueprints and returns a precise, per-item correction action plan in <20 min, benchmarked hourly against the correction-letter set.

*Inferred: ADU + California + builder-side from "permits." Open question for /grill-me: builder-side only, or also the city reviewer side? (CrossBeam ended up doing both.)*

Notes

• This skill writes a *prompt*, it doesn't execute the task.
• Inspired by Michael T. Brown's CrossBeam — the personal-injury lawyer who, never having written a line of code, beat 13,000 builders to win Anthropic's 2026 global hackathon by prompting the model the way he briefs an associate. Three modifiers: --adversarial (a plan→execute→test agent split so no agent grades its own homework), --budget (treat the context window as a budget, not a dumpster), and --legal (literal IRAC that flags judgment-bound clauses).