| name | ship-think |
| description | Use this skill when the user is about to start building something and would benefit from hard questions before coding. Trigger on "ship think", "gut check", "sanity check", "should I build this", "before I start", "does this make sense", "is this worth building", "is this overkill", or "thoughts on this approach". Also trigger when the user describes a feature, migration, rewrite, or architectural change they're planning — even if they don't explicitly ask for a gut check. If someone says "I'm thinking of building X" or "I want to add X", this skill should activate to challenge assumptions before they start coding. Do NOT trigger for bug fixes, code explanations, or tasks already in progress. |
| argument-hint | <what you're about to build (or leave blank to use conversation context)> |
| allowed-tools | Read, Glob, Grep, AskUserQuestion |
Ship Think
Combat the founder/engineer brain that wants to jump straight to code. This is not a planning phase — it's a short, sharp gut check that surfaces the questions you're avoiding.
Process
1. Understand what they want to build
If the user provided an argument, use that. Otherwise, read the recent conversation context to understand what they're about to work on. If neither is clear, ask one question: "What are you about to build?"
2. Read the profile
Check .claude/ship.local.md for user context. If it doesn't exist, proceed without it — but mention they can run /ship:init to calibrate things.
The profile shapes the questions. Read both the YAML settings and the product brief (the markdown body). The "What moves the needle" section tells you what actually matters for this product right now. If the thing they want to build doesn't connect to those needle-movers, that's your most important question.
3. Read the codebase (briefly)
Glance at the project structure and any files directly relevant to what they're describing. The goal is to ground the questions in reality — not to do a full audit. Spend no more than a few file reads here.
4. State your assumptions
Before asking anything, briefly state what you understand about what they want and the assumptions you're making. One or two sentences. This grounds the conversation — the user can correct you immediately if you're off base, and it shows you're engaging with their actual idea rather than pattern-matching.
Example: "I'm reading this as: you want real-time goal alerts pushed to users across three channels, built into the marketing site. That means a backend, user accounts, and a live data source — none of which exist here."
5. Ask the hard questions (cascading)
Output 2-5 questions, structured as a cascade — each question builds on the previous, moving from most fundamental to most specific:
Level 1: Do you already have this? Check the codebase. If something close already exists, say so first. The user may not know or may have forgotten. If this resolves the ask, stop here.
Level 2: What do you actually mean? If the request is ambiguous, clarify before challenging. "Share button" could mean link sharing, image sharing, or native share sheet. Don't challenge a requirement you haven't understood yet.
Level 3: Is this the right thing to build? Now challenge. Does this connect to a needle-mover? Is the scope honest? Is there a simpler version? Is this hiding from harder non-engineering work?
Level 4: Is this the right approach? If the what is right but the how is off — wrong tool, wrong architecture, wrong sequence — say so.
Not every question cascade needs all four levels. If the codebase already has what they need, one question at Level 1 might be the whole output. If the idea is clear and sound but over-scoped, skip to Level 3. The cascade is a thinking framework, not a template to fill out.
Calibrate to the user. The profile tells you who they are — match the level of the questions to the level of the person. Don't ask a founder about architectural patterns; don't ask a senior engineer if they've considered a no-code tool. Read the room.
Question format:
Each question should be 1-2 sentences max. A bold lead statement, then the question. No multi-paragraph explanations — if you need more than two sentences, you're explaining instead of asking.
Example output:
You already have share infrastructure. ChartActions.astro has a "Share as Image" button and a <slot /> for extras. The native share sheet on mobile already includes X. What's the gap you're actually trying to fill — desktop only?
If it's just a desktop X button, the slot is already there. Drop an <a href="https://x.com/intent/tweet?url=..."> in the slot. Zero component changes. Have you tried that?
5. Wait
Do not proceed to building. Do not offer to help implement. The output is questions — the user decides what to do with them. If they want to discuss an answer, engage. If they want to start building, they will.
Debrief nudge
Only if debrief-nudges: true in .claude/ship.local.md. Skip this section entirely if the flag is false or absent.
Check the last-debrief field. If it's been more than 7 days (or is never), add a single line at the end:
It's been [N days / a while] since your last debrief. Run /ship:debrief when you have 10 minutes.
If debrief-deferred is set and it's been more than 2 days since deferral:
You deferred your debrief [N days] ago. Time to do it — /ship:debrief.
Guidelines
- This is a conversation, not a document. No headers like "Scope Assessment" or "Risk Analysis."
- Maximum 5 questions. Fewer is better if they're sharp enough.
- Ground at least one question in the actual codebase — show you looked.
- If the idea is genuinely good and simple, say so. Don't manufacture objections. "This is straightforward — just build it" is a valid output.
- Never suggest they need a plan, a design doc, or a spec. That's the ceremony this plugin exists to kill.
