version: "1.0.0" name: elicit description: Force a structured second pass on something just generated — a spec, plan, design decision, financial model, code architecture, prose. Use when output looks "fine" but you suspect there's more depth, when a decision is high-stakes, when stress-testing assumptions, or when a workflow hits a fork and you want to think through alternatives before committing. Picks one of nine reasoning methods (pre-mortem, inversion, first principles, red team / blue team, Socratic, constraint removal, stakeholder mapping, analogical, second-order effects) and applies it to the recent output. Triggers: "elicit", "stress test this", "pre-mortem", "what could go wrong", "rethink this", "second pass", "challenge this". Note: for financial-model stress tests, defer to vault-auditor. For code adversarial review, defer to compound-engineering:review:adversarial-reviewer. For agent prompts, defer to rex-redteam.

Advanced Elicitation

A structured second pass on something just generated. The point is not to ask the LLM to "try again" — vague requests produce vague revisions. Instead, pick a named reasoning method and force the AI to re-examine its own output through that specific lens. Different methods surface different blind spots.

When to invoke

• A spec, plan, design, or model just got generated and the user wants to push deeper
• A high-stakes decision is about to be made (architecture, pricing, hiring, launch timing)
• The output reads "fine" but the user suspects gaps
• A workflow hits a fork — pick approach A or B
• Before committing to a multi-day implementation

How to run

Step 0 — direct invocation shortcut

If the user names a method directly (elicit pre-mortem, run inversion on this, red team this spec), skip Step 1 entirely and run that method. Only render the menu if the user invokes the skill without naming a method.

Step 1 — surface 3-5 relevant methods

Look at what was just generated. Choose 3-5 methods from the list below that fit the artifact. Don't offer all nine — too much choice paralyzes. Present them as a numbered list with one-line descriptions tailored to this artifact.

Example, after generating a pricing model:

Pick a method to stress-test this:

1. Pre-mortem — assume the pricing failed in 12 months, work backward to why

2. Inversion — design pricing guaranteed to fail, then invert

3. Stakeholder mapping — re-evaluate from buyer / champion / finance / competitor perspective

4. Second-order effects — what does this pricing cause that we didn't intend?

5. Constraint removal — drop the "must be profitable in year 1" constraint, what changes?

Step 2 — apply the method

The user picks one (or asks for a reshuffle if none fit). Apply it rigorously to the original output. Produce specific, actionable findings — not vague concerns. Each finding ties to a part of the original artifact.

Step 3 — present the delta

Show what changed or what should change. Format:

ELICITATION: [method name]
═══════════════════════════
 
Findings:
  1. [specific issue / insight tied to original artifact]
  2. [...]
 
Recommended changes:
  - [concrete edit to spec / plan / design]
  - [...]
 
Open questions for the user:
  - [...]

Step 4 — accept, discard, or repeat

The user decides what to act on. Offer to run a second method if the user wants more depth. Three passes is usually the cap before diminishing returns.

The nine methods

1. Pre-mortem analysis

Assume the project / spec / decision already failed 6-18 months out. Work backward to find why. Forces consideration of failure modes the optimistic plan glossed over.

Best for: specs, launch plans, architecture decisions, financial projections, hiring decisions.

2. Inversion

Instead of asking "how do we succeed?", ask "how do we guarantee failure?" — then invert each failure mode into a thing to avoid. Catches risks that forward thinking misses.

Best for: strategy, security review, UX decisions.

3. First principles

Strip away every assumption. Rebuild the conclusion from ground truth (physics, math, user behavior, business reality). Catches reasoning that inherited assumptions from convention rather than truth.

Best for: architecture, pricing, anything that "everyone does it this way".

4. Red team vs blue team

Attack your own work as the red team — find every weakness. Then defend it as the blue team. Two passes, opposite stances. Surfaces both vulnerabilities and the legitimate reasons the original choice still wins.

Best for: security architecture, competitive positioning, contentious technical decisions.

5. Socratic questioning

Challenge every claim with "why?" and "how do you know?" — recursively, three to five layers deep. Exposes claims that rest on assumption rather than evidence.

Best for: product claims, market sizing, "this will obviously work" reasoning.

6. Constraint removal

Identify every constraint the original output assumed. Drop them one at a time. See what the design becomes without each. Then add them back selectively. Reveals which constraints are real and which are inherited.

Best for: architecture, scope decisions, budget planning.

7. Stakeholder mapping

List every stakeholder affected by the decision. Re-evaluate the output from each perspective: their goals, their fears, what they'd push back on, what they'd amplify. Surfaces hidden veto holders and amplifiers.

Best for: launches, internal-tools rollouts, pricing changes, anything multi-party.

8. Analogical reasoning

Find parallels in other domains where this same problem was solved (or failed). Apply the lessons. The closer the analogy, the stronger the transfer.

Best for: novel products, new market entry, organizational design.

9. Second-order effects

For each first-order effect of the decision, ask "and then what?" — two layers out. Catches consequences the original analysis treated as someone else's problem.

Best for: policy decisions, pricing changes, platform rule changes, hiring patterns.

Notes for the assistant

• The user picks the method. Do not pick for them unless they explicitly ask.
• The first pre-mortem is almost always the right starting point for any spec or plan. If the user is unsure, recommend it.
• Be specific. "There might be edge cases" is not a finding. "If the user submits a webhook with a duplicate idempotency key while the original request is still in-flight, you'll double-charge them" is a finding.
• After applying the method, surface the changes the artifact actually needs — don't just list problems.
• If the user discards every finding, do not push back. Their judgment is the final word. Note the dismissed findings in the response so they're visible if a regression occurs later.
• This skill is portable. It works on any artifact: code, prose, financial models, designs, plans, hiring decisions, partnership terms.