CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/tool-selection-decision-record

Defines the output contract for writing down a chosen developer tool as a portable decision record: the observed project signal, exactly one primary recommendation, rationale that names the rejected alternative, what to read next, and a mandatory list of the conditions that would flip the choice. Adapts Architecture Decision Record conventions (context, decision, consequences, status, supersede rather than edit) to tool selection, and refuses any recommendation inferred from a README or a folder name instead of a manifest, lockfile, config file, or existing test directory. Distinct from a catalog or advisor that compares candidate tools on their merits: this owns the shape of the written record, not the comparison. Use when a tool has just been chosen (test framework, build tool, linter, package manager, migration tool) and the choice needs to be recorded so a later reader can see the signal, the rejected alternative, and what would reverse it.

75

Quality

94%

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

Overview
Quality
Evals
Security
Files

Quality

Content

85%

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

A well-structured instruction skill: actionable template, worked example, and review checklist drive high actionability and workflow clarity, with clean one-level progressive disclosure. The only soft spot is conciseness, where ADR background is duplicated between the spine and the reference file.

Suggestions

Trim the inline ADR field mapping in 'The record fields' section to a one-line pointer, since references/adr-background.md already carries the full mapping and its rationale.

De-duplicate the Nygard immutability quote, which currently appears in both Rule 4 and the anti-patterns table — keep it in one place and cross-reference.

Consider moving the ADR provenance sentences in Rule 1, Rule 2, and Rule 3 ('This follows the ADR specificity convention', 'This is the ADR Context field taken literally') into the background reference to reduce repetition in the spine.

DimensionReasoningScore

Conciseness

The ~230-line body is information-dense and mostly earns its tokens, but ADR provenance and field-to-ADR mapping are restated inline while also living in references/adr-background.md, and the immutability point recurs across Rule 4 and the anti-patterns table — tightening this redundancy would lift it to a 3.

2 / 3

Actionability

Provides a copy-paste markdown Template, a filled worked example, a nine-line review checklist, and an anti-patterns table with explicit fixes — concrete and executable guidance rather than vague direction.

3 / 3

Workflow Clarity

The four rules give a clear sequence (one recommendation → observed signal → mandatory flip conditions → supersede not edit) with a validation checkpoint ('When no admissible signal exists, do not write a record') and a review checklist that acts as a feedback loop for the draft record.

3 / 3

Progressive Disclosure

SKILL.md is an overview with two well-signaled, one-level-deep references (references/adr-background.md and references/worked-example.md), both real files, with the ADR provenance and full worked example appropriately split out of the spine.

3 / 3

Total

11

/

12

Passed

Description

100%

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 strong, third-person description that states the output contract concretely, gives an explicit Use-when trigger with natural terms, and draws a clear boundary against comparison/advisor skills. It scores at the top of every dimension.

DimensionReasoningScore

Specificity

Lists multiple concrete output components — 'the observed project signal, exactly one primary recommendation, rationale that names the rejected alternative, what to read next, and a mandatory list of the conditions that would flip the choice' — matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

Explicitly answers both what ('Defines the output contract for writing down a chosen developer tool as a portable decision record') and when ('Use when a tool has just been chosen ... and the choice needs to be recorded'), with an explicit Use-when trigger clause.

3 / 3

Trigger Term Quality

Natural user-facing terms are covered: 'Use when a tool has just been chosen (test framework, build tool, linter, package manager, migration tool) and the choice needs to be recorded', giving good coverage of phrases a user would actually say.

3 / 3

Distinctiveness Conflict Risk

Explicitly carves a distinct niche — 'Distinct from a catalog or advisor that compares candidate tools on their merits: this owns the shape of the written record, not the comparison' — making it unlikely to trigger for the wrong skill.

3 / 3

Total

12

/

12

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents