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 shennawardana23/skillme --skill planning-and-task-breakdowngit clone --depth 1 https://github.com/shennawardana23/skillmeWrote 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/shennawardana23/skillme/planning-and-task-breakdown)<a href="https://agentmods.dev/skills/shennawardana23/skillme/planning-and-task-breakdown"><img src="https://agentmods.dev/badge/skills/shennawardana23/skillme/planning-and-task-breakdown/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/shennawardana23/skillme/planning-and-task-breakdown"><img src="https://agentmods.dev/badge/skills/shennawardana23/skillme/planning-and-task-breakdown.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.00071 | $0.01677 |
| Opus 5 | $0.00036 | $0.00839 |
| Sonnet 5 | $0.00014 | $0.00335 |
| Haiku 4.5 | $0.00007 | $0.00168 |
Grade A, and why
planning-and-task-breakdown 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 8d 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 — 181 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Planning and Task Breakdown
Decompose an already-scoped body of work into small, verifiable tasks with explicit acceptance criteria, ordered by what depends on what. Good task breakdown is the difference between an agent that completes work reliably and one that produces a tangled mess mid-feature — every task should be small enough to implement, test, and verify in one focused session.
Use skills/planning/ instead for a single lightweight plan document for
one request. Use this skill once a spec or clear requirement already
exists and the job is turning it into an ordered list of implementable
tasks — this is the mechanism skills/spec-driven-development/'s Plan and
Tasks phases delegate to.
When to use
A spec exists and needs to become implementable units; a task feels too large or vague to start; work needs to be parallelized across multiple agents or sessions; the implementation order isn't obvious.
Skip it for: a single-file change with obvious scope, or a spec that already contains well-defined tasks.
The process
1. Plan in read-only mode first
Read the spec and the relevant codebase sections, identify existing patterns and conventions, map dependencies between components, note risks and unknowns — without writing any code yet. The output of this phase is a plan document, not implementation.
2. Map the dependency graph
Database schema
│
├── API models/types
│ ├── API endpoints ── Frontend API client ── UI components
│ └── Validation logic
└── Seed data / migrations
Implementation order follows this graph bottom-up — build foundations before what depends on them, not in whatever order feels most interesting.
3. Slice vertically, not horizontally
Horizontal (avoid): "build all of the schema, then all of the API, then all of the UI, then connect it" — nothing works end-to-end until the very last task lands.
Vertical (prefer): "user can create an account" (schema + API + UI for registration), "user can log in," "user can create a task" — each task delivers one complete, testable path through the whole stack.
What ships with it
1 file 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.
- 8d ago First seen · 181 lines · 71 tokens per session scan A 2a8148f273f5
planning-and-task-breakdown is a skill published in the GitHub repository shennawardana23/skillme (2 stars, last pushed 14d ago), licensed Apache-2.0. It adds 71 tokens to every session and 1,677 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-09-03.
Other skills, from other repositories
autonomous-workflow
The phase-based machinery (0–7) behind the aw dispatcher — task intake through tested PR delivery in an isolated Git worktree, with optional companion skills for planning, quality gates, TDD, UX, code quality, docs, and CI verification. Companions skip silently if not installed. NOT the entry point and not…
batch-linear-tickets
Batch-analyze and resolve multiple Linear tickets — bug fixes and feature work. For each ticket: classifies as bug or feature (auto from Linear labels, or via the --type flag), dispatches the appropriate per-ticket analysis (linear-ticket-investigator + rca-investigator for bugs, just linear-ticket-investigator for…
aw
Ships autonomous, end-to-end coding work — implement a feature or fix, all the way to a tested draft PR — from a single opt-in entry point. Detects the task tier (Micro / Lite / Full) and routes: Micro/Lite run single-pass in this context; Full hands off to the aw-planner → aw-executor agents. Use when the user asks…
openspec-implementation
A workflow for implementing an approved technical specification one task at a time. It reads the proposal, makes the changes, runs tests, and validates the result.
codely-plan-create-github
Create a plan for the specified task and store it as GitHub issues in the repository of the current working directory. Given the URL of a GitHub issue, it turns that issue into the parent "plan" issue (Goal, Context and a checklist of phases) and creates one child issue per phase, linking every phase as a native…
codely-plan_phase-implement-github
Implement one phase of a plan stored as GitHub issues in the repository of the current working directory. Given the URL of a phase (child) issue it implements that phase; given the parent plan issue it finds and implements the current phase. Only implements a single phase per invocation, then stops for user review. It…