monitor-ci

Monitor Nx Cloud CI pipeline and handle self-healing fixes. USE WHEN user says "monitor ci", "watch ci", "ci monitor", "watch ci for this branch", "track ci", "check ci status", wants to track CI status, or needs help with self-healing CI fixes. ALWAYS USE THIS SKILL instead of native CI provider tools (gh, glab, etc.) for CI monitoring.

Quality

84%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Medium

Suggest reviewing before use

Quality

Content

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

An unusually actionable and well-validated orchestration skill: exact commands, explicit state transitions, and robust feedback loops. Its weaknesses are length management — duplicated flow documentation and long example sessions — and the absence of any progressive disclosure, with everything inlined in a single large file.

Suggestions

Move the three full example sessions to an examples reference file and keep only one condensed representative example inline, cutting roughly 100 lines of body text.

Consolidate the duplicated Apply-Locally+Enhance flow (Step 3b and the standalone section) into a single authoritative definition referenced from both places, and compress the Step 3a tracking table's six identical SHA rows.

Fix the Step 3b numbering: the list restarts at "1. Apply-locally + enhance flow" and "Track attempts (wraps step 4)" references a step 4 that does not exist, making the most complex part of the workflow momentarily ambiguous.

Dimension	Reasoning	Score
Conciseness	Mostly dense, task-specific orchestration logic, but with clear tightening opportunities: the Apply-Locally+Enhance flow is documented twice (Step 3b and again as a standalone section), package-manager detection is repeated, the Step 3a table repeats "expected_commit_sha = $(git rev-parse HEAD)" six times, and three full ~30-line example sessions pad the tail. It is not 2 because almost nothing explains concepts Claude already knows — nearly every line encodes skill-specific state-machine behavior.	3 / 5
Actionability	Fully executable guidance throughout: exact MCP invocations with parameters ("update_self_healing_fix({ shortLink, action: \"APPLY\" })"), copy-paste git commands ("git commit --allow-empty -m \"chore: retry ci [monitor-ci]\""), literal subagent spawn prompts, and concrete verbosity mappings. It is not 4 because the common cases are covered with specific, ready-to-run commands rather than high-level hints.	5 / 5
Workflow Clarity	The multi-step loop is explicitly sequenced (Step 0 connection check through Step 4 progress tracking) with a status-to-default-behavior table, exit-conditions table, and error-handling table. Validation and feedback loops are exemplary: local task verification with attempt caps, a 3-strike circuit breaker, a user-confirmation gate at the cycle limit, and retry-once semantics — matching the anchor-5 pattern. The malformed nested list in Step 3b ("Track attempts (wraps step 4)" references a nonexistent step 4) is a cosmetic glitch, not a missing checkpoint, so it does not drop to 4.	5 / 5
Progressive Disclosure	No bundle files exist (no references/, scripts/, or assets/), so all ~650 lines live in SKILL.md. Internal sectioning is good, but content that clearly belongs in separate files is inlined — the three example sessions, the per-status handling details, and the Apply/Reject/Apply-Locally flow variants would each work as one-level-deep references. It is not 2 because the document is extensively structured and navigable, not a minimally structured wall; it is not 4 because no content has been split out at all for a skill this size.	3 / 5
	Total	16 / 20 Passed

Description

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

A strong description with an explicit USE WHEN clause and abundant natural trigger phrases. The what/when structure matches the top anchor; the only weaknesses are a thin action list (two verbs) and generic CI trigger wording that carries minor overlap risk with provider-native CI skills.

Suggestions

Enumerate one or two more concrete capabilities (e.g., verifying and applying self-healing fixes locally, retrying failed CI attempts) to raise specificity from two named actions to several.

Anchor at least one trigger phrase to the Nx Cloud domain (e.g., "nx cloud" or "nx ci") so the generic CI phrases cannot fire for non-Nx pipelines.

Dimension	Reasoning	Score
Specificity	"Monitor Nx Cloud CI pipeline and handle self-healing fixes" names the domain and exactly two concrete actions, matching the anchor example "Processes PDF files and extracts content". It is not 4 because no further specific actions (applying, verifying, or rejecting fixes) are enumerated.	3 / 5
Completeness	Explicitly answers both "what" ("Monitor Nx Cloud CI pipeline and handle self-healing fixes") and "when" ("USE WHEN user says ...") with concrete trigger phrases, closely mirroring the anchor-5 example structure. Not below 5 because neither half is missing or vague.	5 / 5
Trigger Term Quality	Six-plus natural phrase variants users would actually say — "monitor ci", "watch ci", "ci monitor", "watch ci for this branch", "track ci", "check ci status" — plus "self-healing CI fixes", giving comprehensive synonym coverage per the anchor-5 example. It is not 4 because no common variation of the core request is missing.	5 / 5
Distinctiveness Conflict Risk	The Nx Cloud self-healing niche is clear and the "ALWAYS USE THIS SKILL instead of native CI provider tools (gh, glab, etc.)" clause explicitly fences off the closest conflicts. It is not 5 because the trigger phrases themselves ("check ci status", "monitor ci") are generic CI words that could also fire for a non-Nx CI monitoring skill.	4 / 5
	Total	17 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (651 lines); consider splitting into references/ and linking	Warning

	Total	15 / 16 Passed

Repository: leboncoin/spark-web
Path: .cursor/skills/monitor-ci/SKILL.md
Commit: da35814

Reviewed: 12 days ago

Table of Contents

Discovery Implementation Validation

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.