Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/joshukraine/dotfiles/qa-handoffnpx skills add joshukraine/dotfiles --skill qa-handoffgit clone --depth 1 https://github.com/joshukraine/dotfilesWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/joshukraine/dotfiles/qa-handoff)<a href="https://agentmods.dev/skills/joshukraine/dotfiles/qa-handoff"><img src="https://agentmods.dev/badge/skills/joshukraine/dotfiles/qa-handoff.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00041 | $0.03793 |
| Opus 5 | $0.00020 | $0.01896 |
| Sonnet 5 | $0.00008 | $0.00759 |
| Haiku 4.5 | $0.00004 | $0.00379 |
Grade A, and why
qa-handoff scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 147 lines — stays where its author put it; the contents beside it link to each section on GitHub.
QA Handoff
You are a senior developer preparing a hands-on testing guide for a QA colleague. Your colleague understands the product but is NOT tracking implementation details, architecture decisions, or code-level rationale. Write for someone who needs a clear, step-by-step guide to exercise the new work and find gaps in behavior and UX.
Step 0: Detect the project type
Pick the mode from what's in the repo:
- Rails app — a
Gemfileplusconfig/application.rborbin/rails. Follow the Rails path (templatetemplate.html). - Static site (Hugo) — a Hugo config (
hugo.toml/hugo.yaml/hugo.json, orconfig.toml/config/_default/) with acontent/directory (or another static-site generator). Follow the Static-site path (templatetemplate-static.html). - Neither — tell the user this skill targets Rails apps and static sites, and stop.
Both paths produce the same kind of artifact — a single self-contained HTML page built from the shared house style and shipped through the shared publish pipeline. They differ only in which template and section content they use.
Not the same as /walkthrough — that's the per-PR counterpart (one change, exercised before review or --published to the PR). This is the broad, committed QA guide for a whole phase.
Context
Both paths: Read the project's CLAUDE.md (project name, any audience/viewport guidance, the ## QA Publish Target block) and docs/prd/ROADMAP.md if present (current phase). Check docs/debriefs/full/ for the most recent debrief; if one covers the current work, reuse its Product Tour as the basis for the walkthrough (strip rationale, keep the actions and expected behaviors). Otherwise build the walkthrough from recent git history.
Rails path also: Read db/seeds.rb to identify test accounts and credentials (reference them exactly). Review the Gemfile and recent migrations for setup the tester needs.
Static-site path also: Identify the deploy-preview URL the tester should open — a Netlify deploy preview is the typical source; if it isn't obvious from CLAUDE.md or the repo, ask the user. Note the local preview command (hugo server) and whether the preview is access-gated. Check the Hugo config for multiple languages (languages / defaultContentLanguage, an i18n/ dir, or content/<lang>/) — if multilingual, include the Languages & Translations section. Identify forms and external integrations and their backends (Netlify Forms, an external API, a separate app), and note any restricted to certain domains (e.g. a CORS allowlist) so the guide can tell testers which environment to use. For URL continuity, remember Hugo migrations often preserve old paths by slug-matching rather than redirect maps — check both that preserved URLs still resolve and that removed URLs are intentionally gone.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 147 lines · 41 tokens per session scan A 88512aa66ffc
qa-handoff is a skill published in the GitHub repository joshukraine/dotfiles (422 stars, last pushed 24d ago), licensed MIT. It adds 41 tokens to every session and 3,793 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
verify-ui-change-in-cloud
Verifies user-facing Warp client changes by spawning a cloud agent with computer use to test Warp. Use only when the user explicitly requested computer-use verification or accepted an offer to run it, and ONLY in non-sandboxed environments and local environments. Triggers a cloud agent that runs the test-warp-ui skill.
test-warp-ui
Guides testing Warp UI features and changes using the computer use tool. Use this skill only when computer-use testing was requested (explicit request or accepted offer) and the computeruse tool is available to the agent. Covers launching Warp and verifying UI behavior.
wispr-flow-debug
Debug and test the Wispr Flow AutoHotkey dictation triggers (Copilot key + extra keys) from WSL by deploying macos.ahk to the Windows Desktop, reloading AutoHotkey, and reading the debug log. Use when an activation/trigger key isn't starting/stopping dictation, when the overlay clicks land wrong, or when verifying a…
ralph-loop
Ralph Wiggum 迭代开发循环。三阶段工作流（需求→规划→构建），每阶段有 code review + 测试 gate。 触发词：ralph loop、迭代开发、interview me、plan system、build system。.
cmux-rebuild
Manage the user's durable dev sessions — zellij sessions on remote hosts (bonbon, taffy) reached over mosh, plus the local host's (trifle) own detached zellij sessions, surfaced as cmux tabs via ssh::durable / zellij::resume. Load when the user wants to rebuild/resurrect lost cmux durable surfaces after a cmux restart…
ml-paper-writing
Write publication-ready ML/AI papers for NeurIPS, ICML, ICLR, ACL, AAAI, COLM. Use when drafting papers from research repos, structuring arguments, verifying citations, or preparing camera-ready submissions. Includes LaTeX templates, reviewer guidelines, and citation verification workflows.