Breaking requirements into manageable issues

A requirements document gives us something to build against. There is still a planning step between that document and picking up the first issue: deciding how to divide the work, what depends on what, and which decisions need attention before implementation can start.

That is where I use the plan-implementation skill. It turns a PRD or clarified plan into a local issue breakdown that I can review before creating anything in a tracker.

Matt Pocock authored the original to-prd and to-issues skills and workflow. I have modified them for how I want to work, including the local planning record and the publication checks described here. Credit for the originals belongs to Matt; you can explore his work in Matt's skills repository. My adaptations are now named write-requirements and plan-implementation. This article covers my version as of its updated date.

Start from the requirements

In Turning planning decisions into requirements, I described preserving the decisions from planning in a PRD with stable requirement and acceptance-criterion IDs. Those references give the issue breakdown something concrete to cover.

This illustrative invocation uses the Claude Code command for my implementation:

/raholsn:plan-implementation docs/prds/2026-08-06-export-retry-prd.md

The skill can also use a clarified plan directly or read a supplied tracker reference when access is available. If the intended source is unclear, it asks which one to use. The newest file is not necessarily the right plan.

The source sets the scope. Splitting a requirement into issues should preserve the agreed behavior and non-goals, including any unresolved decisions. Relevant code can help establish existing contracts and dependencies, but an implementation guess should not become a new product requirement along the way.

Give each issue an observable result

Continuing the illustrative export-retry example, the previous post used this requirement:

Retrying an eligible failed export uses the parameters saved with the original request.

A useful first implementation slice could take one agreed class of eligible failure through the complete retry path: the user requests a retry from the dashboard, the application creates the new attempt with the original parameters, and the resulting export can be checked.

That is a vertical slice. It crosses the layers needed to demonstrate a narrow behavior. Separate tickets for a database change, an endpoint and a button may describe necessary work, but each leaves the intended behavior waiting on the others before we can try it.

The skill prefers a first slice that delivers value or proves the riskiest integration. Sometimes separate enabling work is necessary; the breakdown should explain why it cannot reasonably fit inside a useful slice.

For our example, an issue excerpt might look like this:

I-02: Retry an eligible failed export with its saved parameters

Covers: R1, AC1
Scope: The agreed first failure category, through the dashboard and export flow.
Non-goal: Editing report parameters during retry.

Acceptance criterion:
Given an eligible failed export and a user permitted to retry it,
when the user requests a retry from the dashboard,
the new attempt uses the original saved report parameters.

This is a provisional excerpt, not a complete issue. The earlier example left eligibility and permissions unresolved. Those decisions still need answers before this implementation can be ready.

Separate missing decisions from dependencies

The skill uses two classifications to describe how much human input an issue needs:

Readiness is a separate field. An AFK issue can be blocked by another implementation issue. A HITL decision task can be ready for someone to address immediately.

For the unresolved retry example, I-01 could be a HITL task to establish the eligible failures and permission rules, with the agreed rules recorded as its outcome. I-02 would remain HITL and blocked while those decisions affect its behavior. After they are resolved and its acceptance criteria are updated, it could become AFK. Any remaining technical prerequisites would still determine whether it is ready.

Creating I-01 in a tracker does not resolve the decision. Its dependent issue needs the answer, not just a ticket number.

AFK also does not mean that implementation has been authorized or that the result will be correct. It describes the planning state. I still need to choose the work to start and review what is built.

Check that the requirements survived the split

A collection of plausible issues can still leave part of the PRD uncovered. The skill maps every in-scope requirement and acceptance criterion to stable local issue IDs.

For the small excerpt above, the coverage record could include:

This makes omissions easier to inspect. A proposed deferral stays visible until it is resolved; the assistant should not call the plan complete while silently dropping a requirement.

The dependency check looks for missing references and cycles, as well as the reason each dependency exists. The breakdown should also make clear who owns integration across issues. Two individually sensible tickets can still leave the connection between them unspecified.

Testing, migration, rollout and operational work belong in the breakdown where the source requires them. I want those requirements carried forward without adding a generic set of tickets to every plan.

The issue-planning workflow

These diagrams describe the current skill instructions, not a recorded run.

Open the overview at full size

Review the breakdown locally

The first output is a Markdown file. For this example, it could be:

docs/issues/2026-09-11-export-retry-issues.md

I can choose the path. Otherwise the skill uses an existing issue-planning directory, falling back to docs/issues/. It preserves existing files unless I request a revision, and leaves the source PRD intact.

The saved breakdown includes the source, scope, issue bodies, coverage map and dependencies. The response summarizes the issue count, AFK/HITL split, readiness and remaining gaps. Stable IDs such as I-02 make it possible to discuss and revise an issue without losing its references.

This part needs no company profile or tracker. A local plan is a useful result on its own, including a provisional plan that clearly shows what remains blocked.

Publish the plan when it is ready for the tracker

When I request publication, the skill uses the company profile to resolve the tracker connection and defaults. It validates the target and fields, checks for duplicates and prepares the exact proposal for review.

I can choose Publish, Edit or Cancel. The proposal includes the issue bodies, status and other fields, plus any dependency links or follow-up updates. Approving the local breakdown alone does not publish it.

Published issues need enough context to stand on their own. A local PRD path can record where the requirements came from, but someone reading a tracker ticket may not have that file.

An explicitly approved planning backlog can include blocked issues. Their status should say so. If the tracker cannot represent native blocker links through the available tools, the proposal can use explicit references in the bodies and explain that limitation.

Keep track of partial publication

Publishing several issues introduces another practical problem: a batch can stop halfway through.

The skill creates issues in dependency order and records each confirmed tracker ID and URL against its local ID. If a write fails or returns an uncertain result, it stops and uses read-only lookups to establish what exists.

For example, if two issues were confirmed and the third request timed out, retrying the whole batch could create duplicates. The saved record should show the two confirmed issues, the uncertain third result and the operations still remaining. Resuming requires reconciliation and fresh approval of that remaining work.

That record is part of the value of saving the breakdown before publishing. It connects the plan we reviewed to the items that were actually created.

The skill and the next piece of work

You can find the plan-implementation skill on GitHub.

This completes the planning path from challenging the idea, through requirements, to issues small enough to build and verify. When I choose a ready implementation issue, the work skill can take it forward. Creating the backlog does not start that step automatically.

For me, the useful result is a clear next piece of work, with enough context to understand it and enough honesty about what still needs deciding. The AI helps organize that breakdown; I need to check that the slices make sense and still add up to the outcome we wanted.

Happy coding!