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 ymd38/dev-skills --skill yds-gh-issue-resolvergit clone --depth 1 https://github.com/ymd38/dev-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/ymd38/dev-skills/yds-gh-issue-resolver)<a href="https://agentmods.dev/skills/ymd38/dev-skills/yds-gh-issue-resolver"><img src="https://agentmods.dev/badge/skills/ymd38/dev-skills/yds-gh-issue-resolver.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.00143 | $0.02978 |
| Opus 5 | $0.00072 | $0.01489 |
| Sonnet 5 | $0.00029 | $0.00596 |
| Haiku 4.5 | $0.00014 | $0.00298 |
Grade A, and why
yds-gh-issue-resolver 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 7d 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 — 294 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub Issue Resolver
Overview
Implement and verify a fix for a GitHub Issue, starting from the agreed response plan that yds-gh-issue-planner has already posted as a comment on the issue. This skill creates a feature branch, uses a git worktree as a temporary implementation sandbox, runs tests, opens a Pull Request, and verifies the fix against the original issue.
Prerequisites
- The target issue must have an agreed plan comment previously posted by
yds-gh-issue-planner, identified by the HTML marker<!-- gh-issue-planner:agreed-plan -->near the end of the comment body. - If no such comment exists, stop and direct the user to run
yds-gh-issue-plannerfirst. Do not improvise an unagreed plan in this skill.
Workflow
Step 1: Fetch the Issue and Agreed Plan
Run the following command (replace <id> with the issue number):
gh issue view <id> --json number,title,body,labels,state,url,comments
From the comments array:
- Locate the most recent comment whose body contains the marker
<!-- gh-issue-planner:agreed-plan -->. - Treat that comment as the agreed plan and extract the 対応方針 / 影響範囲 / 実装方法 sections.
- If no such comment exists, abort with a message asking the user to run
yds-gh-issue-plannerfirst.
Step 2: Branch and Worktree Setup
# 1. Create a branch from the default branch (without switching the main working tree)
git branch <branch-name>
# Examples: fix/42-add-timeout-to-fetch feat/15-user-export-api
# 2. Create an isolated worktree from that branch
git worktree add ../<branch-name> <branch-name>
Branch naming convention:
- Bug fixes:
fix/<id>-<short-description> - Features:
feat/<id>-<short-description> - Refactors:
refactor/<id>-<short-description>
All implementation work (Steps 3–4) is performed inside the worktree directory ../<branch-name>. The main working tree stays on its current branch throughout.
Step 3: Implementation
Apply the changes defined in the agreed plan inside the worktree directory. Follow these rules:
- Make minimal, focused changes — do not scope-creep beyond the agreed plan
- Run existing tests after each logical change to catch regressions early
- Add or update tests to cover the changed behavior
- If the agreed plan turns out to be infeasible or incomplete, stop and return to
yds-gh-issue-plannerrather than silently expanding the scope here
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.
- 7d ago First seen · 294 lines · 143 tokens per session scan A 68b2bc61c6f8
yds-gh-issue-resolver is a skill published in the GitHub repository ymd38/dev-skills (4 stars, last pushed 10d ago), licensed MIT. It adds 143 tokens to every session and 2,978 once invoked, about $0.0007 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-31.
Other skills, from other repositories
security-pipeline
Use when security verification is needed - pre-commit security checks, vulnerability scanning, STRIDE threat analysis. Integrates with /handoff-verify --security and /commit-push-pr. CWE Top 25 based.
caveman-commit
Ultra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. Use when user says "write a commit", "commit message", "generate commit", "/commit", or invokes /caveman-commit.…
no-mistakes
Validate committed feature-branch changes through the no-mistakes pipeline: intent, rebase, review, test, docs, lint, push, PR, and CI. Use when the user asks to run no-mistakes, ship safely, validate before pushing, or gate a change before it reaches upstream.
commit-trailers
Commit mesajlarina yapilandirilmis karar trailer'lari ekle. Constraint, Rejected, Confidence, Scope-risk, Not-tested trailer'lari ile karar baglamini koru.
release
Guide through the Cortex TMS release process — version bump, changelog, sync, tag, publish. Every step requires user approval.
land-and-deploy
Merge PR, wait for CI, verify deploy, run canary. The complete landing pipeline.