RFE Creator

Claude Code skills for creating, reviewing, and submitting RFEs to the RHAIRFE Jira project and Initiatives to the RHOAIENG Jira project.

Inspired by the PRD/RFE workflow in ambient, which established the pipeline pattern and multi-perspective review concept.

Quick Start

Works for every registered type: RFEs by default, Initiatives with --type initiative.

# The pipeline skills
/rfe-create     # Write a new work item
/rfe-review     # Review, improve, and auto-revise work items
/rfe-split      # Split an oversized work item into right-sized pieces
/rfe-submit     # Submit new or update existing work items in Jira
/rfe-speedrun   # Full pipeline end-to-end with minimal interaction
/rfe-auto-fix   # Batch review+revise+split pipeline (non-interactive)

# Write a new work item
/rfe-create                                      # An RFE, from a problem statement
/rfe-create --type initiative                    # An Initiative, from an engineering objective

# Improve an existing Jira work item
/rfe-review RHAIRFE-1234                         # Fetch, review, and auto-revise an RFE
/rfe-review --type initiative RHOAIENG-12345     # Fetch, review, and auto-revise an Initiative
/rfe-split RHAIRFE-1234                          # Split an oversized RFE
/rfe-split --type initiative RHOAIENG-12345      # Split an oversized Initiative
/rfe-speedrun RHAIRFE-1234                       # Fetch, review, revise, and update an RFE in one step
/rfe-speedrun --type initiative RHOAIENG-12345   # Fetch, review, revise, and update an Initiative in one step

# Batch operations
/rfe-speedrun --input batch.yaml --headless --dry-run                     # Batch create + review RFEs from YAML
/rfe-speedrun --type initiative --input batch.yaml --headless --dry-run   # Batch create + review Initiatives from YAML
/rfe-speedrun --input batch.yaml --headless --announce-complete           # Print completion marker for CI
/rfe-auto-fix --jql "project = RHAIRFE AND ..."                           # Batch review RFEs from a JQL query
/rfe-auto-fix --type initiative --jql "project = RHOAIENG AND ..."        # Batch review Initiatives from a JQL query
/rfe-auto-fix RHAIRFE-1234 RHAIRFE-5678                                   # Batch review explicit RFE keys
/rfe-auto-fix --type initiative RHOAIENG-12345 RHOAIENG-12346             # Batch review explicit Initiative keys

# Maintenance
/rfe-creator.update-deps   # Force update vendored dependencies

Every skill takes --type <type> (rfe or initiative); without it the type is resolved from the ids you pass (RHAIRFE-* / RFE-* are RFEs, RHOAIENG-* / INIT-* are Initiatives) and defaults to rfe. The dotted names of the original RFE skills (/rfe.create, /rfe.review, /rfe.split, /rfe.submit, /rfe.speedrun, /rfe.auto-fix) remain as compatibility aliases that run the same bodies. See docs/working-with-work-item-types.md for how the type is chosen and what changes with it.

Work Item Types

RFE and Initiative are the two registered work item types:

Type	Jira project	Jira issue type	Flag	Id before submit
RFE	RHAIRFE	Feature Request	--type rfe (the default)	RFE-001
Initiative	RHOAIENG	Initiative	--type initiative	INIT-001

The skill bodies are shared; each type's judgement — template, clarifying questions, review rules, split rules and review dimensions — lives under types/<type>/, next to a data-only descriptor, types/<type>/type.yaml, which python3 scripts/validate_types.py lints and python3 scripts/type_registry.py reads. The field reference is types/README.md, the guide to adding a type is docs/type-provider-guide.md, and the mechanism's development notes (which scripts read the registry, its delivery history) are in docs/work-item-types-development.md.

Install

From a checkout (development, CI, the evals): clone the repository and run the skills with the checkout as the working directory. Nothing else is needed; the first skill run bootstraps the vendored dependencies.

