uinaf/gh-deploy-pipeline
Set up or align a GitHub Actions deploy pipeline for an app or service. Use when standardizing repos around the verify-then-deploy shape: push to main → detect affected lanes → verify and build artifacts → e2e → deploy each lane to its host (Cloudflare Pages, AWS Amplify, GHCR + VPS).
92
90%
Does it follow best practices?
Impact
97%
1.25xAverage score across 4 eval scenarios
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that is highly specific, includes rich trigger terms, clearly answers both what and when, and explicitly distinguishes itself from a related skill. The pipeline shape description (push to main → detect → verify → e2e → deploy) gives Claude a very clear mental model of when to select this skill. The negative scoping ('not publishing artifacts to a registry') further reduces conflict risk.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and architectural details: 'set up or align a GitHub Actions deploy pipeline', 'push to main → detect affected lanes → verify and build artifacts → e2e → deploy each lane', and names specific hosts like Cloudflare Pages, AWS Amplify, GHCR + VPS. Very concrete. | 3 / 3 |
Completeness | Clearly answers both 'what' (set up/align a GitHub Actions deploy pipeline with the verify-then-deploy shape) and 'when' ('Use when standardizing repos around the verify-then-deploy shape'). Also includes explicit negative scoping ('not publishing artifacts to a registry') and distinguishes from a related skill (`gh-release-pipeline`). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'GitHub Actions', 'deploy pipeline', 'Cloudflare Pages', 'AWS Amplify', 'GHCR', 'VPS', 'e2e', 'concurrency group', 'push to main'. These cover a wide range of terms a user working on CI/CD deployment would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with explicit differentiation from the related `gh-release-pipeline` skill. The description carves out a clear niche: deploying running apps via GitHub Actions with a specific pipeline shape, not publishing versioned packages. Unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, concise deploy pipeline skill that clearly communicates the pipeline topology, sequencing, and guardrails. Its main weakness is that actionability depends heavily on referenced files (workflows.md, targets.md, secrets.md) that aren't provided in the bundle, leaving the SKILL.md body with mostly procedural guidance rather than executable snippets. The guardrails section and non-cancellable concurrency emphasis add genuine safety value.
Suggestions
Include at least one more complete, executable YAML snippet inline — e.g., the concurrency group configuration or the paths-filter setup — so the skill is actionable even without loading referenced files.
Provide the referenced bundle files (references/workflows.md, references/targets.md, references/secrets.md, references/troubleshooting.md) or include minimal inline fallback content so the skill isn't hollow when references are unavailable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient throughout. It assumes Claude understands CI/CD concepts, GitHub Actions, Docker, and hosting platforms without explaining them. Every section adds domain-specific knowledge about the deploy pipeline shape, concurrency semantics, and artifact flow that Claude wouldn't inherently know. | 3 / 3 |
Actionability | The workflow steps are concrete and well-sequenced, and the YAML example is executable. However, most of the guidance is procedural description rather than copy-paste-ready code — the composite actions, the paths-filter config, the Turbo affected walker, and the concurrency group syntax are described but not shown as complete executable snippets. The skill relies heavily on referenced files for the actual implementation details. | 2 / 3 |
Workflow Clarity | The 10-step workflow is clearly sequenced with explicit validation checkpoints: step 8 adds a smoke/health-check after deploy, step 9 describes end-to-end validation including confirming only the touched lane ran, and step 10 references troubleshooting. The pipeline shape diagram at the top makes the topology immediately clear. Feedback loops are implicit in the verify→e2e→deploy→smoke chain with non-cancellable concurrency preventing race conditions. | 3 / 3 |
Progressive Disclosure | The skill references four supporting files (references/targets.md, references/workflows.md, references/secrets.md, references/troubleshooting.md) with clear signals about when to load each one. However, no bundle files were provided, so these references cannot be verified. The instruction to load references 'only after the target lanes and host are known' is good progressive disclosure design, but the SKILL.md itself contains a fair amount of inline detail that could potentially be offloaded, and the references are unverifiable. | 2 / 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.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
Reviewed
Table of Contents