Use when user needs to think through decisions, explore trade-offs, or challenge assumptions before acting. Triggers: 'think with me', 'help me decide', 'what am I missing?', 'devil's advocate', 'pre-mortem'.
Purpose: Facilitate structured thinking through decisions, trade-offs, and unknowns using cognitive frameworks. Forces genuine dialogue by restricting tool access — Claude becomes a thinking partner, not a doer.
Key innovation: The tool restriction IS the feature. No Write, Edit, or Bash access means Claude cannot jump to implementation. Discussion summary stays in conversation; persistence is delegated to other skills.
User triggers:
Workflow position:
/shipkit-spec (clarify what to build)/shipkit-engineering-definition (think through decisions before capturing)/shipkit-plan (explore approaches before committing)Recommended:
.shipkit/why.json — Project vision provides decision-making context.shipkit/architecture.json — Existing decisions constrain new ones.shipkit/stack.json — Technical constraints shape optionsIf missing: Proceed without — the skill works for greenfield decisions too. Ask the user for relevant context instead.
Read available context files (do NOT create or modify any files):
Read: .shipkit/why.json → Project vision, goals, constraints
Read: .shipkit/architecture.json → Existing decisions and rationale
Read: .shipkit/stack.json → Technology choices and constraints
If files don't exist, skip silently. The discussion can proceed without them.
Purpose: Understand what's already been decided so the discussion builds on existing context rather than contradicting it.
Ask the user to define the discussion scope using AskUserQuestion.
Present two questions:
Question 1 — Topic Confirmation: Restate what you understand the user wants to discuss. Ask them to confirm or refine.
Question 2 — Discussion Style:
Offer three modes (see references/discussion-styles.md):
| Style | Description |
|---|---|
| Socratic | I ask questions, you discover answers. Best for early exploration. |
| Direct | I provide structured analysis and observations. Best for experienced builders. |
| Framework-Guided | I walk you through a specific thinking framework step by step. Best for complex decisions. |
Question 3 — Propose Exit Criteria: Based on the topic, propose 2-4 semantic exit criteria — specific decisions or clarity points that signal the discussion has achieved its purpose.
Exit criteria examples:
Ask the user to confirm, modify, or add to the exit criteria.
Track these criteria throughout the discussion. They determine when the discussion is complete.
Based on the topic and style, select the appropriate framework from references/frameworks/:
| Problem Pattern | Framework | Reference |
|---|---|---|
| Binary/multi-option choice | Decision Matrix | references/frameworks/decision-matrix.md |
| Challenging assumptions | First Principles | references/frameworks/first-principles.md |
| Risk assessment | Pre-Mortem | references/frameworks/pre-mortem.md |
| Ripple effects analysis | Consequence Mapping | references/frameworks/consequence-mapping.md |
| Stress-testing a preference | Devil's Advocate | references/frameworks/devils-advocate.md |
| Comparing 3+ options | Option Evaluation Rubric | references/frameworks/option-evaluation-rubric.md |
Read the selected framework reference before applying it.
Apply the framework CONVERSATIONALLY:
Critical rule: Never dump an entire framework as output. The framework guides YOUR questions — the user shouldn't feel like they're filling out a form.
Throughout the discussion, actively surface what the user hasn't considered.
Listen for implicit beliefs and surface them:
Check who else is affected:
Look for gaps in the analysis:
When you detect a potential blind spot:
Periodically check the exit criteria from Step 2.
When criteria are substantially met (or the discussion has naturally reached a conclusion):
Present a concise summary of:
Review each exit criterion:
Based on what was discussed, recommend the appropriate skill to capture decisions:
| If the discussion produced... | Suggest |
|---|---|
| Architecture or technology decision | /shipkit-engineering-definition — to log the decision with rationale |
| Feature requirements or scope | /shipkit-spec — to formalize into a specification |
| Implementation approach | /shipkit-plan — to create an actionable plan |
| Project vision or strategy | /shipkit-why-project — to update project vision |
| Data model or contract decisions | /shipkit-engineering-definition — to define in engineering blueprint |
| Risk assessment or launch criteria | /shipkit-preflight — to track readiness |
Do NOT write files yourself. The discussion summary is displayed in conversation only. The user decides whether and how to persist it.
Ask: "Would you like to explore any of these further, or shall we move to capturing these decisions?"
Read, Glob, Grep, AskUserQuestionWrite, Edit, Bash, NotebookEdit.shipkit/why.json — Project vision and goals.shipkit/architecture.json — Existing architecture decisions.shipkit/stack.json — Technology stack.shipkit/specs/active/*.json — Active specifications (if relevant to discussion)Write Strategy: NONE (This skill does not write files)
Discussion output stays in conversation. Persistence is delegated to other skills via the handoff in Step 5.
/shipkit-master → Routes thinking/discussion requests here/shipkit-engineering-definition → Update engineering blueprint/shipkit-spec → Formalize feature requirements/shipkit-plan → Create implementation plans/shipkit-why-project → Update project vision/shipkit-engineering-definition → Define engineering blueprint (includes data contracts)This skill sits BEFORE action-oriented skills. It ensures decisions are well-reasoned before they become artifacts. The output is clarity, not files.
The discussion produced decisions that need persistence. Suggest the appropriate skill based on what was decided.
If the user doesn't want to persist now, that's fine — the conversation history contains the reasoning. But remind them that conversation context doesn't survive sessions.
Natural next steps:
/shipkit-engineering-definition — if an architecture decision was made/shipkit-spec — if a feature scope was clarified/shipkit-plan — if an implementation approach was chosenreferences/README.mdreferences/frameworks/decision-matrix.mdreferences/frameworks/first-principles.mdreferences/frameworks/pre-mortem.mdreferences/frameworks/consequence-mapping.mdreferences/frameworks/devils-advocate.mdreferences/frameworks/option-evaluation-rubric.mdreferences/discussion-styles.mdRemember: The restriction is the feature. You are a thinking partner, not a doer. The best outcome is a human who is clearer about their own thinking, not a file that was written.