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/testdouble/han/work-items-to-issuesnpx skills add testdouble/han --skill work-items-to-issuesgit clone --depth 1 https://github.com/testdouble/hanWrote 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/testdouble/han/work-items-to-issues)<a href="https://agentmods.dev/skills/testdouble/han/work-items-to-issues"><img src="https://agentmods.dev/badge/skills/testdouble/han/work-items-to-issues.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.00119 | $0.03218 |
| Opus 5 | $0.00060 | $0.01609 |
| Sonnet 5 | $0.00024 | $0.00644 |
| Haiku 4.5 | $0.00012 | $0.00322 |
Grade A, and why
work-items-to-issues 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 yesterday.
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 — 196 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Project Context
- personal config directory: !
bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude" - project .han/config.md: !
cat .han/config.md 2>/dev/null || echo ""
As your first action, use the Read tool on .han/config.md inside the personal config directory path above. A read
that returns no file is no personal configuration: continue silently. When that file or the project .han/config.md
probe supplies content, apply it per config-rule.md, which governs precedence
between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.
Work Items to GitHub Issues
Take an already-broken-down work-items.md file (produced by /plan-work-items) and publish each slice as a GitHub
issue in its target repo.
The breakdown work — drafting slices, assigning symbolic IDs, specifying dependencies, inventorying references — has already been done upstream. This skill's job is to map each slice to its target repo, validate the format, write a per-repo work-items file alongside the source, and run the publish pipeline.
Rules
- Each slice lives in exactly one repo. Cross-repo coordination is documented in prose at the top of
work-items.md— never as a native blocker link. - Native
blocked_byrelationships are within-repo only. A cross-repoDepends onis a format error to surface for repair. - Symbolic-ID prefixes: accept whatever the input uses. Both shapes are valid input — single-prefix across repos (e.g.,
W-Nfor every slice) and per-repo prefixes (e.g.,V2-Nbackend,W-Nfrontend,EV-Nevents). The publish scripts accept any uppercase prefix. - Every slice issue body MUST link the reference artifacts an implementer needs — API/event contracts, design frames, schema docs, runbooks, ADRs, coding standards. Issues that consume an HTTP endpoint or event payload MUST link the contract section that defines it.
- UI slices, when the plan folder has a
ui-designs/subfolder, MUST embed the relevant screenshots inline using same-target-repo raw URLs. See references/screenshot-embed-rules.md. - NEVER include process artifacts in issue bodies or the work-items preamble. Excluded categories — iteration histories,
decision logs, review findings, team findings, facilitation summaries, gap analyses, and anything under an
artifacts/subfolder of the plan that is not a contract or design reference. Full include/exclude list in references/reference-artifact-inventory.md.
What ships with it
8 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.
- references/issue-template.md 6.6 KB
- references/reference-artifact-inventory.md 5.9 KB
- references/screenshot-embed-rules.md 6.5 KB
- references/work-items-file-format.md 4.4 KB
- scripts/create-issues.sh 4.0 KB runs code
- scripts/link-blockers.sh 4.0 KB runs code
- scripts/publish-work-items.sh 1.2 KB runs code
- scripts/upload-screenshots.sh 12 KB runs code
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.
- yesterday First seen · 196 lines · 119 tokens per session scan A 0826a93242f7
work-items-to-issues is a skill published in the GitHub repository testdouble/han (256 stars, last pushed 4d ago), licensed MIT. It adds 119 tokens to every session and 3,218 once invoked, about $0.0006 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-09-03.
Other skills, from other repositories
pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
phx-pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
branch-and-worktree-workflow
Isolates feature work in its own branch or worktree and integrates it cleanly when done. Use this when starting work that should not disturb the current workspace, when several efforts must proceed in parallel on one repository, or when implementation is finished and the change needs merging, rebasing, or splitting…
genshijin-commit
超圧縮コミットメッセージ生成。Conventional Commits形式で件名≤50文字、 「何を」より「なぜ」を重視。日本語・英語両対応。 「コミットメッセージ作って」「/commit」「/genshijin-commit」で起動。 ステージング変更時に自動起動候補。.
commit-push-pr
Full git workflow - creates branch, commits, pushes, and creates or updates a PR with summary and test plan.
commit
Create a single well-crafted git commit from current changes. Analyzes diff, follows repo's commit style, and writes a concise "why not what" message.