CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

teamharness-team-coordination

Use when a Leader must choose Project Work boundaries, owners, dependency shape, DAG vs Loop, acceptance criteria, or follow-up strategy. Do not use for Quick Task execution after the mode is already selected.

Quality

78%

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 ./plugins/teamharness/skills/team/team-coordination/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

A tight, well-structured coordination playbook: concrete checklists, decision points, and prohibitions with almost no token waste. Its main gaps are mild cross-section redundancy and the absence of a single enumerated end-to-end workflow or worked example.

Suggestions

Consolidate the repeated single-owner rule into one section and cross-reference it from the others to reclaim a few tokens.

Add one short worked example of a dispatch message and the subsequent accept-or-revise decision to make the check_task flow concrete.

Optionally state the leader workflow as an ordered list (clarify -> choose mode -> bound tasks -> dispatch -> decide -> report) so the sequence is explicit rather than implied by section order.

DimensionReasoningScore

Conciseness

Lean, imperative bullets with no padding and no explanation of concepts Claude already knows. Not 5 because the same rules are stated two to three times across sections (single-owner conflicts appear in the intro, 'Good Task Boundaries', and 'Patch Rules'; 'report accepted outcomes' is also repeated).

4 / 5

Actionability

Concrete, executable instruction-only guidance: an explicit pre-delegation checklist, a five-option decision list after check_task, the deliverable path 'shared/tasks/{task-id}/', and explicit prohibitions. Not 5 because there are no worked examples (e.g. a sample dispatch or acceptance decision) and 'check_task' is assumed known.

4 / 5

Workflow Clarity

The leader workflow is sequenced through the sections (clarify, choose mode, bound tasks, dispatch, decide on results) with an explicit post-completion decision checkpoint. Not 5 because the end-to-end order is implicit in section layout rather than enumerated, and error-recovery paths after a rejected result are only sketched.

4 / 5

Progressive Disclosure

No bundle files exist and none are needed — the body contains only decision guidance, not bulk reference material that should be split out. Sections are well-organized with clear headers, no nested references, and easy navigation.

5 / 5

Total

17

/

20

Passed

Description

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

A strongly scoped trigger with concrete decision areas and an explicit negative boundary, but it is entirely 'when'-oriented: the skill's actual function is left implicit, and natural-language synonyms for the trigger terms are thin.

Suggestions

State the 'what' explicitly, e.g. 'Guide Leaders through decomposing multi-member work: define task boundaries, assign one owner per task, pick DAG or Loop execution, and set acceptance criteria.'

Add natural trigger synonyms users would actually say, such as 'who owns which task', 'how to split work across workers', or 'iterate vs one-shot plan'.

Keep the negative boundary but anchor it with a positive contrast so the 'what' can be inferred even if the trigger clause is trimmed.

DimensionReasoningScore

Specificity

Lists several specific decision areas ('Project Work boundaries, owners, dependency shape, DAG vs Loop, acceptance criteria, or follow-up strategy') rather than generic language. Not 5 because all items hang on a single 'choose' verb, so the skill's actual actions are never stated.

4 / 5

Completeness

Has an explicit 'Use when...' clause with concrete triggers plus a negative boundary ('Do not use for Quick Task execution after the mode is already selected'). Not 5 because the 'what' is only implied — the description never states what the skill actually does.

4 / 5

Trigger Term Quality

Framework terms like 'DAG vs Loop', 'Project Work', 'acceptance criteria', and 'Quick Task' plausibly match requester phrasing, but common natural variations and synonyms (e.g. 'who owns what', 'task split', 'iterate until done') are missing.

3 / 5

Distinctiveness Conflict Risk

TeamHarness-specific vocabulary carves a clear niche and the explicit do-not-use clause reduces mis-triggering. Not 5 because broadly worded items like 'boundaries' and 'owners' retain minor overlap risk with generic delegation/coordination skills.

4 / 5

Total

15

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

agentscope-ai/AgentTeams

Path

plugins/teamharness/skills/team/team-coordination/SKILL.md

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.