Universal team coordination skill with dynamic role generation. Uses team-worker agent architecture with role-spec files. Only coordinator is built-in -- all worker roles are generated at runtime as role-specs and spawned via team-worker agent. Beat/cadence model for orchestration. Triggers on "Team Coordinate ".
47
50%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/team-coordinate/SKILL.mdQuality
Discovery
50%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 provides some architectural specifics about how the skill works internally (team-worker agents, role-specs, beat/cadence model) but lacks concrete descriptions of what end-user tasks it accomplishes. It has a trigger phrase but insufficient natural language trigger terms and scenario-based 'when to use' guidance. The focus on implementation details over user-facing capabilities weakens its effectiveness as a skill selector.
Suggestions
Add concrete action verbs describing what the skill does for users, e.g., 'Breaks down complex projects into subtasks, assigns specialized worker roles, tracks progress across parallel workstreams'.
Expand the 'when' clause beyond just the command trigger to include natural user scenarios, e.g., 'Use when the user needs to coordinate multiple aspects of a complex task, delegate work across specialties, or manage a multi-step project requiring different expertise areas'.
Include natural trigger terms users might say, such as 'delegate', 'multi-agent', 'parallel tasks', 'project coordination', 'break down work', or 'team up'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (team coordination) and mentions some architectural details (team-worker agent architecture, role-spec files, beat/cadence model), but the actual concrete actions the skill performs are vague — 'coordination' and 'dynamic role generation' are abstract rather than listing specific tasks like 'assign tasks', 'track progress', or 'generate status reports'. | 2 / 3 |
Completeness | The 'what' is partially addressed (team coordination with dynamic role generation and agent architecture), and there is a trigger clause ('Triggers on "Team Coordinate"'), but the 'when' guidance is minimal — it only specifies a command-style trigger rather than describing scenarios or user intents that should activate this skill. | 2 / 3 |
Trigger Term Quality | It includes the explicit trigger phrase 'Team Coordinate' and mentions terms like 'team coordination', 'worker roles', and 'orchestration', but these are somewhat technical/jargon-heavy. Common natural user terms like 'delegate tasks', 'manage team', 'assign work', or 'project management' are missing. | 2 / 3 |
Distinctiveness Conflict Risk | The description is somewhat distinctive with its specific architecture (team-worker agent, role-specs, beat/cadence model) and explicit trigger phrase, but 'team coordination' and 'orchestration' are broad enough to potentially overlap with project management, task delegation, or workflow automation skills. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a comprehensive architectural overview of a team coordination system with some concrete patterns (spawn template, completion action, session schema). Its main weaknesses are the lack of validation checkpoints integrated into workflows, verbose inline schemas that could be offloaded to reference files, and insufficient concrete examples for key operations like role-spec generation and task analysis. The content sits between a reference document and an actionable skill guide without fully succeeding as either.
Suggestions
Add explicit validation checkpoints between phases (e.g., 'Validate task-analysis.json has ≥1 task and no circular dependencies before proceeding to Phase 2') to create proper feedback loops for this multi-step orchestration.
Include a concrete end-to-end example showing a sample task input, the generated role-specs, task chain, and final output — this would make the abstract phase descriptions actionable.
Move the full JSON schema for team-session.json and the detailed directory tree into a referenced spec file (e.g., specs/session-schema.md) to reduce SKILL.md length and improve progressive disclosure.
Integrate error handling into the workflow steps rather than listing it separately — e.g., after the spawn step, note what to check and how to recover inline.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is moderately efficient but includes substantial structural detail (full JSON schemas, directory trees, architecture diagrams) that could be offloaded to reference files. Some tables and sections repeat information (e.g., CLI tools listed twice). However, most content is domain-specific configuration that Claude wouldn't inherently know. | 2 / 3 |
Actionability | The spawn template and completion action provide concrete, copy-paste-ready patterns, but many sections describe architecture rather than instruct. Key operations like 'generate role-specs' and 'task analysis' lack concrete examples of what the output should look like. The Agent() and AskUserQuestion() calls are specific and executable, but Phase 1-5 details are deferred to external files without inline summaries. | 2 / 3 |
Workflow Clarity | The lifecycle is outlined with a clear phase sequence (Phase 0-5) and the resume flow has explicit steps. However, validation checkpoints are largely absent — there's no explicit verification between phases (e.g., validate role-specs before spawning, validate task-analysis before proceeding). Error handling is listed but not integrated into the workflow as feedback loops. | 2 / 3 |
Progressive Disclosure | References to specs/ and roles/ directories are well-signaled with relative links, which is good structure. However, since no bundle files are provided, we cannot verify these references resolve. The SKILL.md itself is quite long (~200+ lines) with inline JSON schemas and directory trees that could be in referenced spec files, suggesting the split between overview and detail isn't optimal. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
Total | 10 / 11 Passed | |
5ff5e86
Table of Contents
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.