CtrlK
BlogDocsLog inGet started
Tessl Logo

update-ci-images

Long-running orchestration to rebuild every Positron CI image (ubuntu24_04, rocky_8, 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 6 builds are green.

62

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

Quality

Content

77%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is an exceptionally actionable, well-sequenced runbook with strong validation checkpoints and feedback loops for a genuinely complex long-running task. The weaker dimensions are conciseness (some explanatory prose could be trimmed) and progressive disclosure (a large failure-pattern reference block lives inline rather than in a separate file).

Suggestions

Move the 'Known failure patterns' section into a `references/known-failures.md` file and link to it from Phase 4, keeping only the decision rule inline.

Tighten the PPM race and caffeinate explanations to the actionable fix, dropping the root-cause narrative Claude can infer.

Consider a one-line 'Quick reference' table mapping each phase to its script so navigation is faster.

DimensionReasoningScore

Conciseness

The body is dense and mostly earns its tokens with repo-specific operational detail, but several passages (the PPM publish-window race root-cause narrative, the caffeinate idle-sleep rationale) are explanatory prose that could be tightened without losing clarity.

2 / 3

Actionability

It provides fully executable, copy-paste-ready commands — exact `gh api -X PATCH`, `git -C "$REPO"` invocations, and concrete script paths like `bash <dir>/scripts/dispatch-job.sh` — with no pseudocode gaps.

3 / 3

Workflow Clarity

Phases 0–5 are explicitly sequenced with validation gates (preflight 'MUST pass before changing anything'), per-root-cause retry budgets, and a diagnose→fix→re-dispatch feedback loop for this batch operation, matching the 'clear sequence with explicit validation and feedback loops' anchor.

3 / 3

Progressive Disclosure

Executable helpers are well externalized into four clearly signaled one-level-deep `scripts/` references, but the sizable 'Known failure patterns' block is reference-style material kept inline and there is no `references/` directory, so the split could be cleaner.

2 / 3

Total

10

/

12

Passed

Description

67%

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 niche-scoped, with concrete actions and a distinct purpose. Its main weakness is the absence of an explicit 'Use when…' trigger clause and a reliance on jargon over natural user phrasing, which caps completeness and trigger-term quality.

Suggestions

Add an explicit 'Use when…' clause naming the natural trigger (e.g. 'Use when rebuilding/updating all Positron CI images to a new tag with a new Node version').

Soften jargon in the opening with a natural phrasing a user would actually say ('update the CI images', 'rebuild images with a new Node').

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — 'rebuild every Positron CI image', 'Creates a branch + PR, bumps NODE_VERSION, dispatches the build workflows', 'monitors the runs, auto-fixes failures and retries, and leaves the PR open' — matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

The 'what' is answered thoroughly, but there is no explicit 'when should Claude use it' / 'Use when…' clause; per the guidelines a missing explicit trigger clause caps completeness at 2.

2 / 3

Trigger Term Quality

It contains some natural terms a user might say ('rebuild every Positron CI image', 'new Node version') but is dominated by technical jargon ('multi-arch amd64+arm64 manifest', 'bounded concurrency') with no 'Use when…' phrasing, so coverage of natural trigger terms is partial.

2 / 3

Distinctiveness Conflict Risk

It targets a narrow, repo-specific niche (rebuilding Positron CI images at one new tag with a new Node version) with distinct triggers, making it unlikely to fire for the wrong skill.

3 / 3

Total

10

/

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.

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.