paulasilvatech RHDH Jira
Execute Red Hat Developer Hub Jira workflows for RHIDP, RHDHPLAN, RHDHBUGS, and RHDHSUPP by routing the user's request to the correct command reference, preferring acli for simple work, and using GraphQL or REST only when the workflow requires bulk reads or custom-field writes.
When to invoke
- "Refine RHIDP-123 and check whether it is ready for sprint planning."
- "Create a RHDHPLAN feature from this context."
- "Assign owners for these RHDH Jira issues."
- "Prepare the RHDH sprint report and release status."
- "Update Jira status, comments, transitions, and parent cascade."
Prerequisites and context
aclimust be onPATHand authenticated with API token auth.- Python 3 is required for helper scripts.
- REST and GraphQL fallback require token setup validated by
scripts/setup.py. - Run
python scripts/setup.pybefore live Jira workflows; usepython scripts/setup.py --jsonwhen structured capability checks are needed. - Do not read token file contents into chat. If REST or GraphQL setup is missing, state the missing capability and continue with
acliwhen possible.
Procedure
- Identify the command from the first word of the user's request, a Jira key, or the requested outcome.
- Load the relevant command reference before running Jira operations.
- Ask only for missing project, issue type, team, or mutation confirmation.
- Prefer read-only discovery before mutation, including duplicate checks for creation workflows.
- Present planned mutations and wait for user confirmation before creating, assigning, transitioning, linking, closing, or commenting.
- Use
--yesonly after the user confirms the exact mutation. - Report data sources, query scope, and any fallback path used.
Command routing
| Command | Use when | Reference |
|---|---|---|
assign |
Recommend or assign owners using expertise and capacity. | references/assign.md |
refine |
Check readiness, duplicates, hierarchy, fields, comments, and sprint fit. | references/refine.md |
plan |
Prepare sprint planning with carryover, velocity, capacity, and ready queue. | references/plan.md |
sprint-report |
Summarize sprint review, demos, completion, and member breakdown. | references/sprint-report.md |
release |
Produce release readiness, feature matrix, dependencies, bugs, and risks. | references/release.md |
to-feature |
Create an RHDHPLAN Feature from context. | references/to-feature.md |
to-epic |
Create an RHIDP Epic from context. | references/to-epic.md |
to-issue |
Create a Story, Task, Bug, Spike, or Sub-task from context. | references/to-issue.md |
update-jira-status |
Update issue status, comments, transitions, and parent cascade. | references/update-jira-status.md |
API preference and projects
Use APIs in this order:
aclifor simple single-issue reads and writes.- GraphQL for bulk reads, expertise profiles, capacity, and refinement checks.
- REST API for custom-field writes or fallback when
aclicannot mutate the field.
Before REST or GraphQL, run python scripts/setup.py --json and confirm the token file is configured.
| Key | Purpose | Issue types |
|---|---|---|
| RHIDP | Engineering work | Epic, Story, Task, Sub-task, Vulnerability |
| RHDHPLAN | Program planning | Feature, Outcome, Feature Request, Sub-task |
| RHDHBUGS | Product defects | Bug, Sub-task |
| RHDHSUPP | Support-engineering interactions | Bug |
Do not query archived RHDHPAI unless the user explicitly asks for historical analysis.
Progressive disclosure and bundled resources
| Resource | Use when |
|---|---|
references/acli-commands.md |
Running unfamiliar acli commands or handling flag behavior. |
references/fields.md |
Looking up fields, custom field IDs, labels, priorities, and components. |
references/workflows.md |
Checking transitions and status exit criteria. |
references/templates.md |
Creating issues. |
references/jql-patterns.md |
Building JQL, finding boards, and sprint queries. |
references/auth.md |
Setting up REST or GraphQL authentication. |
references/rest-api-fallback.md |
Updating custom fields when acli cannot. |
references/graphql-queries.md |
Complex reads and bulk issue queries. |
references/duplicates.md |
Duplicate detection. |
references/grill.md |
Challenging incomplete issue requests before creation. |
references/sizing.md |
T-shirt sizing and story points. |
references/support.md |
Support-engineering workflow details. |
scripts/setup.py |
Verify live Jira, REST, and GraphQL capability. |
scripts/parse_issues.py |
Enrich JSON search results with custom fields, labels, sprint, story points, and team. |
scripts/command-metadata.json |
Command metadata for routing and help. |
assets/examples/ |
Example artifacts. |
assets/templates/ |
Templates consumed by creation workflows. |
Safety and gotchas
- Confirm before mutation: creation, assignment, transition, linking, closing, and commenting require explicit user confirmation.
- Do not expose secrets: never paste Jira tokens, API keys, or
.jira-tokencontents. acli auth statuscan mislead: use a Jira project list smoke test for API token auth.- Issue key flags vary:
viewuses a positional issue key, while many mutations use--key. --fieldsis restrictive on search: use JSON plusscripts/parse_issues.py --enrichfor custom fields, labels, sprint, story points, and team.- Team JQL is not display-name based: use
Team[Team]syntax and the team UUID. - Descriptions can be ADF: do not round-trip Atlassian Document Format through plain
--description. - Search results can truncate silently: use
--limit 200,--count, or pagination for bulk work. - Prefer comments for decision trail: do not bloat issue descriptions with every decision update.
Output template
## RHDH Jira result
**Status:** complete | needs confirmation | blocked
**Command:** assign | refine | plan | sprint-report | release | to-feature | to-epic | to-issue | update-jira-status
**Projects/issues:** <RHIDP/RHDHPLAN/RHDHBUGS/RHDHSUPP keys>
**Data sources:** acli | GraphQL | REST | fallback
### Findings or planned changes
- <finding, recommendation, or mutation>
### Validation
- `python scripts/setup.py`: pass | fail | not run
- Custom-field enrichment: pass | fail | not needed
- User confirmed mutation: yes | no | not applicable
Quality gate
- The request is routed to the correct command reference.
-
python scripts/setup.pyorpython scripts/setup.py --jsonwas run before live Jira access requiring configured capabilities. - GraphQL and REST are used only when their setup is validated or
aclicannot satisfy the workflow. - Mutations are presented and confirmed before execution;
--yesis used only after confirmation. - Tokens, API keys, and
.jira-tokencontents are never exposed. - Sprint or release reports state data sources, query scope, and fallback used.
- The output follows
## Output templateexactly.