The Claude Code skills I actually use, packaged as an installable plugin marketplace.
Every rule in here was paid for with a broken build, a wasted wave, or a production surprise. They are written as guardrails rather than tutorials: short, imperative, and specific about the failure they prevent.
/plugin marketplace add theogyeezy/skillz
/plugin install engineering@skillz
/plugin install servicenow@skillz
Install only the plugin you want. engineering is stack-agnostic; servicenow is only useful if you
work on the ServiceNow platform.
Installed skills are namespaced by plugin. Restart Claude Code after installing, then type:
/engineering:fleet ship dark mode across the web app
/engineering:pr-ci-cd-ship
/engineering:verify-live-integration
/engineering:prototype-to-parity
/engineering:docs-audit
/servicenow:sn-scripting
/servicenow:sn-sdk-fluent
/servicenow:sn-aia-agents
/servicenow:sn-atf
/servicenow:sn-live-debug
You usually don't have to type them at all. Each skill's description field states when it applies, so
Claude loads the relevant one on its own — ask it to ship a branch and pr-ci-cd-ship fires without
being named. Typing the name is for when you want to force it.
Prefer to manage them by hand? Copy any skill directory into ~/.claude/skills/ and it loads the same
way, but under its bare name (/fleet instead of /engineering:fleet). Don't do both — you'll get two
copies of every skill.
| Skill | Use it when |
|---|---|
| fleet | You want a goal decomposed into file-disjoint tasks and run as a wave of tiered subagents (opus/sonnet/haiku) in isolated git worktrees, adversarially verified, then merged serially so trunk stays green. Includes a loop mode and an optional multi-machine mode. |
| pr-ci-cd-ship | You're shipping a branch through PR → CI → merge → deploy → live verify and don't want to babysit it. Uses the pipeline's own run-watch as the wake signal instead of polling, and treats a manual approval gate as a real review. |
| verify-live-integration | You're integrating a third-party or beta SDK, or building a destructive operation. A green mock only proves your code matches the shape you assumed. Covers introspecting the real surface and making deletes/migrations safe by construction. |
| prototype-to-parity | A prototype or mockup got approved and now has to become the real thing, 1:1. Extract a parity spec, implement test-first, then adversarially review the build against the prototype. |
| docs-audit | Living docs have lagged weeks of shipping. Separates living docs from dated historical records, produces a cited drift report, then applies fixes with the same rigor as the audit. |
| Skill | Use it when |
|---|---|
| sn-scripting | Before writing any server/client script. The scoped-API allow-list, silent-failure patterns (scoped proxies return undefined rather than throwing), and Jelly escape rules. |
| sn-sdk-fluent | Before writing or editing any Fluent .now.ts file. Build-rejecting statement forms, $id/Now.ID rules, and the reference-integrity trap where Now.ID silently does not resolve inside data:. |
| sn-aia-agents | Before building or debugging AI Agent Studio agents. Leads with the self-invoking tool-script contract — the bug that makes every tool call die at 0ms with error "undefined" and no server-side log at any level. |
| sn-atf | Before running or authoring ATF tests against a live instance. The browser test-runner requirement, clean-state discipline, and the live-trigger interplay that silently clears a catalog item's Process Engine binding. |
| sn-live-debug | Debugging anything on a live instance. Server-side probing recipes, the syslog ^OR binding trap, and an evidence-first methodology: find a working analog and diff it. |
- The
fleetskill calls theWorkflowtool, which requires explicit user opt-in. Invoking/fleetis that opt-in. It ships withwave.js(the workflow script) and aLESSONS.mdits retro phase writes back to. - Distributed mode in
fleetstays dormant unless you create amachines.jsonnext to the skill. Seemachines.json.example. Realmachines.jsonfiles are gitignored. - The ServiceNow skills describe ServiceNow product behavior observed on a development instance. They contain no credentials, instance hostnames, or customer data. The only literal sys_ids present are out-of-box platform records identical on every instance.
MIT. See LICENSE.