prd-to-issues

PRD to Issues

Break a PRD into independently-grabbable Jira-ready work items using vertical slices (tracer bullets).

Write the resulting action items for experienced human developers. Describe desired product behavior, observable outcomes, constraints, and relevant context. Do not write them as step-by-step instructions for an autonomous coding agent.

Modes

Interpret the first argument as the mode. Valid values are default and fast. If no argument is provided, use default.

• default: Start from a full PRD. Locate or request the PRD, decompose it into vertical slices, review the breakdown with the user, then create Jira-ready files.
• fast: Start directly from the user's input. Do not require, request, or synthesize a full PRD. Extract the feature goal, users or actors, expected behavior, constraints, dependencies, and known non-goals from the conversation and any referenced files, then create Jira action items from that context.

In fast mode, query only missing information that materially changes the action items. If non-obvious pieces of information are missing, use the interactive ask_question tool like the write-a-prd skill does. Batch related questions into one round, offer predefined options when useful, and fall back to concise chat questions only if no interactive question tool exists. Do not interview for a complete PRD; resolve only the gaps needed to make the Jira items coherent and actionable. Assume obvious defaults and record them in the ticket only when they matter. Do not invent product rules, validation behavior, error handling, or edge cases just to make the tickets feel complete.

Before the first serious question round in fast mode, read references/fast-mode-intake.md.

Process

1. Gather the source context

In default mode, ask the user for the PRD source if it is not already in context. Prefer a markdown file in the workspace. If needed, ask for the relevant file path or for the PRD text to be pasted.

If the PRD is already available in the workspace, read it directly.

In fast mode, use the user's current request, prior conversation, and any referenced files as the source. Do not ask for a PRD. If the input is too vague to derive stable tickets, ask only for the missing decisions that would affect scope, behavior, dependencies, acceptance criteria, or rollout risk.

Extract settled facts before asking anything new. If the user already gave the actor, desired behavior, rollout constraints, dependencies, or non-goals, carry them forward instead of re-interviewing.

If a potentially important behavior is not specified, do not quietly promote it into a requirement. Either leave it out, ask about it if it would materially change the slices, or record it as an assumption or open question.

2. Explore the codebase

Inspect the repository before drafting slices unless the workspace is empty or clearly unrelated. Use it to verify product terms, existing workflows, system boundaries, and non-obvious constraints that should affect the issue breakdown.

3. Draft vertical slices

Break the source context into tracer bullet issues. In default mode the source context is the PRD. In fast mode it is the user's input plus any answers gathered with ask_question. Each issue is a thin vertical slice that cuts through all relevant integration layers end-to-end, not a horizontal slice of one layer.

Slices may be HITL or AFK. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK where possible.

Before proposing the breakdown, read references/slice-design-checklist.md.

4. Quiz the user

In fast mode, skip this review loop unless the source input leaves multiple plausible slice breakdowns and choosing the wrong one would materially change the Jira files. If the breakdown itself is ambiguous, ask the smallest useful set of questions with ask_question, then continue to file creation.

In default mode, use the full review loop:

Present the proposed breakdown as a numbered list. For each slice, show:

• Title: short descriptive name
• Type: HITL / AFK
• Blocked by: which other slices, if any, must complete first
• User stories covered: which user stories from the PRD this addresses

Ask the user:

• Does the granularity feel right? (too coarse / too fine)
• Are the dependency relationships correct?
• Should any slices be merged or split further?
• Are the correct slices marked as HITL and AFK?

Iterate until the user approves the breakdown.

If the user explicitly says the breakdown is already approved, or the prompt says to assume approval, skip this review loop and move directly to file creation.

5. Create Jira-ready markdown files

For each approved slice, create a markdown file that the user can copy into Jira.

Each file must describe the slice in terms of expected behavior and business or product outcome. Assume the reader is an experienced developer who can determine the implementation details. Avoid decomposing the work into prescriptive layer-by-layer instructions or agent-style execution steps.

If the PRD contains suggested solution details such as APIs, tables, schemas, services, UI components, jobs, or other implementation ideas, treat them as context rather than as instructions to copy into the action item. Only keep such details when they are necessary constraints or dependencies.

Especially in fast mode, prefer fidelity to the source over false completeness. Do not add acceptance criteria for naming rules, deduplication behavior, permission nuances, recovery flows, or other product details unless the source context, repo evidence, or explicit user answers support them.

Before drafting the first issue, read these bundled references:

• In fast mode, also read references/fast-mode-intake.md
• references/slice-design-checklist.md for vertical-slice quality checks and dependency heuristics
• references/ticket-writing-checklist.md for writing style, rewrite tests, and note hygiene
• references/jira-issue-template.md for the exact Jira-compatible raw HTML structure and template rules
• references/example-ticket.md for a fully worked example of the expected tone, scenario framing, and note density

The markdown file should use Jira-compatible raw HTML blocks and must follow the exact structure from references/jira-issue-template.md unless the user explicitly asks for a different format.

Unless the user requests another location, create the files in a action-items/jira-issues/ directory in the workspace.

Create files in dependency order so later files can reference earlier slice titles or filenames in the Blockiert durch field when a real prerequisite slice exists. If a slice can start immediately, omit Blockiert durch instead of writing a placeholder such as Keine.

Use a predictable filename pattern such as 01-short-slice-title.md, 02-next-slice-title.md, and so on.

If the PRD does not already provide the user story in Als ... moechte ich ... damit ... form, derive it from the slice intent.

Acceptance criteria must be expressed as named scenarios inside dashed panels, not as a plain checklist. Acceptance criteria should describe externally verifiable behavior, outcomes, and constraints rather than internal implementation steps. Scenarios must not reference internal code artifacts such as class names, service names, method signatures, enum constants, configuration keys, or database table and column names. When the PRD names such identifiers, translate them into observable behavior or domain-level language before writing the scenario.

Use the rewrite test from references/ticket-writing-checklist.md before finalizing each slice.

Do not create or modify GitHub issues as part of this skill.

The output of this skill is the set of markdown files, not the Jira tickets themselves.

Language: German throughout

All generated ticket content must be written in German. This applies to titles, user stories, scenario names, scenario body text, note labels, and note content. The only exceptions are proper nouns, technical terms with no established German equivalent, and code identifiers. The Gherkin keywords (Angenommen, Wenn, Dann, Und) and the user story frame (Als, möchte ich, damit) are already German in the template; the rest of the ticket must match.