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.

60

Quality

70%

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 ./.agents/skills/team-assembly/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

86%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-sequenced instruction skill: every line is a directive, conditionals are explicit, and the body stays within token budget. The only real gap is the absence of a final coverage-validation checkpoint and the reliance on an external routing document for the substantive mapping detail.

Suggestions

Add a final validation step, e.g. "Before briefing, confirm every touched path's domain is covered by at least one selected reviewer," to close the workflow with an explicit checkpoint.

Include a small inline example of a path-to-domain mapping (or fold the routing table into a bundled reference file) so execution does not depend entirely on an external doc.

DimensionReasoningScore

Conciseness

The 16-line body is lean and efficient: six numbered directives plus one guard note, with zero padding and no explanation of concepts Claude already knows. Every token earns its place, matching the anchor-5 example.

5 / 5

Actionability

Steps are concrete and executable for an instruction-only skill — read a named file ("docs/development/review-routing.md"), map paths to domains, brief reviewers with specified inputs ("the diff, controlling plan, and primary source files"), run reviews in parallel. It falls short of 5 because key operational detail (the actual path-to-domain mapping) is delegated to an external routing doc, and there are no concrete examples of domains or briefs.

4 / 5

Workflow Clarity

A clear six-step sequence with explicit conditional decision points ("when contracts or multiple consumers change", "where their files do not overlap") and a closing guard rule. It is not 5 because there is no final validation checkpoint (e.g. verify the selected team covers every touched domain before briefing) and no feedback loop; it is above 3 because the conditionals act as explicit checkpoints rather than implicit ones.

4 / 5

Progressive Disclosure

This is a sub-50-line, single-purpose skill with no bundle directories (references/, scripts/, assets/ do not exist), and the body is well organized as a numbered list with a clearly signaled one-level-deep external reference. Per the rubric's simple-skill guideline, this earns a 5.

5 / 5

Total

18

/

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.

A crisp, domain-specific description with a clear 'what' and concrete selection criteria, written in appropriate third-person/ imperative voice. Its main weakness is the complete absence of 'when to use' trigger guidance, plus missing natural synonyms that users would say when needing this skill.

Suggestions

Add an explicit 'when' clause, e.g. "Use when assembling reviewers for a change, picking reviewers for a pull request, or deciding who must review a diff."

Include natural trigger synonyms users would say, such as "code review", "PR review", "pick reviewers", or "review routing", to improve trigger-term coverage.

Optionally enumerate 1-2 more concrete capabilities (e.g. "briefs reviewers and synthesizes verdicts") to raise specificity beyond a single action.

DimensionReasoningScore

Specificity

The description names one concrete action — "Select the minimum complete reviewer team" — with four selection criteria ("touched paths, contracts, integrations, and risk"), but does not list several distinct actions as the 4/5 anchors require. It is clearly above anchor 2 ('names the domain but actions are minimal') because the criteria make the action concrete, yet below anchor 4 because coverage is a single verb with modifiers.

3 / 5

Completeness

The 'what' is clear (select the minimum complete reviewer team based on stated criteria), but there is no 'Use when...' clause or any trigger guidance, so completeness is capped at 3 per the judging guidelines. It is not a 2 because the 'what' is specific, not vague.

3 / 5

Trigger Term Quality

Relevant terms like "reviewer team", "change", "contracts", and "risk" are present and would appear in a user's request, but common variations and synonyms are missing (e.g. "code review", "pick reviewers", "review routing", "pull request"). This matches anchor 3 ('some relevant keywords but missing common variations or synonyms') better than 4, which expects broad natural-term coverage.

3 / 5

Distinctiveness Conflict Risk

"minimum complete reviewer team for a Fallow change" carves out a clear niche that is unlikely to fire for unrelated skills, with only minor overlap risk against generic code-review or PR-review skills. Not a 5 because the description lacks explicit trigger phrases that would fully disambiguate it from adjacent review-orchestration skills.

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.