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/borhen68/skillengine/planning-and-task-breakdownnpx skills add borhen68/SkillEngine --skill planning-and-task-breakdowngit clone --depth 1 https://github.com/borhen68/SkillEngineWrote 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/borhen68/skillengine/planning-and-task-breakdown)<a href="https://agentmods.dev/skills/borhen68/skillengine/planning-and-task-breakdown"><img src="https://agentmods.dev/badge/skills/borhen68/skillengine/planning-and-task-breakdown.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.00056 | $0.01960 |
| Opus 5 | $0.00028 | $0.00980 |
| Sonnet 5 | $0.00011 | $0.00392 |
| Haiku 4.5 | $0.00006 | $0.00196 |
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 5d 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.
This is a copy
94% identical to planning-and-task-breakdown — 34 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 250 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Planning and Task Breakdown
Overview
The difference between a project that ships on time and one that spirals into endless rework is rarely the complexity of the work — it's the clarity of the plan. Vague tasks breed vague results. A task that says "build auth" will produce a mess. A task that says "implement password validation with bcrypt, rate limiting at 5 attempts per IP, and return 429 on lockout" produces something you can verify.
The planning contract: Every task must have a clear verb, a specific scope, and verifiable acceptance criteria. If you can't describe "done" in one sentence, the task is too big. Break it down until each piece is independently implementable, testable, and reviewable.
Real-world impact: Teams with explicit task breakdowns ship 2x faster and have 50% fewer scope-creep issues. The 10 minutes spent decomposing work saves hours of "wait, I also need to..." mid-implementation pivots.
When to Use
- You have a spec and need to break it into implementable units
- A task feels too large or vague to start
- Work needs to be parallelized across multiple agents or sessions
- You need to communicate scope to a human
- The implementation order isn't obvious
When NOT to use: Single-file changes with obvious scope, or when the spec already contains well-defined tasks.
The Planning Process
Step 1: Enter Plan Mode
Before writing any code, operate in read-only mode:
- Read the spec and relevant codebase sections
- Identify existing patterns and conventions
- Map dependencies between components
- Note risks and unknowns
Do NOT write code during planning. The output is a plan document, not implementation.
Step 2: Identify the Dependency Graph
Map what depends on what:
Database schema
│
├── API models/types
│ │
│ ├── API endpoints
│ │ │
│ │ └── Frontend API client
│ │ │
│ │ └── UI components
│ │
│ └── Validation logic
│
└── Seed data / migrations
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.
- 5d ago First seen · 250 lines · 56 tokens per session scan A 206c21924eee
planning-and-task-breakdown is a skill published in the GitHub repository borhen68/SkillEngine (17 stars, last pushed 2mo ago), licensed MIT. It adds 56 tokens to every session and 1,960 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. It is 94% identical to planning-and-task-breakdown, differing in 34 lines, and is treated as a copy.
Other skills, from other repositories
code-review-and-quality
执行多维度代码审查。用于合并任何变更之前；用于审查自己、其他 agent 或人类编写的代码；用于在代码进入主分支前从多个维度评估代码质量。.
doubt-driven-development
在每个非平凡决策成立前，用全新上下文进行对抗式审查。当正确性比速度更重要、处理不熟悉代码、风险较高（生产、安全敏感逻辑、不可逆操作），或任何自信输出现在验证比之后调试更便宜时使用。.
test-driven-development
用测试驱动开发。用于实现任何逻辑、修复任何 bug，或改变任何行为。用于需要证明代码能工作、收到 bug 报告，或即将修改现有功能时。.
ci-cd-and-automation
自动化 CI/CD pipeline 设置。用于设置或修改构建和部署 pipeline 时；用于需要自动化质量门禁、在 CI 中配置 test runners，或建立部署策略时。.
code-simplification
为清晰度简化代码。用于在不改变行为的前提下重构代码以提升清晰度；用于代码能运行但比应有状态更难阅读、维护或扩展时；用于审查已累积不必要复杂度的代码时。.
context-engineering
优化 agent 上下文设置。当开始新会话、agent 输出质量下降、在任务之间切换，或需要为项目配置规则文件和上下文时使用。.