Agent skills for splitting work into issues

Agent skills for splitting work into issues

Recommendation

Mirror Matt Pocock’s to-tickets (mattpocock/skills, MIT) as a Grok Bot skill. It is the strongest recipe found and the most copied one: tracer-bullet vertical slices, explicit “blocked by” edges, a quiz before anything is published, and publishing to GitHub with native sub-issues and blocking links. Add two things from its forks (AFK/HITL typing and a “bigger than a day → split” size check, from AgentiveStack slice), plus the per-unit Verification / Test scenarios fields from Every’s ce-plan. Keep the quiz as the approval gate, because filing issues is an externally visible action.

Next step: 2026-10-08 PM worker reviewer agent orchestration covers what happens after the split: dispatch, implementation and the review gate.

Related: 2026-10-02 Suggestive collaborative agent prompting (grill-me → to-prd, the step before splitting) · 2026-10-02 Overnight and long-running agents (“pre-curated queue”; issue text is data) · 2026-10-08 yetone magpie agent workflow (acceptance criteria that state what was run) · 2026-10-08 Agent lessons ledger lineage (Every / compound-engineering lineage) · 2026-09-28 Opinionated skill packs pstack shape

Verification: 2026-10-08 Agent verification skills — how to prove each slice’s Verification / Test scenarios actually hold (fail-without-fix, not-run record, head-SHA gate). Design gate: 2026-10-08 Design-first feature gate — pre-implementation design sign-off and post-implementation conformance review for new features.

Pinned 2026-10-08 ~23:30 (UTC+8). I read every SKILL.md quoted here from a shallow clone or a raw fetch at its default-branch HEAD. Star counts come from the GitHub API at pin time.

---

1. Ranked top 3

#1 to-tickets: mattpocock/skills

Repo	mattpocock/skills: 280,820★, MIT, last commit b0618bc on 2026-10-08 16:44 (UTC+8)
Files	skills/engineering/to-tickets/SKILL.md · docs page · GitHub tracker doc
Lineage	prd-to-issues → to-issues → merged with to-plan into to-tickets (CHANGELOG #464). to-prd was renamed to-spec.
Creates issues?	Yes. It uses gh issue create in blockers-first order, --parent for sub-issues, and native blocking links (gh issue create --blocked-by, or gh api …/dependencies/blocked_by). A local mode writes .scratch/<feature>/issues/NN-slug.md. GitLab is supported through glab. Linear and Jira are only described in free-form prose recorded at setup.
Interactive?	It does not grill. The grill happens upstream (grill-with-docs → to-spec). The skill does quiz you on the breakdown and won’t publish until you approve it. disable-model-invocation: true, so the user has to invoke it.

What it does. It turns a plan, a spec issue, or the current conversation into tickets. Each ticket is a tracer bullet with blocking edges, and prefactoring goes first. Wide refactors get an expand → migrate batches → contract sequence instead of vertical slices. Chain: grill-with-docs → to-spec → to-tickets → implement → code-review → retro.

Key instructions (SKILL.md)

“Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests): vertical, NOT a horizontal slice of one layer · A completed slice is demoable or verifiable on its own · Each slice is sized to fit in a single fresh context window · Any prefactoring should be done first”

“Present the proposed breakdown as a numbered list … Does the granularity feel right? … Are the blocking edges correct … Iterate until the user approves the breakdown.”

“publish one issue per ticket in dependency order (blockers first) … Use the platform’s native blocking relationship where it has one … Apply the ready-for-agent triage label … Do NOT close or modify any parent issue.”

Output shape (the issue template, verbatim headings):

## Parent
#42

## What to build
End-to-end behaviour from the user's perspective, not layer-by-layer.

## Acceptance criteria
- [ ] Criterion 1
- [ ] Criterion 2

## Blocked by
- #43   (omitted when native blocking edges were set)

The quiz list before publishing looks like 1. Title · Blocked by: None · What it delivers: ….

