Claude Skills by curtisgalloway

How to write skills, hooks, subagent definitions, and agent-facing scripts that survive a change of harness (Claude Code, Antigravity, whatever ships next), and how to port one that didn't. Use when authoring or reviewing any of those, before hardcoding a path, variable, or tool name another harness wouldn't have, or when a skill "does nothing" under a different agent. Ships scripts/portability_scan.py, a mechanical check for these assumptions.

SYNTHETIC TEST FIXTURE - a skill welded to one harness. Every finding here is deliberate.

SYNTHETIC TEST FIXTURE - the same skill written to survive a change of harness.

Reference doc — how to locate the live Claude Code session transcript on disk and extract real user prompts from it (filter rules, slash-command pair collapsing, noise stripping). Other skills (learn, wrapup) Read this file before parsing transcripts. Not a user-invocable skill.

Adopt a thinking-partner posture for design, architecture, and brainstorming: explore the problem, lay out options and tradeoffs, push back — without touching code. Use when the user wants to think something through ("let's brainstorm", "should I", "talk me through the tradeoffs") rather than have a change made; drop the posture when they say to build.

Review a repo-owned Markdown document with a stakeholder through Google Docs, in numbered rounds. The Markdown file in git stays the source of truth; each round is a new Doc built from it, the reviewer's direct edits and margin comments are read back and applied to the file, and the reply to their comments opens the next round. Use when the user says "review this in a Google Doc", "send it to <name> for review", "process my comments in the doc", "read the doc back", "next round", "publish rou...

Preserve working state across a context clear or agent restart. Write mode dumps a HANDOFF.md the next session can cold-start from (task, state, decisions, dead ends, next steps); resume mode reads it back and continues the work. Use when the user invokes /handoff, says they're about to clear context / restart / compact / "pick this up tomorrow", or starts a session by asking to resume from a handoff.

A loop-safety posture: after 12 turns without meaningful progress, stop, file a stuck report, and wait for direction. Use when the user wants protection against runaway loops or silent thrashing ("intern mode", "stop if you get stuck"). Stays active until explicitly released.

Two modes. Quick (default): review the current session transcript for lessons that would have made it go smoother — failed commands, wrong tool arguments, user corrections, environment surprises — and propose additions to the workspace or global instruction file (AGENTS.md/CLAUDE.md); the promotion path from private auto-memory into reviewed, versioned instructions. Full (/learn --full): analyze the last 30 days of sessions, cluster recurring task patterns, propose new skills for your skills ...

Summarize past coding-agent sessions into teaching-oriented markdown files. Reads session transcripts from the agent's project-specific transcript directory, finds sessions that haven't been summarized yet (keyed on session_id in existing summary frontmatter), and writes one summary per unsummarized session. Use when the user invokes /teach or asks to "summarize previous sessions" / "catch up on session summaries".

Generate a concise agent-work summary covering all sessions since the last git commit — what was asked for, how it was driven, and which skills were used. Suitable for pasting into PR descriptions or commit messages. Use when the user invokes /wrapup or asks to "summarize what the agent did" / "give me a PR summary" / "what happened this session".

Conventions for command-line tools that both people and agents will drive — a portable exit-code contract, a `--skill` flag that emits the tool's own usage doc, strict `--json`, non-interactive-by-default behavior, and where a tool that runs as a service keeps its secrets. Use when writing a new CLI, reviewing an existing one, adding service/daemon management to one, or deciding what a command should return when it fails.

Score the health of open-source packages so you can choose between dependency alternatives on evidence instead of fame. Use this skill whenever you are about to add, recommend, or evaluate a third-party dependency; whenever the user asks "which library should I use", "is X maintained", "X vs Y", or asks you to audit existing dependencies; and before pinning any new package in a manifest (Cargo.toml, package.json, pyproject.toml, go.mod). Run it even if you already "know" the popular choice — ...

Use Jujutsu (jj) for version control instead of git. Trigger whenever a `.jj/` directory exists in the repo, or the user mentions jj or jujutsu, and then for ANY version-control operation in that repo — status, diff, log, commit, branch, bookmark, push, fetch, rebase, squash, split, conflict resolution, undo, or history rewriting. Do not trigger in plain git repos with no `.jj/`.

Produce a source-anchored implementation spec for a single peripheral (Ethernet MAC, UART, GPIO, SD/MMC, USB, I2C/SPI, …) from driver source you or your organization authored or may otherwise copy from — every fact cites the file:line it was derived from at a pinned commit, so a reviewer can check the spec against the code and drift is detectable when the code moves. Use when asked to document, spec, or port a driver whose source is yours; for encumbered (GPL, NDA, third-party) source use cle...

The consumer side of the clean-room driver-porting pipeline: rules, enforcement, and auditing for agents that write target-OS driver code from a verified spec. Use when implementing or reviewing ported-driver code, installing enforcement (hooks, restricted agents, settings), filing a spec-gap, or auditing a session for contamination. Companion to os-investigator and cleanroom-spec, which produce the spec this skill consumes.

