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

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