Pros

• It defends vertical slicing with evidence. The docs page cites a team whose “26-ticket stack sliced by layer” took “roughly twenty agent runs per closed ticket, about three quarters of them rework”.
• Blocking edges are first-class, and it works the frontier (any ticket whose blockers are all done can be picked up).
• It publishes natively: sub-issues, blocked-by, and a ready-for-agent label.
• The docs FAQ is honest about failures: over-decomposition (“twelve tickets for a three-line change”), horizontal slices slipping through, and acceptance criteria that “graded nothing”.
• Plain markdown, MIT, very actively maintained.
• It is the field default. Adam Rackis (1,068 likes): “Matt Pocock’s /grill-me and /to-tickets for bigger tasks”. jpadilla1293 reports 500+ PRs from tickets made this way. GitHub code search returned 1,198 SKILL.md hits for vertical slice + blocked by + sub-issue, and most of them are copies or forks of this skill.

Cons

• No explicit sizing. The only size rule is “fits in a single fresh context window”. There are no points or T-shirt sizes.
• It dropped the older to-issues AFK/HITL typing.
• It depends on /setup-matt-pocock-skills having written an ### Issue tracker block into AGENTS.md or CLAUDE.md.
• Linear is prose-only, with no worked recipe.
• The native flags need gh ≥ 2.94 (release notes, 2026-06-10). The box has gh 2.46.0, so --parent and --blocked-by would fail here.
• Dispatch is manual by design. The docs say the skill “stops at the artifact”.

How to mirror. Make a new workflow skill, e.g. split-to-issues. Copy the vertical-slice rules, the wide-refactor exception, the quiz and both templates. Replace the tracker indirection with Grok Bot tools:

1. cursor-github create_issue in blockers-first order.
2. add_sub_issue under the parent.
3. gh api --method POST repos/O/R/issues/N/dependencies/blocked_by -F issue_id=<db id> for edges. The MCP has no blocked-by tool, and the box’s gh is too old for --blocked-by.
4. Fall back to local files under Projects/<name>/issues/ or .scratch/ when the repo has no tracker.

The quiz doubles as the approval Grok Bot needs before filing anything. Put it next to project-pm (the PM owns “next” and hands off slices) and project-map (it renders the frontier). It runs downstream of a grill step, which Noa doesn’t have yet (see §5).

---

#2 slice: AgentiveStack/skills (a compact to-issues variant with AFK/HITL and sizing)

Repo	AgentiveStack/skills slice/SKILL.md: 72★, MIT, last push 2026-04-29
Creates issues?	Optional. Local docs/contexts/<name>/specs/<feature>-slices.md is the default. Option B is gh issue create in dependency order. No native edges: “Blocked by” is text in the body.
Interactive?	Quiz only, including “Are the correct slices marked AFK vs HITL?” and “Which slices should have tests?”

What it does. It is the Pocock recipe compressed to about 130 lines. It adds slice types, a per-slice testing scope, and an anti-patterns list.

Key instructions

“First slice should be the simplest possible end-to-end path (the tracer bullet) · Subsequent slices add breadth, edge cases, polish”

“AFK — can be implemented by an AI agent without human input. Prefer these. HITL — requires human decision, design review, or external action”

“Too-thick slices: If a slice takes more than a day, it’s probably too thick. Split it. · Testing as a separate slice: Tests are part of each slice · ‘Setup’ slices: Avoid slices that are just ‘set up the infrastructure.’”

Output shape (quiz list, verbatim from the skill):

1. [Title] (AFK)
   Blocked by: None — can start immediately
   Tests: [what to test in this slice]
3. [Title] (HITL — needs design decision on X)
   Blocked by: #1

The issue body has these sections: What to build · Acceptance criteria (behavioural) · Testing scope (what to test / what NOT to test) · Blocked by.

