pipe_skill
- Shell
8
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill simota/agent-skills --skill pipe- SKILL.md8.6 KB
Overview
This skill is a GitHub Actions workflow architect focused on designing, hardening, and optimizing CI/CD pipelines. It handles trigger strategy, permission minimization, reusable-composite design, PR automation, self-hosted runner patterns, and performance tuning. Use it when you need a production-grade workflow or a single focused improvement to CI security, speed, or maintainability.
How this skill works
I inspect existing workflows, trigger definitions, job graphs, cache and matrix usage, third-party action pins, and permission scopes. I propose changes: minimal top-level permissions with job-level grants, SHA-pinned actions, concurrency groups, DRY refactors into composite actions or reusable workflows, and path-based filters for monorepos. I provide concrete workflow snippets, testing instructions (act, workflow_dispatch), and a handoff summary for maintenance or security review.
When to use it
- Design a new GitHub Actions workflow for a project or service
- Harden CI security: permissions, OIDC, SHA pinning, SLSA steps
- Reduce CI time and cost: parallelization, caching, matrix optimization
- Introduce PR automation: labelers, auto-assign, stale/auto-close, auto-merge
- Implement monorepo selective runs or add self-hosted runner strategy
Best practices
- Set top-level permissions: {} and grant minimum per job; avoid write-all
- SHA-pin all third-party actions and enable Dependabot for actions updates
- Use concurrency groups with cancel-in-progress for PR workflows
- Extract repeated setup into Composite Actions and repeated pipelines into Reusable Workflows (DRY threshold: 3+)
- Prefer OIDC for cloud auth, and simulate changes locally with act before push
Example use cases
- Create a PR workflow that cancels in-progress runs, uses minimal permissions, and auto-labels based on changed paths
- Refactor three identical CI pipelines into a single reusable workflow shared across repositories
- Harden a release pipeline: OIDC for deployment, SHA-pinned actions, required checks and merge queue
- Optimize a matrix build by using dynamic matrices, cache keyed by lockfile, and fail-fast configuration
- Design self-hosted runner auto-scaling with ARC patterns and custom runner images for heavy Docker builds
FAQ
I will never change org-level or runner configurations without explicit approval; I will pause and ask when those decisions affect billing or org policy.
How do you validate proposed workflow changes?
I recommend local tests with act and workflow_dispatch, provide test steps and expected outcomes, and include a short checklist for production rollout and monitoring.