Agent skill

Deployment

by ericrisco in ericrisco/rsc-harness

A skill your agent uses when taking an app from source to live: choosing the deploy target from requirements (Hetzner+Coolify vs Vercel vs a third), then wiring container → CI → registry → host with…

MITAuto-check: notesDevOps & Cloud

Install Deployment

skills CLI
$ npx skills add ericrisco/rsc-harness --skill deployment -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ericrisco/rsc-harness deployment --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ericrisco/rsc-harness.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/deployment .claude/skills/deployment && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
deployment
GitHub stars
156
Token cost
~4.2k tokens
SKILL.md length
1,314 words
Files
8 (incl. scripts, references)
Skills in repo
229
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when taking an app from source to live: choosing the deploy target from requirements (Hetzner+Coolify vs Vercel vs a third), then wiring container → CI → registry → host with…

  • Works in 3 steps: Hetzner VPS + Coolify — cheapest… → Vercel — zero-ops serverless/edge, ideal… → A third that fits the case's sharpest…
  • Taking an app from source to live: choosing the deploy target from requirements (Hetzner+Coolify vs Vercel vs a third)
  • SKILL.md covers Decision rules, Docker — the canonical…, docker-compose for local dev +… and GitHub Actions —…, plus 8 more sections
  • Runs Shell scripts from its folder; calls docker, curl and trivy; needs GITHUB_TOKEN and NPM_TOKEN

What it does

Deployment is an agent skill from ericrisco/rsc-harness. Use when taking an app from source to live: choosing the deploy target from requirements (Hetzner+Coolify vs Vercel vs a third), then wiring container → CI → registry → host with build secrets, healthchecks and rollback. NOT one platform's mechanics (that is coolify, vercel, railway, render), NOT the Dockerfile alone (that is docker).

Its SKILL.md is about 4.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 10 other files, including scripts and reference files (for example `evals/README.md`, `evals/cases.yaml` and `references/coolify.md`).

It sits in DevOps & Cloud, covering Containers and Deployment. It works with Docker, Vercel, PostgreSQL and Python. The repository describes itself as: Your agent invents things because it has no memory, and can't touch your database because it has no arms. rsc is the meta-harness that gives it both, plus the trade to know the… The licence is MIT.

When your agent uses it

  • Taking an app from source to live: choosing the deploy target from requirements (Hetzner+Coolify vs Vercel vs a third)
  • Then wiring container → CI → registry → host with build secrets
  • Healthchecks and rollback

Example prompts

  • “/deployment”

Requirements

  • Python 3
  • A Bash shell
  • Docker
  • A credential in NPM_TOKEN
  • A credential in GITHUB_TOKEN

Workflow steps

3 steps, taken from the first numbered list in SKILL.md.

  1. Hetzner VPS + Coolify — cheapest control, EU residency, sustained/always-on/stateful;
  2. Vercel — zero-ops serverless/edge, ideal Next.js, scales to zero for spiky traffic;
  3. A third that fits the case's sharpest constraint — Railway (tiny/simple, predictable

What it can do on your machine

Read from SKILL.md and the folder at commit 92fde8f. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (Shell), which the agent can run.

    Shell commands in SKILL.md call:

    • docker
    • curl
    • trivy
    • hadolint
    • bash

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • github.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • GITHUB_TOKEN
    • NPM_TOKEN
    • POSTGRES_PASSWORD
    • COOLIFY_TOKEN

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Deployment loads about 4.2k tokens when it runs, and up to ~17k if it reads all its reference files. Until then it costs about 89 tokens; SKILL.md has 1,314 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~89
When it runs · the whole SKILL.md, loaded when a task matches
~4.2k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~17k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:106
    .env*
  • NoteMentions a .env fileSKILL.md:330
    | Secrets in `compose.yaml` env | `.env` (gitignored) / Coolify secret env |

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from ericrisco/rsc-harness at commit 92fde8f, republished under its MIT licence (© ericrisco). 1,314 words, ~4,166 tokens.

