rfc-backlog - SKILL.md Agent Skill

name: rfc-backlog description: Turn a technical RFC into an actionable backlog of JIRA stories and tasks, grounded in the codebase the RFC affects. Derives unified, independently-shippable work items (each with a user-story sentence, acceptance criteria, functional and non-functional requirements), presents them for review, then — unless run as a dry run — collects component/epic/label defaults and creates the tickets in JIRA. Use when you have an approved or near-approved RFC and need to plan the implementation as trackable work. argument-hint: "[] [--dry-run]" allowed-tools: Read, Write, Edit, Grep, Glob, Bash, WebFetch, mcpjira-atlassian-hub-localjira_get_all_projects, mcpjira-atlassian-hub-localjira_get_project_components, mcpjira-atlassian-hub-localjira_search, mcpjira-atlassian-hub-localjira_create_issue, mcpjira-atlassian-hub-localjira_link_to_epic, mcpjira-atlassian-hub-localjira_get_issue

RFC → Backlog Skill

Convert a technical RFC into a backlog of JIRA work items. The aim is a backlog an engineer could pick up and start on: each item is a unified, independently-compilable, value-delivering piece of work — not a generic "implement the RFC" placeholder.

This skill is the planning bridge between /rfc-review (judge the design) and implementation (do the work). It reads the RFC, grounds the work in the actual codebase, and — when not a dry run — writes the tickets.

Usage

/rfc-backlog                              # Find the RFC on the current branch, derive a backlog, create tickets
/rfc-backlog docs/rfcs/my-rfc.md          # Use a specific RFC file
/rfc-backlog --dry-run                    # Derive and display the backlog only — never touches JIRA
/rfc-backlog docs/rfcs/my-rfc.md --dry-run

When to invoke this skill

The user asks to break an RFC down into stories/tasks, a backlog, a work plan, or JIRA tickets.
An RFC is approved (or close) and the user wants to plan implementation as trackable work.

Do NOT invoke for reviewing an RFC's design — use /rfc-review for that. This skill assumes the design is settled enough to plan against; if the RFC is still contentious, suggest a review first.

Issue classification rule

Apply this rule to every derived item — it decides the JIRA issue type:

Story — the work results in a pull request (code, build, docs-as-code, tests). It compiles and delivers value, even if only scaffolding for future work.
Task — the work produces no PR: investigation/spikes, "meet with team X", decisions, coordination, manual ops.

Workflow (summary)

The detailed, authoritative steps live in prompt.md. In brief:

Locate & ingest the RFC — argument path, else branch/PR context, else ask.
Map the affected codebase — resolve the directories, libraries, and build targets the RFC names so requirements are concrete.
Derive the backlog — decompose into unified items; classify each as Story or Task; order by dependency.
Present the backlog inline for review (template in assets/templates/backlog-item.md).
Revise — incorporate the user's changes; iterate until they approve the list.
Dry-run gate — if --dry-run, stop here. No prompts, no JIRA writes.
Gather metadata — load config.json defaults, confirm/collect component, epic, labels, project key; save back to config.json.
Create tickets — confirm the count, then create each issue in JIRA, link to the epic, and report the created keys/URLs.

Output rules

Every item is shippable. If an item can't compile or deliver standalone value, split it or fold it into another. State the dependency order explicitly.
Ground requirements in the codebase. Functional requirements name real targets ("produces libhipdnn_xxx.so", "adds hipdnnFooBar() to the public header") — not vague restatements of the RFC.
Stories are fully specified. Each Story has the user-story sentence, acceptance criteria, functional requirements, and non-functional requirements. Do not pad — a Story with no meaningful non-functional requirement says "None" rather than inventing one.
Never write to JIRA without two gates: explicit approval of the list (Step 5) and explicit confirmation of metadata (Step 7). --dry-run short-circuits before either.
Cite the RFC. Each item references the RFC section it derives from, so the reader can trace it back.