Produce a clean-room implementation spec for a single peripheral (Ethernet MAC, UART, GPIO, SD/MMC, USB, display/mailbox, I2C/SPI, …) so an engineer can write a from-scratch driver in a differently-licensed OS. Use when asked to spec a driver or research a hardware block before coding it. Orchestrates os-investigator and the board-expert skill, and enforces the transfer protocol, mandatory leak scanning, and the provenance ledger; consumer-side enforcement lives in cleanroom-implementer.

Board expert for the Indiedroid Nova (ameriDroid; same hardware as the 9Tripod Pico PC V2.0) and for Rockchip RK3588S/RK3588 bring-up generally (Radxa ROCK 5, Orange Pi 5, …): memory map and MMIO addresses, device tree, boot chain and exception-level hand-off, PSCI/SMP, GIC-600, timers, clocks/power (CRU, SCMI, RK806), debug UART, GPIO/pinmux via the GRF, PCIe/USB/eMMC, and which sources and datasheets to cite. Use for any Indiedroid Nova or RK3588(S) hardware, low-level software, or bring-up...

Investigate OS and firmware source (Linux kernel, Trusted Firmware-A, vendor boot code, device trees) for a clean-room reimplementation in a differently-licensed OS: returns hardware facts and mechanism descriptions in original words — never source code, even when asked — every fact tagged by provenance class (databook/standard/DT/source-observed). Use whenever someone asks how the kernel or firmware does X, or what address/IRQ/clock/init sequence a peripheral uses, even if they don't say "cl...

Review a driver implementation against a reference implementation of the same hardware and produce an anchored findings report — missing init steps, wrong constants, absent errata workarounds, ordering/timing divergences — where every finding cites the file:line on both sides at pinned commits, so a reader can open either tree and check it. Defaults to the driver in the current directory as the implementation under review; locates the reference via a matching board-expert skill, or by asking ...

Board expert for the Raspberry Pi 5 / Compute Module 5 (BCM2712 SoC + RP1 southbridge): memory map and MMIO addresses, device tree, boot chain and exception-level hand-off, PSCI/SMP, interrupts, timers, clocks/power, UART/GPIO, PCIe and the RP1, plus sources and datasheets for bring-up. Use for any Pi 5, CM5, BCM2712, or RP1 hardware or low-level question. Pairs with os-investigator, which supplies the method and the clean-room no-source-code rule.

Drive a Bus Pirate 5/5XL/6 (buspirate) from its terminal or a host script: transaction syntax, mode selection, IO pinout, programmable power supply and pull-ups, per-pin voltage measurement, logic analyzer, and the BPIO2 binary scripting port. Use when probing, sniffing, scanning, or bit-banging an I2C, SPI, UART, 1-Wire, 2-wire, 3-wire, or JTAG/SWD bus, dumping an EEPROM or flash chip, or figuring out which of the two serial ports is which. Covers Bus Pirate 5 and later only — classic v3.x i...

Set up and run USB traffic capture with a Cynthion USB analyzer. Covers device verification, loading the analyzer bitstream, hardware wiring, launching Packetry for GUI capture, and headless (no-GUI) capture to .pcap files using the bundled Rust or Python tools. Use when the user asks to capture USB traffic, analyze a USB device, run headless/automated capture, or start a USB capture session with Cynthion.

Decode, analyze, and diff USB capture files (.pcap/.pcapng) produced by Packetry and Cynthion. Use when the user mentions a .pcap or .pcapng from Packetry or Cynthion, asks to decode/analyze/read/diff/summarize a USB capture, or has questions about specific endpoints, descriptors, or transfer sequences in a capture file.

Orchestrate a structured USB protocol reverse-engineering session with Cynthion hardware: capture, diff, infer command structure for a proprietary device, then generate replay and Facedancer emulation scaffolds. Use to reverse a USB device's protocol or build a clone or emulator. Not for generic capture analysis — use cynthion-pcap-decode.

Install and verify the software prerequisites for Cynthion skills (cynthion CLI, Packetry GUI, tshark, Linux udev rules). Run this once on a new machine before using any other Cynthion skill. Use when the user asks to set up Cynthion, install Cynthion software, or when a Cynthion skill fails due to missing tools.

Operate an MCCI Model 3411 "Merganser" USB 3.2 Gen2 test device: find and drive its FTDI control port and on-device RTEMS shell, switch between loopback, USB-IF compliance, and multi-bulk personalities, and run host-side throughput and data-integrity tests with usbiotest. Use when an MCCI 3411, Merganser, or SuperMUTT-compatible loopback/compliance device comes up, or to benchmark USB 3.2 Gen2 host throughput. Covers the VID/PID confusion between the control and data ports.

Remote-control a Siglent SDS1000X-E series oscilloscope (SDS1104X-E, SDS1204X-E, etc.) over the network — SCPI command essentials, screenshots, deep-memory waveform transfer, and the firmware quirks that hang naive clients. Use when the user wants to talk to, automate, screenshot, or pull waveform data from a Siglent SDS1000X-E-series scope.

Generate a USB device-profile JSON — endpoint transfer types, directions, and max packet sizes across all configurations — by reading the device's driver source, so the Cynthion decode pipeline can type endpoints when enumeration traffic wasn't captured. Use when asked to generate, update, or inspect a device profile, or when preparing a device for capture analysis.