---
name: lawve-ai/irac-prompt-stephane-boghossian
source: https://app.decimal.ai/s/lawve-ai-irac-prompt-stephane-boghossian@1/SKILL.md
source_sha256: 4fc375b8bab6
---

# 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).