team-live-ops by @donchitos

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 log_decision. Decisions in automation_always_ask categories (is_always_ask_category helper) always prompt regardless of mode. See .claude/docs/automation-modes.md.

Phase 0: Resolve Config

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,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).

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. 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.

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: <resolved>): <the agents listed for that size above>. Not spawned this run: <every other agent this pipeline names> — consulted through <nearest active core agent>. 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

First, verify the artifact. If the return contract named a path, check the path exists before treating the phase as done — a named artifact that is not on disk is a failed phase, however fluent the response reads. An agent can burn a full phase and return a plausible preamble having written nothing, which is neither BLOCKED nor an error nor "cannot complete", so the trigger below never fires. Resume it naming the unmet contract; the context is usually still there.

If any spawned agent returns BLOCKED, errors, or cannot complete: surface it immediately, don't proceed past a dependency it blocks, and always produce a partial report. Full procedure: .claude/docs/error-recovery-protocol.md.

If a BLOCKED state is unresolvable, end with Verdict: BLOCKED instead of COMPLETE.

File Write Protocol

All file writes (season design docs, analytics plans, communication calendars) are delegated to sub-agents spawned via Agent. Those writes follow the bounded exception documented above under "Why this does not violate the Collaboration Protocol" — the path is one you named, the artifact is new under production/, docs/ or tests/, and the phase is gated by an AskUserQuestion. A sub-agent does not prompt per write inside those bounds; outside them it must ask. This orchestrator does not write files directly.

Output

A summary covering: season theme and scope, economy design highlights, success metrics, content list, communication plan, and any open decisions needing user input before production.

Verdict: COMPLETE — season plan produced and handed off for production.

Next Steps

Run /design-review on the season design document for consistency validation.
Run /sprint-plan to schedule content creation work for the season.
Run /team-release when the season content is ready to deploy.