Name: ci
Rating: 58.4 (1 reviews)
Author: Chachamaru127

ci

CI red? Call us. Pipeline fire brigade deploys. Use when user mentions CI failures, build errors, test failures, or pipeline issues. Do NOT load for: local builds, standard implementation work, reviews, or setup.

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./opencode/skills/ci/SKILL.md

The canonical home for this skill is ci in Chachamaru127/claude-code-harness

Quality

Content

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

A well-structured, actionable CI-failure workflow with concrete commands, a safety-first approval gate, and real one-level-deep references. It is held back from the top tier by decorative diagrams, redundant prohibition restatements, and a VibeCoder section that re-explains concepts Claude already knows.

Suggestions

Collapse the test-skip/cheating prohibition to a single canonical location and have other sections reference it, removing the triple restatement.

Trim the decorative ASCII 'CI 失敗報告 → テスト vs 実装判定' box to a compact bullet list or move it into a reference file.

Move the VibeCoder glossary (re-explaining that 'CI が落ちた' means tests failed) out of the main body or drop it, since Claude already knows this.

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient (prohibition table, git commands, subagent prompt template earn their place) but includes decorative ASCII diagrams and a VibeCoder section that re-explains basics ('CI が落ちた = 自動テストが失敗している状態'), and the test-skip prohibition is repeated across three sections.	3 / 5
Actionability	Concrete, copy-paste-ready git log commands and a fully specified Task tool invocation prompt with a parameterized template provide mostly executable guidance, with only minor gaps in the analysis/fix execution details themselves (deferred to references).	4 / 5
Workflow Clarity	A clear 5-step sequence with a Step 0 classification gate, an approval-request template, a prohibition checklist, and an explicit retry-feedback loop ('修正 → 再実行 → 失敗のループが2回以上') gives most checkpoints; some validation steps remain implicit rather than enumerated.	4 / 5
Progressive Disclosure	References analyzing-failures.md and fixing-tests.md exist and are cleanly signaled one level deep in the 機能詳細 table; the body is well-sectioned, though some inlined material (git log flag catalog, VibeCoder guide) could arguably live in references.	4 / 5
	Total	15 / 20 Passed

Description

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

Strong trigger guidance and excellent distinctiveness via the positive/negative load conditions, weakened by a metaphorical 'what' and a first-person voice violation ('Call us') that costs specificity. Tightening the action statement and dropping 'us' would lift it to top-tier.

Suggestions

Replace the metaphorical 'Pipeline fire brigade deploys' with a concrete action statement in third person (e.g., 'Diagnoses CI failures, classifies root cause, and applies approved fixes').

Remove the first-person 'Call us' to comply with third-person voice guidance and recover the specificity penalty.

Add a couple of natural trigger synonyms ('tests failing', 'build broken') to push trigger term coverage toward comprehensive.

Dimension	Reasoning	Score
Specificity	The description names the CI failure domain clearly ('CI failures, build errors, test failures, or pipeline issues') but the only stated action is the metaphorical 'Pipeline fire brigade deploys', which is generic fluff rather than a concrete action; additionally the first-person 'Call us' triggers the -1 specificity penalty per the voice guideline.	2 / 5
Completeness	An explicit 'Use when...' clause with both positive triggers and a 'Do NOT load for...' exclusion list clearly answers 'when'; the 'what' is present but weak ('fire brigade deploys' is metaphorical), so it falls just short of a 5.	4 / 5
Trigger Term Quality	Natural user phrases like 'CI red', 'CI failures', 'build errors', 'test failures', and 'pipeline issues' give good keyword coverage, though a few common variations ('tests failing', 'build broken') are absent.	4 / 5
Distinctiveness Conflict Risk	A clear CI-failure niche with distinct triggers plus an explicit exclusion list ('Do NOT load for: local builds, standard implementation work, reviews, or setup') minimizes conflict risk with adjacent skills.	5 / 5
	Total	15 / 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
relative_links	Relative link issues: 2 missing, 2 deeper-than-1-level	Warning

	Total	15 / 16 Passed

Repository: Chachamaru127/claude-code-harness
Path: opencode/skills/ci/SKILL.md
Commit: 2b2b748

Reviewed: 3 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.