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 mthines/agent-skills --skill aw-create-walkthroughgit clone --depth 1 https://github.com/mthines/agent-skillsWrote 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/mthines/agent-skills/aw-create-walkthrough)<a href="https://agentmods.dev/skills/mthines/agent-skills/aw-create-walkthrough"><img src="https://agentmods.dev/badge/skills/mthines/agent-skills/aw-create-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/mthines/agent-skills/aw-create-walkthrough"><img src="https://agentmods.dev/badge/skills/mthines/agent-skills/aw-create-walkthrough.svg" alt="Reviewed on agentmods" width="80" 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.00073 | $0.01001 |
| Opus 5 | $0.00036 | $0.00500 |
| Sonnet 5 | $0.00015 | $0.00200 |
| Haiku 4.5 | $0.00007 | $0.00100 |
Grade C, and why
aw-create-walkthrough scanned grade C with 1 finding 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 9d 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.
Hidden instructionshighPrompt injection
Directives inside HTML comments, invisible characters or bidirectional overrides are read by the model and not by the person reviewing the file.
<!-- Step-by-step instructions for a reviewer to verify the changes work --> How it starts
The opening of the file, as written. The whole thing — 152 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Create Walkthrough Artifact
Generate .agent/{branch-name}/walkthrough.md — the final summary for PR delivery.
Prerequisites
Before invoking this skill:
- All tests must be passing
- Documentation must be updated
plan.mdmust exist and have an up-to-date Progress Log- You must be inside the worktree
Procedure
Step 1: Determine file location and gather information
Run this command to get the artifact path and gather git information — do NOT guess the branch name:
BRANCH=$(git branch --show-current) && mkdir -p ".agent/${BRANCH}" && echo "Artifact path: .agent/${BRANCH}/walkthrough.md" && echo "---" && git diff --stat main...HEAD && echo "---" && git log --oneline main...HEAD
From plan.md (read the file — must run in the same shell session as above, or re-assign BRANCH):
BRANCH=$(git branch --show-current) && cat ".agent/${BRANCH}/plan.md"
Extract: Summary, Decisions, Requirements, File Changes table.
From test results:
Recall or re-run the test suite to confirm current status.
Step 2: Write walkthrough.md
Create the file at the path from Step 1 using the template below. Do NOT hardcode or guess the branch name.
Step 3: Present to user
After writing the file, output the walkthrough content directly in the conversation so the user sees it immediately.
Template
All timestamps MUST use full ISO 8601 with time: YYYY-MM-DDTHH:MM:SSZ
---
created: { TIMESTAMP }
branch: { BRANCH }
task: { TASK_DESCRIPTION }
pr: { PR_NUMBER }
---
# Walkthrough: {TASK_DESCRIPTION}
## Quick Reference
- **Branch**: `{BRANCH}`
- **PR**: #{PR_NUMBER}
- **Worktree**: `{WORKTREE_PATH}`
## Summary
<!-- 2-3 sentences: what was implemented and the key outcome -->
## Changes
| File | Change | Purpose |
| ---- | ------ | ------- |
<!-- List ALL modified/created/deleted files from git diff -->
## Key Decisions
<!-- Numbered list of important decisions made during implementation.
Pull from plan.md Decisions table — include only the most significant ones. -->
1. {decision and brief rationale}
## Testing Results
<!-- Test outcomes with pass/fail indicators -->
- [x] {test category}: {result summary}
- [x] {test category}: {result summary}
## How to Verify
<!-- Step-by-step instructions for a reviewer to verify the changes work -->
1. {step}
2. {step}
3. {step}
## Next Steps
1. Review draft PR
2. Mark as ready for review
3. After merge: `gw remove {BRANCH}`
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.
- 9d ago First seen · 152 lines · 73 tokens per session scan C 911d0e2a3a23
aw-create-walkthrough is a skill published in the GitHub repository mthines/agent-skills (13 stars, last pushed today), licensed MIT. It adds 73 tokens to every session and 1,001 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it C with 1 finding (hidden instructions). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
git-workflow-and-versioning
Guides git commit discipline, trunk-based branching, and semantic versioning/changelogs for released code, including Go modules' major-version import path rule. Use when committing, branching, resolving conflicts, cutting a release, choosing a semantic version bump, tagging a release, or writing a changelog entry.
incremental-implementation
Builds in thin vertical slices -- implement one piece, test it, verify it, commit, then expand -- instead of writing a whole feature in one pass. Use when implementing any change touching more than one file, when a task feels too large to start, or before writing more than roughly 100 lines without running anything.
codely-plan_phase-implement-github
Implement one phase of a plan stored as GitHub issues in the repository of the current working directory. Given the URL of a phase (child) issue it implements that phase; given the parent plan issue it finds and implements the current phase. Only implements a single phase per invocation, then stops for user review. It…
codely-git-conventional_commit
Create a git commit following the team's Conventional Commit conventions. Use when the user asks to commit changes or create a commit.
local-pr-review
Act as a senior engineer and review the committed changes on the current git branch against the base branch (develop or main) — a local, pre-push PR review. Use this skill whenever the user wants feedback on a branch as a whole before opening or merging a pull request — phrases like "review my branch", "PR review…
create-commit
Compose and create a git commit whose message follows the Angular Conventional Commits standard, so semantic-release can version and changelog it automatically. Use this skill whenever the user wants to commit staged changes, "make a commit", "commit this", "write a commit message", "commit with conventional/angular…