Reusable playbooks for coding agents that need to do real work.

The front door

ask-adarsh

Routing · Any agent

Describe what you are trying to do, and it tells you which of these skills to reach for — one primary skill, a second only if the task genuinely has two halves, plus the exact command to invoke it and the first concrete step.

• Routes on the outcome you want, not on keywords in your sentence.
• Prefers one focused skill over stacking three together.
• Admits when nothing fits rather than inventing a match.

The heavy one

cpp-to-rust-port

Rust · C / C++ · FFI · Migration

Turns “port this C++ to Rust” into an actual migration: agree what must behave identically, freeze that behavior in tests first, port one subsystem end to end, and only delete the C++ once the Rust passes the same inputs with the same outputs.

• Parity harness before the rewrite: characterization tests, golden files for binary formats, and differential tests that run both implementations on the same input.
• Real rules for the dangerous edges — where unsafe is allowed to live, how to stop a Rust panic crossing an FFI boundary, how to make CMake and Cargo agree on build profiles.
• A named list of the anti-patterns it will not let you ship, and completion gates covering behavior, safety, performance, and observability.
• Proven on asdcplib — a production digital-cinema C++ library with deep ties to cryptography, KLV parsing, and SMPTE standards — rather than on a textbook example.

Version control

jj

Jujutsu · Git · Workflow

How to drive Jujutsu safely, including repositories that are colocated with Git: the daily flow, history edits, bookmarks and pushing, conflict resolution, and recovery — with a cheat sheet for translating the Git command you were about to type.

• Every command form is safe to run unattended — messages passed as flags, splits done by file path.
• Recovery is jj undo and jj op restore, not a hard reset.
• In colocated repos it keeps Git read-only, so the two tools do not fight over the working copy.

Everyday editing

reuse-first

Code review · Refactoring · Any language

Make the smallest coherent change that fits the repository you are already in. Look for the existing utility, test helper, error type, and convention before writing a new one — then reuse, extend, extract, or add, in that order.

• Names the shallow abstractions it refuses to add — wrappers, helpers, managers, and forwarding methods that pass a call through.
• Equally clear about when not to reuse: do not distort a working API just to claim you reused something.
• Has an opinion on comments — explain the rationale and the constraint, not the control flow.

Writing

technical-blog-writing

Writing · Documentation · Verification

Plan, draft, and fact-check a developer-facing article. Pick the shape that matches what you are writing — tutorial, deep dive, migration story, benchmark, postmortem — then verify the claims in it before anyone else has to.

• Code is treated as a tested artifact: run it, show the real output, or label it unverified and say what is left to check.
• Benchmarks have to carry their methodology — environment, baseline, sample counts, limitations.
• Editing happens in named passes, so accuracy is checked separately from clarity.