team-live-ops skill

Argument check: If no season name or event description is provided, output:

"Usage: /team-live-ops [season name or event description] — Provide the name or description of the season or live event to plan."

Then stop immediately without spawning any subagents or reading any files.

When this skill is invoked with a valid argument, orchestrate the live-ops team through a structured planning pipeline.

Decision Points: At each phase transition, use AskUserQuestion to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. In collaborative mode, the user must approve before moving to the next phase. In guided mode the pipeline advances automatically unless a phase is BLOCKED; in autonomous mode it runs end to end, recording each phase outcome via logdecision. Decisions in automationalwaysask categories (isalwaysaskcategory helper) always prompt regardless of mode. See .claude/docs/automation-modes.md.

Phase 0: Resolve Config

!bash "${CLAUDESKILLDIR}/../../hooks/yaml-helper.sh" resolveconfig --keys reviewmode,automation,team.size

Resolved above — use as-is; --review overrides review_mode. No block → defaults in .claude/docs/config-resolution.md.

review_mode sets gate depth:

• full — spawn all director and lead gates as described
• lean — skip director gates unless they are PHASE-GATE type (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
• solo — skip all director gate spawning entirely; run the skill without any agent gates

automation drives the Decision Points note above. See the Decision Points note above and .claude/docs/automation-modes.md for how each mode changes pipeline behavior.

team.size: which agents are active (orthogonal to review_mode gate-depth and workflow docs).

Directors (CD/TD/PR) still spawn at phase gates regardless of size; a non-core agent needed at individual routes through the nearest active core agent with an informational note. "Phase gate" means any phase that ends in an AskUserQuestion decision point before the pipeline advances — not every phase. Apply the test literally: if the phase below has no decision point, it is not a gate, and an agent restricted to "phase gates only" is not spawned for it. This active-set scoping applies throughout the pipeline below: any phase that names an agent outside the active set routes through the nearest core agent rather than spawning it.

• individual (default): live-ops-designer + economy-designer. Other agents consulted via these two, not spawned separately.
• small: + analytics-engineer + community-manager (the full pipeline as documented).
• studio: + writer + narrative-director + per-season reviews.

Announce the active set before Phase 1 — never let the collapse be silent. Before spawning anything, state in one line which agents this run will actually spawn, and which the pipeline below names but will not spawn at the resolved team.size. For example:

Active set (team.size: ): .

Not spawned this run: — consulted

through . Raise team.size (or modes.rigor) to widen.

Fill it from the team.size list directly above and the agents this file's own pipeline names — not from an example. Both sets differ per orchestrator.

The pipeline below reads as a multi-agent fan-out and at the shipped default it is one or two agents — team-release names eight and runs one, team-narrative names six across five phases and runs writer alone. The collapse is correct: team.size is rigor-fronted and the narrow default is the token lever, measured at roughly 10x. What was wrong is that nothing said so, so a reader could not distinguish a correctly-collapsed run from a broken pipeline, and the per-agent "routes through the nearest core agent with an informational note" rule above fires at routing time and never states the shape of the run as a whole.

This is the same rule as the skipped-check reporting elsewhere in this file: a constraint that is enforced but never surfaced is indistinguishable, to the person reading the output, from one that was never enforced.

Team Composition

• live-ops-designer — Season structure, event cadence, retention mechanics, battle pass
• economy-designer — Live economy balance, store rotation, currency pricing, pity timers
• analytics-engineer — Success metrics, A/B test design, event tracking, dashboard specs
• community-manager — Player-facing announcements, event descriptions, seasonal messaging
• narrative-director — Seasonal narrative theme, story arc, world event framing
• writer — Event descriptions, reward item names, seasonal flavor text, announcement copy

How to Delegate

Use the Agent tool to spawn each team member as a subagent:

• subagent_type: live-ops-designer — Season/event structure and retention mechanics
• subagent_type: economy-designer — Live economy balance and reward pricing
• subagent_type: analytics-engineer — Success metrics, A/B tests, event instrumentation
• subagent_type: community-manager — Player-facing communication and messaging
• subagent_type: narrative-director — Seasonal theme and narrative framing
• subagent_type: writer — All player-facing text: event descriptions, item names, copy

Brief each agent — do not dump context. Read the shared inputs once and pass a distilled brief inline: the lines each agent actually needs, never a file path for a document you have already read (an agent handed a path re-reads the whole file). Pass a path only for a document you have not read and only that agent needs.

End every agent prompt with a return contract: "Write your full output to [path] — that named path is your write authorisation under the bounded exception below, so write it without a separate approval prompt. Return only (1) the path written, (2) a ≤5-bullet summary of decisions, (3) any BLOCKED/CONCERNS items, one line each. Do not restate the documents you read." Without it, an agent returns everything it read back into this session.

Why this does not violate the Collaboration Protocol. CLAUDE.md requires an agent to ask "May I write this to [filepath]?" before Write/Edit. A subagent spawned here writes without asking, and that is a deliberate, bounded exception rather than an oversight — the same call already made for consistency-check appending to active.md. The exception holds only when all three are true: (1) the path is one you named in the prompt, so the user approved the destination when they approved the phase; (2) it is a new artifact under production/, docs/ or tests/, never an edit to existing source or config; (3) the phase that produced it is itself gated by an AskUserQuestion before the pipeline advances. Outside those three, the agent must ask. Do not "fix" this by asking per subagent — a prompt per agent per phase makes an orchestrator unusable, which is why the exception exists.

Launch independent agents in parallel where the pipeline allows it (Phases 3 and 4 can run simultaneously).

Pipeline

Phase 1: Season/Event Scoping

Delegate to live-ops-designer:

• Define the season or event: type (seasonal, limited-time event, challenge), duration, theme direction
• Outline the content list: what's new (modes, items, challenges, story beats)
• Define the retention hook: what brings players back daily/weekly during this season
• Identify resource budget: how much new content needs to be created vs. reused
• Output: season brief with scope, content list, and retention mechanic overview

Phase 2: Narrative Theme

Delegate to narrative-director:

• Read the season brief from Phase 1
• Design the seasonal narrative theme: how does this event connect to the game world?
• Define the central story hook players will discover during the event
• Identify which existing lore threads this season can advance
• Output: narrative framing document (theme, story hook, lore connections)

Phase 3: Economy Design (parallel with Phase 2 if theme is clear)

Delegate to economy-designer:

• Read the season brief and existing economy rules from design/live-ops/economy-rules.md
• Design the reward track: free tier progression, premium tier value proposition
• Plan the in-season economy: seasonal currency, store rotation, pricing
• Define pity timer mechanics and bad-luck protection for any random elements
• Verify no pay-to-win items in premium track
• Output: economy design doc with reward tables, pricing, and currency flow

Phase 4: Analytics and Success Metrics (parallel with Phase 3)

Delegate to analytics-engineer:

• Read the season brief
• Define success metrics: participation rate target, retention lift target, battle pass completion rate
• Design any A/B tests to run during the season (e.g., different reward cadences)
• Specify new telemetry events needed for this season's content
• Output: analytics plan with success criteria and instrumentation requirements

Phase 5: Content Writing (parallel)

Delegate in parallel:

• narrative-director (if needed): Write any in-game narrative text (cutscene scripts, NPC dialogue, world event descriptions) for the season
• writer: Write all player-facing text — event names, reward item descriptions, challenge objective text, seasonal flavor text
• Both should read the narrative framing doc from Phase 2

Phase 6: Player Communication Plan

Delegate to community-manager:

• Read the season brief, economy design, and narrative framing
• Draft the season launch announcement (tone, key highlights, platform-specific versions)
• Plan the communication cadence: pre-launch teaser, launch day post, mid-season reminder, final week FOMO push
• Draft known-issues section placeholder for day-1 patch notes
• Output: communication calendar with draft copy for each touchpoint

Phase 7: Review and Sign-off

Collect outputs from all phases and present a consolidated season plan:

• Season brief (Phase 1)
• Narrative framing (Phase 2)
• Economy design and reward tables (Phase 3)
• Analytics plan and success metrics (Phase 4)
• Written content inventory (Phase 5)
• Communication calendar (Phase 6)

Present a summary to the user with:

• Content scope: what is being created
• Economy health check: does the reward track feel fair and non-predatory?
• Analytics readiness: are success criteria defined and instrumented?
• Ethics review: check the Phase 3 economy design against design/live-ops/ethics-policy.md
• If the file does not exist: flag "ETHICS REVIEW SKIPPED: design/live-ops/ethics-policy.md not found. Economy design was not reviewed against an ethics policy. Recommend creating one before production begins." Include this flag in the season design output document. Add to next steps: create design/live-ops/ethics-policy.md.
• If the file exists and a violation is found: flag "ETHICS FLAG: [element] in Phase 3 economy design violates [policy rule]. Approval is blocked until this is resolved." Do NOT issue a COMPLETE verdict or write output documents. Use AskUserQuestion with options: revise economy design / override with documented rationale / cancel. If user chooses to revise: re-spawn economy-designer to produce a corrected design, then return to Phase 7 review. If user selects Cancel: end with Verdict: BLOCKED — "Live ops design cancelled due to unresolved ethics violation. Resolve the flagged issues and re-run /team-live-ops."
• Open questions: decisions still needed before production begins

Ask the user to approve the season plan before delegating to production teams. Issue the COMPLETE verdict only after the user approves and no unresolved ethics violations remain. If an ethics violation is unresolved, end with Verdict: BLOCKED.

Output Documents

All documents save to design/live-ops/ — but the orchestrator asks before writing them. design/ is NOT one of the three directories the bounded write exception covers (production/, docs/, tests/), so a sub-agent handed one of these paths must prompt. Do not widen the exception to silence that. Follow team-level's pattern instead: sub-agents write their working artifacts under production/, where the exception does reach them; you compile the final documents and ask via AskUserQuestion — "May I write the season plan to design/live-ops/…?" — writing them only on approval.

Paths:

• seasons/S[N]_[name].md — Season design document (from Phase 1-3)
• seasons/S[N][name]analytics.md — Analytics plan (from Phase 4)
• seasons/S[N][name]comms.md — Communication calendar (from Phase 6)

Error Recovery Protocol