apphouse-check

name

apphouse-check

description

Audit an existing iOS app against the AppHouse quality standard and produce a prioritized findings report (P0 release blockers → P3 polish). Checks the project manifest, settings screen contract, loading/empty/error/offline states, monetization correctness, Firebase security, analytics events, website/legal pages, and App Store readiness. Use when the user says "apphouse check", "audit this app", "is this app ready to ship", "release check", "what's missing in this app", or before any App Store submission.

AppHouse Check

Audit the current app repo against the AppHouse standard. Output is a findings report, not fixes — findings link to files and say exactly what to change, but this skill does not modify the app (the user decides what to fix, or asks separately).

Workflow

1. Load context

• Read apphouse.project.yml from the repo root. If missing, that is automatically finding #1 (P1) — recommend running apphouse-new-app in retrofit mode — then continue the audit with facts detected from code.
• Detect the basics: Xcode project, SwiftUI vs UIKit, SDKs present (Firebase, RevenueCat, analytics), website folder if any.

2. Run the audit

Work through references/audit-checklist.md area by area. For each item, verify in the code/config — never assume from the manifest alone (the manifest says what should exist; the code says what does). Grep and read the relevant files; cite file:line evidence for every finding.

Scope control: if the user asked for a specific area ("check monetization"), audit only that area, fully.

3. Classify findings

• P0 — release blocker: will cause rejection, data loss, security incident, or broken purchases (e.g. Firestore in test mode, no restore purchases, missing /privacy URL, hardcoded prices)
• P1 — must fix soon: hurts users or revenue but won't block release (e.g. no offline entitlement cache, missing paywall analytics)
• P2 — recommended: quality gaps vs the AppHouse standard (e.g. missing haptics, no empty states)
• P3 — polish: nice-to-have

4. Report

Produce a Markdown report:

1. Verdict line: "Ship-ready" / "N blockers before submission"
2. Summary table: area → status (✅ / ⚠️ / ❌) → finding count by priority
3. Findings, grouped by priority, each with: what's wrong, evidence (file:line), and the concrete fix
4. Manifest drift: anything where apphouse.project.yml disagrees with reality (says App Check enabled but code doesn't use it, etc.)

Save the report to docs/apphouse-check-<YYYY-MM-DD>.md in the app repo if the user wants a record; otherwise just print it.

Guardrails

• Evidence or it didn't happen: every ❌ must cite a file/config it checked. If an area can't be verified from the repo (e.g. ASC dashboard state, RevenueCat dashboard), mark it unverifiable locally with instructions to check — never guess a pass/fail.
• Read-only: this skill never edits the app.
• Deep dives route to specialists: ASO → app-store-aso-localization, screenshots → app-store-screenshots, pricing → app-store-price-index, reviews → app-store-reviews, visual design → ios-swiftui-design-language.

Files

• references/audit-checklist.md — the full audit checklist with per-item verification hints