withqwerty/ship/init

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:

1. What's your role? (founder, solo dev, tech lead, non-technical founder, etc.)
2. What stage is this project at? (prototype/MVP, early users, scaling, mature)

About the product:

1. In one sentence, what does this product do and who is it for?
2. 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:

1. What matters most in terms of how you build? (speed to market, code quality, security, user experience, cost — pick up to 2)
2. Default review mode: brutal or kind?
3. 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.md is already in .gitignore. If not, append it.
• Briefly confirm: "Added .claude/*.local.md to .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.