mk:elicit

Elicitation — Structured Second-Pass Reasoning

Re-examine an existing output (review verdict, plan, analysis) through a named reasoning method. Surfaces insights that generic "make it better" requests miss.

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.

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 |

Workflow

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

Auto-Suggestion Logic

When invoked without a method choice, suggest 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 |

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.

Gotchas

• Reasoning methods are not commutative — order changes the output — running Red Team then Socratic surfaces attack vectors first and then validates them with evidence, producing a security-focused analysis; reversing to Socratic then Red Team validates assumptions before probing attacks, and often kills the adversarial framing entirely; always apply methods in the order that matches the user's primary concern.
• Socratic method loops indefinitely without a termination criterion — "What evidence supports this claim?" applied recursively has no natural stopping point; without an explicit depth limit (e.g., stop at 3 levels of questioning or when no new claims emerge), the agent keeps decomposing until the context window fills; set a max depth before starting Socratic elicitation.
• Inversion only works reliably on binary decisions, not multi-option trade-offs — "What would make this maximally wrong?" applied to a 3-option architectural choice produces a vague worst-case mix; inversion is sharp when the decision is yes/no (ship vs don't ship, add vs remove); for multi-option decisions, use Constraint Removal or Stakeholder Mapping instead.
• Pre-mortem degenerates to a generic worry list without a concrete ship date and scope — "Assume this shipped and failed" requires a specific artifact (the plan, the feature, the migration) to be meaningful; if the target is vague ("our auth system"), the pre-mortem produces abstract risks ("scalability", "security") that don't map to actionable mitigations; always attach pre-mortem to a specific, scoped output.
• Elicitation output appended to the verdict file does NOT change the gate decision — users sometimes interpret a CRITICAL finding from Red Team elicitation as requiring a Gate 2 re-evaluation; the skill explicitly does not change verdicts; if the elicitation reveals a CRITICAL issue, the user must manually trigger a new mk:review pass to produce a revised verdict before proceeding to Phase 5.

What This Skill Does NOT Do

• Does NOT replace the review — it supplements it
• Does NOT change verdicts or gate decisions
• Does NOT generate code — analysis only
• Does NOT run automatically — always user-triggered