Conciseness

The body is telegraphic and assumes Claude's competence: no basic concepts are explained, and every section carries operational rules rather than padding. A few spots could still be tightened, such as 'Each round is a fresh agent with no memory of the last, so the issue, the branch and the pull request are the only record' and slight redundancy between 'What done looks like' item 2 and invariant 5 ('one branch per issue, one open PR per issue').

Actionability

Guidance is copy-paste ready throughout: exact commands with flags ('gh issue view <n> --json number,title,body,url,state,labels,assignees,author,comments', 'git ls-remote --exit-code --heads origin tessl/<id>', 'gh pr create --base <base> --label tessl --title ...'), exact comment templates with literal marker strings, and defined placeholders (<n>, <id>, <base>).

Workflow Clarity

The multi-step process is explicitly sequenced: a prioritized situation list, the Canonical Workflow (plan, then build), and the ordered 'Doing the work' steps (base, branch, setup, tests, before the PR, PR, link). Validation checkpoints are explicit and repeated: 'Read it again before every write', 'run it and see it fail for the reason you expect', re-running tests after merging the base, and the error-recovery loop of 'gh pr list --head <branch> --state open' before retrying a failed 'gh pr create'.

Progressive Disclosure

The body is well sectioned with clear headers (inputs, situations, invariants, workflow, doing the work, judgment) and no buried or nested references, but it is a ~170-line monolith with no bundle files: the skill exceeds the 50-line threshold at which well-organized sections alone earn a 5, and minor cross-section overlap (done-state vs invariants) leaves small organization gaps.

Specificity

Multiple specific concrete actions cover the full lifecycle: 'read the issue and the repository, plan it with the plan skill when it needs a design, build it test-first with the build skill on the issue's own branch, and open one pull request for the issue', plus the stop condition 'Stops without a trace when a person has taken the issue back'. The only fluff is 'the Perihelion way', which is minor against otherwise comprehensive coverage.

Completeness

The 'what' is explicit and concrete (read, plan, build test-first, open one PR). A 'when' is present via the equivalent trigger condition 'a GitHub issue that a person labelled for Tessl', but it is woven into the object description rather than stated as an explicit 'Use when...' clause, so it could be more explicit. Not score 3 because explicit trigger guidance (the label) does exist; not 5 because there is no clearly phrased invocation trigger.

Trigger Term Quality

Relevant domain keywords are present ('GitHub issue', 'pull request', 'branch', 'label', 'test-first'), but common natural variations are missing: a user handing work over would say 'ticket', 'implement this issue', 'take this issue', or 'fix this', none of which appear. 'Tessl' and 'the Perihelion way' are internal jargon rather than terms a user naturally says.

Distinctiveness Conflict Risk

A clear niche with distinct triggers: only issues labelled for Tessl, a fixed branch convention ('tessl/<id>'), specific marker comments ('tessl-factory'), and delegation to named sibling skills (plan, build). Minimal realistic overlap with generic issue or PR skills.