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 skills add joshukraine/dotfiles --skill walkthroughgit 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/walkthrough)<a href="https://agentmods.dev/skills/joshukraine/dotfiles/walkthrough"><img src="https://agentmods.dev/badge/skills/joshukraine/dotfiles/walkthrough/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/joshukraine/dotfiles/walkthrough"><img src="https://agentmods.dev/badge/skills/joshukraine/dotfiles/walkthrough.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Rogue Agent · line 101 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
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.00033 | $0.03763 |
| Opus 5.5 | $0.00013 | $0.01505 |
| Sonnet 5.5 | $0.00007 | $0.00753 |
| Haiku 4.5 | $0.00003 | $0.00376 |
Grade A, and why
walkthrough 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 1mo 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 — 193 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Walkthrough
Generate a concise, click-by-click manual walkthrough of the current branch's user-facing changes, so the human orchestrator can exercise the feature in a browser before the formal /code-review. Seeing a feature work is faster than reading code or a PR description for catching UX problems.
This skill does not modify code or perform code review. It renders the walkthrough as a single self-contained HTML file — with click-to-copy commands, URLs, and logins — in both modes. By default it writes that HTML to the project's local tmp/ as scratch and opens it. With --publish it also uploads the HTML to the project's configured QA host (when one is declared in the project's CLAUDE.md) and posts a PR comment linking to it, with a Markdown rendition as a collapsible fallback (Markdown is the only thing a GitHub comment can render inline).
Where it sits in the workflow — two slots:
- Generate (default) — run after
/create-prand before/code-review, and re-run as needed. The orchestrator's iterative pre-flight check. - Publish (
--publish) — run once after/code-reviewand any review fixes, just before merge (or after merge, to backfill a walkthrough that was missed). Posts the final walkthrough to the PR so the QA tester can follow it after deploy.
Not the same as:
/debrief— a heavy architecture and test-coverage write-up for milestones./qa-handoff— a broad, committed QA guide for a whole phase./walkthrough --publishis the per-PR counterpart: one change, posted to the PR.
Command Options
--publish: Post the final walkthrough as a comment on the PR, regenerating it first so it matches the code under review. Run once, after review — normally just before merge, but it also works on an already-merged PR to backfill a missed walkthrough. See the Publishing section.
Your task
If invoked with --publish, follow the Publishing the final walkthrough section below instead. Otherwise, generate a new walkthrough:
What ships with it
1 file 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.
- 1mo ago First seen · 193 lines · 33 tokens per session scan A 2ac531962d86
walkthrough is a skill published in the GitHub repository joshukraine/dotfiles (429 stars, last pushed 5d ago), licensed MIT. It adds 33 tokens to every session and 3,763 once invoked, about $0.0001 per session on Opus 5.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.
Capybara Testing
Expert-level Capybara acceptance testing skill for Ruby and Rails applications. Covers RSpec integration, DSL methods, scoping, Page Objects with SitePrism, JavaScript interactions, and database cleaning strategies.
playwright
Automate browsers and E2E tests with Python Playwright: screenshots, traces.
playwriter
Control the user own Chrome browser via Playwriter extension with Playwright code snippets in a stateful local js sandbox via playwriter cli. Use this over other Playwright MCPs to automate the browser — it connects to the user's existing Chrome instead of launching a new one. Use this for JS-heavy websites…
end-to-end
Use when the agent must execute or directly observe decisive live software acceptance through a real user-visible or runtime surface, including browser, Emacs, terminal display, async/network delivery, persistence, or scheduler behavior. Automation may drive the actual surface. Do not use solely to give manual test…