nic-ci-pipelines

CI/CD pipeline structure, GitHub Actions workflows, reusable workflow patterns, and matrix builds for NIC. Use when working on CI workflows, debugging build failures, adding new workflow steps, modifying build matrices, or understanding the release pipeline.

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

71%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 genuinely high-signal body: almost every line is non-obvious, repo-specific knowledge (gating rules, registry topology, concurrency semantics, gotchas with concrete failure examples) with no padding. Its weaknesses are structural — the two-stage release story is told three times, and the exhaustive workflow inventory is inlined rather than split into a reference file — plus the absence of a single worked example of correct gate syntax.

Suggestions

Move the four workflow inventory tables (Core CI, Release, Reusable, Security/Maintenance) into a references/workflows.md file and keep a one-line summary table in SKILL.md pointing to it — this is the main fix for progressive_disclosure.

Consolidate the three overlapping tellings of the internal/public repo split and two-stage release (Repository Split, Workflow Architecture diagram, Two-Stage Release Architecture) into one authoritative section; the tables then only need the repo column.

Add a short copy-paste example of a correctly gated job ('github.repository == ... && ( ... )' with all extra conditions in one balanced group) and a minimal dispatch example for release-prep/release-publish to lift actionability to fully executable.

Dimension	Reasoning	Score
Conciseness	The body is dense with repo-specific facts Claude cannot know (gate strings, concurrency groups, registry names, hash inputs) and wastes no tokens on background concepts, but the internal/public repo split and Stage 1/Stage 2 release description are repeated across the 'Repository Split', 'Workflow Architecture', and 'Two-Stage Release Architecture' sections, matching anchor 4's 'minor instances that could be trimmed' rather than anchor 5.	4 / 5
Actionability	Guidance is highly concrete — exact paths ('.github/scripts/validate-workflow-gating.sh', '.github/data/version.txt'), a per-command diff-path table, and named failure modes like "contains(skip_step, 'prep') also matches 'push-prep-images'" — but it never shows a copy-paste example of a correctly gated job or a sample dispatch invocation, so it sits at anchor 4 rather than anchor 5's fully copy-paste-ready coverage.	4 / 5
Workflow Clarity	Multi-step pipelines are clearly sequenced (ASCII dependency diagrams, explicit Stage 1/Stage 2 split, retry path for publish failures) with real validation checkpoints (release-gate, verify-codegen diff table, github-release failing loudly before milestone close, 'run it locally after editing any job's if'), but there is no step-by-step procedure for the most common reader tasks (adding a gated job, dispatching a release), matching anchor 4 rather than 5.	4 / 5
Progressive Disclosure	No bundle files exist, so everything lives in a ~250-line SKILL.md; sections and tables are well organized, but the four workflow-inventory tables (25+ workflows) are inline reference material that clearly belongs in a separate file with pointers, which fits anchor 3 ('content that should be separate is inline') better than anchor 4 and better than anchor 2 given the clean internal structure.	3 / 5
	Total	15 / 20 Passed

Description

87%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: it states a concrete capability list for a clearly-bounded domain and pairs it with an explicit, multi-trigger 'Use when…' clause in third person. The only weakness is noun-phrase 'what' items and a few missing natural synonyms in the trigger list.

Dimension	Reasoning	Score
Specificity	Names several concrete capability areas ('CI/CD pipeline structure, GitHub Actions workflows, reusable workflow patterns, and matrix builds for NIC'), but they are stated as topics rather than actions and coverage has minor gaps (e.g. release staging and secrets handling are unmentioned), matching anchor 4 rather than the comprehensive anchor 5 or the thinner anchor 3.	4 / 5
Completeness	It explicitly answers both what ('CI/CD pipeline structure, GitHub Actions workflows, reusable workflow patterns, and matrix builds for NIC') and when ('Use when working on CI workflows, debugging build failures, adding new workflow steps, modifying build matrices, or understanding the release pipeline') with concrete trigger phrases, matching anchor 5; anchor 4 would require a weaker or less explicit 'when' clause.	5 / 5
Trigger Term Quality	Good natural keyword coverage — 'CI workflows', 'debugging build failures', 'adding new workflow steps', 'modifying build matrices', 'release pipeline', 'GitHub Actions' — but a few natural synonyms are missing (e.g. '.github/workflows', 'pipeline yaml', 'actionlint'), so it fits anchor 4 rather than anchor 5's comprehensive synonym coverage.	4 / 5
Distinctiveness Conflict Risk	The 'for NIC' qualifier plus CI-pipeline-specific triggers give it a clear niche with minimal overlap risk against other skills, matching anchor 5.	5 / 5
	Total	18 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: nginx/kubernetes-ingress
Path: .github/skills/nic-ci-pipelines/SKILL.md
Commit: 499c5f6

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