create-swe-project

Slipway — launch a new project

Take a project idea to a completely set-up, working project in ~/Dev/<codename>: gate-green, git-initialised, native projects generated, conventions wired. The trick is that scripts/scaffold.sh + templates/ already contain everything common between projects (distilled from zephyr, perch, fledgeling-app, dAIolog and the team-files operating specs) — so your job is the decisions, and the script's job is the files. Do not hand-write files the templates cover; that is what makes setup cheap.

Running as a Gemini model? Read gemini.md in this directory first, then follow this file with the overrides it names. It converts §5's launch-pipeline phases into a chain of files (DESIGN.md, UX.md, INDEX.md) with a filled mock-inventory ledger, a bound ledger read back off the built marketing page, and a route-out for the static-page and brownfield work the corpus measures this family collapsing on. Other models skip it.

0 — Doctor

Run <skill-dir>/scripts/doctor.sh (read-only JSON) before the interview so recommendations match the machine: no macos/ios module without xcodegen, no 1Password seeding without op, no rust without cargo. Mention anything missing that the chosen modules would need.

1 — Understand the idea, generate codenames

From the user's idea, decide which modules fit and generate three codename options: single word, lowercase, evocative rather than descriptive — the portfolio precedent is zephyr, perch, anvil, loupe, tare, sift, margin. Check ls ~/Dev first and never propose a name that collides with an existing directory.

2 — Ask the clarifying questions up front (one round)

One AskUserQuestion call, all questions together, before anything is created:

• Codename — the 3 generated options (put your recommended one first, marked "(Recommended)"); the built-in Other lets them type their own. Show what each implies: ~/Dev/<codename>, <codename>.local.
• Modules (multiSelect) — web Next.js app · api NestJS API · macos SwiftUI app · ios SwiftUI iOS app · rn React Native (Expo) mobile app · tokens design-tokens package · data Mongoose+Redis layer · auth sign-in + emails + dev login · admin allowlisted admin console · push APNs notifications · waitlist referral-loop pre-launch waitlist · observability Sentry wiring (inert until DSN) · rust cross-OS core crate. Infer before asking: a product with accounts implies auth (which implies data); "admin", "back office", "moderation" implies admin; a native/mobile app with alerts implies push; a SaaS gets web+tokens+data+auth by default; a marketing site gets web+tokens only; an unvalidated/pre-launch idea adds waitlist. Put the inferred set in the options as the recommended choice and let the user adjust — ask rather than guess only when the idea genuinely doesn't settle it. Implications are automatic in the script (push→auth→data→web; admin→data).
• Mobile approach (only when the idea implies a mobile app and the modules answer hasn't settled it) — native Swift/SwiftUI (ios, XcodeGen, simulator-first) vs React Native/Expo (rn, one codebase for iOS+Android, hoisted pnpm + monorepo Metro per BP §18). Recommend Swift when the app is Apple-only or needs deep platform integration; Expo when Android matters or the team iterates fastest in React.
• macOS style (only when macos selected) — window (Recommended): native NavigationSplitView shell with sidebar + top nav with search · menubar: MenuBarExtra agent app, no Dock icon (LSUIElement). Passed as --macos-style window|menubar.
• Bundle-id prefix (only when macos/ios/rn selected) — app.<codename> (Recommended) · dev.<codename> · com.<codename> · custom. Apps get .mac / .ios / .mobile suffixes — distinct identity per sibling app from day one (BP §18).
• GitHub org — where the repo will live: fledgeling-co (personal-product studio) · lprhodes (experiments/personal) · Diolog26 / DiologIR (Diolog work) · none for now. Infer from the idea (a Diolog feature → Diolog org; a product → fledgeling-co; a quick experiment → lprhodes) and put the inferred org first. Passed as --github-org: the remote is set and the gh repo create --push command lands in next-steps — nothing is pushed without the user running it.
• macOS distribution (only when macos selected) — direct (Recommended): Developer ID + notarized DMG, no sandbox · mas: Mac App Store / TestFlight, App Sandbox on (a review requirement). Passed as --macos-dist; it selects the entitlements file, so it must be asked up front, not retrofitted.
• Design reference (only when a UI surface is selected) — a site or brand to bootstrap DESIGN.md from (via design-md-from-website, which measures real computed styles), or skip to design fresh later. Passed as --design-ref; recorded in the manifest and next-steps.
• 1Password — which account/team id and vault this project's secrets live in. Run op account list and op vault list --account <id> first and present the real values as options (plus "skip"). The chosen pair is passed as --op-account / --op-vault and seeded into apps/web/.env.local (identifiers only — actual secret values are resolved later by scripts/env-pull.sh via the op CLI, straight into the file, never through your context).