authoring-project-skillslisted

# Authoring project skills Project skills live in `docs/skills/` and document repeatable workflows for humans and AI. The always-on trigger lives in CLAUDE.md (*scan `docs/skills/` before a task; create/update one after a repeatable task, ending your response with `✏️ Skill <created|updated>: docs/skills/<file>.md — <reason>`*). **This skill is the full how-to** for actually writing one well. ## Signals to skill it - Hit a non-obvious gotcha (env mismatch, hidden dependency, undocumented step). - Ran a multi-step sequence to set up, debug, deploy, or migrate. - Answered "how do I X here" by tracing through several files. - A teammate is likely to ask the same question later. ## Scope: generalize before writing A skill must cover the *class* of problems, not the single incident that triggered it. Before writing, ask: "what is the general workflow this incident is one instance of?" — and write THAT. Parameterize the incident-specific parts (the specific package, workflow file, error code, branch) into steps that work for the whole class; keep concrete values only as examples inside the steps. - Bad (incident-scoped): `fix-github-packages-401-in-ci.md` — one package, one workflow, one status code. - Good (class-scoped): `fix-ci-package-registry-auth.md` — any registry auth failure (401/403), any workflow, any repo. - If the generalized version would duplicate an existing skill, update that skill instead. ## No trash skills — skip when in doubt A skill that's never opened aga