Pros: AFK/HITL maps directly onto “hand to a cheap implementer” vs “keep for Noa”. It has a crude size ceiling (a day) and the clearest anti-pattern list. Small, plain markdown, MIT. Cons: Small project with low activity since April. Blocking edges are text only, and it doesn’t use sub-issues. “Prefer many thin slices” pushes toward the over-decomposition that Pocock now warns against. It reads docs/CONTEXT_MAP.md, a convention specific to that repo. How to mirror: Don’t adopt it as a separate skill. Graft three things into #1: the Type: AFK|HITL line, the “more than a day → split” check, and the “no setup slices / no test slices” anti-patterns. Similar forks with useful extras:

• softspark prd-to-issues (Apache-2.0, 179★, active): “if every issue has blockers, the slicing is wrong”, plus user-story traceability.
• aurelienmaze to-sub-issues (MIT): a shared _context_issue.md so “implementation never has to read the original ticket”, and a ~100k-token size budget.

---

#3 ce-plan: EveryInc/compound-engineering-plugin (best per-unit body; files one issue, not many)

Repo	EveryInc/compound-engineering-plugin: 25,431★, MIT, last commit 2026-10-08 07:40 (UTC+8)
Files	skills/ce-plan/SKILL.md · references/structure.md (§3.3–3.5 units) · references/plan-handoff.md (Create Issue)
Creates issues?	One issue per plan. “Create Issue” runs gh issue create --title "<type>: <title>" --body-file <plan_path>. For Linear it looks for a connector or MCP first, then the API, then a CLI. The units stay inside one markdown or HTML plan, and ce-work executes them.
Interactive?	Heavy. It asks one blocking question at a time. Output is Direct, Chat brief or Durable. A handoff menu follows, plus a document-review pass. ce-brainstorm covers the WHAT upstream.

Key instructions (structure.md)

“Each unit should represent one meaningful change that an implementer could typically land as an atomic commit. Good units are: Focused on one component, behavior, or integration boundary … Ordered by dependency … Avoid: 2-5 minute micro-steps”

“Each unit carries a stable plan-local U-ID … U-IDs survive reordering, splitting, and deletion … existing IDs are never renumbered.”

Per unit: “Goal · Requirements (cite R-IDs) · Dependencies (cite by U-ID) · Files · Approach · Patterns to follow · Test scenarios (happy path / edge / error / integration) · Verification — how an implementer should know the unit is complete, expressed as outcomes”

Output shape:

### U3. Tag filter end-to-end
**Goal:** …   **Requirements:** R2, R5   **Dependencies:** U1
**Files:** src/tags/filter.ts, tests/tags/filter.test.ts
**Test scenarios:**
- Covers AE2. Selecting two tags returns only recipes with both
- Empty tag set returns all recipes
**Verification:** filter round-trips through the URL and survives reload

Pros: It has the richest per-unit contract seen here: test scenarios by category, verification as outcomes, stable IDs. Its sizing guidance is explicit (“Usually 2-4 / 3-6 / 4-8 implementation units” by depth). It finds trackers by capability (connector or MCP before CLI), which fits Grok Bot well. MIT, very active. Cons: It doesn’t split into issues. The issue is the whole plan. Units are “focused on one component”, so they can drift layer-wise, and it doesn’t push vertical slices. It is tightly bound to its harness: dozens of reference files, a model-elevation script, ce-doc-review, and host question tools. How to mirror: Borrow only the unit template: Goal / Requirements / Dependencies / Test scenarios / Verification, plus stable IDs. Use it as the “What to build + Acceptance criteria” body in #1. Its AC are outcome-shaped and can fail before work starts, which fixes the “criteria graded nothing” failure the Pocock FAQ admits to. It sits beside pstack architect (shape first) and figure-it-out Phase B.

---

2. Other candidates considered

