CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/dod-adherence-review

Audits an existing Definition of Done checklist line by line against repository evidence (review records, diffs, CI runs, coverage reports, scan output) and tags every line met, not met, or unverifiable, refusing to pass a line on self-attestation or on a claim with no matching diff. Covers the line-pattern-to-evidence mapping for the common checklist shapes (code reviewed, coverage threshold, docs updated, acceptance criteria covered, staging deploy plus smoke, no new accessibility regressions, telemetry wired), the entry-stage versus exit-stage split many teams run, the roll-up verdict rules, and the audit table that gets emitted. Does not author, revise, or soften the checklist. Use when a story or pull request is about to be marked done and a committed Definition of Done exists that nobody has actually checked the work against.

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

Low

Low-risk findings worth noting

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 thorough, highly actionable audit methodology with a clear sequenced workflow, explicit evidence standards, and a well-placed single reference. The only weakness is verbosity: several caveats and the Scrum Guide framing recur and could be consolidated.

Suggestions

Consolidate the repeated 'team/organization owns the lines' point, which appears in the scoping section, the Scrum Guide section, and the anti-patterns table, into a single statement to tighten the body.

Trim the 'What the Scrum Guide actually says' section to just the two facts the audit rests on; the multiple Guide URL citations and the ISTQB aside are defensive context that does not advance the audit steps.

Cut the narrative prose around the two-stage split and let the stage table plus the 'Declare the stage before auditing' note carry that content, removing the duplicated explanation.

DimensionReasoningScore

Conciseness

Mostly efficient procedural content with little explanation of things Claude already knows, but it runs ~280 lines and repeats several points (team-ownership of the lines, Scrum Guide citations, the two-stage split) that could be tightened, matching 'mostly efficient but could be tightened'.

2 / 3

Actionability

Provides concrete, executable guidance throughout — exact commands and JSON fields (`gh pr view --json reviews,reviewDecision`, LCOV `LF:`/`LH:` fields, `git diff --name-only`, axe `violations` array) plus a copy-paste output-format template, matching 'fully executable commands; copy-paste ready'.

3 / 3

Workflow Clarity

A clear six-step sequence (pin revision → split → map → assign states → apply evidence standards → roll up) with explicit validation standards acting as checkpoints and a feedback loop (unverifiable blocks until a named human supplies evidence; re-run against the new head), matching the top anchor.

3 / 3

Progressive Disclosure

The long worked example is split into a single one-level-deep, clearly signaled reference at line 250 (`references/worked-example.md`), with the main file holding overview-level method content; navigation is easy and references are not nested.

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 concrete audit actions, names the specific coverage areas, draws a clear scope boundary, and ends with an explicit Use-when trigger. It satisfies all four dimensions at the top of the scale.

DimensionReasoningScore

Specificity

Lists multiple concrete actions in third person ('Audits an existing Definition of Done checklist line by line', 'tags every line met, not met, or unverifiable') plus the specific coverage (line-pattern mapping, entry/exit split, verdict rules, audit table), matching the 'multiple specific concrete actions' anchor.

3 / 3

Completeness

Clearly answers both what (audits and tags lines against evidence, covers the mapping and verdict rules) and when via an explicit 'Use when a story or pull request is about to be marked done and a committed Definition of Done exists' trigger clause.

3 / 3

Trigger Term Quality

Natural domain terms a user would say are present ('Definition of Done', 'story', 'pull request', 'marked done'), giving good coverage rather than jargon-only phrasing.

3 / 3

Distinctiveness Conflict Risk

Occupies a clear niche (compliance audit of an existing DoD, explicitly 'Does not author, revise, or soften the checklist') with distinct triggers unlikely to fire for adjacent skills.

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