███████╗██╗ ██╗██╗██╗ ██╗ ███████╗
██╔════╝██║ ██╔╝██║██║ ██║ ██╔════╝
███████╗█████╔╝ ██║██║ ██║ ███████╗
╚════██║██╔═██╗ ██║██║ ██║ ╚════██║
███████║██║ ██╗██║███████╗███████╗███████║
╚══════╝╚═╝ ╚═╝╚═╝╚══════╝╚══════╝╚══════╝
Agent skills you can install individually or all at once. Each skill is its own directory with its own guide, with no dependencies.
- Install
- The Skills: Filing and memory · Writing around code · Inside a coding session · Platform APIs
- Repository Layout
- Contributing
- License
You need Node 22.20 or newer, which is what the skills CLI asks for, and nothing else.
Install the whole collection:
npx skills add kendrick/skillsOr take one:
npx skills add kendrick/skills --skill technical-writingEither way the CLI writes the skill directories where your harness looks for them, and the skill is live in your next session. To check it landed, ask your agent to use it by name:
> use technical-writing on this commit message
If you're picking a first one, start with technical-writing, file-issue, or readme-coauthorship. None of them need a vault or an approved plan, and all three land on work you already do. One thing to know about the middle one: file-issue posts through the GitHub CLI, so authenticate gh before you expect it to file anything. Without that it still drafts, and says plainly that it can't post.
Each skill's own README covers any CLI it expects.
| Skill | What it does | Install flag |
|---|---|---|
| inbox-to-memory | Meeting exhaust into groomed notes and durable memory | --skill inbox-to-memory |
| memory-index | Registers memory scopes with qmd and keeps the index fresh | --skill memory-index |
| memory-consolidate | Turns ltm doctor findings into memory candidates for review |
--skill memory-consolidate |
| jd-file | Gives an arriving thing its Johnny.Decimal number and register line | --skill jd-file |
| jd-audit | Finds drift between a Johnny.Decimal register and its folders | --skill jd-audit |
| technical-writing | Commits, comments, and PR prose against named public standards | --skill technical-writing |
| readme-coauthorship | READMEs, brand-new or long-neglected, root or nested | --skill readme-coauthorship |
| file-issue | One GitHub issue, interrogated before it's filed | --skill file-issue |
| jira-refine | Refinement transcripts into enriched Jira issues | --skill jira-refine |
| eli5 | Says the last message again, shorter and without jargon | --skill eli5 |
| adversarial-review | Reviews a diff by trying to break its own findings | --skill adversarial-review |
| divvy-up | Runs an approved plan as waves of parallel subagents | --skill divvy-up |
| work-issue | Runs one issue from approved plan to answered review threads | --skill work-issue |
| handoff | Carries unfinished work into a fresh session | --skill handoff |
| mutation-testing | Breaks a guard a diff adds and reports which tests noticed | --skill mutation-testing |
| work-wave | Runs N issues at once, one work-issue lane each, merge-tested first | --skill work-wave |
| databricks-api | Databricks REST APIs and the Python SDK, eight domains | --skill databricks-api |
Drop your meeting exhaust—transcripts, slide decks, PDFs, half-finished scratch notes—into an _inbox/ folder, say "process the inbox," and each input comes back as one groomed markdown note: frontmatter up top, extracted quotes and tensions and action items in the middle, the verbatim original at the bottom. Along the way it flags memory candidates across three tiers, and you approve each record before it's written.
Registers a memory scope with qmd so agents can search it: one collection per _memory/ record folder, one for the groomed notes with the raw transcripts in notes/raw/ left out, and a context string for each, written from the scope's own CLAUDE.md. Folders decide collections: a record belongs to the collection of the folder it sits in, whatever its frontmatter says. qmd has no file watcher, so refresh reindexes after records land, and you can call it from a hook.
Runs ltm doctor over a scope's _memory/ and writes what it finds, such as stale records, long supersession chains, and orphans, as a report of memory candidates. The report uses the same candidate lines a groomed note does, so inbox-to-memory's Phase 5 handles each finding like any other: approving a line amends the target record and rewrites the line, and declining one adds | dismissed: with your reason, which takes it out of the unpromoted_candidates count. The skill writes the report and never touches a record, and it keeps no list of check names, so a check the kit adds later reaches the report unchanged.
Gives an incoming thing its Johnny.Decimal number, puts it in the right tree, and writes the register line in the same motion, so the index can't quietly fall behind the folders. It reads the vault's own conventions file for the grammar instead of hardcoding rules, and scales its caution to the stakes: a clean match files without a question, a new area never happens without you saying so.
Checks a Johnny.Decimal system for drift and walks you through reconciling what it finds. The comparison itself is a standard-library Python script reading the same conventions file jd-file reads, because a diff wants a diff tool rather than a fresh act of judgment every run. Severity tracks how much judgment a finding still needs, and reconciliation decisions stay yours.
Routes developer-facing prose—commit messages, code comments, PR descriptions, review correspondence, API reference, READMEs—to a profile that names which public standards apply: Diátaxis, Google developer style, ASD-STE100 principles, and Kohl's Global English. Artifacts with no profile yet fall back to the global rules. Every draft ends in a mandatory audit.
Co-authors READMEs—this one included—whether brand-new, long-neglected, at the repo root, or buried in a monorepo. It scans the repo before asking anything, refuses to fabricate what it can't verify, and structures what it writes as a funnel from general to specific. Runs guided, a short wizard of targeted questions, or autopilot, which infers everything from repo metadata.
Writes one GitHub issue and files it with gh. Most issue tooling checks that you filled in the template; this checks whether what you filled in is any good—can a stranger run your reproduction steps, can your acceptance criteria fail, does a coding agent picking it up know how to verify its own work. It reads the repo first, so an existing issue form always wins.
Turns a recorded backlog-refinement transcript into enriched Jira issues. It segments by the project keys spoken aloud, fills a fixed seven-field template, plus a Labels slot when the config declares label families, only from what was actually said, and anchors every acceptance criterion to a verbatim quote—a slot the room never reached gets a - not discussed line instead of a guess. Nothing reaches Jira until you mark a staged ticket approved.
Type /eli5 when the agent's last message didn't land, and it says it again—shorter, no jargon, like one human talking to another. Pass the confusing part as an argument (/eli5 the part about cache invalidation) to re-pitch just that piece. The restatement adds no new claims and only ever fires when you type it. A mashup of bro from Lauren Tan's pstack and wait-what from Matt Pocock's skills, both MIT.
Reviews a diff by treating every finding as a hypothesis rather than a result. It partitions the changed files into non-overlapping territories—money, authz, state transitions, schema, budgets, representation boundaries—sends one finder at each in parallel, then hands every claim to a fresh agent that never saw the reasoning behind it and is told to break it. Only a finding that survives can block a merge, and blockers get a failing test before anyone writes the fix.
Runs an implementation plan you've already approved as waves of parallel subagents rather than one task at a time. One mechanism makes that safe: every task declares the exact files it owns, and a script proves no two tasks in a wave own the same path before anything is dispatched. An overlap stops the run rather than warning about it, because two agents editing one file in one working tree lose a write and neither reports it.
Writes a handoff before you end a coding-agent session, either to a file on your machine or to a document panel when you're working on the web. Invoke it again in a fresh session and it restores the task list, then stops for your go-ahead. Raw conversation history would lose the detail needed to finish the work. The handoff guide covers Claude Code, Codex, and GitHub Copilot CLI invocation.
Breaks a guard your diff just added and reports which tests noticed. It fires on what the diff adds—a rejection, a validation, an invariant, a limit, a permission check—rather than on what kind of file it lands in, and writes two mutations per guard: the plausible refactor, which measures how much of the suite would catch a reasonable edit, and the adversarial route, which asks whether the guard watches the right quantity at all. Restore happens by name and is checked against a snapshot, because a directory-form restore once reverted a new test alongside the mutation and the suite came back green without it.
Picks up where divvy-up leaves off: the built diff, the pull request, and everything after that nobody wrote down—rebasing, pushing, reading what an external reviewer said, repairing what's in scope, and answering every thread. State lives on disk, not in the conversation, so a session that ends mid-run resumes by typing the same command again. A human merges; this skill stops one step short.
Runs several issues at once, each as its own work-issue lane in its own worktree, and owns only what is true across them. One mechanism makes the fan-out safe: a script proves every lane's footprint disjoint from every other's before anything is dispatched, and the orchestrator then answers the question the script cannot—whether one lane's change alters what another builds against—and derives the merge order from the answers. The lanes are merge-tested together in a detached worktree before any of them opens a pull request, and facts one lane learns reach the others' workers mid-run. A human merges, in the order the report gives.
A router plus eight domain skills covering the Databricks REST APIs and the Python SDK: Unity Catalog, Jobs and Workflows, SQL warehouses, Model Serving, Delta Sharing, Genie, Marketplace, and file management. One rule holds it together: every endpoint, field, and enum value it hands you comes from a doc it actually read, not from memory. The router points you to a domain, the domain points you to the bucket file.
- databricks-api/, file-issue/, jira-refine/, inbox-to-memory/, memory-index/, memory-consolidate/, jd-file/, jd-audit/, readme-coauthorship/, handoff/, adversarial-review/, divvy-up/, work-issue/, mutation-testing/, work-wave/, technical-writing/, eli5/: the skills themselves, one directory each
- _docs/: research notes behind the skills, like the readme-coauthorship writeup and the issue-authorship survey
- _maintenance/: maintainer tooling, one subdirectory per skill that needs it: the refresh workflow that keeps
databricks-apisynced with upstream Databricks docs, the upstream sync behindhandoff, the check that holds thejdpair's prose to the vault register, and the decision ledgers, evals, and provenance records behind the rest - tests/: smoke scripts that pin the load-bearing decisions in each skill and in the repo's agent docs; each runs standalone from the repo root, like
bash tests/technical-writing-smoke.sh
Contributions are welcome and the process is informal: open an issue or a PR. There's no template to fill out and no CLA to sign. If you're adding a skill, AGENTS.md describes what one ships: a SKILL.md and a README.md in its own directory, a decision ledger under _maintenance/, and a smoke test under tests/. The first two are the skill; the last two are what keep it honest as it changes.
MIT. See LICENSE.