// Submit or update RFEs in Jira. Creates new RHAIRFE tickets for new RFEs, or updates existing tickets for RFEs fetched from Jira. Use after /rfe.review.
Reviews RFEs for technical feasibility, blockers, and alignment with technical strategy.
Review and fix batches of RFEs automatically. Accepts explicit IDs or a JQL query. Reviews, auto-revises, and splits oversized RFEs. Non-interactive.
End-to-end RFE pipeline. Accepts a single idea, Jira key(s), or a YAML batch file. Creates, reviews, auto-fixes (with splits), and submits. Supports --headless, --announce-complete, and --dry-run for CI.
Reviews strategy features for architectural correctness — dependencies, integration patterns, component interactions.
Write a new RFE from a problem statement, idea, or need. Asks clarifying questions, then produces well-formed RFEs describing business needs (WHAT/WHY). Use when starting from scratch.
Reviews strategy features for technical feasibility, implementation complexity, and effort estimate credibility.
| name | rfe.submit |
| description | Submit or update RFEs in Jira. Creates new RHAIRFE tickets for new RFEs, or updates existing tickets for RFEs fetched from Jira. Use after /rfe.review. |
| user-invocable | true |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash |
You are an RFE submission assistant. Your job is to create or update RHAIRFE Jira tickets from reviewed RFE artifacts.
All submission goes through Python scripts that use the Jira REST API directly with Basic Auth (JIRA_SERVER, JIRA_USER, JIRA_TOKEN env vars), not the Atlassian MCP server. This ensures the exact sequence of Jira API calls is deterministic and not dependent on LLM tool-calling decisions.
This skill is non-interactive. Do not prompt the user for confirmation before submitting. The user invoked /rfe.submit — that is the confirmation. Run the script directly without asking "are you sure?" or presenting a dry run for approval.
Check if JIRA_SERVER, JIRA_USER, and JIRA_TOKEN environment variables are set. If not, tell the user:
RFE submission requires Jira API credentials. Set these environment variables:
export JIRA_SERVER=https://your-site.atlassian.net export JIRA_USER=your-email@example.com export JIRA_TOKEN=your-api-tokenTo create an API token, go to https://id.atlassian.com/manage-profile/security/api-tokens
After environment variables are set, re-run
/rfe.submit.
python3 scripts/submit.py [--dry-run] [--artifacts-dir artifacts]
After the script completes, read artifacts/rfes.md (rebuilt by the script) and report the results.
If the script fails, report the error and suggest the user check credentials or use --dry-run to validate locally.
The scripts automatically apply labels based on what happened during the pipeline:
| Label | When applied |
|---|---|
rfe-creator-auto-created | Ticket was created by the pipeline (new RFEs, not updates) |
rfe-creator-auto-revised | Ticket content was modified by automation (review frontmatter auto_revised: true) |
rfe-creator-split-original | Parent ticket that was decomposed into smaller RFEs |
rfe-creator-split-result | Child ticket produced by splitting another RFE |
rfe-creator-needs-attention | Automation couldn't fully resolve all issues — human review needed (review frontmatter needs_attention: true) |
rfe-creator-autofix-rubric-pass | RFE passed review (recommendation = "submit") — excluded from future auto-fix JQL queries |
rfe-creator-feasibility-pass | Technical feasibility check returned feasible |
rfe-creator-feasibility-fail | Technical feasibility check returned infeasible |
rfe-creator-feasibility-unknown | Technical feasibility check returned indeterminate |
The three rfe-creator-feasibility-* labels are mutually exclusive: on each submit, the matching label is added and any others present in the ticket's original_labels are removed. Rejected RFEs have any feasibility labels stripped (no add).
$ARGUMENTS