| name | apphouse-new-app |
| description | Bootstrap a new AppHouse iOS app (or retrofit an existing one) so nothing is forgotten — app identity, Firebase setup, RevenueCat subscriptions, backend security, subdomain website with legal pages, analytics, and App Store Connect. Creates and fills apphouse.project.yml, the per-app manifest every other AppHouse skill reads. Use when the user says "new app", "start a new app", "bootstrap", "set up this app the AppHouse way", "create apphouse.project.yml", or begins a fresh iOS/SwiftUI project. |
AppHouse New App
Turn an app idea (or an existing repo) into an AppHouse-standard project. The deliverables are:
apphouse.project.yml in the repo root — the single source of truth for this app's facts. Every AppHouse skill reads it instead of re-asking the user.- A completed launch checklist — every infrastructure decision made deliberately, nothing forgotten.
Core rule
An empty or missing section in apphouse.project.yml means that area is NOT set up yet. The manifest doubles as the forgot-nothing checklist. Never silently skip a section — either fill it, or mark it explicitly with status: skipped and a reason.
Never put secrets, API keys, or credentials in the manifest. It stores names and references (e.g. the RevenueCat entitlement name, the env var name that holds a key) — never values.
Workflow
1. Establish context
- If
apphouse.project.yml already exists: read it, report which sections are complete / empty, and continue from the gaps.
- If this is an existing codebase without a manifest: scan the project first (bundle ID from the Xcode project, Firebase config from
GoogleService-Info.plist, RevenueCat/Firebase SDK usage, existing analytics calls) and pre-fill everything detectable before asking the user anything.
- If this is a brand-new idea: ask only the minimum to start — app name, one-line value proposition, target user. Everything else comes from the checklist walk.
2. Create the manifest
Copy templates/apphouse.project.yml from this skill into the repo root and fill in what is known. Keep the comments — they document what each field is for.
3. Walk the launch checklist
Work through references/launch-checklist.md section by section, in order:
- Identity & App Store Connect
- Firebase (project, services, security rules, App Check)
- RevenueCat (entitlements, offerings, paywall placement)
- Backend & security (rate limiting, auth, abuse protection)
- Website & subdomain (required routes, legal pages)
- Analytics (standard event set)
- Release readiness
For each section: decide with the user, execute what can be executed now (or produce concrete TODO commands for what needs the user's dashboards), then record the decision in the manifest. Update the manifest as you go, not at the end.
4. Verify and summarize
- Validate the manifest: every top-level section is either filled or explicitly
status: skipped.
- Print a final launch-readiness table: section → done / pending / skipped, with the concrete next action for anything pending.
Retrofit mode (existing app)
Same workflow, but detection-first: everything discoverable from code, config files, and existing dashboards gets pre-filled; the checklist walk only covers gaps. Useful when the user says "apply AppHouse standards to this app" or "why is X not set up in this app".
Guardrails
- Prefer official CLIs and APIs (Firebase CLI/MCP, App Store Connect API) over telling the user to click through dashboards; when only the dashboard works, give exact click-path instructions.
- Any action that creates or mutates cloud resources (Firebase project, ASC app record): state what will be created and confirm before doing it.
- This skill sets up the structure; deep work belongs to specialist skills — ASO to
app-store-aso-localization, screenshots to app-store-screenshots, pricing to app-store-price-index, marketing to apphouse-marketing, quality audit to apphouse-check.
Files
templates/apphouse.project.yml — the manifest template with commentsreferences/launch-checklist.md — the full section-by-section checklist with defaults and rationale
