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 retz8/pastiche --skill divide-taskgit clone --depth 1 https://github.com/retz8/pasticheWrote 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/retz8/pastiche/divide-task)<a href="https://agentmods.dev/skills/retz8/pastiche/divide-task"><img src="https://agentmods.dev/badge/skills/retz8/pastiche/divide-task/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/retz8/pastiche/divide-task"><img src="https://agentmods.dev/badge/skills/retz8/pastiche/divide-task.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.00060 | $0.00481 |
| Opus 5.5 | $0.00024 | $0.00192 |
| Sonnet 5.5 | $0.00012 | $0.00096 |
| Haiku 4.5 | $0.00006 | $0.00048 |
Grade A, and why
divide-task 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.
What it actually says
divide-task
Harness conventions: _dev/docs/harness.md. Requires: task spec written, task [WIP], feature branch checked out.
Workflow
-
Derive sub-tasks from the spec. Each sub-task is one implementation step, sized for a single overnight session. Number them
N.1, N.2, …whereNis the task's TODO number. -
Analyze each sub-task:
- Autonomy — purely mechanical, mergeable without human judgment →
autonomous-ready; otherwise →decision-needed. When in doubt,decision-needed. - Dependencies — which sub-tasks must land first. Independent sub-tasks that touch disjoint files/logic may run in parallel; note the execution order.
- Autonomy — purely mechanical, mergeable without human judgment →
-
Review with the user before creating anything: list sub-tasks, labels, and dependency order. Adjust until approved.
-
Create child issues. For each sub-task:
- Title
[N.x] <name>; body: one-paragraph scope + pointer to the spec path; same milestone as the parent; autonomy label. - For blocked ones: create
blocked-by-<blocker-issue-number>labels on demand (gh label create) and apply them. Blockers must be created first so their issue numbers exist. - Link each as a sub-issue of the parent (GitHub sub-issue, or a task-list in the parent body if unavailable).
- Title
-
Mirror into
_dev/TODO.md. Under the task line, add an indented checklist:- [ ] **N.x** <name> (#<issue>). -
Update the parent issue. Add the sub-issue links and the spec reference.
Label lifecycle (for whoever completes a sub-task)
When a blocking sub-task closes, remove its blocked-by-<its-number> label from every issue carrying it, and tick the sub-task checkbox in TODO.md.
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 First seen · 32 lines · 60 tokens per session scan A d2a8ac79bc73
divide-task is a skill published in the GitHub repository retz8/pastiche (4 stars, last pushed 4mo ago), licensed MIT. It adds 60 tokens to every session and 481 once invoked, about $0.0002 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
contribution-workflow
Design or document how new work enters a design system: contribution types, proposal criteria, review stages, sign-off and release. Triggers: contribution process, how should someone contribute, contribution guidelines, adding a new component. Not for audit findings to tickets (backlog-generator).
backlog-generator
Turn existing audit findings into sprint-ready tickets with T-shirt estimates, acceptance criteria, dependencies and phases. Triggers: tickets from audit, backlog from findings, sprint planning from report. Not for the contribution process (contribution-workflow).
forge-sync
Use when checking if .forge/ artifacts are stale after a change to requirements, architecture, or any upstream artifact. Use before running /build, /review, or /ship to confirm the artifact chain is consistent. Use when the user says "is anything out of date" or "what needs to be regenerated".
feedback
Use when implementation, review, security, scalability, or incident work reveals that an upstream .forge/ artifact is wrong, when a contract is missing an operation, when an ADR is being contradicted by a current need, when security recommends architecture changes, or when the user says "we discovered the spec is…
planning-and-task-breakdown
Use when .forge/prd.md and .forge/architecture.md exist and the work needs to be decomposed before implementation, when sizing tasks for a sprint, when mapping dependencies between modules, or when a critical path needs to be identified before parallel work begins.
documentation-hygiene
Use when reviewing documentation quality, when establishing README and changelog standards, when preventing doc rot, when in-code comments duplicate code instead of explaining intent, or when subdirectories of a repo have no documentation entry point.