Guardrail·Cloud & DevOps

CI/CD and Automation

Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality…

You say
Buy it · $49 Read it before you buy $49 Written by addyosmani · unverified publisher
Context cost
2.8k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 11.3 kBtext throughout, nothing executable
Licence
MITpaid listing
Last change
no release on file
Servers it uses
Noneruns standalone

What it does

Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Guardrail

Constrains what the agent is allowed to do.

devopsci-cd
Filed under

Cloud & DevOps

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md11.3 kB · 391 lines
--- name: ci-cd-and-automation description: Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies. ---
6# CI/CD and Automation
7
8## Overview
9
10Automate quality gates so that no change reaches production without passing tests, lint, type checking, and build. CI/CD is the enforcement mechanism for every other skill — it catches what humans and agents miss, and it does so consistently on every single change.
11
12**Shift Left:** Catch problems as early in the pipeline as possible. A bug caught in linting costs minutes; the same bug caught in production costs hours. Move checks upstream — static analysis before tests, tests before staging, staging before production.
13
14**Faster is Safer:** Smaller batches and more frequent releases reduce risk, not increase it. A deployment with 3 changes is easier to debug than one with 30. Frequent releases build confidence in the release process itself.
15
16## When to Use
17
18- Setting up a new project's CI pipeline
19- Adding or modifying automated checks
20- Configuring deployment pipelines
21- When a change should trigger automated verification
22- Debugging CI failures
23
24## The Quality Gate Pipeline
25
26Every change goes through these gates before merge:
27
28```
29Pull Request Opened
30
31
32┌─────────────────┐
33│ LINT CHECK │ eslint, prettier
34│ ↓ pass │
35│ TYPE CHECK │ tsc --noEmit
36│ ↓ pass │
37│ UNIT TESTS │ jest/vitest
38│ ↓ pass │
39│ BUILD │ npm run build
40│ ↓ pass │
41│ INTEGRATION │ API/DB tests
42│ ↓ pass │
43│ E2E (optional) │ Playwright/Cypress
44│ ↓ pass │
45│ SECURITY AUDIT │ npm audit
46│ ↓ pass │
47│ BUNDLE SIZE │ bundlesize check
48└─────────────────┘
49
50
51 Ready for review
52```
53
54**No gate can be skipped.** If lint fails, fix lint — don't disable the rule. If a test fails, fix the code — don't skip the test.
55
56## GitHub Actions Configuration
57
58### Basic CI Pipeline
59
60```yaml
61# .github/workflows/ci.yml
62name: CI
63
64on:
65 pull_request:
66 branches: [main]
67 push:
68 branches: [main]
69
70jobs:
71 quality:
72 runs-on: ubuntu-latest
73 steps:
74 - uses: actions/checkout@v4
75
76 - uses: actions/setup-node@v4
77 with:
78 node-version: '22'
79 cache: 'npm'
80
81 - name: Install dependencies
82 run: npm ci
83
84 - name: Lint
85 run: npm run lint
86
87 - name: Type check
88 run: npx tsc --noEmit
89
90 - name: Test
91 run: npm test -- --coverage
92
93 - name: Build
94 run: npm run build
95
96 - name: Security audit
97 run: npm audit --audit-level=high
98```
99
100### With Database Integration Tests
101
102```yaml
103 integration:
104 runs-on: ubuntu-latest
105 services:
106 postgres:
107 image: postgres:16
108 env:
109 POSTGRES_DB: testdb
110 POSTGRES_USER: ci_user
111 POSTGRES_PASSWORD: ${{ secrets.CI_DB_PASSWORD }}
112 ports:
113 - 5432:5432
114 options: >-
115 --health-cmd pg_isready
116 --health-interval 10s
117 --health-timeout 5s
118 --health-retries 5
119
120 steps:
121 - uses: actions/checkout@v4
122 - uses: actions/setup-node@v4
123 with:
124 node-version: '22'
125 cache: 'npm'
126 - run: npm ci
127 - name: Run migrations
128 run: npx prisma migrate deploy
129 env:
130 DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
131 - name: Integration tests
132 run: npm run test:integration
133 env:
134 DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
135```
136
137> **Note:** Even for CI-only test databases, use GitHub Secrets for credentials rather than hardcoding values. This builds good habits and prevents accidental reuse of test credentials in other contexts.
138
139### E2E Tests
140
141```yaml
142 e2e:
143 runs-on: ubuntu-latest
144 steps:
145 - uses: actions/checkout@v4
146 - uses: actions/setup-node@v4
147 with:
148 node-version: '22'
149 cache: 'npm'
150 - run: npm ci
151 - name: Install Playwright
152 run: npx playwright install --with-deps chromium
153 - name: Build
154 run: npm run build
155 - name: Run E2E tests
156 run: npx playwright test
157 - uses: actions/upload-artifact@v4
158 if: failure()
159 with:
160 name: playwright-report
161 path: playwright-report/
162```
163
164## Feeding CI Failures Back to Agents
165
166The power of CI with AI agents is the feedback loop. When CI fails:
167
168```
169CI fails
170
171
172Copy the failure output
173
174
175Feed it to the agent:
176"The CI pipeline failed with this error:
177[paste specific error]
178Fix the issue and verify locally before pushing again."
179
180
181Agent fixes → pushes → CI runs again
182```
183
184**Key patterns:**
185
186```
187Lint failure → Agent runs npm run lint --fix and commits
188Type error → Agent reads the error location and fixes the type
189Test failure → Agent follows debugging-and-error-recovery skill
190Build error → Agent checks config and dependencies
191```
192
193## Deployment Strategies
194
195### Preview Deployments
196
197Every PR gets a preview deployment for manual testing:
198
199```yaml
200# Deploy preview on PR (Vercel/Netlify/etc.)
201deploy-preview:
202 runs-on: ubuntu-latest
203 if: github.event_name == 'pull_request'
204 steps:
205 - uses: actions/checkout@v4
206 - name: Deploy preview
207 run: npx vercel --token=${{ secrets.VERCEL_TOKEN }}
208```
209
210### Feature Flags
211
212Feature flags decouple deployment from release. Deploy incomplete or risky features behind flags so you can:
213
214- **Ship code without enabling it.** Merge to main early, enable when ready.
215- **Roll back without redeploying.** Disable the flag instead of reverting code.
216- **Canary new features.** Enable for 1% of users, then 10%, then 100%.
217- **Run A/B tests.** Compare behavior with and without the feature.
218
219```typescript
220// Simple feature flag pattern
221if (featureFlags.isEnabled('new-checkout-flow', { userId })) {
222 return renderNewCheckout();
223}
224return renderLegacyCheckout();
225```
226
227**Flag lifecycle:** Create → Enable for testing → Canary → Full rollout → Remove the flag and dead code. Flags that live forever become technical debt — set a cleanup date when you create them.
228
229### Staged Rollouts
230
231```
232PR merged to main
233
234
235 Staging deployment (auto)
236 │ Manual verification
237
238 Production deployment (manual trigger or auto after staging)
239
240
241 Monitor for errors (15-minute window)
242
243 ├── Errors detected → Rollback
244 └── Clean → Done
245```
246
247### Rollback Plan
248
249Every deployment should be reversible:
250
251```yaml
252# Manual rollback workflow
253name: Rollback
254on:
255 workflow_dispatch:
256 inputs:
257 version:
258 description: 'Version to rollback to'
259 required: true
260
261jobs:
262 rollback:
263 runs-on: ubuntu-latest
264 steps:
265 - name: Rollback deployment
266 run: |
267 # Deploy the specified previous version
268 npx vercel rollback ${{ inputs.version }}
269```
270
271## Environment Management
272
273```
274.env.example → Committed (template for developers)
275.env → NOT committed (local development)
276.env.test → Committed (test environment, no real secrets)
277CI secrets → Stored in GitHub Secrets / vault
278Production secrets → Stored in deployment platform / vault
279```
280
281CI should never have production secrets. Use separate secrets for CI testing.
282
283## Automation Beyond CI
284
285### Dependabot / Renovate
286
287```yaml
288# .github/dependabot.yml
289version: 2
290updates:
291 - package-ecosystem: npm
292 directory: /
293 schedule:
294 interval: weekly
295 open-pull-requests-limit: 5
296```
297
298### Build Cop Role
299
300Designate someone responsible for keeping CI green. When the build breaks, the Build Cop's job is to fix or revert — not the person whose change caused the break. This prevents broken builds from accumulating while everyone assumes someone else will fix it.
301
302### PR Checks
303
304- **Required reviews:** At least 1 approval before merge
305- **Required status checks:** CI must pass before merge
306- **Branch protection:** No force-pushes to main
307- **Auto-merge:** If all checks pass and approved, merge automatically
308
309## CI Optimization
310
311When the pipeline exceeds 10 minutes, apply these strategies in order of impact:
312
313```
314Slow CI pipeline?
315├── Cache dependencies
316│ └── Use actions/cache or setup-node cache option for node_modules
317├── Run jobs in parallel
318│ └── Split lint, typecheck, test, build into separate parallel jobs
319├── Only run what changed
320│ └── Use path filters to skip unrelated jobs (e.g., skip e2e for docs-only PRs)
321├── Use matrix builds
322│ └── Shard test suites across multiple runners
323├── Optimize the test suite
324│ └── Remove slow tests from the critical path, run them on a schedule instead
325└── Use larger runners
326 └── GitHub-hosted larger runners or self-hosted for CPU-heavy builds
327```
328
329**Example: caching and parallelism**
330```yaml
331jobs:
332 lint:
333 runs-on: ubuntu-latest
334 steps:
335 - uses: actions/checkout@v4
336 - uses: actions/setup-node@v4
337 with: { node-version: '22', cache: 'npm' }
338 - run: npm ci
339 - run: npm run lint
340
341 typecheck:
342 runs-on: ubuntu-latest
343 steps:
344 - uses: actions/checkout@v4
345 - uses: actions/setup-node@v4
346 with: { node-version: '22', cache: 'npm' }
347 - run: npm ci
348 - run: npx tsc --noEmit
349
350 test:
351 runs-on: ubuntu-latest
352 steps:
353 - uses: actions/checkout@v4
354 - uses: actions/setup-node@v4
355 with: { node-version: '22', cache: 'npm' }
356 - run: npm ci
357 - run: npm test -- --coverage
358```
359
360## Common Rationalizations
361
362| Rationalization | Reality |
363|---|---|
364| "CI is too slow" | Optimize the pipeline (see CI Optimization below), don't skip it. A 5-minute pipeline prevents hours of debugging. |
365| "This change is trivial, skip CI" | Trivial changes break builds. CI is fast for trivial changes anyway. |
366| "The test is flaky, just re-run" | Flaky tests mask real bugs and waste everyone's time. Fix the flakiness. |
367| "We'll add CI later" | Projects without CI accumulate broken states. Set it up on day one. |
368| "Manual testing is enough" | Manual testing doesn't scale and isn't repeatable. Automate what you can. |
369
370## Red Flags
371
372- No CI pipeline in the project
373- CI failures ignored or silenced
374- Tests disabled in CI to make the pipeline pass
375- Production deploys without staging verification
376- No rollback mechanism
377- Secrets stored in code or CI config files (not secrets manager)
378- Long CI times with no optimization effort
379
380## Verification
381
382After setting up or modifying CI:
383
384- [ ] All quality gates are present (lint, types, tests, build, audit)
385- [ ] Pipeline runs on every PR and push to main
386- [ ] Failures block merge (branch protection configured)
387- [ ] CI results feed back into the development loop
388- [ ] Secrets are stored in the secrets manager, not in code
389- [ ] Deployment has a rollback mechanism
390- [ ] Pipeline runs in under 10 minutes for the test suite
391
In the file
SKILL.md1,560 words
Files1
LicenceMIT
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈60
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
2,765
on trigger
The instruction body, read only when the skill fires.
1.4%
of a 200k window
Ten skills this size would take about 14% of the window before you open a file.
050k100k150k200k context window

2.8k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

1 file, 11.3 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md11.3 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing. The MIT licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

$49 once
CI/CD and Automation · MIT · addyosmani
one-time
Price$49 once
LicenceMIT — the author’s, unchanged by this purchase
Paid throughStripe, once, on the card you add at the checkout
Keeps workingfor good — the files are yours once they are on disk
Updatesevery update its author ships, delivered through this account

You can read the whole bundle before paying — the SKILL.md above is the product, not a preview of it. What the money buys is the delivery: the folder packaged and handed to your machine by key, every update its author ships, and our support if it does not do what this listing says. The terms of use are MIT, set by the author and unchanged by buying it here.

Payment runs through Stripe, on a page like this one rather than a redirect. Once there is an account it joins the same mcprush invoice as everything else you run, so there is never a second card to enter.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
Price$49
Referenceaddyosmani/ci-cd-and-automation

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Publisher
Servers0