CtrlK
BlogDocsLog inGet started
Tessl Logo

team-audio

Orchestrate the audio team — audio-director, sound-designer, technical-artist, gameplay-programmer — direction through implementation.

53

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/team-audio/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

70%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is an exceptionally actionable and well-gated orchestration pipeline — literal prompts, paths, verdicts, and error-recovery checks cover even edge cases — but it is padded with repeated policy justifications and inlines long meta-explanations that belong in reference files. Consolidating the write-exception and team.size rationale into a single referenced doc would lift both conciseness and progressive disclosure without losing any operational content.

Suggestions

State the bounded write exception once (e.g., in the File Write Protocol section) and reference it from the other two places instead of re-explaining it; cut the repeated justifications ('Do not fix this by asking per subagent…', the 'constraint enforced but never surfaced' rationale stated twice).

Move the team.size/phase-gate scoping essay and the Collaboration-Protocol exception blockquote into a reference file (e.g., references/write-protocol.md) and keep only the operative rules plus a one-line pointer in SKILL.md.

Compress the 'Announce the active set' preamble to its template plus one sentence of rationale — the three-paragraph defense of why the announcement exists can shrink to a single line.

DimensionReasoningScore

Conciseness

The file is noticeably verbose with several padded sections: the ~30-line team.size/phase-gate meta-explanation restates the same rule three ways ('This active-set scoping applies throughout the pipeline below…'), the bounded write exception is explained at length three separate times (return-contract note, the 'Why this does not violate the Collaboration Protocol' blockquote, and the File Write Protocol section), and philosophical justifications ('a constraint that is enforced but never surfaced is indistinguishable…') are repeated twice. The core pipeline steps are lean, but the redundancy is substantial rather than 'some', placing it at anchor 2 rather than 3.

2 / 5

Actionability

The guidance is copy-paste ready and concrete throughout: exact `subagent_type` values, a per-agent write-destination table with literal paths and slug rules, a verbatim return-contract string to end every prompt with, literal verdict strings ('COMPLETE — engine validation NOT ASSESSED ([reason])'), the announce-the-active-set line templates, and the engine-specialist derivation spelled out (Godot→godot-specialist, Unity→unity-specialist, Unreal→unreal-specialist). It is not 4 because there are no material gaps — even edge cases (no engine configured, missing sound bible) have exact output lines to emit.

5 / 5

Workflow Clarity

The sequence is explicit (Phase 0 config → Steps 1–4 → compile → save → summary) with validation checkpoints throughout: AskUserQuestion gates at each transition, BLOCKING labelling for unresolved accessibility gaps that halts Step 3, artifact verification in Error Recovery ('a named artifact that is not on disk is a failed phase, however fluent the response reads'), explicit resume instructions, partial-report requirements, and distinct COMPLETE/BLOCKED verdict formats with skipped-check reporting. This matches the anchor-5 example's validate → fix → retry loop structure.

5 / 5

Progressive Disclosure

There is good in-file structure (headers, a write-destination table) and references to project docs (`.claude/docs/automation-modes.md`, `.claude/docs/error-recovery-protocol.md`) are clearly signaled and one level deep. However, no bundle files exist and everything lives in SKILL.md: the ~15-line Collaboration-Protocol exception essay, the File Write Protocol section, and the long team.size scoping rationale are policy content that clearly belongs in a separate reference file, matching anchor 3 ('content that should be separate is inline'). It is not 4 because these inline policy blocks are substantial, not minor.

3 / 5

Total

15

/

20

Passed

Description

53%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is distinct and grammatically clean, naming the domain and the exact team roster, but it reads more like a role manifest than a triggerable description: no 'when to use' guidance, few natural trigger synonyms (sound, SFX, music), and no concrete deliverables. It is functional but below the quality of the reference good examples.

Suggestions

Add an explicit trigger clause, e.g. 'Use when designing or implementing audio for a game feature or area — combat, biomes, UI, boss encounters — or when the user mentions sound design, SFX, or game music.'

State concrete deliverables in the 'what': producing an audio design document, SFX specs, an integration plan, and audio-manager code, not just 'direction through implementation'.

Include natural synonyms users would actually say — 'sound design', 'SFX', 'music', 'game audio' — so the description matches how the request will be phrased.

DimensionReasoningScore

Specificity

The description names the domain ("Orchestrate the audio team") and enumerates concrete team roles ("audio-director, sound-designer, technical-artist, gameplay-programmer"), but the actual actions are thin — "direction through implementation" is a vague span, not a list of what the skill produces (audio design docs, SFX specs, integration plans). It sits between anchor 2 (domain named, generic actions) and anchor 4 (several specific actions); the named agent roster lifts it just above the midpoint, but no concrete deliverable is mentioned.

3 / 5

Completeness

The 'what' is present and reasonably clear (orchestrate an audio team from direction through implementation), but there is no 'Use when...' clause or equivalent trigger guidance — nothing tells Claude when this skill applies (e.g., designing audio for a game feature/area). Per the judging guideline, a missing 'Use when' clause caps completeness at 3; it is not 4 because the 'when' is entirely absent, not merely implicit.

3 / 5

Trigger Term Quality

"audio" (via "audio team" and agent names) is a natural keyword a user would say, but common variations are missing: "sound design", "SFX", "music", "sound", "game audio" appear nowhere. This matches anchor 3 (some relevant keywords but missing common variations/synonyms) rather than 4, which requires good coverage with only a few terms missing.

3 / 5

Distinctiveness Conflict Risk

The named agent roster ("audio-director, sound-designer, technical-artist, gameplay-programmer") carves a clear niche that few skills would overlap with — only closely related team-orchestration skills (e.g., a video/art team orchestrator) could collide. It is not 5 because the description doesn't state the game-audio-design scope explicitly, leaving minor overlap risk with adjacent team skills.

4 / 5

Total

13

/

20

Passed

Validation

81%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 13 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

allowed_tools_field

'allowed-tools' contains unusual tool name(s)

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

referenced_paths_exist

Referenced path issues: 1 missing

Warning

Total

13

/

16

Passed

Repository
Donchitos/Claude-Code-Game-Studios
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.