/role-activation

name: role-activation
description: 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.

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 | `ios-app` | | `settings.gradle*` + `app/` only | `android-app` | | both of the above | `mobile-app` | | `package.json` with a web framework, or any `public/`+`index.html` | `web-app` | | server framework or `Dockerfile`/`Procfile`, no UI surface | `backend-service` | | a binary entry point (`bin`, `cmd/`, `main.go`, `[[bin]]`) and no UI | `cli` | | a package manifest that publishes, with no entry point | `library` |

Tier for brownfield: derive from the app's size and shape (module count, subscription/ads SDKs present), and say which signal decided it. **When detection is ambiguous, ask the user one question — do not guess.** A wrong product type turns off the wrong specialists.

Why a role exists

The matrix below decides *when* a role activates. It does not decide whether the role should exist at all — that is a separate, cheaper question, and skipping it is how a role catalogue grows past what any product actually needs. Once a role clears this bar, `docs/03-decision-rights.md` is where its actual authority — propose, challenge, decide, execute, record evidence — is written down; this table only answers whether the role should exist, not what it may do once it does.

**A role is justified only if it needs at least one of:**

| Tag | Meaning | |---|---| | `authority` | independent decision authority — it decides something no other role can decide for it | | `context` | an independent context that must not inherit another role's framing (an evidence-gatherer that reasoned from the thing it's evidence-gathering *for* would confirm its own hypothesis) | | `capability` | a materially different capability or security boundary (a different platform, a different attack surface, a different tool) | | `duties` | accountability that must remain separate for governance reasons (the author cannot be the sole reviewer, the actor cannot be the sole auditor) |

Everything else is a skill, an operating mode, a checklist, or a gate inside an existing role — not a new agent file. This is the test Phase 2 of the studio's own revamp already applied once, cutting a ~40-role plan to today's 29; the table below re-applies it to the roster as it stands now.

| Role | Tag | Why | |---|---|---| | `ceo` | `authority` | final scope/vision authority no other role holds | | `cpo` | `authority` | product-decision authority distinct from engineering | | `cto` | `authority` | technical-strategy authority distinct from product | | `chief-of-staff` | `context` | one founder-facing decision-brief context, deliberately not the CEO's own strategic framing — its own description says it "is only worth running if it removes more decisions than it creates" | | `product-manager` | `capability` | day-to-day ticket-clarification capability below CPO's strategic layer, so CPO is not the bottleneck for every clarification | | `product-researcher` | `context` | evidence-gathering that must not inherit the CPO's framing, or it would confirm its own hypothesis rather than test it | | `tech-lead` | `authority` | technical-design authority distinct from CTO's strategic layer | | `tech-manager` | `authority` | execution/scheduling authority — the only role that merges | | `ux-architect` | `capability` | information-architecture/flow capability distinct from screen composition | | `product-designer` | `capability` | visual/screen-composition capability, deliberately not self-approving its own fidelity | | `ios-developer` | `capability` | Swift/SwiftUI platform capability | | `android-developer` | `capability` | Kotlin/Compose platform capability | | `backend-developer` | `capability` | server/API/infra-as-code capability | | `web-developer` | `capability` | browser-platform capability — the IC that makes product type `web-app` staffed | | `monetization-engineer` | `capability` | billing/ads correctness is a distinct capability and a distinct financial-blast-radius boundary from general implementation | | `aso-specialist` | `capability` | store-listing/keyword capability, distinct from product or engineering | | `data-analyst` | `capability` | analytics-schema and consent-gate capability | | `devops-engin