withqwerty Ship Init
Create the user's ship profile at .claude/ship.local.md. This file is two things: a settings file that calibrates ship skills, and a living product brief that every skill reads to understand what matters.
Process
1. Check for existing profile
Read .claude/ship.local.md in the current project. If it exists, show the current profile and ask whether to update it or start fresh.
2. Ask the questions
Ask these one at a time, conversationally. Do not dump all at once.
About you:
- What's your role? (founder, solo dev, tech lead, non-technical founder, etc.)
- What stage is this project at? (prototype/MVP, early users, scaling, mature)
About the product: 3. In one sentence, what does this product do and who is it for? 4. What are the 1-2 things that would actually move the needle right now? (Not engineering tasks — product/business outcomes. e.g. "get first 100 users", "reduce churn", "launch the paid tier", "prove the core loop works")
Ship settings: 5. What matters most in terms of how you build? (speed to market, code quality, security, user experience, cost — pick up to 2) 6. Default review mode: brutal or kind? 7. Want debrief nudges? (yes/no — default: no)
3. Write the profile
Write .claude/ship.local.md with YAML frontmatter and a markdown body:
---
role: founder
project-stage: mvp
default-review-mode: brutal
build-priorities:
- speed to market
- user experience
always-flag:
- security
- data loss
debrief-nudges: false
last-debrief: never
---
# [Product Name]
[One sentence: what it does and who it's for.]
## What moves the needle
- [Concrete outcome 1 — framed as a result, not a task]
- [Concrete outcome 2]
## Current reality
[2-3 sentences: where the product actually is right now. What's working, what's not, what's unknown. Written by you based on the conversation and a glance at the codebase. Be honest — this is the "you are here" marker.]
The markdown body is the product brief. It gets updated by /ship:debrief as priorities evolve. Every ship skill reads it to understand not just who the user is, but what they're building and what matters for it right now.
The always-flag field defaults to [security, data loss]. The last-debrief field tracks when /ship:debrief was last run.
4. Shared repo check
Ask: "Is this repo shared with others, or just you?"
If shared (or user prefers private):
- Check if
.claude/*.local.mdis already in.gitignore. If not, append it. - Briefly confirm: "Added
.claude/*.local.mdto .gitignore — your profile won't be committed."
If solo / user wants to commit it:
- Do nothing. The file will be tracked normally.
5. Confirm
Show the user what was written. Tell them they can re-run /ship:init anytime, or edit the file directly. Mention that /ship:debrief will keep the product brief evolving.
Guidelines
- Keep the conversation warm but efficient. Three minutes max.
- The product questions (3 and 4) are the most important. Push for specificity. "Grow the business" is not a needle-mover — "get 10 paying customers" is.
- Glance at the codebase to write the "Current reality" section. A quick look at the project structure, README, and recent commits is enough to write 2-3 honest sentences.
- Do not over-explain what the profile is for.
- The product brief should read like Jason Fried wrote it — clear, concise, opinionated about what matters. No corporate language, no hedging.