---
title: "mk:elicit"
description: "Structured second-pass reasoning — re-examine review verdicts, plans, or analyses through named methods (pre-mortem, red team, Socratic, inversion, first principles, and more)."
---

# mk:elicit

Structured second-pass reasoning that re-examines an existing output (review verdict, plan, analysis) through a named reasoning method. Surfaces insights that generic "make it better" requests miss. Does NOT perform initial review (use `mk:review`), create implementation plans (use `mk:plan-creator`), or do open exploration (use `mk:brainstorming`).

## What This Skill Does

- Re-examines existing artifacts through one of 8 named reasoning lenses
- Produces structured findings with severity ratings (CRITICAL / IMPORTANT / INFORMATIONAL) and actionable recommendations
- Appends analysis as a supplementary section to the original artifact (never overwrites)
- Auto-suggests a reasoning method based on context when user does not specify one

## When to Use

- After `/mk:review` verdict -- deepen analysis before Gate 2
- After plan creation -- stress-test assumptions before Gate 1
- After any agent output when user wants a specific angle of analysis
- When user says "dig deeper", "what am I missing", "challenge this"

**NOT this skill if:** you have no existing artifact to re-examine -- use `mk:brainstorming` for open exploration, or `mk:problem-solving` for approach-stuck situations.

## Example Prompt

```
Run a pre-mortem analysis on our deployment plan for the payment system migration. Assume it shipped last Friday and failed in production — what broke, why, and what should we change before the real deployment?
```

## Core Capabilities

### Reasoning Methods

| Method | Lens | Best For |
|--------|------|----------|
| **Pre-mortem** | "Assume this shipped and failed. Why?" | Risk discovery, failure mode analysis |
| **Inversion** | "What would make this maximally wrong?" | Assumption testing, edge cases |
| **Red Team** | "You are an attacker. How do you exploit this?" | Security analysis, adversarial thinking |
| **Socratic** | "What evidence supports each claim?" | Logic validation, gap detection |
| **First Principles** | "Strip assumptions. What's fundamentally true?" | Architecture decisions, design simplification |
| **Constraint Removal** | "What if [constraint X] didn't exist?" | Innovation, scope exploration |
| **Stakeholder Mapping** | "Who else is affected? What do they need?" | Impact analysis, requirements gaps |
| **Analogical** | "What similar system solved this differently?" | Alternative approaches, pattern matching |

### Auto-Suggestion Logic

When invoked without a method choice, the skill suggests based on context:

| Context | Suggested Method |
|---------|-----------------|
| Review found security issues | Red Team |
| Review found low coverage | Pre-mortem |
| Plan has many assumptions | First Principles |
| Architecture decision | Inversion |
| Complex feature with many stakeholders | Stakeholder Mapping |
| Default / unclear | Socratic |

## Arguments

No positional arguments. Invoked by name after the primary skill output exists:

```
/mk:elicit
```

The skill presents the method table and asks the user to pick one. The user may also specify a method directly in the prompt (e.g., "run pre-mortem on this plan").

## Workflow

1. **Load context** -- Read the output being re-examined (verdict file, plan file, or conversation context)
2. **Present methods** -- Show the reasoning methods table; ask user to pick one (or auto-suggest based on context)
3. **Apply method** -- Re-examine the output through the chosen lens
4. **Produce analysis** -- Structured output with:
   - Method applied
   - Key findings (numbered, actionable)
   - Severity: CRITICAL / IMPORTANT / INFORMATIONAL
   - Recommendations (what to change, if anything)
5. **Optional repeat** -- User may pick another method for multi-lens analysis

## Usage

```
/mk:elicit                           # Interactive: pick a method
/mk:elicit pre-mortem on this plan   # Direct: apply pre-mortem
```

## Output Format

```markdown
## Elicitation: [Method Name]

**Target:** [what was re-examined]
**Method:** [brief description of the lens applied]

### Findings

1. **[CRITICAL]** [finding] -- [recommendation]
2. **[IMPORTANT]** [finding] -- [recommendation]
3. **[INFORMATIONAL]** [finding] -- [observation]

### Summary

[1-2 sentence synthesis of what this method revealed]

### Action Required

- [ ] [specific action items, if any]
```

## Integration with mk:review

After the review verdict (step-04), the reviewer MAY offer elicitation:

```
Review complete. Verdict: WARN (2 warnings).

Would you like to run elicitation on this verdict?
Pick a method: pre-mortem | inversion | red-team | socratic | first-principles | skip
```

Elicitation output appends to the verdict file as a supplementary section. It does NOT change the verdict (PASS/WARN/FAIL) -- it adds depth. If elicitation reveals a CRITICAL issue, the user must manually trigger a new `mk:review` pass to produce a revised verdict.

## Common Use Cases

- Stress-testing a deployment plan with pre-mortem before a major release
- Running Red Team analysis on an auth module that passed review but feels risky
- Applying First Principles to simplify an over-engineered architecture decision
- Using Stakeholder Mapping to identify unrepresented user groups before shipping
- Running Socratic questioning on a plan with many unverified claims

## Pro Tips

- **Methods are not commutative -- order changes the output.** Running Red Team then Socratic surfaces attack vectors first and validates them with evidence. Reversing to Socratic then Red Team validates assumptions before probing attacks, and often kills the adversarial framing. Always apply methods in the order matching the user's primary concern.
- **Pre-mortem needs a concrete ship date and scope** to avoid degenerating into a generic worry list. Attach it to a specific, scoped output (the plan, the feature, the migration).
- **Inversion only works reliably on binary decisions** -- yes/no (ship vs don't ship, add vs remove). For multi-option trade-offs, use Constraint Removal or Stakeholder Mapping instead.
- **Set a max depth before Socratic elicitation** -- "What evidence supports this claim?" has no natural stopping point. Stop at 3 levels of questioning or when no new claims emerge.
- **Elicitation does not change gate decisions** -- a CRITICAL finding from Red Team does not automatically trigger Gate 2 re-evaluation. You must manually run a new `mk:review` pass.
- **What this skill does NOT do:** replace the review, change verdicts or gate decisions, generate code, or run automatically (always user-triggered).
