Two rules above all:
- No proprietary content in transferable skills. No project names, company names, domain names, IPs, ports, OS-specific commands tied to one stack, secret env-var names, table names, or paths from any specific project. The categories of leak are documented in
templates/sanitization-guidance.md. Sanitization is judgment-based: run thesanitize-transferableskill on your draft before opening a PR — it produces a categorized findings file and a fillable checklist footer. - Transferable patches must include a sanitization footer. Every PR that modifies a
skills/**/SKILL.mdfile must include aSanitization checklist:block in the PR description, with each category fromtemplates/sanitization-guidance.mdexplicitly accounted for. Copy the footer thesanitize-transferableskill generates; tick each box only after you (the human) re-confirm. Empty footers and "✓ all good" shorthand fail CI.
- New transferable skills (
skills/<category>/<name>/SKILL.mdplus optionalreferences/,scripts/,assets/). Pick the category folder whose existing skills share the most intent with yours; if none fits, propose a new category in the PR description. - Improvements to existing transferable skills, sourced either from your own work or from a supervisor proposal in
proposals/. - New tooling under
bin/that supports the chain runner, manager bot, or supervisor workflow. - Schema and template improvements.
- Anything that names a specific company, domain, or stack.
- Skills that only make sense inside one codebase. Those are proprietary; keep them in your project's
.claude/skills/. - Bulk AI-generated skill packs without per-skill review.
When a supervisor run produces a transferable proposal under proposals/:
- Read the proposal's rationale block — does the lesson generalize, or is it project-specific?
- If it generalizes: open a PR moving the proposal into
skills/<category>/<name>/SKILL.md. Re-do the sanitization checklist yourself (don't trust the supervisor's footer blindly; it's a draft). - If it doesn't: delete the proposal. The lesson belongs in the proprietary counterpart only.
---
name: <kebab-case>
description: <one-paragraph: what the skill does, when it triggers>
version: 1.0.0
---User-invocable skills add user-invocable: true. Skills that only run as part of a chain omit it.
- Match the prose style of existing skills: imperative voice, short sentences, no marketing language.
- Numbered top-level sections (
## 1. Pre-flight,## 2. Decide, ...) when the skill is a sequential procedure. - Examples in fenced code blocks. Real commands, not pseudo-code.