From the Claude Code marketplace: /plugin marketplace add opendatahub-io/skills-registry, then /plugin install rfe-creator@opendatahub-skills, and run the skills from any project directory. The plugin lives under ~/.claude/plugins/cache/; the first thing each skill does in a directory other than the plugin's own root is run the bootstrap's --layout step through its own plugin path, which links the plugin's scripts/ and types/ into the working directory. From then on every command runs exactly as in a checkout. The bootstrap refuses a directory that already has its own scripts/ or types/ rather than mixing them. What the bootstrap writes into your project — the two links, .context/, the pipeline state under tmp/, the vendored .claude/agents/*-scorer.md and .claude/skills/{assess-rfe,assess-initiative,export-rubric}/ — is appended to the repository's .git/info/exclude when the directory is inside a git repository (entries are anchored to the subdirectory when it is not the top level; a tmp/ you already have is left alone and named in a note; it prints the list instead when it cannot write there). Your work items under artifacts/, including the exported artifacts/rfe-rubric.md, are yours to commit or ignore. Permission rules are per project: to run the pipelines headless without prompts, copy the permissions block (the allow list and additionalDirectories) from this repository's .claude/settings.json into your project's .claude/settings.local.json. The plugin ships its two pipeline hooks itself (hooks/hooks.json: the same handlers as the checkout's .claude/settings.json, rooted at the plugin directory), so there is no hooks block to copy. Both are opt-in: export RFE_CREATOR_ENABLE_CONTEXT_HOOK=1 in the session that runs a pipeline. The SessionStart hook re-injects the pipeline state after every auto-compaction; the Stop hook keeps the orchestrator in the dispatch loop while tmp/pipeline-state.yaml is not at DONE, answering a premature end of turn with the same recovery banner (it lets a stuck run go after six unchanged blocks, with a warning). Without the variable both are no-ops, which keeps a stale state file from an aborted run out of unrelated sessions. A checkout that also has the plugin installed runs both copies of each hook (Claude Code does not deduplicate a plugin hook against a settings hook): the recovery banner prints twice, harmlessly.

From the Codex marketplace (codex plugin marketplace add opendatahub-io/skills-registry): Codex installs the repository under ~/.codex/plugins/cache/<marketplace>/rfe-creator/<version>/ and runs the skills from your project (Codex's documentation does not say whether that fetch is complete; the plugin's scripts/ and types/ must be present in it). Codex substitutes no variables in a skill body, so the layout check's path is resolved from the skill file's location, which Codex shows in its skill list; after that the layout is the same. The agent-free skills, $rfe-create, $rfe-submit and $rfe-creator.update-deps, run end to end under Codex. The review, split, auto-fix and speedrun pipelines are written against Claude Code's Agent tool and the scorer agent definitions the bootstrap vendors into .claude/agents/; Codex has its own subagent tools (spawn_agent and friends) and reads agent definitions from its own locations, so those pipelines are unverified under Codex, not known to work. Codex discovers the plugin's hooks/hooks.json too (same file, same shape; Codex exports CLAUDE_PLUGIN_ROOT for compatibility), but skips a plugin's hooks until you review and trust them once with /hooks; whether codex exec runs them is not documented.

Pipeline

The same commands run the pipeline for both types: RFEs by default, Initiatives with --type initiative. Initiative review also runs a strategic alignment assessment (against RHAISTRAT Outcomes) in addition to rubric scoring and technical feasibility.

New work items

/rfe-create → /rfe-review → /rfe-submit
/rfe-create --type initiative → /rfe-review --type initiative → /rfe-submit --type initiative

/rfe-review auto-revises issues it finds (up to 2 cycles). You can also edit artifacts manually between steps.

/rfe-speedrun (/rfe-speedrun --type initiative) runs the full pipeline with reasonable defaults and minimal interaction.

Existing Jira work items

/rfe-review RHAIRFE-1234 → /rfe-submit
/rfe-review --type initiative RHOAIENG-12345 → /rfe-submit --type initiative

Or in one step: /rfe-speedrun RHAIRFE-1234, /rfe-speedrun --type initiative RHOAIENG-12345. Use RHAIRFE-* / RHOAIENG-* keys for existing Jira items and RFE-* / INIT-* ids for new ones.

Batch Operations

Create and review multiple work items from a YAML file:

/rfe-speedrun --headless --dry-run --input batch.yaml
/rfe-speedrun --type initiative --headless --dry-run --input batch.yaml

YAML format:

- prompt: "Users need to verify model signatures at serving time"
  priority: Critical
  labels: [candidate-3.5]
- prompt: "TrustyAI operator crashes on large clusters"
  priority: Major

Review a batch of existing Jira work items:

/rfe-auto-fix --jql "project = RHAIRFE AND status = New" --limit 20
/rfe-auto-fix RHAIRFE-1234 RHAIRFE-5678 RHAIRFE-9012
/rfe-auto-fix --type initiative --jql "project = RHOAIENG AND status = New" --limit 20
/rfe-auto-fix --type initiative RHOAIENG-12345 RHOAIENG-12346

Auto-fix processes in batches (default 5), handles review, revision, splitting, retry, and report generation.

Strategy Pipeline

The strategy skills live in a dedicated repo: fullsend-ai/strat-creator. This plugin no longer ships copies of its reviewer skills.

Pipeline Steps

1. Create: Describe your need. The skill asks clarifying questions and produces RFEs. Supports --headless to skip questions (for batch/CI use).
2. Review: Scores RFEs against the assess-rfe rubric, checks technical feasibility, and auto-revises issues. Accepts Jira keys to review existing RFEs. Supports --headless for non-interactive use.
3. Split: Decompose an oversized RFE into right-sized pieces. Runs review on new RFEs, self-corrects right-sizing (up to 3 cycles), and checks scope coverage. Supports --headless.
4. Auto-fix: Batch pipeline that orchestrates review + revision + split + retry across many RFEs. Accepts explicit IDs or a --jql query. Processes in configurable batches (--batch-size N, default 5). Generates run reports and HTML review reports.
5. Submit: Creates new RHAIRFE tickets or updates existing ones in Jira. Supports --dry-run to validate without writing to Jira. A non-interactive run (a CI job calling scripts/submit.py directly) passes --auto-approve or --hold-interrupted so that an interrupted revision — an existing item whose body changed while its review never recorded auto_revised — is held for a human instead of published; the skill passes neither when invoked interactively, since a user who edited the task file by hand is making a manual revision, and appends --hold-interrupted under --headless (the speedrun's Phase 3 handoff).
6. Speedrun: End-to-end pipeline (create → auto-fix → submit). Supports --input <yaml> for batch creation, --headless for CI, --announce-complete for completion signaling, --dry-run to skip Jira writes, and --batch-size N.

All pipeline steps apply identically to Initiatives (--type initiative). Initiative review additionally runs a strategic alignment check against the parent RHAISTRAT Outcome when one is linked (read from Jira's Parent field at fetch, or from the batch entry's parent_key for a created Initiative).

Editing Between Steps

All artifacts are written to artifacts/. You can edit any file between steps:

• Edit an RFE in artifacts/rfe-tasks/RFE-001.md, then re-run /rfe-review
• Edit an Initiative in artifacts/initiatives/INIT-001.md, then re-run /rfe-review --type initiative
• Re-run /rfe-create (or /rfe-create --type initiative) to start over from scratch

assess-rfe Integration

Skills automatically bootstrap the assess-rfe plugin from GitHub on first use:

• During creation: The rubric is exported to artifacts/rfe-rubric.md and used to guide clarifying questions.
• During review: /rfe-review invokes assess-rfe for rubric scoring.
• Without network access: The skills still work — creation uses built-in questions, review runs only the technical feasibility check.

Run /rfe-creator.update-deps to force-refresh to the latest version.

Architecture Context

For RHOAI work, the technical feasibility and strategy reviews use architecture context from opendatahub-io/architecture-context. This is fetched automatically via sparse checkout on first use.

Jira Integration

Submission uses the Jira REST API directly via Python scripts (not the MCP server). Set these environment variables:

export JIRA_SERVER=https://your-site.atlassian.net
export JIRA_USER=your-email@example.com
export JIRA_TOKEN=your-api-token

The Atlassian MCP server is used for read operations (fetching issues, comments) when available, with a REST API fallback.

Development

Prerequisites

• Python 3.10+ with ruff
• shellcheck

Validate Changes

make lint

This runs skillsaw, ruff (check + format), shellcheck, the work item type lints, and pytest. The type lint needs the dev dependencies (pip install -r requirements-dev.txt).

You can auto-fix some skillsaw issues with make skillsaw-fix.

See AGENTS.md for architecture details and conventions.

Releasing

The version string in .claude-plugin/plugin.json is the update gate for marketplace users: Claude Code re-fetches an installed plugin only when that string changes, so a merged change reaches a marketplace install only once a release bumps it (a checkout and the CI pipelines track branches and are unaffected). A release is a pull request that bumps version in both manifests (.claude-plugin/plugin.json and .codex-plugin/plugin.json; a test keeps them equal) and names what the increment delivers; once it is merged, the entry in opendatahub-io/skills-registry moves to the same number in the same window (scripts/check_versions.py there reads it from this repository's manifest). The rule for the number: a minor bump per user-visible increment, a patch bump when a merged change alters the plugin's behaviour for interactive users, no release for internal-only work. Marketplace users then pick it up with /plugin update rfe-creator@opendatahub-skills.

CI / Headless Mode

All orchestrator skills support --headless for non-interactive use in CI pipelines. Combined with --dry-run, you can validate the full pipeline without Jira writes:

claude -p "/rfe-speedrun --headless --dry-run --input batch.yaml"

Add --announce-complete to print a FULL RUN COMPLETE marker when the pipeline finishes — useful for CI harnesses that need a reliable completion signal:

claude -p "/rfe-speedrun --headless --announce-complete --input batch.yaml"

Flag persistence: parsed arguments are written to tmp/*.yaml config files so they survive context compression during long batch runs.

Fullsend

The repository also ships a Fullsend agent under .fullsend/ that runs the same skills inside an OpenShell sandbox, with Jira reachable read-only through a provider and bootstrap done on the host. See .fullsend/rfe-creator/README.md for prerequisites, environment variables and the fullsend run invocation.