Download SKILL.mdSave it as .claude/skills/deployment/SKILL.md (or your agent's skills folder). This skill also uses 7 other files; get the full folder from GitHub.
name
deployment
description
Use when taking an app from source to live: choosing the deploy target from requirements (Hetzner+Coolify vs Vercel vs a third), then wiring container → CI → registry → host with build secrets, healthchecks and rollback. NOT one platform's mechanics (that is `coolify`, `vercel`, `railway`, `render`), NOT the Dockerfile alone (that is `docker`).
tags
deploy, docker, ci, github-actions, coolify
recommends
secure-coding
origin
risco

Ship it — Docker, GitHub Actions, and a deploy target (Coolify · Vercel · Hetzner)

Take any app in this repo from source → hardened container → green CI/CD → live on the right host, with secrets that never leak into image layers or logs, and a defined rollback path.

text
source → Dockerfile (multi-stage) → CI (lint·test·build·scan) → registry (ghcr) → target (Coolify·Vercel·Hetzner, rolling) → live + rollback
                                                                                     ▲
                                                              choose via references/hosting-targets.md

Out of scope — say so and stop: Kubernetes / Helm / ECS / Nomad orchestration; cloud IaC (Terraform, Pulumi, CloudFormation — only the GHA↔cloud OIDC handshake is covered, not provisioning); application runtime code and DB schema/migration logic (the per-stack skills at the bottom own what runs inside the container).

Decision rules

Consult these first. They settle 90% of choices before you write a line.

Table A — Base image by stack

StackBase imageNotes
FastAPI / Pythongcr.io/distroless/python3-debian12:nonroot (or python:3.13-slim)UID 65532, no shell
Gogcr.io/distroless/static-debian12:nonrootCGO_ENABLED=0 static, ~10 MB
Next.jsnode:24-bookworm-slimActive LTS; output: "standalone"
Flutter webnginxinc/nginx-unprivileged:1.27-alpinestatic SPA + try_files fallback
Postgrespostgres:18-alpinemanaged/official — do NOT build a custom image

Table B — Coolify build pack

SituationPick
Repo has a DockerfileDockerfile pack (always — CI/prod parity)
No Dockerfile, standard stackNixpacks / Railpack
Static SPA, no serverStatic
Multi-service local parityDocker Compose
CI already builds & pushesDocker Image (deploy prebuilt ghcr image)

If it has a Dockerfile, use the Dockerfile pack.

Table C — Deploy strategy

Change typeStrategy
Backward-compatibleRolling (Coolify default, healthcheck-gated)
Breaking / instant cutover / risky migrationBlue-green: two Coolify resources + domain swap
Want gradual % traffic (canary)Canary = release to a small subset, watch metrics, then ramp. Vanilla Coolify has no traffic split — emulate with feature flags (in-app % gating) or a blue-green pair behind a flagged path

Table D — Secret delivery

Secret kindMechanism
Build-time non-secretARG
Build-time secret (private dep token)BuildKit --mount=type=secret (NEVER ARG)
Runtime secretCoolify env (Is Secret) / GHA secrets
Cloud authOIDC — never a stored key

Docker — the canonical multi-stage shape

One process per container: no supervisord-managed bundles, let the orchestrator scale.

dockerfile
# syntax=docker/dockerfile:1
# ---- builder: full toolchain, deps cached before source ----
FROM <builder-base> AS builder
WORKDIR /app
COPY <lockfile> <manifest> ./           # lockfile FIRST → cached dep layer
RUN <install-deps-from-lockfile>        # changes only when the lockfile changes
COPY . .                                # source last
RUN <build>

# ---- runtime: minimal, non-root, no toolchain ----
FROM <runtime-base>                      # distroless / -slim / unprivileged nginx
WORKDIR /app
COPY --from=builder --chown=nonroot:nonroot /app/<artifact> ./
USER nonroot:nonroot
EXPOSE 8000
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD ["<readiness-probe>"]             # exec-form (distroless has no shell)
CMD ["<entrypoint>", "--host", "0.0.0.0", "--port", "8000"]
dockerfile
# GOOD: secret consumed in-layer, never persisted
RUN --mount=type=secret,id=npm_token \
    NPM_TOKEN="$(cat /run/secrets/npm_token)" npm ci
# BAD: ARG bakes the token into image history forever
ARG NPM_TOKEN
RUN npm ci   # token now visible in `docker history`
text
# .dockerignore — write this before your first build
.git
node_modules
.env*
dist
.next
__pycache__
*.log
coverage
Dockerfile*
compose*
README.md
.github
bash
DOCKER_BUILDKIT=1 docker build --secret id=npm_token,env=NPM_TOKEN -t app:dev .

→ full per-stack Dockerfiles: references/dockerfiles-by-stack.md · image-authoring depth (shrinking, base-image choice, cache busting): ../docker/SKILL.md

docker-compose for local dev + Postgres

yaml
# compose.yaml — Compose Spec, no `version:` key
services:
  app:
    build:
      context: .
      target: dev                       # dev stage of the multi-stage Dockerfile
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - .:/app                          # bind mount → hot reload
      - /app/.venv                      # anonymous volume guards container deps
    environment:
      DATABASE_URL: postgres://postgres:postgres@db:5432/app_dev
    develop:
      watch:
        - { path: ./pyproject.toml, action: rebuild }
        - { path: ./app, action: sync, target: /app/app }
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:18-alpine
    ports:
      - "127.0.0.1:5432:5432"           # host-only; NEVER 0.0.0.0 in prod
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: app_dev
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d app_dev"]
      interval: 5s
      timeout: 3s
      retries: 5

volumes:
  pgdata:
  • GOOD: bind-mount source for dev hot reload; BAD: bind-mount source over a prod image (it shadows the baked build).
  • GOOD: bind Postgres to 127.0.0.1; BAD: bind it to 0.0.0.0 in prod (publicly reachable DB).

→ prod overlay + mailpit: references/dockerfiles-by-stack.md

GitHub Actions — least-privilege pipeline

yaml
# .github/workflows/ci.yml
name: ci
on:
  push:
    branches: [main]
  pull_request:
permissions:
  contents: read                        # default-deny; escalate per job
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: bash scripts/verify.sh
  build-push:
    needs: verify
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - id: meta
        uses: docker/metadata-action@v5
        with:
          images: ghcr.io/${{ github.repository }}
          tags: |
            type=sha
            type=semver,pattern={{version}}
      - uses: docker/build-push-action@v7
        with:
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
          provenance: true
      - uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1 # v0.35.0
        with:
          image-ref: ghcr.io/${{ github.repository }}:sha-${{ github.sha }}
          exit-code: "1"
          severity: "HIGH,CRITICAL"
          ignore-unfixed: true
  • GOOD: scoped per-job permissions (only build-push gets packages: write / id-token: write).
  • BAD: blanket permissions: write-all — any compromised step can push images or mint tokens.
  • GOOD: third-party actions pinned to a full commit SHA with a version comment (@<sha> # v0.35.0). In the March 2026 trivy-action supply-chain incident (GHSA-69fq-xp46-6x23 / CVE-2026-33634), 76 of 77 tags were force-pushed to credential-stealing malware; the advisory's named known-safe ref is v0.35.0 (commit 57a97c7e7821a5776cebc9bb87c984fa69cba8f1), the one clean tag still pointing at the real master HEAD. A moving tag would have pulled the malware; this SHA pin does not. Let Dependabot bump the SHA once upstream re-tags cleanly.

→ matrix, reusable workflows, OIDC-to-cloud, environments/approvals, releases: references/github-actions.md · workflow-syntax depth: ../github-actions/SKILL.md

Choosing a deploy target (3 options)

Never recommend a single host. Gather requirements → recommend exactly three targets with trade-offs, so the choice is made with eyes open. The canonical slate:

  1. Hetzner VPS + Coolify — cheapest control, EU residency, sustained/always-on/stateful; you own ops. (The combo references/coolify.md runs on; see below.)
  2. Vercel — zero-ops serverless/edge, ideal Next.js, scales to zero for spiky traffic; metered cost climbs at sustained scale, US-default region.
  3. A third that fits the case's sharpest constraint — Railway (tiny/simple, predictable bill), Fly.io (true global edge, 30+ regions), or a hyperscaler (enterprise compliance).

Requirements to gather first: expected total/concurrent users · traffic shape (steady vs spiky) · budget ceiling · data region/residency & compliance · team ops comfort · scaling needs (scale-to-zero, global latency) · stateful needs (own DB/queue/websockets).

Quick steer: Next.js + spiky traffic + ops-averse → Vercel. Cost-sensitive / EU-resident / sustained / own stateful services → Hetzner+Coolify. The Dockerfile this skill produces is the escape hatch — start on Vercel, move to Hetzner+Coolify when the bill grows, same artifact.

→ deep coverage (limits, regions, pricing, decision matrix, worked examples): references/hosting-targets.md

Coolify — wiring the chosen target

Only the parts that touch the pipeline; the platform walkthrough lives elsewhere.

  • Pick the Dockerfile build pack when a Dockerfile exists — same artifact CI builds, full control, prod/CI parity.
  • Set Ports Exposes to the container port your app listens on (e.g. 8000); Traefik routes the domain to it.
  • Set the Health Check path/port → this is what gates the rolling swap to the new container.
  • Mark sensitive env vars Is Secret — encrypted at rest, masked in logs and UI.
  • Enable GitHub App auto-deploy on push, OR call the deploy webhook from CI (one or the other, not both).
  • Rollback = redeploy a previously stored image in one click; pair with backward-compatible migrations.
bash
curl --fail -X POST \
  -H "Authorization: Bearer $COOLIFY_TOKEN" \
  "https://coolify.example.com/api/v1/deploy?uuid=$APP_UUID&force=false"

→ persistent storage, custom domains + Let's Encrypt, per-PR previews, CPU/memory limits, blue-green: references/coolify.md and ../coolify/SKILL.md

Show full SKILL.md (541 more words)Show less

Secrets flow (GitHub → registry → Coolify)

text
GitHub secrets / OIDC ──mint short-lived creds──▶ build pushes to ghcr.io (no key stored)
     │                                                        │
     └──── nothing long-lived in a workflow file             ▼
                                       Coolify pulls (deploy-scoped registry cred)
                                                     │
                                                     ▼
                                runtime env injected by Coolify (encrypted at rest)
  • A secret crosses at most one trust boundary per hop — never forward a GHA secret into the running container; let Coolify inject runtime env.
  • Nothing long-lived lives in a workflow file: GITHUB_TOKEN and OIDC tokens are minted per run and expire.
  • ${{ }} secrets are masked in logs, but set -x and echo "$SECRET" defeat the mask — forbid both.

12-factor config & observability

Config from env, validated at boot, fail-fast — a bad config crashes on startup, never at request time. Idiom per stack: pydantic-settings BaseSettings (raises at import), zod envSchema.parse(process.env) (throws at boot), env.Must(env.ParseAs[Config]()) for Go (exits at boot).

Log JSON to stdout (slog for Go, structlog/uvicorn JSON for FastAPI, pino for Next.js); never log secrets; expose /healthz (liveness, no deps) + /readyz (checks deps).

python
# FastAPI: liveness is dependency-free; readiness probes the DB so a node that
# can't reach Postgres never takes traffic during the rolling swap.
@app.get("/healthz")
async def healthz() -> dict[str, str]:
    return {"status": "ok"}

@app.get("/readyz")
async def readyz() -> dict[str, str]:
    await db.execute("SELECT 1")   # raises 500 if the DB is unreachable
    return {"status": "ready"}

Anti-patterns — rationalizations → STOP

RationalizationSTOP — do this instead
:latest is fine for nowPin tag+digest (FROM img@sha256:…); :latest breaks reproducibility and rollback
I'll pass the token as ARGBuildKit --mount=type=secret; ARG persists in docker history
permissions: write-all is simplerDefault-deny; grant per job (packages: write, id-token: write)
Store a registry password in GHA secretsUse OIDC / GITHUB_TOKEN; no long-lived key
Run as root, it's just a containerNon-root UID + read-only rootfs + cap_drop: ALL (add back only NET_BIND_SERVICE to bind <1024)
Skip the healthcheck, the app boots fastNo healthcheck = no rolling gate = downtime / bad version live
Copy the whole repo then RUN installCopy the lockfile first; cache the deps layer
Nixpacks is easier than my DockerfileIf a Dockerfile exists, use it — CI/prod parity
Secrets in compose.yaml env.env (gitignored) / Coolify secret env
Migrate the DB destructively in deployBackward-compatible migrations, or rolling breaks
echo $SECRET to debug CINever; masked vars still leak via set -x and logs
Build once per env with different secretsBuild one image; inject config at runtime (12-factor)

Quick reference

TaskCommand / file
Build with secretDOCKER_BUILDKIT=1 docker build --secret id=npm_token,env=NPM_TOKEN -t app:dev .
Scan imagetrivy image --severity HIGH,CRITICAL --exit-code 1 IMG
Lint Dockerfilehadolint Dockerfile
Lint workflowsactionlint
Run verify gatebash scripts/verify.sh (hadolint+actionlint+trivy+build smoke, local and CI)
Local updocker compose up --watch
Trigger Coolify deploycurl --fail -X POST …/api/v1/deploy?uuid=…&force=false
Roll backCoolify → redeploy prior image

Pre-ship checklist

  • Runs as non-root
  • Base image pinned (tag + digest)
  • .dockerignore present
  • HEALTHCHECK hits a real readiness path
  • No secrets in layers or logs
  • Least-privilege GITHUB_TOKEN
  • trivy clean (no HIGH/CRITICAL)
  • Rollback path known

Project grounding (02-DOCS)

In a project with a 02-DOCS/ layer (the harness Karpathy wiki), read 02-DOCS/wiki/stack/deployment.md first and stay consistent with it. Create or update it with this project's real choices — base-image/container choices, the CI pipeline, the target config, the secrets flow, the rollback strategy — index it in 02-DOCS/wiki/index.md (the Knowledge map root CLAUDE.md points to), and bump its Updated date in the same change. No 02-DOCS/ layer? Skip silently (optionally suggest harness) — technical conventions are recorded, not gated; never block the task on this.

Hand off

  • Platform mechanics once the target is chosen: ../coolify/SKILL.md, ../vercel/SKILL.md, ../railway/SKILL.md, ../render/SKILL.md, ../fly-io/SKILL.md, ../hetzner/SKILL.md.
  • ../secure-coding/SKILL.md — input validation, authn/z, and secret-handling this skill assumes the app already does.
  • ../harness/SKILL.md — 01-TOOLS provider creds (Stripe, Postgres, OAuth…) that become runtime env on the target.
  • ../fastapi/SKILL.md, ../nextjs/SKILL.md, ../go/SKILL.md, ../flutter/SKILL.md, ../postgresdb/SKILL.md — the application code that runs inside the container; this skill stops at that boundary.

© ericrisco, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 7 other files (scripts, references) in skills/deployment of ericrisco/rsc-harness.

  • SKILL.md
  • evals/README.md
  • evals/cases.yaml
  • references/coolify.md
  • references/dockerfiles-by-stack.md
  • references/github-actions.md
  • references/hosting-targets.md
  • scripts/verify.sh

Open the folder on GitHubat commit 92fde8f

Compare with similar skills

Deployment next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Deployment compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Deployment this skillericrisco/rsc-harness156—~4.2kAutomated safety check: NotesMIT
Minimegasandia-minimega/minimega160—~3.2kAutomated safety check: PassGPL-3.0-only
DDNS Build and Release MaintenanceNewFuture/DDNS4.7k—~444Automated safety check: PassMIT
Monstermq Broker Configvogler75/monster-mq142—~2.2kAutomated safety check: PassGPL-3.0
Generate Ors Envadithya-s-k/FineEnvs421—~2.3kAutomated safety check: NotesApache-2.0
Docker Deploymentfossasia/eventyay1.7k—~574Automated safety check: NotesApache-2.0

Similar skills

  • Minimega

    sandia-minimega/minimega

    This skill should be used when the user asks how to configure, run, automate, integrate, or troubleshoot minimega (VMs, namespaces, VLANs, clusters, miniccc, miniweb, command socket or Python API…

    160 GitHub stars~3.2k tokensUpdated yesterday
    DevOps & CloudAuto-check passed
  • Maintains the DDNS project's GitHub Actions, Docker and Nuitka builds, packaging and release preparation without touching publishing credentials.

    4.7k GitHub stars~444 tokensUpdated yesterday
    DevOps & CloudAuto-check passed
  • Monstermq Broker Config

    vogler75/monster-mq

    Guide for configuring, deploying, and operating the MonsterMQ broker.

    142 GitHub stars~2.2k tokensUpdated today
    DevOps & CloudAuto-check passed
  • Generate Ors Env

    adithya-s-k/FineEnvs

    Builds an Open Reward Standard (ORS) variant of an RL environment using the official openreward Python package.

    421 GitHub stars~2.3k tokensUpdated yesterday
    DevOps & CloudAuto-check: notes
  • Docker Deployment

    fossasia/eventyay

    Docker Compose, container services, deployment. An agent skill from fossasia/eventyay.

    1.7k GitHub stars~574 tokensUpdated today
    DevOps & CloudAuto-check: notes
  • Official

    Build, configure, scaffold, and deploy OCI Functions from a local machine using a dependency-first, Fn-context-guided flow with argv-safe mutation execution, nonce-scoped confirmations, and a…

    872 GitHub stars~4.6k tokensUpdated yesterday
    DevOps & CloudAuto-check passed

More from ericrisco/rsc-harness

All 229 skills in this repo
  • Ab Testing

    ericrisco/rsc-harness

    A skill your agent uses when designing or analyzing a controlled experiment — falsifiable hypothesis, sample size from an MDE, reading significance/CI/power, CUPED, or rescuing tests that won't go…

    156 GitHub stars~2.4k tokensUpdated today
    Auto-check passed
  • Accessibility

    ericrisco/rsc-harness

    A skill your agent uses when making a web UI conform to WCAG 2.2 Level AA — axe-core or Lighthouse a11y violations, keyboard operability, focus management, ARIA roles/names/live regions, contrast…

    156 GitHub stars~3.4k tokensUpdated today
    Auto-check passed
  • Ads

    ericrisco/rsc-harness

    A skill your agent uses when running or fixing paid acquisition on Google or Meta — campaign structure (Performance Max, Demand Gen, Search, Advantage+), platform-fit creative, budget/scaling rules…

    156 GitHub stars~2.2k tokensUpdated today
    Auto-check passed
  • Agent Eval

    ericrisco/rsc-harness

    A skill your agent uses when measuring whether an LLM or agent system actually got better and gating merges on it: golden sets, fixing an inflated LLM-as-judge, scoring RAG (faithfulness, contextual…

    156 GitHub stars~3.2k tokensUpdated today
    Auto-check passed
  • AI Media

    ericrisco/rsc-harness

    A skill your agent uses when a creative goal must become a finished media file: pick and order generative-media models per modality — AI voiceover, image-to-video clips, score — then glue them with…

    156 GitHub stars~3.3k tokensUpdated today
    Auto-check passed
  • Analytics

    ericrisco/rsc-harness

    A skill your agent uses when instrumenting product or web analytics — GA4/PostHog SDK wiring, event taxonomy, funnels, double-counted events, consent gating, PII scrubbing.

    156 GitHub stars~2.8k tokensUpdated today
    Auto-check passed

Categories

Questions about Deployment

What does Deployment do?

A skill your agent uses when taking an app from source to live: choosing the deploy target from requirements (Hetzner+Coolify vs Vercel vs a third), then wiring container → CI → registry → host with…. Deployment is an agent skill from ericrisco/rsc-harness. Use when taking an app from source to live: choosing the deploy target from requirements (Hetzner+Coolify vs Vercel vs a third), then wiring container → CI → registry → host with build secrets, healthchecks and rollback.

When should I use Deployment?

Deployment fits situations like: taking an app from source to live: choosing the deploy target from requirements (Hetzner+Coolify vs Vercel vs a third); then wiring container → CI → registry → host with build secrets; healthchecks and rollback.

How do I install Deployment in Claude Code?

Run `npx skills add ericrisco/rsc-harness --skill deployment -a claude-code`. Or copy the skill folder (skills/deployment in ericrisco/rsc-harness) into .claude/skills/deployment in your project. Claude Code loads it when a task matches its description.

How do I install Deployment in Codex?

Run `npx skills add ericrisco/rsc-harness --skill deployment -a codex`. Or copy the skill folder (skills/deployment in ericrisco/rsc-harness) into .agents/skills/deployment in your project. Codex loads it when a task matches its description.

Can I use Deployment in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ericrisco/rsc-harness --skill deployment -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/deployment, .gemini/skills/deployment, .github/skills/deployment and .opencode/skills/deployment in your project.

What does Deployment need to run?

Going by SKILL.md and its folder, Deployment needs a shell for the scripts in its folder, the command-line tools its instructions call (docker, curl, trivy, hadolint and bash) and credentials named GITHUB_TOKEN, NPM_TOKEN, POSTGRES_PASSWORD and COOLIFY_TOKEN. Our summary lists: Python 3; A Bash shell; Docker; A credential in NPM_TOKEN; A credential in GITHUB_TOKEN.

Does Deployment access the network?

SKILL.md names 1 domain. As links in the text: github.com. This is read from the text; nothing was executed.

Is Deployment safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Deployment use?

Deployment is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Deployment use?

About 4.2k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 13k tokens, read only when the agent opens those files.

What are the alternatives to Deployment?

Skills that share tags, products or a category with Deployment: Minimega (sandia-minimega/minimega, 160 stars), DDNS Build and Release Maintenance (NewFuture/DDNS, 4.7k stars), Monstermq Broker Config (vogler75/monster-mq, 142 stars) and Generate Ors Env (adithya-s-k/FineEnvs, 421 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Deployment?

ericrisco (a GitHub user) maintains it in ericrisco/rsc-harness, which has 156 GitHub stars. The repository holds 229 skills in this directory. The repository was last updated on October 6, 2026.

Source: ericrisco/rsc-harness on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.