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 ryan-scheinberg/harness --skill plan-to-slicesgit clone --depth 1 https://github.com/ryan-scheinberg/harnessWrote 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/ryan-scheinberg/harness/plan-to-slices)<a href="https://agentmods.dev/skills/ryan-scheinberg/harness/plan-to-slices"><img src="https://agentmods.dev/badge/skills/ryan-scheinberg/harness/plan-to-slices/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/ryan-scheinberg/harness/plan-to-slices"><img src="https://agentmods.dev/badge/skills/ryan-scheinberg/harness/plan-to-slices.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.00039 | $0.00632 |
| Opus 5 | $0.00019 | $0.00316 |
| Sonnet 5 | $0.00008 | $0.00126 |
| Haiku 4.5 | $0.00004 | $0.00063 |
Grade A, and why
plan-to-slices 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 9d 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 — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Read PROJECT_BRIEF.md and produce SLICES.md — an ordered sequence of vertical, demoable slices, each with acceptance criteria a dev can turn into tests
If there's no brief, tell the user to run define-project first. Slicing without a brief just ships the ambiguity forward into dev turns
Process
- Read the brief. Scope, MVP, technical approach, risks
- Explore the codebase if one exists. Module boundaries, test patterns, what's already there. Slices land where seams already exist
- Identify vertical slices. Slice 1 is the thinnest end-to-end path that proves the core approach
- Order by dependency and risk. Uncertain integrations push forward so you learn early. User-facing value before internal polish. Clearly label dependencies so independent slices can run in parallel
- Write acceptance criteria — 3–5 observable outcomes per slice
Slicing rules
- Every slice is vertical. No "set up the database" slice unless the project is pure infra. A horizontal slice can't be demoed, so you lose the feedback that makes slicing valuable
- O11y lives inside the slice that introduces the behavior
- Sizes within an order of magnitude. If one slice is 10x the others, split it; if one is 1/10th, fold it in. Agents complete well-sized vertical slices strongly — don't over-fragment out of caution
Acceptance criteria
Observable and verifiable. "POST /users returns 201 with user ID" — not "user creation works." Scoped to this slice; don't duplicate criteria earlier slices already own
Cover: happy path always; input validation where a new interface appears; edge cases when core to the slice; integration with prior slices from slice 2 onward. The implementer discovers more tests during red-green-refactor — you're defining the boundary of done, not the full test plan
Output — SLICES.md
# [Project Name] — Implementation Slices
> Generated from [PROJECT_BRIEF.md](./PROJECT_BRIEF.md)
## Slice 1: [Verb] [what] *(MVP)*
### What this delivers
One sentence — what a user/system can do once this ships
### Acceptance criteria
1. ...
2. ...
### Implementation notes
Key decisions, constraints, layers touched. For slice 2+: **Depends on**: Slice N
---
(repeat per slice)
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.
- 9d ago First seen · 61 lines · 39 tokens per session scan A f8aca4aa7e42
plan-to-slices is a skill published in the GitHub repository ryan-scheinberg/harness (2 stars, last pushed 1mo ago), licensed MIT. It adds 39 tokens to every session and 632 once invoked, about $0.0002 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
test-first-bugs
Enforces a test-driven bug-fixing workflow. Use when a user reports a bug, failing code, an error, or asks to fix something.
nl-to-constraints
Transforms natural language requirements (user stories, verbal descriptions, business rules) into formal specifications and constraints. Use when converting informal requirements into structured, testable specifications with explicit constraints. Outputs in multiple formats including BDD-style Given-When-Then, JSON…
lsp-refactoring
Intelligent code refactoring using IDE-level tools (rename, find-references, go-to-definition), AST-aware pattern matching, and TDD verification. Use for safe, large-scale refactoring with precision.
tdd-workflow
A test-first development workflow, commonly called TDD, where a failing test is written before the code that should make it pass. The cycle then adds the smallest working change and cleans it up.
user-story
Create user stories with Mike Cohn format and Gherkin acceptance criteria. Use when turning user needs into development-ready work with clear outcomes and testable conditions.
absolute-work
End-to-end, phase-gated SDLC for AI coding agents: relentless design interview → reviewed spec → dependency-graphed task board → safe-wave TDD execution → verification → converge. Handles features, bugs, refactors, greenfield projects, planning breakdowns, and migrations. Triggers on "absolute work", "build this…