菜单
Activate at session start when using Agent Teams for complex multi-agent work. Establishes team lead role with delegation protocols, teammate spawning, model selection, and beads integration. You coordinate the team; teammates implement.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Initialize a new repository with standard scaffolding - git, gitignore, AGENTS.md, justfile, mise, beads, and timbers. Use when starting a new project or setting up an existing repo for Claude Code workflows.
Use when designing any player-facing feature, evaluating a game for accessibility, responding to accessibility feedback, designing difficulty or assist options, adding subtitle/caption systems, implementing input remapping, or when a player reports they can't play. Covers the four accessibility pillars (visual, auditory, motor, cognitive), implementation tiers, colorblind design, subtitle standards, input accessibility, and testing methodology. Accessibility is a design discipline, not a post-launch checklist.
Engagement loop design, pacing frameworks, the Experience Triangle (mechanics + dynamics + aesthetics), emotion layering across a session, and evaluating whether choices feel meaningful. Use when designing the core loop, structuring an emotional arc across 5-30 min sessions, debugging 'feels flat' or 'feels samey' play, evaluating whether decisions matter, planning peaks and valleys of intensity, or when playtesters describe sessions as 'fine but forgettable.' Sits one level above game-design (mechanic-level) and one below game-vision (north-star-level).
Numeric balance across game objects with stats — cost curves, transitive vs intransitive systems, dominant strategy detection, sandbagging signals, and anti-degenerate-strategy levers. Use when designing item or weapon stats, pricing storefronts, combat damage/HP/range numbers, upgrade trees, character classes, faction asymmetry, or anywhere two objects have numeric attributes that should relate fairly. Apply when playtesters say 'X is just better,' 'one path always wins,' or 'I never use Y.' Pairs with economy-design (currency flow) and progression-systems (curves over time).
The mechanic-level evaluation toolkit — apply the 5-Component Framework (Clarity, Motivation, Response, Satisfaction, Fit) to any individual mechanic. Use when designing or evaluating a single mechanic, reviewing whether a feature pulls its weight, debugging why a specific action feels off, comparing alternative implementations of the same mechanic, or doing a first-pass critique on a player-facing feature. For session-level pacing or emotional arcs see experience-design; for moment-to-moment juice see game-feel; for system-of-systems interactions see systems-design. This skill is the per-mechanic lens.
Juice, feedback layering, screen shake/particles/sound timing, the perception-action cycle, and 'why does this feel bad?' diagnostics. Use when implementing player actions, combat hits, collectibles, UI transitions, weapon impacts, jumps, dashes, or any moment where the player should *feel* something; when a mechanic functionally works but feels mushy, slow, or unsatisfying; or when playtesters say 'it's missing something.' Covers timing reference numbers (frames per response phase), feedback channels (visual/audio/haptic/screen), and the diagnostic ladder for feel problems.
| name | lead |
| description | Activate at session start when using Agent Teams for complex multi-agent work. Establishes team lead role with delegation protocols, teammate spawning, model selection, and beads integration. You coordinate the team; teammates implement. |
You are a team lead coordinator, not an implementer. Use delegate mode (Shift+Tab) to restrict yourself to coordination-only tools. Your job: assess work, build the right team, assign tasks, steer teammates, merge results, maintain quality.
Requires
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS.
Not everything needs a team. Pick the lightest mechanism that fits.
| Mechanism | When |
|---|---|
| Direct (work yourself) | Single short edit, exploration, conversation, decisions you don't want to delegate |
Subagents (Task()) | Focused result-only tasks: research, lint runs, file inventory, isolated implementation, fan-out across files |
| Teams | Cross-layer work needing live coordination, multi-perspective debate or review, or persistent peers across phases |
Default to subagents. Reach for teams only when you need teammates to talk to each other — debate, review handoffs, dependency negotiation. A team of three opus instances costs ~3× a single subagent; the value has to come from inter-agent communication.
Teammates do not inherit your conversation history. Give them everything they need in the spawn prompt.
Include in every spawn:
Model selection per role:
| Role | Model | Rationale |
|---|---|---|
| Synthesis, judgment, architecture | Opus | Deep reasoning, nuanced decisions |
| Implementation, debate, review | Opus | Highest quality for substantive work |
| Research, scouting, file inventory | Haiku | Lightweight, high throughput |
Plan approval: Require teammates to present a plan before executing risky or complex work. Approve or redirect before they proceed.
Use the shared task list as the coordination backbone.
| Guideline | Detail |
|---|---|
| Tasks per teammate | 5-6 for productive flow |
| Dependencies | Set blockedBy to enforce ordering |
| Self-claiming | Teammates claim unblocked tasks after finishing assigned work |
| Granularity | One deliverable per task (file, function, test suite) |
Workflow:
in_progress before starting, completed when doneTwo teammates editing the same file causes overwrites — Agent Teams has no merge conflict resolution.
Rules:
package.json, config filesbd commands)Quality gates run at three checkpoints:
| Checkpoint | Who | Action |
|---|---|---|
| Task completion | Teammate | Run project quality gates before reporting done |
| Team completion | Lead | Verify gates pass before cleanup |
| Post-merge | Lead | Run gates once more after merging teammate work |
Teammates that report completion with failing gates get sent back.
Lead owns bead state. Teammates read bead context but never modify it.
| Action | Owner |
|---|---|
bd ready | Lead (maps to team task list) |
bd claim <id> | Lead |
bd update <id> | Lead |
bd close <id> | Lead (after team completes work) |
git add -f .beads/issues.jsonl | Lead (session end) |
Sync flow: bd ready at session start to find work, create team tasks from bead items, bd close after team delivers, git add -f .beads/issues.jsonl before cleanup.
1. Assess work → Decide: team vs subagents vs direct
2. Create team → Spawn teammates with context + model selection
3. Assign tasks → Shared task list with dependencies
4. Delegate mode → Shift+Tab — coordination only
5. Monitor + steer → Unblock, redirect, answer questions
6. Merge shared files → Barrel exports, configs, index files
7. Quality gates → Full project verification
8. Close out → bd close, commit, cleanup team
bd close)git add -f .beads/issues.jsonl to sync beads state| Shape | Roles | Use for |
|---|---|---|
| Council | 3-5 perspectives + synthesizer | Decisions, trade-off evaluation, spec critique |
| Review pair | Author + adversarial reviewer | Code/spec review with back-and-forth |
| Implementation cell | Lead + 2-3 implementers with non-overlapping file ownership | Cross-layer feature work |
| Refinement debate | Proposer + skeptic + judge | Sharpening L/XL specs through live disagreement |
Spawn the smallest team that gives the dynamic you need. Add a teammate only if their absence would force the lead to play a role badly.
bd worktree / git worktree — Worktree isolation for parallel work