CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

steward

Use when an agent opens, owns, or drives a pull request in this repository, and again for every CI, review, conflict, base-movement, merge, close, or check-in event. Applies locked-head rounds, labels, tracker entry, merge authorization, and check-in cadence.

Quality

88%

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

SKILL.md
Quality
Evals
Security

Quality

Content

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

This is a tightly engineered policy skill: an event-decision table with explicit validation gates (conflict probes, merge preflight, expiry re-checks), concrete numeric cadences, and clean deferral of mechanics to clearly annotated owner documents. The only deductions are minor: a version-specific tracker link and two required specifics (attribution footer text, canonical prompt) that are deferred rather than shown.

Suggestions

Move the version-specific "0.28.0 release tracker" link out of the body (e.g., into the release-process owner document it already references) so the skill stays evergreen and trims a time-sensitive token.

Inline the exact required attribution footer text (or a one-line template of it) next to "End authored GitHub comments with the required attribution footer" so the rule is executable without a doc round-trip.

Consider replacing the self-referential "Keep this skill at or below 120 lines" line with nothing or a maintainer-note comment; it spends body tokens on upkeep rather than on driving the PR.

DimensionReasoningScore

Conciseness

The body is lean and rule-dense ("conflicts never wait", "first check near 50 minutes and later checks near four hours") with no concept padding, but the time-sensitive "0.28.0 release tracker" link and the self-referential "Keep this skill at or below 120 lines" line are tokens that do not earn their place for executing the skill, per the time-sensitivity guideline.

4 / 5

Actionability

The guidance is largely executable policy — the event-to-decision table, "never whole-array replacement or `gh pr edit`", and "Stop after three quiet checks" are concrete — but a few required specifics live only in referenced docs (the "required attribution footer" text, the canonical reviewer prompt), leaving minor gaps versus anchor 5's copy-paste readiness.

4 / 5

Workflow Clarity

Sequencing and validation are explicit throughout: "Probe conflict first" ordering, "Run live exact-head/base preflight, then merge only when every item passes", the expiry re-check ("probe the live base and read CI once more"), and the six-round boundary checkpoint, with feedback loops (round retry, conflict recovery) and an event-decision checklist for a complex process — matching anchor 5 rather than anchor 4, which requires actual validation gaps.

5 / 5

Progressive Disclosure

The body is a lean overview with well-signaled one-level-deep references, each annotated with its owned scope ("Round orchestration: candidate locks, rounds, recovery, waits, review state, carry-forward, and merge preflight"); no nested references exist and mechanics are appropriately split to owner documents, matching anchor 5.

5 / 5

Total

18

/

20

Passed

Description

87%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 is a strong, explicit trigger-rich statement: it clearly names both what the skill applies (locked-head rounds, labels, tracker entry, merge authorization, check-in cadence) and exactly when to use it, with an enumerated event list. Its only weakness is that the 'what' relies on compressed domain jargon and omits common synonyms like 'PR'.

DimensionReasoningScore

Specificity

"Applies locked-head rounds, labels, tracker entry, merge authorization, and check-in cadence" enumerates five specific mechanisms, exceeding anchor 3's 1-2 concrete actions, but they are noun-phrase mechanisms under a single grab-bag verb rather than the fully concrete, comprehensively spelled-out actions of anchor 5.

4 / 5

Completeness

"Use when an agent opens, owns, or drives a pull request in this repository, and again for every CI, review, conflict, base-movement, merge, close, or check-in event" explicitly and concretely answers when, and "Applies locked-head rounds, labels, tracker entry, merge authorization, and check-in cadence" explicitly answers what — both parts are stated with concrete trigger phrases, matching anchor 5 rather than anchor 4 where the 'when' could be more explicit.

5 / 5

Trigger Term Quality

"pull request", "CI", "review", "conflict", "merge", "close", and "check-in" are natural terms a user driving a PR would say, giving good coverage; common synonyms like the "PR" abbreviation are missing, so it falls short of anchor 5's comprehensive synonym/extension coverage.

4 / 5

Distinctiveness Conflict Risk

"a pull request in this repository" combined with event-specific triggers (CI, base-movement, check-in) carves a clear PR-stewardship niche with distinct triggers and minimal risk of firing for the wrong skill.

5 / 5

Total

18

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 10 suspicious

Warning

Total

15

/

16

Passed

Repository

richlander/dotnet-inspect

Path

.claude/skills/steward/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.