An SDK for Package Skills
Colors is an SDK for building Package Skills.
Three libraries — red, green, and blue — give agents dry-run guarantees, secret indirection, and strict lifecycle control over real infrastructure, in the runtime your team already uses.
npx skills add getcolors/once
Run inside your coding agent — it grants Once, a skill to provision a VPS with a personal PaaS like Netlify or Vercel.
# colors.yml
profile: once-colors
workdir: .colors
once:
applications:
- host: www.getcolors.ai
image: ghcr.io/getcolors/colors-website:latest
github: getcolors/colors-website
provider-compute: oci
provider-smtp: resend
provider-dns: cloudflare
provider-backend: r2
compute-prevent-destroy: trueA different primitive for a different job
Web automation and infrastructure automation demand different guarantees.
Browser Skill
Eyes and hands on the web
Navigates DOM elements, fills forms, scrapes content — bridges natural language intent with web interaction.
Package Skill
Determinism and lifecycle control
Provisions platforms, infrastructures, and containers — with dry-run boundaries and strict credential handling instead of raw shell access.
Package Skill
What is a Package Skill?
A Package Skill is a deterministic infrastructure and platform automation module built for AI coding agents using the Colors SDK (available in TypeScript/Bun, Clojure/Babashka, or Python/uv). It provisions and manages production resources—such as Kubernetes clusters, databases, dev machines, or personal PaaS environments—by reading a non-secret desired state file (colors.yml), enforcing mandatory dry-run boundaries before contacting live providers, maintaining strict credential indirection through environment variables (COLORS_PAR_*), and managing resource lifecycles through execution graphs (DAGs).
What a Package Skill bundles
Desired state
Non-secret desired state
colors.yml declares hostnames, DNS zones, and mail domains directly — no separate settings to keep in sync.
Runtimes
Deterministic runtimes & launchers
Colors’ three pinned runtimes — Bun, Babashka, or uv — not ad-hoc shell scripts.
Credentials
Environment & credential boundaries
Secrets stay in COLORS_PAR_* env vars, referenced by name and never rendered into files.
Three libraries. One SDK.
Colors is an SDK made of three interchangeable libraries for building Package Skills. Pick the runtime your team already uses — the guarantees don't change: dry-run boundaries, secret indirection, identical desired-state semantics.
Agent Skill
Create Package Skill: build a new Package Skill with your agent
Create Package Skill gives a coding agent the workflow for building a new Colors Package Skill and a deployment that uses it — from requirements and credential boundaries through implementation, safe dry runs, and an authorized production deployment.
npx skills add getcolors/skills@create-package-skill
This is an Agent Skill, not a Package Skill. npx skills use gives it to your agent for the next request without installing it into a project.
Phase 1
Define
Agree on names, behavior, acceptance criteria, deployment target, credentials, cost, and authorization before touching files.
Phase 2
Scaffold safely
Create only non-secret desired state and credential placeholders, then stop for review. Secrets never enter chat or tracked files.
Phase 3
Build and deploy
Implement autonomously, test every layer, use real SHA pins, preserve safety guards, and deploy only within explicit authorization.
Agent Skill
Submit Package Skill: add an existing Package Skill to the Catalog
Submit Package Skill gives a coding agent the workflow for validating an existing Colors Package Skill, adding its catalog recipe, and opening an authorized pull request for curated discovery on getcolors.ai.
npx skills add getcolors/skills@submit-package-skill
This is an Agent Skill, not a Package Skill. The Catalog adds discoverability only: GitHub remains the source, and npx skills remains the installer.
Phase 1
Validate
Inspect every SKILL.md and verify the Colors runtime, desired state, dry-run boundary, credential indirection, and lifecycle DAGs.
Phase 2
Add the recipe
Create one validated recipe for the product, grouping interchangeable runtime variants and infrastructure-oriented search keywords.
Phase 3
Open the PR
Run catalog validation and the site build, then create a branch, commit, push, fork, or pull request only with explicit authorization.