Candidate	Output	Creates issues?	Interactive	License · activity	Port	Why not top 3
GitHub Spec Kit /speckit.tasks + github extension taskstoissues	tasks.md phases per user story. - [ ] T012 [P] [US1] Create User model in src/models/user.py. [P] marks parallel tasks, and there is a dependency section.	Yes, via the GitHub MCP issue_write. Titles are T001: desc, deduped by T-ID, and it refuses a non-GitHub remote. The core command is deprecated in favour of the extension.	/clarify upstream. Tasks step isn’t interactive	MIT · 140,650★ · commit 2026-10-08	Medium (CLI scaffolding, hooks)	Tasks are file-level and layer-ish inside a story (model → service → endpoint). That makes too many tiny issues with no AC per issue. Good at story-level independence (“Independent Test” per story).
Taskmaster parse-prd / expand / analyze-complexity	JSON tasks (title, description, details, testStrategy, dependencies, priority). Complexity 1–10 → recommended subtask count.	No. Tasks live in .taskmaster/tasks/tasks.json. Docs mention linking external IDs only.	No grill. Optional research mode	MIT + Commons Clause · 28,185★ · default branch last commit 2026-04-23	Low (own CLI/MCP + API keys)	Only tool with numeric sizing (complexity → expand), but prose PRD in, generic tasks out (ssojet: “Vague PRD in, vague tasks out”). Not vertical.
obra/superpowers writing-plans	docs/superpowers/plans/YYYY-MM-DD-*.md. Tasks with exact Files, Interfaces (Consumes/Produces), TDD steps.	No (markdown)	brainstorming upstream	MIT · 296,660★ · commit 2026-09-26	Easy	An in-ticket plan, not a splitter. Worth stealing: “Split by responsibility, not by technical layer” and the Interfaces block.
Kiro specs tasks.md	requirements.md (EARS + AC) → design.md → tasks.md. Runs independent tasks in waves.	No (IDE task UI)	Requirements- or design-first approval gates	Closed IDE	Low	Good wave/DAG idea, but tied to the Kiro IDE.
snarktank/ai-dev-tasks generate-tasks.md	Parent tasks → wait for “Go” → sub-tasks + Relevant Files	No	”Go” gate	Apache-2.0 · 7,799★ · last push 2025-11-05	Trivial	Checklist for a “junior developer”. No AC, no dependencies, stale.
LSDIPPOLLC linear-planner	Tree: Project → Milestone → Parent → Sub-task. Branch names.	Yes, Linear MCP (save_issue, blockedBy, milestones)	Clarify → present tree → confirm	MIT · 0★ · 2026-04	Easy if Linear MCP is present	Best Linear recipe found: “1-3 days max”, “Every issue must have clear acceptance criteria”. Not vertical. Tiny project.
megrbui linear-issue-breakdown (Cursor skill)	Markdown: requirements summary + parallel PR-sized subtasks + unit tests	Yes, Linear MCP create_issue with parentId after confirmation	Refinement questions	No license · 0★	Easy	Reads Linear project docs first (nice). No license.
jdh313 breakdown	”ADHD-friendly” tasks with ~30min estimates and done criteria	Yes, Linear MCP + Obsidian notes	Coached dialogue. Decompose vs recompose modes	No SPDX license · 0★ · active	Medium	For personal projects, not code. Its recompose mode (reconcile drifted issues) is a good idea.
chriscox project-planner	Proposal doc → tracking issue + one issue per phase	Yes: gh issue create + GraphQL addSubIssue	Triage: proposal / feature / bug	MIT · 11★ · 2026-03	Easy	Phases, not slices. The useful idea is triaging which artifact to make.
SchneiderDaniel issue-cutter (Pi skill)	Sub-issues with ≥2 AC + human validation steps	Yes: gh sub-issues + GraphQL addBlockedBy	Refinement gate + confirm	MIT · 66★ · active	Easy	Cautionary: it claims “vertical slice” but orders “Backend before frontend”, with one layer label per issue (database→backend→frontend) in a forced linear chain.
posit-dev sub-issue	Reference for gh ≥2.94 sub-issue commands	Tooling only	—	MIT	Trivial	Helper, not a splitter. Handy cheat-sheet.
anthropics/claude-code feature-dev · anthropics/skills	7-phase feature workflow (Discovery → Clarifying Questions → Architecture → Implementation)	No	Clarifying-questions phase	Anthropic repos	—	No issue-splitting skill in either repo (grep of both at HEAD).

