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 sungurerdim/dev-skills --skill ds-issuegit clone --depth 1 https://github.com/sungurerdim/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/sungurerdim/dev-skills/ds-issue)<a href="https://agentmods.dev/skills/sungurerdim/dev-skills/ds-issue"><img src="https://agentmods.dev/badge/skills/sungurerdim/dev-skills/ds-issue/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/sungurerdim/dev-skills/ds-issue"><img src="https://agentmods.dev/badge/skills/sungurerdim/dev-skills/ds-issue.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.07776 |
| Opus 5.5 | $0.00029 | $0.03110 |
| Sonnet 5.5 | $0.00015 | $0.01555 |
| Haiku 4.5 | $0.00007 | $0.00778 |
Grade A, and why
ds-issue 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 — 162 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/ds-issue
AI assistants file issues from memory (unverified anchors, duplicates, dead content), claim "done" nobody proved from code, "fix" issues that are already stale, touch one file while five callers break, and bury the decisions that matter in comments nobody re-reads. This skill makes the whole GitHub-Issues loop trustworthy — record side and work side — with GitHub Issues as the durable store (a last-resort local tasks.md mode exists for repos with no GitHub remote — Contract).
GitHub-Issues lifecycle — verified intake · dedup sweep · code-verified status · issue-bound execution.
The body is the issue. Every decision, criterion, gate baseline, deferral, and closure lives in the issue body, updated with
gh issue edit --body-file -. This skill never puts information in a comment; a comment is read only to promote someone else's requirement into the body. An issue body is a standalone brief: an agent with no access to this conversation can open it and work it. See references/github-features.md § Body is the record.
Completion Evidence — applies to every phase: Report
done/OKonly with the machine-checkable evidence the gates name — the exact command run and its observed output (orfile:linediff). Missing evidence → reportINCOMPLETEplus what is missing. Self-assessment is never evidence. (This band repeats at file end by design — both copies are normative.)
Triggers
- User runs
/ds-issue, asks to open / file / refine an issue, sweep for duplicates, check what's actually done (from code), do a specific issue end-to-end (--do #N), or work through all open issues in sequence (--do --all).
Triggers — INVOKE / DON'T INVOKE
| INVOKE | DON'T INVOKE |
|---|---|
| "make this an issue", "file a bug", "add to backlog" | "open a pull request" (→ ds-pr) |
| "are there duplicate issues? sweep the tracker" | "run linters / fix quality" (→ ds-fix) |
| "what's actually done vs claimed? verify from code" | "design the architecture for X" (→ ds-backend) |
| "do issue #142 end-to-end and close it with proof" | "find why this fails, cause unknown" (→ ds-debug — no issue contract) |
"work through every open issue and close each with proof" (--do --all) |
"do all the things" (no issue scope → ds-ship) |
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.
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 Changed · -38 lines 4de5e2056431
- 1mo ago First seen · 200 lines · 73 tokens per session scan A 39ff84713377
ds-issue is a skill published in the GitHub repository sungurerdim/dev-skills (1 stars, last pushed 1mo ago), licensed MIT. It adds 73 tokens to every session and 7,776 once invoked, about $0.0003 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-31.
Other skills, from other repositories
ring:dispatching-workflows
Executing a phased plan in rolling waves where each phase runs as one multi-agent workflow harness: the supervisor elaborates the phase into tasks against the real landed code, launches a workflow that implements with TDD and runs mandatory in-harness review plus an adversarial contrarian pass (and researchers when…
ring:implementing-tasks
Implementing a single planned task (Task N.M.T) end-to-end: selects the right backend agent by language and service type, drives one TDD RED->GREEN turn, then verifies coverage, lint, license headers, runtime, and delivery before handoff. Runs as Gate 0 before ring:reviewing-code. Use to drive ONE task inside an…
ring:managing-dev-cycle
Managing an in-progress development cycle without driving it: status reports phase, epic/gate progress, assertiveness, and elapsed time from current-cycle.json; cancel confirms, marks the cycle cancelled, and writes a partial feedback report. Use when checking the status of, or cancelling, a running dev cycle. Skip…
ring:mapping-feature-relationships
Mapping how features relate and phasing the work: categorizing PRD features, grouping them into domains, charting cross-feature journeys, dependencies, and integration points, and defining the binding Phases that plan.md mirrors one-to-one at Gate 7. Gate 2 of ring:planning-large-features; runs after…
ring:planning-large-features
Planning the 8-gate Large Track pre-dev workflow (research, PRD, feature map, TRD, API contract, data model, dependency map, plan) with per-gate human approval. Use for features 2+ days that add dependencies, data models, multi-service integration, or new architecture. Skip for small features (use…
ring:planning-small-features
Planning the lightweight 4-gate Small Track pre-dev workflow (research, PRD, TRD, plan) with human approval and state tracking at each gate. Use for features under 2 days that reuse existing patterns and add no new dependencies, data models, or services. Skip for larger or complex features — use…