Skills catalog

kew ships a set of governance artifacts — Claude Code skills plus the security-guard hook — as package data. They install into your project's .claude/ with kew skills, which tracks drift so updates don't clobber your local changes.

kew skills list           # see what's installed and its state
kew skills install --all  # install everything

Lifecycle

• Install: kew skills install <name> or --all copies the artifact into .claude/. kew setup --with-skills does this as part of one-time setup; a plain kew setup prints the install tip instead.
• Update: kew skills update with no names converges everything — it refreshes every artifact that's outdated and installs every artifact that's not-installed. Pass names to scope it.
• Diff: kew skills diff shows what changed, artifact by artifact, before you decide to update.
• locally-modified means the installed copy doesn't match the shipped content or any prior shipped version — you (or an agent) edited it by hand. install/update refuse to touch it (exit 1) unless you pass --force, which overwrites it with the shipped version.

See kew skills for the full command reference and the state machine (not-installed / current / outdated / locally-modified).

Guard updates preserve your config

The security-guard hook is the one artifact that isn't a flat file compare: its drift state is computed by re-rendering the hook template with your current kew.toml, not by diffing bytes against a fixed shipped copy. That means custom [security] patterns —

[security]
blocked_prefix_patterns = ["kubectl delete"]
blocked_exact_patterns = ["DROP DATABASE"]

— survive kew skills update security-guard: the extras are re-applied from config on every render, not diffed away.

kew owns any file that still carries the # managed-by: kew header, hand-edits included: if you edit the hook script in place, the header stays intact, so drift detection classifies it as outdated and kew skills update silently overwrites your edits with the re-rendered version. locally-modified protection only kicks in once the header is removed or the file is replaced outright. For persistent customization, put your patterns in kew.toml's [security] block instead of editing the hook body — those survive updates because they're re-applied on every render.

Catalog

/plan-to-issues

Converts an implementation plan into sized, labeled GitHub issues for the dispatch queue.

# In Claude Code:
/plan-to-issues docs/plans/my-feature.md

What it does: - Reads an implementation plan and groups tasks into issues (max 5 tasks per issue) - Assigns complexity labels based on task count (1-2 = simple, 3-4 = medium, 5 = complex) - Creates issues with plan file references -- the dispatch agent reads the plan at execution time - Declares dependencies between issue groups (wave ordering) - Never adds the ready label -- the human reviews and labels manually - Epic mode: when the issues will be driven by kew epic run, the skill applies epic:<name> to every issue and skips blocked-label bookkeeping (the driver computes the frontier from kew:depends; a manual blocked label would hold nodes back)

kew skills install plan-to-issues

Typical workflow:

Write plan  ->  /plan-to-issues  ->  Review issues  ->  Label "ready"  ->  kew run

Epic workflow (dependency-driven, no manual ready labels):

Write plan  ->  kew epic plan <name> --from <plan>  ->  Review issues  ->  kew epic run <name>

The skill works with any implementation plan, however it's written. If you use a brainstorming -> design spec -> implementation plan pipeline (e.g., Superpowers), run /plan-to-issues after your plan is finalized. The full pipeline looks like:

Brainstorm  ->  Design spec  ->  Implementation plan  ->  /plan-to-issues  ->  Review  ->  Dispatch

/playbook-skill

A meta-skill: it drafts a new playbook skill for one of your fragile subsystems, mining your own git log, CI history, and issues for incidents.

What it does: - Mines git log, merged PRs, and issues touching the subsystem's files for fix/revert incidents - Extracts one invariant per incident, anchored to file:line in the current tree - Identifies the exact proving command(s) for the subsystem - Writes .claude/skills/<subsystem>-change/SKILL.md: invariants, a checklist, and exactly one copy-pasteable acceptance command - Enforces its own quality bar: every invariant must trace to a real incident or test, not an opinion

# In Claude Code, after installing:
# "Write a playbook skill for the auth routes module"

kew skills install playbook-skill

/verify-parity

Fixes the "local checks pass, CI is red" incident class by building a verify script that mirrors CI exactly, plus a regression test that fails the moment they drift.

What it does: - Enumerates every gate step in your pull_request-triggered CI workflows (command + scope) - Reconciles them against a local scripts/verify.sh (or creates one), in both directions - Harvests past red-CI incidents into a Trigger -> exact command Trap Gates table for your agent-instructions file - Writes a parity regression test that normalizes and diffs the verify script against the CI workflows, so new drift fails CI itself

# In Claude Code, after installing:
# "Build a verify/CI parity script for this repo"

kew skills install verify-parity

kew's own scripts/verify.sh + tests/test_verify_parity.py is the worked example this skill cites.

/handoff

Writes a handoff doc for in-flight work that another session, machine, or person needs to pick up cold — uncommitted changes, unverified drafts, work paused mid-task.

What it does: - Captures a TL;DR + provenance line (what's been verified vs. not) up front - Records exact git state and a files-in-the-changeset table - Lists the exact, copy-pasteable verification commands in dependency order - Flags the least-tested integration seams, most-risky first - States invariants the pickup must not break, and the scope boundary for the pickup session

# In Claude Code, at the end of a session:
# "Write a handoff doc for this work"

kew skills install handoff

Writes to docs/handoff/YYYY-MM-DD-<topic>.md by convention.

security-guard (hook, not a skill)

The PreToolUse guard installed by kew setup (and manageable via kew skills like any other artifact). It catches destructive and exfiltration-prone shell patterns and blocks agent writes to .claude/ — defense-in-depth, not a security boundary. See Security for the full framing, the pattern table, and how it relates to sandboxed dispatch.

kew skills install security-guard    # equivalent to `kew setup`'s hook generation
kew skills update security-guard     # re-render from current kew.toml

Because the guard blocks agent writes to .claude/, installed skills and the hook itself are protected from being tampered with by the very agent they govern — a closed loop, not just a one-time install.