---

3. Common patterns in the good ones

1. Vertical slices / tracer bullets. Each issue cuts through every layer and can be demoed alone. The first slice is the thinnest end-to-end path; later ones add breadth (Pocock, slice, softspark, aurelienmaze; superpowers says “not by technical layer”). Field framing: “PR-sized vertical slices that ship working functionality end to end” (chrisparaiso).
2. Settle the design first, then split. grill-with-docs/grill-me → to-spec → to-tickets in one context window (“Don’t clear or compact between /to-spec and /to-tickets”). Every’s version is ce-brainstorm → ce-plan. The splitter itself only quizzes.
3. Quiz before publish. The breakdown is shown as a numbered list. The user is asked about granularity, edges, and merge/split, and nothing is filed until approval. This is also the right gate for Grok Bot’s external-action rule.
4. Explicit dependency edges, published blockers-first so later issues can cite real numbers. Use native sub-issues + blocked-by where the tracker has them, and work the frontier. Warning sign: “if every issue has blockers, the slicing is wrong” (softspark).
5. Prefactor first; expand–contract for wide refactors (Pocock). This is the only principled exception to vertical slicing found.
6. Issue template: Parent · What to build (behaviour, not layers) · Acceptance criteria checklist · Blocked by. Optional extras: Type AFK/HITL, Testing scope, User stories covered, Context to load. No file paths or line numbers (“they go stale fast”), except decision-rich snippets from a prototype.
7. Sizing is weak everywhere. Rules in use: “one fresh context window” (Pocock), “~100k tokens” (aurelienmaze), “more than a day → split” (slice), “1-3 days” (Linear planner), “atomic commit / 2-4…4-8 units” (ce-plan), and complexity 1–10 → subtask count (Taskmaster). Nobody writes T-shirt sizes onto the issue.
8. Testable AC. Pocock’s FAQ says to name, for each criterion, “the observation that would show it false, and confirm it fails at the commit the implementer starts from”. ce-plan’s outcome-shaped Verification + Test scenarios is the most concrete version of this.
9. Failure modes to design against:
   • over-decomposition (“twelve tickets for a three-line change”)
   • horizontal slices slipping through
   • backlog explosion: one operator had Claude mass-close 500+ self-created issues (WindAddict)
   • different tools disagreeing on granularity: “One wrote 13 tasks for it, another 29, one wrote none” (SSShken)
   • spec compression losing detail: “write-a-prd is knowledge compression and thus some important details occasionally get lost” (HN, Bossie)

---

4. Overlap with Noa’s existing skills

Noa skill	Overlap	Gap it leaves
pstack figure-it-out (Phase B)	“Decompose into atomic, independently-landable units. Sequence riskiest-unknown-first. Scaffold and verification come before features.” That’s the same instinct as prefactor-first.	The units become todos inside one run, not tracker issues. No AC template, no blocked-by edges, no quiz (by design it proceeds with “a multi-hour run earns one checkpoint”).
pstack architect / arena	Shape before code: types, module map, two candidate designs.	Design artifact, not a work breakdown. Natural upstream of slicing for one-way-door designs.
project-pm / pm-fold	The PM owns scope, decided design, “next”, and open questions in Projects/<name>.md. Fold promotes ideas.	No step turns “next” into issues. The split skill would be the PM’s outbound hand-off.
project-map	Draws parts, stuck waits, and the next step from code + issues/PRs.	It reads issues and doesn’t create them. It could render the frontier after a split.
new-design-handoff / critique	”Acceptance criteria (testable) + non-goals” for UI work.	Single surface, no splitting. Its AC wording is reusable for UI slices.
lessons-ledger	Different stage (post-hoc review).	Could add a rule like “horizontal slice caused rework” when it happens.
2026-10-02 Suggestive collaborative agent prompting	Already recommends grill-me → /to-prd and BLUEPRINT’s “smallest vertical slice”.	Noa has no grill skill installed. The upstream half is still a paste-prompt.

