role-activationlisted

Use at project start — /app-init, /app-onboard, or /app-run's first step — to decide which of the roles this product actually needs, and to write the durable roster the rest of the flow reads. Triggers whenever a command is about to fan out to a team, or a gate is about to run for a role that may not be on this project.
vmobifystudio/app-dev-team · ★ 4 · AI & Automation · score 74

Install: claude install-skill vmobifystudio/app-dev-team

# Role activation The roster is not fixed. A three-screen utility does not need a CEO *and* a CPO, and a backend service does not need an ASO specialist, a store-readiness gate, or a runtime gate hunting for an `.xcodeproj`. Activation has **two axes**, and both are decided once, up front, and written down. - **Tier** — `flagship` | `utility`. How much process the work deserves (House KB §Tiers). - **Product type** — `ios-app` | `android-app` | `mobile-app` | `backend-service` | `web-app` | `cli` | `library`. Which specialists exist at all. **A deactivated role is recorded, never silently absent.** Everything below exists to serve that one rule: an absent role and a skipped role must stay distinguishable six months later. ## Determining the two axes **Greenfield** — from `docs/01-intake.md`, which `requirements-intake` has already written: - *Product type* ← its `## Product type` answer (intake question 3). One answer, verbatim. - *Tier* ← an explicit `--utility` / `--flagship` flag if the user passed one; otherwise derive: **utility** when the intake describes a single-purpose tool with one core action and no subscription, content library, or AI system; **flagship** otherwise. State the derived tier and its evidence in the Gate 1 brief — it is a scope decision, and Gate 1 is where scope is approved. **Brownfield** — from `brownfield-onboarding` Step 1 detection, never from a README: | Detected | Product type | |---|---| | `*.xcodeproj` / `*.xcworkspace` only