Reusable agent workflows for planning, verification, coding, operations, content, and OpenClaw runtime work.
Install the full tracked catalog with:
npx skills add build000r/skills --allMost agent setups collapse into one of two bad patterns:
- giant system prompts that try to do everything
- one-off prompt snippets that solve one task once and then disappear
That usually means weak reuse, inconsistent quality, poor discoverability, and no clean place for helper scripts, templates, or private local overlays.
This repo is a skill monorepo. Each top-level skill packages a durable workflow
in SKILL.md, with optional references/, scripts/, assets/, app code, and
private skillbox client overlays where needed.
Use it when you want agents to follow repeatable operating procedures instead of re-inventing the same workflow on every run.
| Need | What this repo gives you |
|---|---|
| Reusable engineering workflows | Skills for planning, review, reproduction, mutation testing, and commits |
| Structured local context | Skillbox client overlays for skills that need private portfolio, repo, or deployment context |
| Deterministic helpers where prompts are not enough | App-backed helpers can live beside the monorepo when they need their own runtime or release cadence |
| Deployable asset bundles | Runtime kits and embedded child skills in openclaw-client-bootstrap |
| Pick-your-surface installs | Install one skill, a lane, the whole catalog, or symlink a local checkout |
| Honest boundaries | Skill-specific licensing, partial packaging in dist/, and explicit limitations |
The fastest way to get value is to install a few workflows you will actually use:
# Install a small engineering stack from GitHub
npx skills add build000r/skills -s describe
npx skills add build000r/skills -s reproduce
npx skills add build000r/skills -s commit
# Clone the repo locally if you want to inspect or iterate on the skills
git clone git@github.com:build000r/skills.git
cd skills
# Link the local checkout into Claude + Codex
./scripts/link-skills.sh
# Add a private client overlay for skills that need local context
# Create skillbox-config/clients/my-portfolio/overlay.yaml with your project paths
# If you use the sibling clawgs repo locally, install and verify it separately
../clawgs/scripts/install.sh
../clawgs/scripts/check.shEach skill is meant to encode a repeatable decision process, not just a catchy prompt. The point is to preserve operating discipline.
Most skills are plain instruction packs. When deterministic behavior matters, the repo allows app-backed helpers, scripts, or asset bundles to sit beside the workflow.
Tracked files stay reusable. Local portfolio paths, internal domains, server
IPs, or customer-specific rules belong in skillbox client overlays (skillbox-config/clients/{client}/overlay.yaml).
The default install surface is the set of tracked top-level directories that
contain SKILL.md. You can install one skill, a lane, or the full catalog.
| Approach | Good for | Breaks down when | Why this repo exists |
|---|---|---|---|
| Ad-hoc prompt snippets in notes | Tiny one-off tasks | Nothing is standardized, searchable, or reusable | Skills give each workflow a stable home |
| One giant agent prompt | Opinionated personal setup | Too much context, weak discoverability, hard to maintain | Each workflow becomes independently installable |
| Full custom app/plugin only | Deterministic heavy lifting | Overkill for mostly-instructional workflows | Skills keep the simple cases lightweight |
| This repo | Agent workflows with optional code, templates, and private overlays | You still need skillbox client overlays for context-heavy skills | Best middle ground for reusable agent operations |
| Skill | What it does |
|---|---|
ask-cascade |
Orders user-facing questions from high-level dependencies down to details |
audit-plans |
Audits plans, order, focus, and backlog state |
build-vs-clone |
Decides whether work belongs in an existing repo, shared home, or new build |
cli-ergonomics |
Builds or reviews agent-facing CLIs for compact output, strong defaults, and clean shell UX |
codex-tmux |
Runs Codex in persistent tmux sessions for long jobs |
commit |
Batches working changes into clean, high-level commits |
crap |
Ranks risky hotspots with CRAP-style scoring |
describe |
Turns bugs or features into pass/fail test cases before patching |
dev-sanity |
Checks local dev ecosystem health across services and logs |
divide-and-conquer |
Splits complex work into parallel, non-overlapping sub-agents |
domain-planner |
Plans multi-repo domain slices and implementation contracts |
domain-reviewer |
Audits live work against a plan and retires completed slices |
domain-scaffolder |
Scaffolds backend or frontend domain code from accepted slice plans |
mutate |
Runs mutation testing and triages surviving mutants |
oss-doc-audit |
Audits public docs for drift, grades OSS readiness, and builds ranked cleanup queues |
prompt-reviewer |
Scores prompting quality from Claude/Codex session history |
reproduce |
Uses a command-first QA ladder before handing testing back |
skill-issue |
Creates, validates, improves, and packages skills |
The domain-* family works best as a two-layer system:
- Planning layer:
domain-plannerdefines the slice, locks the contract, and settles the Core Value Gate. - Execution layer:
WORKGRAPH.md,divide-and-conquer,describe,commit, anddomain-reviewerwalk that accepted slice to done.
The important boundary is this: once the plan is accepted, execution should stop re-litigating the 80/20 slice. Core value discipline belongs in planning. Execution should focus on sequencing, implementation, validation, and audit.
| Tool | Job in the loop |
|---|---|
domain-planner |
Creates the 6 plan files, runs the plan quality loop, then emits WORKGRAPH.md as the post-sign-off execution handoff |
WORKGRAPH.md |
Holds executable nodes with depends_on, writes, done_when, validate_cmds, and status |
divide-and-conquer |
Reads the current ready frontier from WORKGRAPH.md, launches safe swarm waves, and handles the final integration review |
describe |
Tightens one fuzzy node when its completion rule or validation path is still ambiguous |
commit |
Leaves a clean checkpoint after the reviewed wave |
domain-reviewer |
Audits the implemented slice against the accepted plan and writes AUDIT_REPORT.md |
[H] user request / slice intent
|
v
[A] domain-planner
|
| 6 plan files + Core Value Gate + quality loop
v
[H] accept plan / save location
|
v
[A] domain-planner -> WORKGRAPH.md
|
v
[A] ready frontier only
|
v
[A] divide-and-conquer
|
+---- fuzzy node? ---- yes ---> [H] describe that node
| |
| v
|<--------------------------------+
|
v
[A] execution wave
|
v
[A] divide-and-conquer review wave
|
v
[A] commit
|
v
[A] update WORKGRAPH.md
|
more ready nodes?
| |
yes no
| |
v v
loop next wave [A] domain-reviewer
|
v
AUDIT_REPORT.md
|
findings / blocked risk?
|
yes -> [H] triage / answer
|
v
add remediation nodes
|
+----> back to ready frontier
- Slice intent: only when the requested slice or business value is unclear.
- Planning ambiguity: real scope or contract decisions during
domain-planner. - Plan acceptance:
planned/vsreleased/, after which the planning contract is considered settled. - Node-level ambiguity: use
describeonly when one workgraph node still has fuzzydone_whenorvalidate_cmds. - Audit or risk escalation: re-enter only when
domain-reviewerfinds a real blocker, risk gate, or unresolved tradeoff.
human decides the slice
agents execute the accepted slice
human re-enters only for ambiguity, risk, or escalation
| Skill | What it does |
|---|---|
deploy |
Deploys, debugs, and operates multi-service infrastructure with mode-driven safety rails |
ssh-info |
Provides mode-driven server connection references and targeted live status checks |
| Skill | What it does |
|---|---|
remotion |
Encodes practical Remotion guidance for React video work and SVG-first motion architecture |
research-paper |
Produces dense research pages plus social companions |
swimmers-sprite |
Generates thronglet sprite packs from master pixel assets |
trend-to-content |
Turns search and social trends into research, PSEO, and video ideas |
clawgs now lives as a sibling repo at ../clawgs/ when you need the Rust-backed
log extraction and thought-emission helper.
| Skill | What it does |
|---|---|
openclaw-client-bootstrap |
Builds production-ready OpenClaw client kits with runtime assets |
openclaw-docs-audit |
Audits bootstrap docs and config against upstream OpenClaw changes |
unclawg-internet |
Runs onboarding, device auth, and setup for OpenClaw agents |
unclawg-discover |
Finds leads and social-listening candidates |
unclawg-feed |
Generates replies and submits approval requests |
unclawg-respond |
Processes revision feedback and fulfills approved edits |
This installs the tracked top-level directories that contain SKILL.md.
npx skills add build000r/skills --allnpx skills add build000r/skills -s describe
npx skills add build000r/skills -s reproduce
npx skills add build000r/skills -s commitEngineering core:
for skill in \
crap \
mutate \
ask-cascade \
commit \
describe \
divide-and-conquer \
domain-planner \
domain-reviewer \
domain-scaffolder \
reproduce \
skill-issue
do
npx skills add build000r/skills -s "$skill"
doneInstall only domain-scaffolder.
Tooling:
for skill in \
prompt-reviewer
do
npx skills add build000r/skills -s "$skill"
doneInstall clawgs separately from the sibling checkout when you need it locally:
../clawgs/scripts/install.sh
../clawgs/scripts/check.shOpenClaw loop:
for skill in \
unclawg-internet \
unclawg-discover \
unclawg-feed \
unclawg-respond
do
npx skills add build000r/skills -s "$skill"
donegit clone git@github.com:build000r/skills.git
cd skills
./scripts/link-skills.shThat script creates or updates symlinks in:
~/.claude/skills/~/.codex/skills/
You can also point it at a checkout explicitly:
./scripts/link-skills.sh /path/to/skillsThe repo currently ships packaged artifacts for some skills in dist/.
ls dist/*.skillDo not assume every skill has a packaged artifact. The repo is mixed-mode.
- Install one or two skills you will genuinely use.
- Clone the repo if you want local inspection, editing, or symlinked dev.
- Run
scripts/link-skills.shto point Claude and Codex at your checkout. - If a skill needs private context, create a client overlay in
skillbox-config/clients/{client}/overlay.yamland fill it in. - If a skill ships app code, run its own install and check scripts after linking.
| Command | What it does | Example |
|---|---|---|
npx skills add build000r/skills --all |
Installs the full tracked catalog | npx skills add build000r/skills --all |
npx skills add build000r/skills -s <skill> |
Installs one named skill | npx skills add build000r/skills -s describe |
./scripts/link-skills.sh |
Symlinks top-level skills from a local checkout into Claude and Codex | ./scripts/link-skills.sh |
./scripts/link-skills.sh /path/to/skills |
Links a different checkout path explicitly | ./scripts/link-skills.sh ~/repos/skills |
../clawgs/scripts/install.sh |
Installs the sibling clawgs helper app |
../clawgs/scripts/install.sh |
../clawgs/scripts/check.sh |
Verifies the sibling clawgs install |
../clawgs/scripts/check.sh |
ls dist/*.skill |
Shows packaged artifacts for selected skills | ls dist/*.skill |
There is no single repo-wide config file.
Most skills are usable immediately after install. The ones that need private
local knowledge use skillbox client overlays, defined in
skillbox-config/clients/{client}/overlay.yaml.
Example client overlay:
# skillbox-config/clients/my-portfolio/overlay.yaml
# Example private overlay for skills that need repo or portfolio context.
cwd_match: ~/repos
scan_roots:
- ~/repos
repo_ownership:
product-repo:
path: ~/repos/product-repo
owns: [auth, billing, admin tooling]
prefer_for: [API changes, schema changes]
marketing-repo:
path: ~/repos/marketing-repo
owns: [landing pages, website copy]
prefer_for: [presentation and content work]
shared_rules:
- Prefer the skills repo for reusable agent workflows and developer tooling.
- Keep private domains, credentials, server notes, and customer context here.Skills that commonly rely on client overlays include:
build-vs-clonedeploydev-sanityaudit-plansdomain-plannerdomain-reviewerdomain-scaffolderprompt-reviewerresearch-paperssh-infotrend-to-contentunclawg-discover
GitHub repo / local checkout
|
v
+--------------------------------------------------+
| top-level skill directories with SKILL.md |
| ask-cascade/ describe/ deploy/ divide-and-conquer/ ...|
+--------------------------------------------------+
| | |
| | |
v v v
references/ scripts/ assets/ or app code
templates, docs install/check runtime kits, Rust app,
examples, guides helpers, glue embedded child skills
\ | /
\ | /
+--------------+----------------+
|
v
agent runtime loads skill
(Claude Code / Codex / Cursor)
|
v
optional client overlay from skillbox-config/clients/
|
v
repeatable workflow with repo-specific context
some-skill/
├── SKILL.md
├── references/
├── scripts/
└── assets/
clawgs now lives as a sibling repo at ../clawgs/:
../clawgs/
├── SKILL.md
├── Cargo.toml
├── src/
├── tests/
└── scripts/
openclaw-client-bootstrap ships deployable
assets plus embedded child skills:
openclaw-client-bootstrap/
├── SKILL.md
├── references/
├── scripts/
└── assets/
├── client-kit/
├── runtime-skills/
└── instances/
--all installs the tracked top-level directories that contain SKILL.md. It
does not promise every private, gitignored, or incubating directory from a
developer's local checkout.
The script intentionally skips non-symlink targets in ~/.claude/skills/ or
~/.codex/skills/. Rename or remove the existing directory, then run the
script again.
Create a client overlay at skillbox-config/clients/{client}/overlay.yaml
and fill in your private context. Some skills ship a references/mode-template.md
that shows the expected fields.
Linking only exposes the skill directory to the agent. App-backed skills may
need their own install and verification steps. For the sibling clawgs repo, run:
../clawgs/scripts/install.sh
../clawgs/scripts/check.shThat is not the current shape of the repo. dist/ contains selected .skill
artifacts only. Use the GitHub install path or local symlink workflow for the
rest.
- This is a mixed-mode monorepo, not a polished package registry or docs site.
- Some skills depend on private local context, so they are incomplete until you add a skillbox client overlay.
- Some skills are personal or operator-heavy by design and may not generalize cleanly outside the author's environment.
- Not every skill has a packaged
.skillbuild indist/. - Licensing is skill-specific rather than centrally normalized.
- The contribution policy is intentionally closed.
Not really. The repo is closer to an operations catalog for agents. Many skills ship references, scripts, assets, client overlay templates, or app code next to the core instructions.
The default public install surface is the set of tracked top-level directories
that contain SKILL.md.
No. Installing a few skills you actually use is usually better than installing everything blindly.
Clone it when you want to inspect instructions, edit a skill, symlink a local checkout into Claude/Codex, or work on app-backed helpers.
They hold private local context such as repo maps, domains, deployment notes,
or portfolio rules that should not live in the tracked public skill files.
Client overlays are managed through skillbox at
skillbox-config/clients/{client}/overlay.yaml.
No. The repo is meant to work with Claude Code, Codex, Cursor, and similar agentic environments.
No. Check each skill directory's frontmatter plus any bundled LICENSE or
LICENSE.txt file before redistributing or packaging it.
About Contributions: Please don't take this the wrong way, but I do not accept outside contributions for any of my projects. I simply don't have the mental bandwidth to review anything, and it's my name on the thing, so I'm responsible for any problems it causes; thus, the risk-reward is highly asymmetric from my perspective. I'd also have to worry about other "stakeholders," which seems unwise for tools I mostly make for myself for free. Feel free to submit issues, and even PRs if you want to illustrate a proposed fix, but know I won't merge them directly. Instead, I'll have Claude or Codex review submissions via
ghand independently decide whether and how to address them. Bug reports in particular are welcome. Sorry if this offends, but I want to avoid wasted time and hurt feelings. I understand this isn't in sync with the prevailing open-source ethos that seeks community contributions, but it's the only way I can move at this velocity and keep my sanity.
Licensing is skill-specific. Check each skill directory's frontmatter and any
bundled LICENSE or LICENSE.txt file before redistributing, packaging, or
embedding a skill elsewhere.