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/sudokar/openspec-plus/openspec-plus-tasksnpx skills add sudokar/openspec-plus --skill openspec-plus-tasksgit clone --depth 1 https://github.com/sudokar/openspec-plusWrote 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/sudokar/openspec-plus/openspec-plus-tasks)<a href="https://agentmods.dev/skills/sudokar/openspec-plus/openspec-plus-tasks"><img src="https://agentmods.dev/badge/skills/sudokar/openspec-plus/openspec-plus-tasks.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 | $0.00084 | $0.03037 |
| Opus 5 | $0.00042 | $0.01519 |
| Sonnet 5 | $0.00017 | $0.00607 |
| Haiku 4.5 | $0.00008 | $0.00304 |
Grade A, and why
openspec-plus-tasks 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 today.
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 — 248 lines — stays where its author put it; the contents beside it link to each section on GitHub.
OpenSpec Plus Tasks
Mission
Enrich OpenSpec's tasks.md generation with vertical-slice discipline and subagent review. Format is owned by the schema template (resolved in Phase 0) — this skill provides thinking discipline before the file is written and a subagent review after.
Two anchors that shape every task group:
- Each task group = a vertical slice — end-to-end through whatever layers are needed, not horizontal layer-by-layer
- Each task group completion = a testable outcome — after the last task in a group is checked, the user can verify something works
This skill is RIGID. NEVER write tasks.md before completing Phase 1 vertical-slice discovery. NEVER skip the subagent review. Reading source code, writing implementation code, running TDD, including exact commit messages, or restructuring the template format is a skill violation.
Red flags — STOP, you are about to violate this skill:
- "I'll group by layer (DB / API / UI) to keep similar tech together"
- "This task group is preparatory work, it doesn't need to be testable on its own"
- "I'll add a 'Files' or 'Dependencies' section to the tasks.md"
- "I should peek at the code to figure out what files to touch"
- "Let me put exact code or shell commands in the task description"
- "The reviewer subagent isn't needed, the tasks look fine to me"
- "Reviewer flagged minor issues, I'll re-dispatch after fixing to confirm"
- "I'll add commit instructions per task"
- "Let me write a TDD-ordered set of sub-tasks"
Inputs
- Proposal — intent, scope boundaries, non-goals
- Specs — requirements with Gherkin scenarios
- Design — architecture decisions, file structure, integration points
- Existing tasks.md files in
openspec/changes/— for naming convention only - NEVER read source code — design phase already grounded patterns
If the design is missing detail you need to slice the work, the design is incomplete. Surface the gap to the user — do not paper over with code reading.
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.
- today Changed · -1 lines 53c18eb58e0c
- 4d ago First seen · 249 lines · 84 tokens per session scan A 5f40878818d7
openspec-plus-tasks is a skill published in the GitHub repository sudokar/openspec-plus (166 stars, last pushed today), licensed MIT. It adds 84 tokens to every session and 3,037 once invoked, about $0.0004 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-30.
Other skills, from other repositories
test-assess
Test agentready assess against real GitHub repositories to validate assessor changes. Selects repos relevant to the change being tested, clones them to a temp directory, runs the local checkout's assessor, reports results and output locations, then cleans up. Use when testing a new or modified assessor, verifying a…
implement-type-annotations
Add comprehensive type hints to Python/TypeScript code to improve IDE support, catch errors early, and enable better AI code understanding.
setup-claude-md
Create comprehensive CLAUDE.md files with tech stack, standard commands, repository structure, and boundaries to optimize repositories for AI-assisted development.
pr-review
Review a GitHub pull request and post one formal review — advance the existing discussion and give precision-first, high-signal feedback. Judgement on the diff, not a build gate — CI validates that it builds, and a targeted probe is allowed as evidence. Use when asked to review a PR or on a cron PR scan.
acceptance-orchestrator-v2
Acceptance Orchestrator workflow skill. Use this skill when the user needs a coding task should be driven end-to-end from issue intake through implementation, review, deployment, and acceptance verification with minimal human re-intervention and the operator should preserve the upstream workflow, copied support files…
deep-debugging
Systematic debugging protocol for bugs that resist quick fixes. Use bisection, hypothesis trees, and scientific method when a bug isn't obvious from the stack trace. Goes beyond bugfix-quick for production-grade root cause analysis.