---

5. Gaps

• No grill/spec step in Noa’s skills. to-tickets assumes grill-with-docs → to-spec ran first in the same context. A mirror needs either a light grill phase or a “source must be a settled spec/issue” precondition.
• Box tooling: gh is 2.46.0, below the 2.94 needed for --parent / --blocked-by. cursor-github has create_issue + add_sub_issue but no blocked-by tool, so edges need gh api …/dependencies/blocked_by (REST, database ids) or a GraphQL addBlockedBy. Not tested live here, because filing test issues is an external action.
• Linear: no Linear connector appears in this workspace’s tool list. Every Linear recipe found assumes mcp__linear-server__*.
• Sizing: no candidate puts a size estimate on each issue in a principled way. Matt’s context-window rule is the most agent-relevant. Taskmaster’s complexity score is the only numeric one, and it isn’t vertical.
• Reddit: Exa site:reddit.com returned nothing usable (same as the 10-02 digest). HN had only comment-level mentions.
• Not checked: Amp/Codex-specific prompts for splitting (none surfaced in search). Cursor rules beyond the one exported Cursor skill above.
• The Curated External Skills note doesn’t list mattpocock/skills, superpowers or compound-engineering yet. That’s left for the owner of that lane (this note writes to Digests only).

---

6. Sources

Repos / files (read at HEAD, 2026-10-08)

• mattpocock/skills: to-tickets SKILL.md · docs/engineering/to-tickets.md · issue-tracker-github.md · wayfinder · CHANGELOG · old prd-to-issues @ fb3629d · issues #513, #554, #946
• EveryInc/compound-engineering-plugin ce-plan
• obra/superpowers writing-plans
• github/spec-kit tasks.md · taskstoissues.md · extensions/github
• eyaltoledano/claude-task-master src/prompts · LICENSE
• anthropics/claude-code plugins · anthropics/skills · hesreallyhim/awesome-claude-code (no splitting entry beyond workflow packs)
• Forks/others: AgentiveStack slice · softspark prd-to-issues · aurelienmaze to-sub-issues · LSDIPPOLLC linear-planner · megrbui linear-issue-breakdown · jdh313 breakdown · chriscox project-planner · SchneiderDaniel issue-cutter · posit-dev sub-issue · snarktank/ai-dev-tasks
• gh v2.94.0 release notes (sub-issues, --blocked-by)

Docs / blogs (Exa)

• Kiro specs · FAUN: Spec Kit vs Taskmaster · ssojet: 9 PRD/spec templates · Spillwave: GSD vs Spec Kit vs OpenSpec vs Taskmaster · kexizeroing: Matt Pocock workflow notes · yudesk: to-PRD + to-Issues · DeepWiki: breaking PRDs into vertical slices

X (dates UTC+8)

• AdamRackis: grill-me + to-tickets (09-13) · jpadilla1293: 500+ PRs from tickets (09-27) · TheCraigHewitt: grill-me → PRD → to-issues (10-08) · chrisparaiso: PR-sized vertical slices (10-06) · oprearocks: to-tickets · kkurilyak: $to-issues in Codex · SSShken: 13 vs 29 vs 0 tasks · WindAddict: 500 self-made issues mass-closed · shao__meng: Pragmatic Engineer × Pocock (spec→tickets, wayfinder)

HN

• Bossie: Linear blockedBy + Ready-for-Agent status · fowlie: grill-with-docs → to-prd → to-issue → tdd