CtrlK
BlogDocsLog inGet started
Tessl Logo

update-ci-images

Long-running orchestration to rebuild every Positron CI image (ubuntu24_04, rocky_8, rocky_9, debian, openSUSE15_6, SLES15_6, and postgres — each as a multi-arch amd64+arm64 manifest) at one new tag with a new Node version. Creates a branch + PR, bumps NODE_VERSION, dispatches the build workflows on that branch with bounded concurrency, monitors the runs, auto-fixes failures and retries, and leaves the PR open for human review once all 7 builds are green.

63

Quality

74%

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

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/update-ci-images/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

The body is a highly actionable, well-sequenced runbook with executable commands, real helper scripts, and strong validation/feedback loops. Its only weakness is length — some inline operational detail could be offloaded to a reference file to improve progressive disclosure.

Suggestions

Extract the 'Known failure patterns' subsection (terra/GDAL, PPM race, TinyTeX) into a references/failure-patterns.md file and link to it one level deep, leaving a short pointer inline.

Factor the Phase 1 PR body template into a template file or asset to reduce body length.

Consider a one-line 'scripts' inventory at the top (what each of the 4 helper scripts does) so the reader can navigate without scanning inline usage.

DimensionReasoningScore

Conciseness

Dense and information-rich with no padding about concepts Claude already knows; the prose that is present (PPM race, TinyTeX mirrors, terra/GDAL) is genuinely non-obvious repo-specific knowledge, though the overall length keeps it just short of a 5.

4 / 5

Actionability

Fully executable bash commands with concrete placeholders and real verified helper scripts (dispatch-job.sh, wait-for-runs.sh, bump-node-version.sh, bump-ppm-snapshot.sh); copy-paste ready guidance covering dispatch, monitoring, fixing, and retrying.

5 / 5

Workflow Clarity

Clear Phase 0-5 sequence with explicit validation checkpoints (clean tree, auth, Node 404 preflight), feedback loops (diagnose -> fix -> re-dispatch -> retry), per-root-cause counter budgets, stop conditions, and PR checklists — fully satisfying the batch/destructive validation requirement.

5 / 5

Progressive Disclosure

Well-organized phases with clearly signaled one-level-deep references to real scripts in ./scripts/; the long inline 'known failure patterns' section is justified as operational repo knowledge but is borderline content that could live in a reference file.

4 / 5

Total

18

/

20

Passed

Description

60%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 highly specific and clearly distinct, but it reads as a dense technical summary rather than a user-facing trigger. It answers 'what' thoroughly but lacks an explicit 'when to use it' clause and natural trigger keywords.

Suggestions

Add an explicit 'Use when ...' trigger clause naming natural user phrases (e.g. 'Use when the user asks to rebuild/refresh CI images, bump the Node version in CI images, or cut a new CI image tag').

Soften jargon — surface natural terms like 'CI images', 'Docker tag', 'Node version bump' earlier in the description instead of leading with 'multi-arch manifest' and 'bounded concurrency'.

Consider trimming the exhaustive image list from the description (it is detailed in the body) to reduce token cost while keeping a recognizable summary.

DimensionReasoningScore

Specificity

Lists multiple concrete actions (rebuild every named image, bump NODE_VERSION, create branch+PR, dispatch build workflows with bounded concurrency, monitor runs, auto-fix failures, retry, leave PR open) with comprehensive coverage of the 7-image matrix.

5 / 5

Completeness

The 'what' is clear and detailed, but there is no explicit 'Use when...' or equivalent trigger clause, so the 'when' is only weakly implied — capping completeness at 3 per the rubric guideline.

3 / 5

Trigger Term Quality

Heavy technical jargon ('multi-arch manifest', 'bounded concurrency') with only a couple of recognizable nouns ('CI image', 'Node version'); no natural trigger phrases a user would actually say when invoking the skill.

2 / 5

Distinctiveness Conflict Risk

A sharply specific niche (Positron CI images, 7 named distros + postgres, Node version bump) with distinct triggers and minimal overlap risk with other skills.

5 / 5

Total

15

/

20

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.

Repository
posit-dev/positron
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.