mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios
synced 2026-04-21 13:27:18 +00:00
Skills update: team-live-ops skill + improvements across 18 existing skills
- Add new /team-live-ops skill for post-launch content planning orchestration - Expand setup-engine, code-review, create-epics-stories, prototype with additional context - Enrich team-* skills (audio, combat, level, narrative, polish, release, ui) with new phases/agents - Update architecture-decision and architecture-review with dependency ordering improvements - Minor additions to balance-check, hotfix, localize, patch-notes, perf-profile - Populate technical-preferences.md with structured configuration sections Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Donchitos
parent
b1fad395cd
commit
14593802fe
20 changed files with 392 additions and 26 deletions
|
|
@ -46,3 +46,30 @@
|
|||
|
||||
<!-- Quick reference linking to full ADRs in docs/architecture/ -->
|
||||
- [No ADRs yet — use /architecture-decision to create one]
|
||||
|
||||
## Engine Specialists
|
||||
|
||||
<!-- Written by /setup-engine when engine is configured. -->
|
||||
<!-- Read by /code-review, /architecture-decision, /architecture-review, and team skills -->
|
||||
<!-- to know which specialist to spawn for engine-specific validation. -->
|
||||
|
||||
- **Primary**: [TO BE CONFIGURED — run /setup-engine]
|
||||
- **Language/Code Specialist**: [TO BE CONFIGURED]
|
||||
- **Shader Specialist**: [TO BE CONFIGURED]
|
||||
- **UI Specialist**: [TO BE CONFIGURED]
|
||||
- **Additional Specialists**: [TO BE CONFIGURED]
|
||||
- **Routing Notes**: [TO BE CONFIGURED]
|
||||
|
||||
### File Extension Routing
|
||||
|
||||
<!-- Skills use this table to select the right specialist per file type. -->
|
||||
<!-- If a row says [TO BE CONFIGURED], fall back to Primary for that file type. -->
|
||||
|
||||
| File Extension / Type | Specialist to Spawn |
|
||||
|-----------------------|---------------------|
|
||||
| Game code (primary language) | [TO BE CONFIGURED] |
|
||||
| Shader / material files | [TO BE CONFIGURED] |
|
||||
| UI / screen files | [TO BE CONFIGURED] |
|
||||
| Scene / prefab / level files | [TO BE CONFIGURED] |
|
||||
| Native extension / plugin files | [TO BE CONFIGURED] |
|
||||
| General architecture review | Primary |
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ name: architecture-decision
|
|||
description: "Creates an Architecture Decision Record (ADR) documenting a significant technical decision, its context, alternatives considered, and consequences. Every major technical choice should have an ADR."
|
||||
argument-hint: "[title]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write
|
||||
allowed-tools: Read, Glob, Grep, Write, Task
|
||||
---
|
||||
|
||||
When this skill is invoked:
|
||||
|
|
@ -246,4 +246,14 @@ to implement it.]
|
|||
- [Links to related design documents]
|
||||
```
|
||||
|
||||
4.5. **Engine Specialist Validation** — Before saving, spawn the **primary engine specialist** via Task to validate the drafted ADR:
|
||||
- Read `.claude/docs/technical-preferences.md` `Engine Specialists` section to get the primary specialist
|
||||
- If no engine is configured (`[TO BE CONFIGURED]`), skip this step
|
||||
- Spawn `subagent_type: [primary specialist]` with: the ADR's Engine Compatibility section, Decision section, Key Interfaces, and the engine reference docs path. Ask them to:
|
||||
1. Confirm the proposed approach is idiomatic for the pinned engine version
|
||||
2. Flag any APIs or patterns that are deprecated or changed post-training-cutoff
|
||||
3. Identify engine-specific risks or gotchas not captured in the current ADR draft
|
||||
- If the specialist identifies a **blocking issue** (wrong API, deprecated approach, engine version incompatibility): revise the Decision and Engine Compatibility sections accordingly, then confirm the changes with the user before proceeding
|
||||
- If the specialist finds **minor notes** only: incorporate them into the ADR's Risks subsection
|
||||
|
||||
5. **Save the ADR** to `docs/architecture/adr-[NNNN]-[slug].md`.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ name: architecture-review
|
|||
description: "Validates completeness and consistency of the project architecture against all GDDs. Builds a traceability matrix mapping every GDD technical requirement to ADRs, identifies coverage gaps, detects cross-ADR conflicts, verifies engine compatibility consistency across all decisions, and produces a PASS/CONCERNS/FAIL verdict. The architecture equivalent of /design-review."
|
||||
argument-hint: "[focus: full | coverage | consistency | engine | single-gdd path/to/gdd.md]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write
|
||||
allowed-tools: Read, Glob, Grep, Write, Task
|
||||
context: fork
|
||||
agent: technical-director
|
||||
---
|
||||
|
|
@ -237,6 +237,20 @@ Post-Cutoff API Conflicts:
|
|||
|
||||
---
|
||||
|
||||
### Engine Specialist Consultation
|
||||
|
||||
After completing the engine audit above, spawn the **primary engine specialist** via Task for a domain-expert second opinion:
|
||||
- Read `.claude/docs/technical-preferences.md` `Engine Specialists` section to get the primary specialist
|
||||
- If no engine is configured, skip this consultation
|
||||
- Spawn `subagent_type: [primary specialist]` with: all ADRs that contain engine-specific decisions or `Post-Cutoff APIs Used` fields, the engine reference docs, and the Phase 5 audit findings. Ask them to:
|
||||
1. Confirm or challenge each audit finding — specialists may know of engine nuances not captured in the reference docs
|
||||
2. Identify engine-specific anti-patterns in the ADRs that the audit may have missed (e.g., using the wrong Godot node type, Unity component coupling, Unreal subsystem misuse)
|
||||
3. Flag ADRs that make assumptions about engine behaviour that differ from the actual pinned version
|
||||
|
||||
Incorporate additional findings under `### Engine Specialist Findings` in the Phase 5 output. These feed into the final verdict — specialist-identified issues carry the same weight as audit-identified issues.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5b: Design Revision Flags (Architecture → GDD Feedback)
|
||||
|
||||
For each **HIGH RISK engine finding** from Phase 5, check whether any GDD makes an
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ argument-hint: "[system-name|path-to-data-file]"
|
|||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep
|
||||
context: fork
|
||||
agent: Explore
|
||||
agent: economy-designer
|
||||
---
|
||||
|
||||
When this skill is invoked:
|
||||
|
|
|
|||
|
|
@ -3,9 +3,9 @@ name: code-review
|
|||
description: "Performs an architectural and quality code review on a specified file or set of files. Checks for coding standard compliance, architectural pattern adherence, SOLID principles, testability, and performance concerns."
|
||||
argument-hint: "[path-to-file-or-directory]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Bash
|
||||
allowed-tools: Read, Glob, Grep, Bash, Task
|
||||
context: fork
|
||||
agent: code-reviewer
|
||||
agent: lead-programmer
|
||||
---
|
||||
|
||||
When this skill is invoked:
|
||||
|
|
@ -14,6 +14,13 @@ When this skill is invoked:
|
|||
|
||||
2. **Read the CLAUDE.md** for project coding standards.
|
||||
|
||||
2.5. **Identify the active engine specialists** by reading `.claude/docs/technical-preferences.md`, section `## Engine Specialists`. Note:
|
||||
- The **Primary** specialist (used for architecture and broad engine concerns)
|
||||
- The **Language/Code Specialist** (used when reviewing the project's primary language files)
|
||||
- The **Shader Specialist** (used when reviewing shader files)
|
||||
- The **UI Specialist** (used when reviewing UI code)
|
||||
- If the section reads `[TO BE CONFIGURED]`, no engine is pinned — skip engine specialist steps below.
|
||||
|
||||
3. **ADR Compliance Check**:
|
||||
|
||||
a. Search for ADR references in: the story file associated with this work (if
|
||||
|
|
@ -79,11 +86,25 @@ When this skill is invoked:
|
|||
- [ ] Thread safety where required
|
||||
- [ ] Resource cleanup (no leaks)
|
||||
|
||||
9. **Output the review** in this format:
|
||||
9. **Engine Specialist Review** — If an engine is configured (step 2.5), spawn engine specialists via Task in parallel with your own review above:
|
||||
- Determine which specialist applies to each file being reviewed:
|
||||
- Primary language files (`.gd`, `.cs`, `.cpp`) → Language/Code Specialist
|
||||
- Shader files (`.gdshader`, `.hlsl`, shader graph) → Shader Specialist
|
||||
- UI screen/widget code → UI Specialist
|
||||
- Cross-cutting or unclear → Primary Specialist
|
||||
- Spawn the relevant specialist(s) with: the file(s), the engine reference docs path (`docs/engine-reference/[engine]/`), and the task: "Review for engine-idiomatic patterns, deprecated or incorrect API usage, engine-specific performance concerns, and any patterns the engine's documentation recommends against."
|
||||
- Also spawn the **Primary Specialist** for any file that touches engine architecture (scene structure, node hierarchy, component design, lifecycle hooks).
|
||||
- Collect findings and include them in the review output under `### Engine Specialist Findings` (placed between `### Game-Specific Concerns` and `### Positive Observations`).
|
||||
- If no engine is configured, omit the `### Engine Specialist Findings` section.
|
||||
|
||||
10. **Output the review** in this format:
|
||||
|
||||
```
|
||||
## Code Review: [File/System Name]
|
||||
|
||||
### Engine Specialist Findings: [N/A — no engine configured / CLEAN / ISSUES FOUND]
|
||||
[Findings from engine specialist(s), or "No engine configured." if skipped]
|
||||
|
||||
### ADR Compliance: [NO ADRS FOUND / COMPLIANT / DRIFT / VIOLATION]
|
||||
[List each ADR checked, result, and any deviations with severity]
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ name: create-epics-stories
|
|||
description: "Translate approved GDDs + architecture + ADRs into implementable epics and stories. Each story embeds the GDD requirement it satisfies, the ADR governing implementation, acceptance criteria, engine compatibility notes, and control manifest rules. Programmers need nothing else to implement a story correctly."
|
||||
argument-hint: "[system-name | layer: foundation|core|feature|presentation | all]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write
|
||||
allowed-tools: Read, Glob, Grep, Write, Task
|
||||
context: fork
|
||||
agent: technical-director
|
||||
---
|
||||
|
|
@ -223,9 +223,31 @@ This boundary prevents scope creep and keeps stories independently reviewable.
|
|||
|
||||
---
|
||||
|
||||
## 7. Approval Before Writing
|
||||
## 7. Lead-Programmer Architecture Review
|
||||
|
||||
For each epic, after all stories are drafted, present a summary:
|
||||
Before asking for approval, spawn a `lead-programmer` subagent via Task to review
|
||||
the drafted stories for the current epic. Provide:
|
||||
- The epic summary (layer, module, governing ADRs)
|
||||
- All drafted story files for this epic
|
||||
- The control manifest (if it exists)
|
||||
|
||||
Ask the lead-programmer to check:
|
||||
- **Story boundaries**: Are any stories too large (should be split) or too small (should be merged)?
|
||||
- **ADR adherence**: Do the implementation notes in the stories faithfully reflect the ADR decisions? Flag any that drift or contradict.
|
||||
- **Dependency ordering**: Is the story sequence safe? Can each story be implemented independently once its prerequisite is done?
|
||||
- **Missing stories**: Are there any infrastructure concerns (interfaces, base classes, test hooks) that need their own story before others can proceed?
|
||||
- **Control manifest compliance**: Do any stories ask for patterns explicitly forbidden in the manifest?
|
||||
|
||||
The lead-programmer produces one of:
|
||||
- **APPROVED** — proceed to user approval as-is
|
||||
- **REVISIONS NEEDED** — list of specific changes; revise the affected stories before proceeding
|
||||
- **BLOCKED** — a fundamental issue (missing ADR, wrong layer, circular dependency) that must be resolved first
|
||||
|
||||
If REVISIONS NEEDED: make the changes and re-present the updated stories to the lead-programmer before requesting user approval. Do not ask the user to approve stories with known structural issues.
|
||||
|
||||
## 8. Approval Before Writing
|
||||
|
||||
For each epic, after stories pass lead-programmer review, present a summary:
|
||||
|
||||
```
|
||||
Epic [N]: [name]
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ name: hotfix
|
|||
description: "Emergency fix workflow that bypasses normal sprint processes with a full audit trail. Creates hotfix branch, tracks approvals, and ensures the fix is backported correctly."
|
||||
argument-hint: "[bug-id or description]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task
|
||||
---
|
||||
When this skill is invoked:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@ name: localize
|
|||
description: "Run the localization workflow: extract strings, validate localization readiness, check for hardcoded text, and generate translation-ready string tables."
|
||||
argument-hint: "[scan|extract|validate|status]"
|
||||
user-invocable: true
|
||||
agent: localization-lead
|
||||
allowed-tools: Read, Glob, Grep, Write, Bash
|
||||
---
|
||||
When this skill is invoked:
|
||||
|
|
|
|||
|
|
@ -4,6 +4,7 @@ description: "Generate player-facing patch notes from git history, sprint data,
|
|||
argument-hint: "[version] [--style brief|detailed|full]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Bash
|
||||
agent: community-manager
|
||||
---
|
||||
|
||||
When this skill is invoked:
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@ name: perf-profile
|
|||
description: "Structured performance profiling workflow. Identifies bottlenecks, measures against budgets, and generates optimization recommendations with priority rankings."
|
||||
argument-hint: "[system-name or 'full']"
|
||||
user-invocable: true
|
||||
agent: performance-analyst
|
||||
allowed-tools: Read, Glob, Grep, Bash
|
||||
---
|
||||
When this skill is invoked:
|
||||
|
|
|
|||
|
|
@ -3,7 +3,10 @@ name: prototype
|
|||
description: "Rapid prototyping workflow. Skips normal standards to quickly validate a game concept or mechanic. Produces throwaway code and a structured prototype report."
|
||||
argument-hint: "[concept-description]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task
|
||||
context: fork
|
||||
agent: prototyper
|
||||
isolation: worktree
|
||||
---
|
||||
|
||||
When this skill is invoked:
|
||||
|
|
@ -84,9 +87,25 @@ When this skill is invoked:
|
|||
[Discoveries that affect other systems or future work]
|
||||
```
|
||||
|
||||
8. **Output a summary** to the user with: the core question, the result, and
|
||||
the recommendation. Link to the full report at
|
||||
`prototypes/[concept-name]/REPORT.md`.
|
||||
8. **Delegate the decision to the creative-director**. Spawn a `creative-director`
|
||||
subagent via Task and provide:
|
||||
- The full REPORT.md content
|
||||
- The original design question
|
||||
- Any game pillars or concept doc from `design/gdd/` that are relevant
|
||||
|
||||
Ask the creative-director to:
|
||||
- Evaluate the prototype result against the game's creative vision and pillars
|
||||
- Confirm, modify, or override the prototyper's PROCEED / PIVOT / KILL recommendation
|
||||
- If PROCEED: identify any creative constraints for the production implementation
|
||||
- If PIVOT: specify which direction aligns better with the pillars
|
||||
- If KILL: note whether the underlying player need should be addressed differently
|
||||
|
||||
The creative-director's decision is final. Update the REPORT.md `Recommendation`
|
||||
section with the creative-director's verdict if it differs from the prototyper's.
|
||||
|
||||
9. **Output a summary** to the user with: the core question, the result, the
|
||||
prototyper's initial recommendation, and the creative-director's final decision.
|
||||
Link to the full report at `prototypes/[concept-name]/REPORT.md`.
|
||||
|
||||
### Important Constraints
|
||||
|
||||
|
|
|
|||
|
|
@ -141,6 +141,77 @@ engine-appropriate defaults. Read the existing template first, then fill in:
|
|||
- Testing: Suggest engine-appropriate framework (GUT for Godot, NUnit for Unity, etc.)
|
||||
- Forbidden Patterns / Allowed Libraries: Leave as placeholder
|
||||
|
||||
### Engine Specialists Routing
|
||||
|
||||
Also populate the `## Engine Specialists` section in `technical-preferences.md` with the correct routing for the chosen engine:
|
||||
|
||||
**For Godot:**
|
||||
```markdown
|
||||
## Engine Specialists
|
||||
- **Primary**: godot-specialist
|
||||
- **Language/Code Specialist**: godot-gdscript-specialist (all .gd files)
|
||||
- **Shader Specialist**: godot-shader-specialist (.gdshader files, VisualShader resources)
|
||||
- **UI Specialist**: godot-specialist (no dedicated UI specialist — primary covers all UI)
|
||||
- **Additional Specialists**: godot-gdextension-specialist (GDExtension / native C++ bindings only)
|
||||
- **Routing Notes**: Invoke primary for architecture decisions, ADR validation, and cross-cutting code review. Invoke GDScript specialist for code quality, signal architecture, static typing enforcement, and GDScript idioms. Invoke shader specialist for material design and shader code. Invoke GDExtension specialist only when native extensions are involved.
|
||||
|
||||
### File Extension Routing
|
||||
|
||||
| File Extension / Type | Specialist to Spawn |
|
||||
|-----------------------|---------------------|
|
||||
| Game code (.gd files) | godot-gdscript-specialist |
|
||||
| Shader / material files (.gdshader, VisualShader) | godot-shader-specialist |
|
||||
| UI / screen files (Control nodes, CanvasLayer) | godot-specialist |
|
||||
| Scene / prefab / level files (.tscn, .tres) | godot-specialist |
|
||||
| Native extension / plugin files (.gdextension, C++) | godot-gdextension-specialist |
|
||||
| General architecture review | godot-specialist |
|
||||
```
|
||||
|
||||
**For Unity:**
|
||||
```markdown
|
||||
## Engine Specialists
|
||||
- **Primary**: unity-specialist
|
||||
- **Language/Code Specialist**: unity-specialist (C# review — primary covers it)
|
||||
- **Shader Specialist**: unity-shader-specialist (Shader Graph, HLSL, URP/HDRP materials)
|
||||
- **UI Specialist**: unity-ui-specialist (UI Toolkit UXML/USS, UGUI Canvas, runtime UI)
|
||||
- **Additional Specialists**: unity-dots-specialist (ECS, Jobs system, Burst compiler), unity-addressables-specialist (asset loading, memory management, content catalogs)
|
||||
- **Routing Notes**: Invoke primary for architecture and general C# code review. Invoke DOTS specialist for any ECS/Jobs/Burst code. Invoke shader specialist for rendering and visual effects. Invoke UI specialist for all interface implementation. Invoke Addressables specialist for asset management systems.
|
||||
|
||||
### File Extension Routing
|
||||
|
||||
| File Extension / Type | Specialist to Spawn |
|
||||
|-----------------------|---------------------|
|
||||
| Game code (.cs files) | unity-specialist |
|
||||
| Shader / material files (.shader, .shadergraph, .mat) | unity-shader-specialist |
|
||||
| UI / screen files (.uxml, .uss, Canvas prefabs) | unity-ui-specialist |
|
||||
| Scene / prefab / level files (.unity, .prefab) | unity-specialist |
|
||||
| Native extension / plugin files (.dll, native plugins) | unity-specialist |
|
||||
| General architecture review | unity-specialist |
|
||||
```
|
||||
|
||||
**For Unreal:**
|
||||
```markdown
|
||||
## Engine Specialists
|
||||
- **Primary**: unreal-specialist
|
||||
- **Language/Code Specialist**: ue-blueprint-specialist (Blueprint graphs) or unreal-specialist (C++)
|
||||
- **Shader Specialist**: unreal-specialist (no dedicated shader specialist — primary covers materials)
|
||||
- **UI Specialist**: ue-umg-specialist (UMG widgets, CommonUI, input routing, widget styling)
|
||||
- **Additional Specialists**: ue-gas-specialist (Gameplay Ability System, attributes, gameplay effects), ue-replication-specialist (property replication, RPCs, client prediction, netcode)
|
||||
- **Routing Notes**: Invoke primary for C++ architecture and broad engine decisions. Invoke Blueprint specialist for Blueprint graph architecture and BP/C++ boundary design. Invoke GAS specialist for all ability and attribute code. Invoke replication specialist for any multiplayer or networked systems. Invoke UMG specialist for all UI implementation.
|
||||
|
||||
### File Extension Routing
|
||||
|
||||
| File Extension / Type | Specialist to Spawn |
|
||||
|-----------------------|---------------------|
|
||||
| Game code (.cpp, .h files) | unreal-specialist |
|
||||
| Shader / material files (.usf, .ush, Material assets) | unreal-specialist |
|
||||
| UI / screen files (.umg, UMG Widget Blueprints) | ue-umg-specialist |
|
||||
| Scene / prefab / level files (.umap, .uasset) | unreal-specialist |
|
||||
| Native extension / plugin files (Plugin .uplugin, modules) | unreal-specialist |
|
||||
| Blueprint graphs (.uasset BP classes) | ue-blueprint-specialist |
|
||||
| General architecture review | unreal-specialist |
|
||||
```
|
||||
|
||||
### Collaborative Step
|
||||
Present the filled-in preferences to the user:
|
||||
> "Here are the default technical preferences for [engine]. Want to customize
|
||||
|
|
|
|||
|
|
@ -28,6 +28,7 @@ Use the Task tool to spawn each team member as a subagent:
|
|||
- `subagent_type: audio-director` — Sonic identity, emotional tone, audio palette
|
||||
- `subagent_type: sound-designer` — SFX specifications, audio events, mixing groups
|
||||
- `subagent_type: technical-artist` — Audio middleware, bus structure, memory budgets
|
||||
- `subagent_type: [primary engine specialist]` — Validate audio integration patterns for the engine
|
||||
- `subagent_type: gameplay-programmer` — Audio manager, gameplay triggers, adaptive music
|
||||
|
||||
Always provide full context in each agent's prompt (feature description, existing audio assets, design doc references).
|
||||
|
|
@ -42,7 +43,7 @@ Spawn the `audio-director` agent to:
|
|||
- Define audio priorities and mix targets
|
||||
- Establish any adaptive audio rules (combat intensity, exploration, tension)
|
||||
|
||||
### Step 2: Sound Design (sound-designer)
|
||||
### Step 2: Sound Design and Audio Accessibility (parallel)
|
||||
Spawn the `sound-designer` agent to:
|
||||
- Create detailed SFX specifications for every audio event
|
||||
- Define sound categories (ambient, UI, gameplay, music, dialogue)
|
||||
|
|
@ -50,7 +51,14 @@ Spawn the `sound-designer` agent to:
|
|||
- Plan audio event list with trigger conditions
|
||||
- Define mixing groups and ducking rules
|
||||
|
||||
### Step 3: Technical Implementation (technical-artist)
|
||||
Spawn the `accessibility-specialist` agent in parallel to:
|
||||
- Identify which audio events carry critical gameplay information (damage received, enemy nearby, objective complete) and require visual alternatives for hearing-impaired players
|
||||
- Specify subtitle requirements: which audio events need captions, what text format, on-screen duration
|
||||
- Check that no gameplay state is communicated by audio alone (all must have a visual fallback)
|
||||
- Review the audio event list for any that could cause issues for players with auditory sensitivities (high-frequency alerts, sudden loud events)
|
||||
- Output: audio accessibility requirements list integrated into the audio event spec
|
||||
|
||||
### Step 3: Technical Implementation (parallel)
|
||||
Spawn the `technical-artist` agent to:
|
||||
- Design the audio middleware integration (Wwise/FMOD/native)
|
||||
- Define audio bus structure and routing
|
||||
|
|
@ -58,6 +66,14 @@ Spawn the `technical-artist` agent to:
|
|||
- Plan streaming vs preloaded asset strategy
|
||||
- Design any audio-reactive visual effects
|
||||
|
||||
Spawn the **primary engine specialist** in parallel (from `.claude/docs/technical-preferences.md` Engine Specialists) to validate the integration approach:
|
||||
- Is the proposed audio middleware integration idiomatic for the engine? (e.g., Godot's built-in AudioStreamPlayer vs FMOD, Unity's Audio Mixer vs Wwise, Unreal's MetaSounds vs FMOD)
|
||||
- Any engine-specific audio node/component patterns that should be used?
|
||||
- Known audio system changes in the pinned engine version that affect the integration plan?
|
||||
- Output: engine audio integration notes to merge with the technical-artist's plan
|
||||
|
||||
If no engine is configured, skip the specialist spawn.
|
||||
|
||||
### Step 4: Code Integration (gameplay-programmer)
|
||||
Spawn the `gameplay-programmer` agent to:
|
||||
- Implement audio manager system or review existing
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ The user must approve before moving to the next phase.
|
|||
- **ai-programmer** — Implement NPC/enemy AI behavior for the feature
|
||||
- **technical-artist** — Create VFX, shader effects, and visual feedback
|
||||
- **sound-designer** — Define audio events, impact sounds, and ambient combat audio
|
||||
- **engine specialist** (primary) — Validate architecture and implementation patterns are idiomatic for the engine (read from `.claude/docs/technical-preferences.md` Engine Specialists section)
|
||||
- **qa-tester** — Write test cases and validate the implementation
|
||||
|
||||
## How to Delegate
|
||||
|
|
@ -28,6 +29,7 @@ Use the Task tool to spawn each team member as a subagent:
|
|||
- `subagent_type: ai-programmer` — Implement NPC/enemy AI behavior
|
||||
- `subagent_type: technical-artist` — Create VFX, shader effects, visual feedback
|
||||
- `subagent_type: sound-designer` — Define audio events, impact sounds, ambient audio
|
||||
- `subagent_type: [primary engine specialist]` — Engine idiom validation for architecture and implementation
|
||||
- `subagent_type: qa-tester` — Write test cases and validate implementation
|
||||
|
||||
Always provide full context in each agent's prompt (design doc path, relevant code files, constraints). Launch independent agents in parallel where the pipeline allows it (e.g., Phase 3 agents can run simultaneously).
|
||||
|
|
@ -46,6 +48,12 @@ Delegate to **gameplay-programmer** (with **ai-programmer** if AI is involved):
|
|||
- Identify integration points with existing systems
|
||||
- Output: architecture sketch with file list and interface definitions
|
||||
|
||||
Then spawn the **primary engine specialist** to validate the proposed architecture:
|
||||
- Is the class/node/component structure idiomatic for the pinned engine? (e.g., Godot node hierarchy, Unity MonoBehaviour vs DOTS, Unreal Actor/Component design)
|
||||
- Are there engine-native systems that should be used instead of custom implementations?
|
||||
- Any proposed APIs that are deprecated or changed in the pinned engine version?
|
||||
- Output: engine architecture notes — incorporate into the architecture before Phase 3 begins
|
||||
|
||||
### Phase 3: Implementation (parallel where possible)
|
||||
Delegate in parallel:
|
||||
- **gameplay-programmer**: Implement core combat mechanic code
|
||||
|
|
|
|||
|
|
@ -31,6 +31,7 @@ Use the Task tool to spawn each team member as a subagent:
|
|||
- `subagent_type: level-designer` — Spatial layout, pacing, encounters, navigation
|
||||
- `subagent_type: systems-designer` — Enemy compositions, loot tables, difficulty balance
|
||||
- `subagent_type: art-director` — Visual theme, color palette, lighting, asset requirements
|
||||
- `subagent_type: accessibility-specialist` — Navigation clarity, colorblind safety, cognitive load
|
||||
- `subagent_type: qa-tester` — Test cases, boundary testing, playtest checklist
|
||||
|
||||
Always provide full context in each agent's prompt (game concept, pillars, existing level docs, narrative docs).
|
||||
|
|
@ -65,7 +66,7 @@ Spawn the `systems-designer` agent to:
|
|||
- Design any area-specific mechanics or environmental hazards
|
||||
- Specify resource distribution (health pickups, save points, shops)
|
||||
|
||||
### Step 4: Visual Direction (art-director)
|
||||
### Step 4: Visual Direction and Accessibility (parallel)
|
||||
Spawn the `art-director` agent to:
|
||||
- Define the visual theme and color palette for the area
|
||||
- Specify lighting mood and time-of-day settings
|
||||
|
|
@ -73,6 +74,13 @@ Spawn the `art-director` agent to:
|
|||
- Define visual landmarks and sight lines
|
||||
- Specify any special VFX needs (weather, particles, fog)
|
||||
|
||||
Spawn the `accessibility-specialist` agent in parallel to:
|
||||
- Review the level layout for navigation clarity (can players orient themselves without relying on color alone?)
|
||||
- Check that critical path signposting uses shape/icon/sound cues in addition to color
|
||||
- Review any puzzle mechanics for cognitive load — flag anything that requires holding more than 3 simultaneous states
|
||||
- Check that key gameplay areas have sufficient contrast for colorblind players
|
||||
- Output: accessibility concerns list with severity (BLOCKING / RECOMMENDED / NICE TO HAVE)
|
||||
|
||||
### Step 5: QA Planning (qa-tester)
|
||||
Spawn the `qa-tester` agent to:
|
||||
- Write test cases for the critical path
|
||||
|
|
|
|||
109
.claude/skills/team-live-ops/SKILL.md
Normal file
109
.claude/skills/team-live-ops/SKILL.md
Normal file
|
|
@ -0,0 +1,109 @@
|
|||
---
|
||||
name: team-live-ops
|
||||
description: "Orchestrate the live-ops team for post-launch content planning: coordinates live-ops-designer, economy-designer, analytics-engineer, community-manager, writer, and narrative-director to design and plan a season, event, or live content update."
|
||||
argument-hint: "[season name or event description]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
|
||||
---
|
||||
When this skill is invoked, 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.
|
||||
The user must approve before moving to the next phase.
|
||||
|
||||
## 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 Task 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
|
||||
|
||||
Always provide full context in each agent's prompt (game concept path, existing season docs, ethics policy path, current economy state). 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**: flag any element that violates the ethics policy in `design/live-ops/ethics-policy.md`
|
||||
- **Open questions**: decisions still needed before production begins
|
||||
|
||||
Ask the user to approve the season plan before delegating to production teams.
|
||||
|
||||
## Output Documents
|
||||
All documents save to `design/live-ops/`:
|
||||
- `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)
|
||||
|
||||
## 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.
|
||||
|
|
@ -25,6 +25,7 @@ Use the Task tool to spawn each team member as a subagent:
|
|||
- `subagent_type: writer` — Dialogue writing, lore entries, in-game text
|
||||
- `subagent_type: world-builder` — World rules, faction design, history, geography
|
||||
- `subagent_type: level-designer` — Level layouts that serve the narrative, pacing
|
||||
- `subagent_type: localization-lead` — i18n validation, string key compliance, translation headroom
|
||||
|
||||
Always provide full context in each agent's prompt (narrative brief, lore dependencies, character profiles). Launch independent agents in parallel where the pipeline allows it (e.g., Phase 2 agents can run simultaneously).
|
||||
|
||||
|
|
@ -57,11 +58,11 @@ Delegate to **narrative-director**:
|
|||
- Confirm narrative pacing aligns with level design
|
||||
- Check that all mysteries have documented "true answers"
|
||||
|
||||
### Phase 5: Polish
|
||||
- Writer reviews all text for localization readiness
|
||||
- Verify no line exceeds dialogue box constraints
|
||||
- Confirm all text uses string keys (localization pipeline ready)
|
||||
- World-builder finalizes canon levels for all new lore
|
||||
### Phase 5: Polish (parallel)
|
||||
Delegate in parallel:
|
||||
- **writer**: Final self-review — verify no line exceeds dialogue box constraints, all text uses string keys (not raw strings), placeholder variable names are consistent
|
||||
- **localization-lead**: Validate i18n compliance — check string key naming conventions, flag any strings with hardcoded formatting that won't survive translation, verify character limit headroom for languages that expand (German/Finnish typically +30%), confirm no cultural assumptions in text that would need locale-specific variants
|
||||
- **world-builder**: Finalize canon levels for all new lore entries
|
||||
|
||||
## Output
|
||||
A summary report covering: narrative brief status, lore entries created/updated, dialogue lines written, level narrative integration points, consistency review results, and any unresolved contradictions.
|
||||
|
|
|
|||
|
|
@ -14,16 +14,20 @@ The user must approve before moving to the next phase.
|
|||
|
||||
## Team Composition
|
||||
- **performance-analyst** — Profiling, optimization, memory analysis, frame budget
|
||||
- **engine-programmer** — Engine-level bottlenecks: rendering pipeline, memory, resource loading (invoke when performance-analyst identifies low-level root causes)
|
||||
- **technical-artist** — VFX polish, shader optimization, visual quality
|
||||
- **sound-designer** — Audio polish, mixing, ambient layers, feedback sounds
|
||||
- **tools-programmer** — Content pipeline tool verification, editor tool stability, automation fixes (invoke when content authoring tools are involved in the polished area)
|
||||
- **qa-tester** — Edge case testing, regression testing, soak testing
|
||||
|
||||
## How to Delegate
|
||||
|
||||
Use the Task tool to spawn each team member as a subagent:
|
||||
- `subagent_type: performance-analyst` — Profiling, optimization, memory analysis
|
||||
- `subagent_type: engine-programmer` — Engine-level fixes for rendering, memory, resource loading
|
||||
- `subagent_type: technical-artist` — VFX polish, shader optimization, visual quality
|
||||
- `subagent_type: sound-designer` — Audio polish, mixing, ambient layers
|
||||
- `subagent_type: tools-programmer` — Content pipeline and editor tool verification
|
||||
- `subagent_type: qa-tester` — Edge case testing, regression testing, soak testing
|
||||
|
||||
Always provide full context in each agent's prompt (target feature/area, performance budgets, known issues). Launch independent agents in parallel where the pipeline allows it (e.g., Phases 3 and 4 can run simultaneously).
|
||||
|
|
@ -46,6 +50,11 @@ Delegate to **performance-analyst** (with relevant programmers as needed):
|
|||
- Verify optimizations don't change gameplay behavior
|
||||
- Output: optimized code with before/after metrics
|
||||
|
||||
If Phase 1 identified engine-level root causes (rendering pipeline, resource loading, memory allocator), delegate those fixes to **engine-programmer** in parallel:
|
||||
- Optimize hot paths in engine systems
|
||||
- Fix allocation pressure in core loops
|
||||
- Output: engine-level fixes with profiler validation
|
||||
|
||||
### Phase 3: Visual Polish (parallel with Phase 2)
|
||||
Delegate to **technical-artist**:
|
||||
- Review VFX for quality and consistency with art bible
|
||||
|
|
|
|||
|
|
@ -16,6 +16,9 @@ The user must approve before moving to the next phase.
|
|||
- **release-manager** — Release branch, versioning, changelog, deployment
|
||||
- **qa-lead** — Test sign-off, regression suite, release quality gate
|
||||
- **devops-engineer** — Build pipeline, artifacts, deployment automation
|
||||
- **security-engineer** — Pre-release security audit (invoke if game has online/multiplayer features or player data)
|
||||
- **analytics-engineer** — Verify telemetry events fire correctly and dashboards are live
|
||||
- **community-manager** — Patch notes, launch announcement, player-facing messaging
|
||||
- **producer** — Go/no-go decision, stakeholder communication, scheduling
|
||||
|
||||
## How to Delegate
|
||||
|
|
@ -24,7 +27,11 @@ Use the Task tool to spawn each team member as a subagent:
|
|||
- `subagent_type: release-manager` — Release branch, versioning, changelog, deployment
|
||||
- `subagent_type: qa-lead` — Test sign-off, regression suite, release quality gate
|
||||
- `subagent_type: devops-engineer` — Build pipeline, artifacts, deployment automation
|
||||
- `subagent_type: security-engineer` — Security audit for online/multiplayer/data features
|
||||
- `subagent_type: analytics-engineer` — Telemetry event verification and dashboard readiness
|
||||
- `subagent_type: community-manager` — Patch notes and launch communication
|
||||
- `subagent_type: producer` — Go/no-go decision, stakeholder communication
|
||||
- `subagent_type: network-programmer` — Netcode stability sign-off (invoke if game has multiplayer)
|
||||
|
||||
Always provide full context in each agent's prompt (version number, milestone status, known issues). Launch independent agents in parallel where the pipeline allows it (e.g., Phase 3 agents can run simultaneously).
|
||||
|
||||
|
|
@ -49,12 +56,15 @@ Delegate to **release-manager**:
|
|||
Delegate in parallel:
|
||||
- **qa-lead**: Execute full regression test suite. Test all critical paths. Verify no S1/S2 bugs. Sign off on quality.
|
||||
- **devops-engineer**: Build release artifacts for all target platforms. Verify builds are clean and reproducible. Run automated tests in CI.
|
||||
- **security-engineer** *(if game has online features, multiplayer, or player data)*: Conduct pre-release security audit. Review authentication, anti-cheat, data privacy compliance. Sign off on security posture.
|
||||
- **network-programmer** *(if game has multiplayer)*: Sign off on netcode stability. Verify lag compensation, reconnect handling, and bandwidth usage under load.
|
||||
|
||||
### Phase 4: Localization and Performance
|
||||
### Phase 4: Localization, Performance, and Analytics
|
||||
Delegate (can run in parallel with Phase 3 if resources available):
|
||||
- Verify all strings are translated (delegate to localization-lead if available)
|
||||
- Run performance benchmarks against targets (delegate to performance-analyst if available)
|
||||
- Output: localization and performance sign-off
|
||||
- Verify all strings are translated (delegate to **localization-lead** if available)
|
||||
- Run performance benchmarks against targets (delegate to **performance-analyst** if available)
|
||||
- **analytics-engineer**: Verify all telemetry events fire correctly on release build. Confirm dashboards are receiving data. Check that critical funnels (onboarding, progression, monetization if applicable) are instrumented.
|
||||
- Output: localization, performance, and analytics sign-off
|
||||
|
||||
### Phase 5: Go/No-Go
|
||||
Delegate to **producer**:
|
||||
|
|
@ -71,10 +81,18 @@ Delegate to **release-manager** + **devops-engineer**:
|
|||
- Deploy to production
|
||||
- Monitor for 48 hours post-release
|
||||
|
||||
Delegate to **community-manager** (in parallel with deployment):
|
||||
- Finalize patch notes using `/patch-notes [version]`
|
||||
- Prepare launch announcement (store page updates, social media, community post)
|
||||
- Draft known issues post if any S3+ issues shipped
|
||||
- Output: all player-facing release communication, ready to publish on deploy confirmation
|
||||
|
||||
### Phase 7: Post-Release
|
||||
- **release-manager**: Generate release report (what shipped, what was deferred, metrics)
|
||||
- **producer**: Update milestone tracking, communicate to stakeholders
|
||||
- **qa-lead**: Monitor incoming bug reports for regressions
|
||||
- **community-manager**: Publish all player-facing communication, monitor community sentiment
|
||||
- **analytics-engineer**: Confirm live dashboards are healthy; alert if any critical events are missing
|
||||
- Schedule post-release retrospective if issues occurred
|
||||
|
||||
## Output
|
||||
|
|
|
|||
|
|
@ -16,6 +16,7 @@ The user must approve before moving to the next phase.
|
|||
- **ux-designer** — User flows, wireframes, accessibility, input handling
|
||||
- **ui-programmer** — UI framework, screens, widgets, data binding, implementation
|
||||
- **art-director** — Visual style, layout polish, consistency with art bible
|
||||
- **engine UI specialist** — Validates UI implementation patterns against engine-specific best practices (read from `.claude/docs/technical-preferences.md` Engine Specialists → UI Specialist)
|
||||
- **accessibility-specialist** — Audits accessibility compliance at Phase 4
|
||||
|
||||
**Templates used by this pipeline:**
|
||||
|
|
@ -30,6 +31,7 @@ Use the Task tool to spawn each team member as a subagent:
|
|||
- `subagent_type: ux-designer` — User flows, wireframes, accessibility, input handling
|
||||
- `subagent_type: ui-programmer` — UI framework, screens, widgets, data binding
|
||||
- `subagent_type: art-director` — Visual style, layout polish, art bible consistency
|
||||
- `subagent_type: [UI engine specialist]` — Engine-specific UI pattern validation (e.g., unity-ui-specialist, ue-umg-specialist, godot-specialist)
|
||||
- `subagent_type: accessibility-specialist` — Accessibility compliance audit
|
||||
|
||||
Always provide full context in each agent's prompt (feature requirements, existing UI patterns, platform targets). Launch independent agents in parallel where the pipeline allows it (e.g., Phase 4 review agents can run simultaneously).
|
||||
|
|
@ -77,6 +79,14 @@ Delegate to **art-director**:
|
|||
|
||||
### Phase 3: Implementation
|
||||
|
||||
Before implementation begins, spawn the **engine UI specialist** (from `.claude/docs/technical-preferences.md` Engine Specialists → UI Specialist) to review the UX spec and visual design spec for engine-specific implementation guidance:
|
||||
- Which engine UI framework should be used for this screen? (e.g., UI Toolkit vs UGUI in Unity, Control nodes vs CanvasLayer in Godot, UMG vs CommonUI in Unreal)
|
||||
- Any engine-specific gotchas for the proposed layout or interaction patterns?
|
||||
- Recommended widget/node structure for the engine?
|
||||
- Output: engine UI implementation notes to hand off to ui-programmer before they begin
|
||||
|
||||
If no engine is configured, skip this step.
|
||||
|
||||
Delegate to **ui-programmer**:
|
||||
- Implement the UI following the UX spec and visual design spec
|
||||
- **Use patterns from `design/ux/interaction-patterns.md`** — do not reinvent patterns that are already specified. If a pattern almost fits but needs modification, note the deviation and flag it for ux-designer review.
|
||||
|
|
|
|||
Loading…
Reference in a new issue