Conciseness

Every sentence carries system-specific operational fact Claude cannot know — 'tessl launch list --link-type ... --json', the '<!-- tessl-factory -->' markers, Linear's delayed state reads, exact branch naming ('tessl/<identifier lowercased>') — with no padding and no explanation of concepts Claude already knows. It matches 'lean and efficient; every token earns its place'.

Actionability

Copy-paste-ready commands cover the common cases: the tessl launch list/cancel commands, the full gh command set, the jq label extraction, the GitHub search query, verbatim comment bodies, GraphQL mutation shapes ('issueUpdate(id, input: {stateId})', 'commentCreate(input: {issueId, body})'), and the endpoint/auth header. The only gaps (Linear read queries, team-state lookup) are minor and derivable from the given shapes.

Workflow Clarity

The workflow has an explicit stop-condition checklist ('Stop with no write and say what was wrong when:...'), first-match situation ordering per TICKET_CHANGE, re-read-before-write checkpoints ('Read the issue and the pull request again. If the issue is still ended and the pull request still open...'), a stale-read feedback loop ('read it again, up to five times, 10 to 30 seconds apart'), and per-failure handling including a retry-once rule. This matches 'clear sequence with explicit validation steps; feedback loops for error recovery; checklists'.

Progressive Disclosure

There are no bundle files (no references/, scripts/, or assets/), and the single-file structure with well-labeled sections (inputs, per-change sections, Unblocking, Invariants, Environment facts, Judgment) is defensible since one run needs all of them. It falls short of the top anchor because the frontmatter's '$ref: ./schemas/inputs.schema.json' points to a file that does not exist in the bundle, and the ~220-line body is at the edge where per-tracker environment details could live in separate reference files.

Specificity

The description enumerates five concrete actions — 'cancel runs when a person takes an issue back, close the pull request when an issue ends, wake the issues it was blocking, wake an issue when a person answers Tessl's question, and cancel runs when a Tessl pull request closes' — comprehensively covering the skill's capabilities. It matches the top anchor (multiple specific concrete actions, comprehensive coverage) with no minor gaps in coverage.

Completeness

The 'what' is explicit via the enumerated actions, and 'when' guidance exists ('when a person takes an issue back', 'when an issue ends', 'when a Tessl pull request closes'), so it is more than weakly implied. However, the trigger guidance is distributed across per-action clauses rather than a consolidated 'Use when...' clause naming the invoking events, so it fits 'both present; when could be more explicit or specific' rather than the top anchor's explicit trigger phrasing.

Trigger Term Quality

Natural phrases like 'takes an issue back', 'issue ends', 'pull request closes', and 'answers Tessl's question', plus named systems 'Linear' and 'GitHub Issues', give good keyword coverage. It falls short of the top anchor because a few natural user-facing variants (e.g. 'remove the label', 'person commented/replied', 'close the issue') are missing and some terms (Tessl, ship-ticket, land-pr) are system jargon rather than natural user terms.

Distinctiveness Conflict Risk

The niche is unmistakable — keeping Tessl's ship-ticket and land-pr run lifecycle in step with human actions on issues and pull requests, on Linear and GitHub Issues — with named proprietary systems throughout. It is clearly distinguishable from any generic skill and has minimal conflict risk, matching the top anchor.