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

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:
   • 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

Auto-Suggestion Logic

When invoked without a method choice, suggest based on context:

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