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 QBall-Inc/the-bulwark --skill plan-to-tasksgit clone --depth 1 https://github.com/QBall-Inc/the-bulwarkWrote 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/qball-inc/the-bulwark/plan-to-tasks)<a href="https://agentmods.dev/skills/qball-inc/the-bulwark/plan-to-tasks"><img src="https://agentmods.dev/badge/skills/qball-inc/the-bulwark/plan-to-tasks/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/qball-inc/the-bulwark/plan-to-tasks"><img src="https://agentmods.dev/badge/skills/qball-inc/the-bulwark/plan-to-tasks.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00050 | $0.01726 |
| Opus 5 | $0.00025 | $0.00863 |
| Sonnet 5 | $0.00010 | $0.00345 |
| Haiku 4.5 | $0.00005 | $0.00173 |
Grade A, and why
plan-to-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 12d 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 — 160 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan to Tasks
Transform the verbose plan document emitted by plan-creation into an execution-friendly task decomposition: a tasks.yaml workpackage index plus one YAML file per workpackage under plans/<slug>/workpackages/. Supports parent/child plan linkage.
When to Use This Skill
| Trigger | Action |
|---|---|
plan-creation just emitted plan_v{N}.md and execution-friendly task structure is needed |
Run /plan-to-tasks plans/<slug>/plan_v{N}.md |
| Existing plan needs structured task decomposition for downstream task-runner tooling | Run /plan-to-tasks <path> |
| Child plan needs parent linkage (bidirectional) | Run /plan-to-tasks <child-plan-path> and answer "Yes (child plan)" to AskUserQuestion |
DO NOT use for: plans that don't follow plan-creation's YAML-block format; mechanical YAML reformatting (this skill expands per-WP detail using LLM judgment, not just file conversion).
Mandatory Execution Checklist (BINDING)
Every item below is mandatory. No deviations. No substitutions. No skipping. Skipping items violates SC1-SC3 (Skill Compliance Rules in Rules.md).
This skill orchestrates parallel sub-agents to expand per-WP YAML files. You are the orchestrator, NOT the executor. Follow every item in order. Do NOT return to the user until all applicable items are checked.
- Stage 1 — Input Resolution: Argument parsed; plan path validated to exist
- Stage 2 — Parent/Child: AskUserQuestion answered (parent/child + parent path if child + slug confirmation)
- Stage 3 — Read: Plan + all synthesis artifacts in plan directory loaded
- Stage 4 — Extract: WP list extracted from plan YAML blocks (id, name, description, dependencies)
- Stage 5 — Expand:
general-purposesub-agents (Sonnet by default) spawned in parallel batches of ≤5 — you MUST NOT write per-WP YAMLs yourself; sub-agents do the work - Stage 5 — Expand: Sub-agents NOT spawned with
run_in_background: true(SA5) - Stage 6 — Index:
tasks.yamlwritten;parent_planfield added if child - Stage 7 — Parent Update (if child): parent
tasks.yamlappended in-place with reference to this child - Stage 8 — Summary: report written to stdout (N WPs, parent linkage status, next-command hint)
- Source plan_v{N}.md NEVER modified (read-only on the source — AC7)
- Safety gate: if
workpackages/already exists in target dir, AskUserQuestion before overwriting (AC8) - Diagnostics: Diagnostic YAML written to
$PROJECT_DIR/logs/diagnostics/
What ships with it
2 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.
- 12d ago First seen · 160 lines · 50 tokens per session scan A f2ef51f45893
plan-to-tasks is a skill published in the GitHub repository QBall-Inc/the-bulwark (8 stars, last pushed yesterday), licensed MIT. It adds 50 tokens to every session and 1,726 once invoked, about $0.0003 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
spec-author
Use to turn a brief into a structured product SPEC — a set of testable CLAUSES, each exactly one statement, tagged requirement / non-goal / decision — that a human edits and freezes before it feeds the decompose engine. Clarify genuine load-bearing ambiguity first, then draft. Invoke whenever someone describes an app…
product-owner
Use to propose the next product work for a repo — on an idle factory tick (nothing ready to deliver) or when a human asks "what should we build next", for product ideas, a backlog, or PO mode. Consults Memory for product direction, inspects the repo, and files 3–5 high-leverage, anti-slop candidates into the Dispatch…
log
Capture front door. Logs 1..N observations as card files at docs/work/{ID}.md (BUG / DEBT / GAP), gateway-inline — no dispatch. Use when the user says "log this", "track that", "note this down", or types /super-bootstrap:log — and when Claude needs to file its own findings (out-of-scope findings from a review, audit…
triage
Read-only grounding phase for a card — every card''s pickup. /super-bootstrap:triage {ID} dispatches the triage subagent (inherit — the session owner's model) to ground the card cold — premise verify, aim validate, blast collect — and append a Verdict block — ## Verdict — auto-fix · {date} (Fix-shape / Probe-deps /…
pact-init
Initialize PACT governance files in the current project.
drain
Parallel-worktree auto-drain of the board. One /super-bootstrap:drain turn = scan the pipeline sources (specs/plans/backlog, plus the scale module's test queue when present) → keep only admissible items → relation-analyze into a conflict-free wave → confirm with the user → spawn one isolated git worktree + headless…