CtrlK
BlogDocsLog inGet started
Tessl Logo

team-assembly

Select the minimum complete reviewer team for a Fallow change based on touched paths, contracts, integrations, and risk.

58

Quality

66%

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-assembly/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.

The body is an exemplar of token efficiency and appropriate delegation — a short, cleanly sequenced workflow that pushes routing detail to one external doc. Its main weakness is actionability: several steps tell Claude what to do without showing how, so execution depends heavily on the referenced routing document.

Suggestions

Add one concrete example of mapping (e.g., "a change to `src/contracts/*.ts` maps to the contracts owner plus every consumer") or a sample reviewer-brief line to make steps 2-4 executable rather than directional.

Specify how to run step 5 in practice (e.g., dispatching parallel subagents and what artifact each returns) so "run independent reviews in parallel" has an operational shape.

Insert a verification checkpoint before synthesis, such as confirming each reviewer's verdict references the diff hunk or file it covers, to close the validation gap in workflow clarity.

DimensionReasoningScore

Conciseness

The ~15-line body is lean and efficient: six terse numbered instructions plus one caution line ("Do not select reviewers only from filenames when behavior affects additional consumers"), with no explanation of concepts Claude already knows and every token earning its place.

5 / 5

Actionability

Step 1 gives a concrete pointer ("Read the current diff and `docs/development/review-routing.md`") and the steps are sequenced, but "Map touched paths and behavioral effects to reviewer domains", "Brief reviewers with the diff", and "Synthesize verdicts" are high-level directives with no commands, examples, or specifics on how to execute them — some concrete guidance, incomplete overall.

3 / 5

Workflow Clarity

The six steps form a clear, well-ordered sequence from reading inputs through synthesis, and the closing caution acts as a guardrail; however, no explicit validation checkpoint exists before synthesizing verdicts (e.g., confirming each reviewer's files were actually examined), leaving a minor validation gap.

4 / 5

Progressive Disclosure

This is a sub-50-line skill with no bundle files (references/, scripts/, assets/ are absent), a well-organized single-purpose body, and exactly one clearly-signaled, one-level-deep reference (docs/development/review-routing.md) that carries the routing detail — matching the rubric's guidance that such skills can score 5 on organization alone.

5 / 5

Total

17

/

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 states a clear, appropriately narrow capability in third person without padding, but it omits any explicit 'when to use' trigger guidance and relies on one action plus criteria rather than multiple concrete actions. Adding a 'Use when...' clause with natural trigger terms would lift both completeness and trigger-term quality.

Suggestions

Append a trigger clause such as "Use when preparing to review a change, picking code reviewers, or routing a diff for review" to supply the missing 'when' explicitly.

Include natural synonyms users would actually say (e.g., "code review", "reviewers", "diff") alongside the current criteria keywords.

Consider naming one or two additional concrete actions (e.g., how reviewers are briefed or that verdicts are synthesized) to broaden the 'what' beyond a single select action.

DimensionReasoningScore

Specificity

"Select the minimum complete reviewer team for a Fallow change" names the domain and one concrete action with selection criteria ("touched paths, contracts, integrations, and risk"), but it does not list several distinct actions, so it falls at the 'domain plus 1-2 concrete actions, not comprehensive' anchor rather than the 'several specific actions' anchor.

3 / 5

Completeness

The 'what' is clear (select the minimum complete reviewer team), but there is no 'Use when...' clause or equivalent explicit trigger guidance — the 'when' is at best weakly implied by 'for a Fallow change', which caps completeness at 3 per the judging guidelines.

3 / 5

Trigger Term Quality

It contains some relevant keywords ("reviewer team", "change", "touched paths", "risk") but misses the natural phrases a user would say, such as "code review", "pick reviewers", or "review a PR", and the project-specific "Fallow" is jargon rather than a user-spoken term.

3 / 5

Distinctiveness Conflict Risk

"Select the minimum complete reviewer team for a Fallow change based on touched paths, contracts, integrations, and risk" occupies a fairly narrow niche (reviewer routing for a project's changes) that is mostly distinct with only minor overlap risk against closely related review-orchestration skills; it is not anchor 5 because it lacks distinct explicit trigger phrases.

4 / 5

Total

13

/

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
fallow-rs/fallow
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.