agentleFS
Sign inStart free
mgiovanimgiovani/cc-arsenal/skills/prd-to-issues/SKILL.md

prd-to-issues

Skill8 starsChanged 48 days agoMITView on GitHub

Turn an approved PRD into tracked issues, one per requirement, with the

  • Installs packages

35 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use prd-to-plan, request-refactor-plan and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • HK-hubSkill

    prd-to-plan

    Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices, saved as a local Markdown file in ./plans/. Use when user wants to break down a PRD, create an implementation plan, plan phases from a PRD, or mentions "tracer bullets".

    Also in 11 projects that use this

  • simo97Skill

    request-refactor-plan

    Use this skill when user wants to create a refactor plan.

    Also in 11 projects that use this

  • ShopifySkill

    triage-issue

    Triage a GitHub issue — classify priority (P0/P1/P2), search for duplicates, and apply labels.

    Also in 13 projects that use this

  • simo97Skill

    design-an-interface

    Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

    Also in 10 projects that use this

  • AnasX7Skill

    scaffold-exercises

    Create exercise directory structures with sections, problems, solutions, and explainers that pass linting. Use when user wants to scaffold exercises, create exercise stubs, or set up a new course section.

    Also in 6 projects that use this

  • AnasX7Skill

    setup-pre-commit

    Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.

    Also in 7 projects that use this

  • +5 more from simo97

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 35 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read the whole PRD first, noting requirement IDs, non-goals, and every [NEEDS CLARIFICATION: ...] tag.

    line 34
  2. Distinctive:

    Before creating anything, check what already exists by searching for the requirement ID:

    line 39
  3. Very specific:

    Create one issue per remaining requirement.

    line 47

“Common” is measured: kept by at least 6 in 10 of the 35 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

PRD to Issues

The seam between a written spec and a tracked backlog. A PRD is one document; work is many issues with an order. This is the translation, and it is mechanical on purpose: the thinking already happened in the PRD.

What you produce

OutputDescription
One issue per requirement IDPRD-FR-001 becomes exactly one issue, with the ID in the title. That ID is the only link back to the spec, and it's what lets a re-run recognize its own earlier output.
Dependencies between issuesTaken from the PRD's own ordering and its stated prerequisites, never invented.
A reportWhat was created, what was skipped, and what blocked.

Method

  1. Read the whole PRD first, noting requirement IDs, non-goals, and every [NEEDS CLARIFICATION: ...] tag.
  2. An unresolved clarification on a requirement means it doesn't get filed. List those separately and say the PRD isn't ready for that requirement yet; a ticket filed on a guess costs more than the one that was never filed.
  3. Before creating anything, check what already exists by searching for the requirement ID:
    bd list --json | grep -o 'PRD-[A-Z]*-[0-9]*'      # or:
gh issue list --search "PRD-FR-001" --state all --json number,title
    Skip an ID that already has an issue and report it as skipped. Never duplicate it, never update it silently.
  4. Create one issue per remaining requirement. Prefer bd, which records dependencies as a graph, and fall back to gh when bd isn't available (brew install beads, then bd init):
    bd create "PRD-FR-001: <requirement title>" -d "$(cat body.md)" -p 2
bd dep add <child-id> <parent-id>                  # child needs parent first
    gh issue create --title "PRD-FR-001: <requirement title>" --body-file body.md
    Carry the requirement text verbatim in the body, along with its Given/When/Then acceptance criteria and a line naming the PRD file. Copying the acceptance criteria unchanged matters, since rewording them is how a spec and its tickets drift apart.
  5. Once every issue exists and has an id, record dependencies. If one points at an issue that was skipped in step 3, report that rather than guessing around it.
  6. Close with a report, tagging each requirement ID as created, skipped because it already existed, or blocked on a clarification.

Rules

RuleWhy
The PRD is the only sourceEvery issue traces to a requirement ID in it. If work looks obviously missing, say so in the report, but don't file it.
Never estimate or prioritize beyond the PRDPriority follows the PRD's own prioritization when it has one, and falls back to the tracker default otherwise.
Never close, reopen, merge, or edit an existing issueThis skill only creates.
Idempotent by requirement IDRunning it twice on the same PRD must create nothing the second time. That's what makes a re-run safe after the PRD is revised, and it rests entirely on the ID being in the title.
Non-goals are not issuesThey're the boundary that keeps the backlog from growing past the spec.
Say what you did not fileA silent skip is indistinguishable from work nobody noticed was missing.

Boundaries

Stops at created issues. Sequencing the work inside one ticket is project-planner; writing or revising the PRD is product-prd. Where a tracker syncs to GitHub itself (bd github sync), let it, and do not create the same issue twice through two paths.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free