Skip to content

Commit 7633bb7

Browse files
durandomclaude
durandom
and
claude
committed
feat: add jira-bridge skill for Jira-to-GitHub Issue bridging
Creates GitHub Issues from groomed Jira tickets so fullsend agents can pick them up. Validates agent-readiness score before bridging, maps Jira components to target repos, handles duplicate detection, and links both sides (Jira comment + GitHub body). Three modes: single ticket bridge, dry-run preview, and batch bridging via JQL. Designed to pair with jira-groom as a two-step workflow: groom → bridge → fullsend picks up. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1 parent 92e5592 commit 7633bb7

3 files changed

Lines changed: 297 additions & 0 deletions

File tree

‎skills/jira-bridge/SKILL.md‎

Lines changed: 162 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,162 @@
1+
---
2+
name: jira-bridge
3+
description: |
4+
Bridge groomed Jira tickets to GitHub Issues for fullsend agent processing. Reads a Jira ticket, creates a GitHub Issue in the target repo with fullsend-compatible formatting, and links both sides. Trigger on "bridge ticket", "jira to github", "jira-bridge RHIDP-1234", "send to fullsend", or any Jira key with bridging intent.
5+
compatibility: "acli or jira-cli on PATH. gh CLI authenticated. Target repos must have fullsend installed."
6+
---
7+
8+
<essential_principles>
9+
10+
# Jira-to-GitHub Bridge
11+
12+
Create GitHub Issues from Jira tickets so fullsend agents can pick them up and implement them. This skill is the second step after `jira-groom` — it assumes the ticket is already agent-ready (score 10+ on the readiness rubric).
13+
14+
The skill does three things:
15+
16+
1. Reads the Jira ticket and extracts structured information
17+
2. Creates a GitHub Issue with fullsend-compatible formatting
18+
3. Links both sides (Jira comment with GH link, GH issue body with Jira link)
19+
20+
</essential_principles>
21+
22+
<intake>
23+
24+
## Usage
25+
26+
```
27+
jira-bridge <TICKET-KEY> # Bridge to auto-detected repo
28+
jira-bridge <TICKET-KEY> --repo owner/name # Bridge to specific repo
29+
jira-bridge <TICKET-KEY> --dry-run # Show what would be created, don't file
30+
jira-bridge --batch <JQL> --repo owner/name # Bridge multiple tickets
31+
```
32+
33+
**Wait for response before proceeding.**
34+
35+
</intake>
36+
37+
<routing>
38+
39+
### Routing rules
40+
41+
1. **Ticket key provided**: Fetch Jira ticket → detect target repo → create GitHub Issue → link both sides.
42+
2. **Ticket key + `--repo`**: Skip repo detection, use the specified repo.
43+
3. **Ticket key + `--dry-run`**: Show the GitHub Issue that would be created. No mutations.
44+
4. **`--batch` + JQL + `--repo`**: Bridge multiple tickets to the same repo. Confirm before filing.
45+
5. **No argument**: Ask for a ticket key.
46+
47+
</routing>
48+
49+
## How It Works
50+
51+
### Step 1 — Fetch and validate the Jira ticket
52+
53+
Read the ticket:
54+
55+
```bash
56+
acli jira workitem view <KEY> --json
57+
```
58+
59+
Fall back to `jira issue view <KEY>` if acli is unavailable.
60+
61+
**Validate agent-readiness**: Run a quick score against the `jira-groom` rubric (load `../jira-groom/references/agent-readiness.md`). If score < 7:
62+
63+
> "This ticket scores {score}/12 on agent-readiness. Run `jira-groom <KEY>` first to improve it, or proceed anyway? [groom/proceed/cancel]"
64+
65+
If score is 7-9, note the weak dimensions but proceed.
66+
67+
### Step 2 — Detect target repository
68+
69+
Resolution order:
70+
71+
1. **`--repo` flag**: Use as-is.
72+
2. **`repo:` label on Jira ticket**: Extract repo name from label value. Map to full `owner/name` using the repo mapping in `references/repo-mapping.md`.
73+
3. **Component field**: Map Jira component to a repo using `references/repo-mapping.md`.
74+
4. **Ask the user**: Present known repos from the mapping file, let them pick.
75+
76+
Verify the repo exists and has fullsend installed:
77+
78+
```bash
79+
gh repo view <owner/name> --json name,owner
80+
```
81+
82+
### Step 3 — Check for existing GitHub Issues
83+
84+
Search for duplicates before creating:
85+
86+
```bash
87+
gh issue list --repo <owner/name> --state open --search "<jira key OR summary keywords>"
88+
```
89+
90+
If a match exists:
91+
92+
> "Found existing issue #{number}: '{title}'. Is this the same work? [skip/link/create-anyway]"
93+
94+
- **skip**: Don't create. Optionally add Jira link to existing issue.
95+
- **link**: Link Jira ticket to existing issue (comment on both sides). Done.
96+
- **create-anyway**: Proceed with new issue.
97+
98+
### Step 4 — Create the GitHub Issue
99+
100+
Build the issue using the template in `references/issue-template.md`.
101+
102+
```bash
103+
gh issue create --repo <owner/name> \
104+
--title "<title>" \
105+
--label "fullsend" \
106+
--body "$(cat <<'EOF'
107+
<body>
108+
EOF
109+
)"
110+
```
111+
112+
**Labels**: Always add `fullsend` so the triage agent picks it up. Add additional labels based on ticket type:
113+
114+
| Jira type | GitHub labels |
115+
|-----------|--------------|
116+
| Bug | `fullsend`, `bug` |
117+
| Story/Task | `fullsend`, `enhancement` |
118+
| Vulnerability/CVE | `fullsend`, `security` |
119+
| Investigation (`needs-investigation`) | `fullsend`, `needs-investigation` |
120+
121+
### Step 5 — Link both sides
122+
123+
**On Jira** — add a comment:
124+
125+
```
126+
acli jira workitem comment --key <KEY> --comment "Bridged to GitHub: <issue-url>" --yes
127+
```
128+
129+
**On GitHub** — the Jira link is already in the issue body (from the template).
130+
131+
### Step 6 — Report
132+
133+
```markdown
134+
Bridged: <JIRA-KEY> → <owner/name>#<number>
135+
Jira: https://redhat.atlassian.net/browse/<KEY>
136+
GitHub: <issue-url>
137+
Score: <readiness-score>/12
138+
```
139+
140+
## Reference Files
141+
142+
| File | Load when... |
143+
|------|-------------|
144+
| `references/issue-template.md` | Always — GitHub Issue body template with fullsend-compatible formatting |
145+
| `references/repo-mapping.md` | Repo detection — maps Jira components/labels to GitHub repos |
146+
| `../jira-groom/references/agent-readiness.md` | Validation — agent-readiness scoring before bridge |
147+
148+
## Relationship to Other Skills
149+
150+
- **`jira-groom`**: Prerequisite — grooms tickets to agent-readiness. Bridge validates the score before proceeding.
151+
- **`rhdh-jira`**: Provides Jira infrastructure (acli, fields, workflows). Bridge uses the same tooling but doesn't duplicate it.
152+
- **fullsend triage agent**: Downstream consumer — picks up the GitHub Issue created by this skill.
153+
154+
## Error Handling
155+
156+
| Error | Action |
157+
|-------|--------|
158+
| Jira ticket not found | "Ticket <KEY> not found." |
159+
| Target repo not found | "Repository <owner/name> not found or no access." |
160+
| `gh issue create` fails | Show error. Common cause: missing labels (create them first). |
161+
| No repo detected | Ask user to specify with `--repo`. |
162+
| Ticket already bridged | Check Jira comments for existing "Bridged to GitHub" link. Ask before creating a second issue. |

‎skills/jira-bridge/references/issue-template.md‎

Lines changed: 95 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
# GitHub Issue Template for Fullsend
2+
3+
Template for creating GitHub Issues that fullsend's triage agent can pick up and route to the coder agent.
4+
5+
## Template
6+
7+
```markdown
8+
## Problem
9+
10+
{problem_description}
11+
12+
## Context
13+
14+
{context}
15+
16+
**Jira ticket**: [{jira_key}]({jira_url})
17+
**Type**: {issue_type}
18+
**Priority**: {priority}
19+
20+
## Location
21+
22+
{location_hints}
23+
24+
## Acceptance Criteria
25+
26+
{acceptance_criteria}
27+
28+
## Notes for the Agent
29+
30+
{agent_notes}
31+
32+
---
33+
*Bridged from Jira by `jira-bridge`*
34+
```
35+
36+
## Field Mapping
37+
38+
How to populate each section from the Jira ticket:
39+
40+
| Template section | Jira source | Fallback |
41+
|-----------------|-------------|----------|
42+
| `problem_description` | Description — extract "Problem" or "Current vs Expected" section | Full description if unstructured |
43+
| `context` | Description — extract "Context" section, plus linked issues | Summary + priority as minimal context |
44+
| `jira_key` | Issue key (e.g., RHIDP-1234) | -- |
45+
| `jira_url` | `https://redhat.atlassian.net/browse/{key}` | Use `issues.redhat.com` if JQL source differs |
46+
| `issue_type` | Issue type field (Bug, Story, Task, etc.) | -- |
47+
| `priority` | Priority field | "Undefined" if not set |
48+
| `location_hints` | Description — extract "Location" section, or `repo:` labels, or component field | Omit section if no location info |
49+
| `acceptance_criteria` | Description — extract "Acceptance Criteria" section | Omit section if none |
50+
| `agent_notes` | Description — extract "Notes for the Agent" section, plus any agent-relevant comments | Omit section if none |
51+
52+
## Title Rules
53+
54+
- Use the Jira summary as the GitHub Issue title
55+
- If the Jira summary is too vague, prepend the type: `fix: {summary}`, `feat: {summary}`
56+
- Keep under 80 characters
57+
- Don't include the Jira key in the title (it's in the body)
58+
59+
## Label Mapping
60+
61+
| Condition | Labels to add |
62+
|-----------|--------------|
63+
| Always | `fullsend` |
64+
| Jira type = Bug | `bug` |
65+
| Jira type = Story or Task | `enhancement` |
66+
| Jira type = Vulnerability | `security` |
67+
| Jira label `needs-investigation` | `needs-investigation` |
68+
| Jira priority = Blocker or Critical | `priority/critical` |
69+
70+
## Idempotency
71+
72+
Before creating, check if the issue already exists:
73+
74+
1. Search for `{jira_key}` in open issues (the Jira link in the body makes this searchable)
75+
2. If found, report "Already bridged" with the existing issue URL
76+
3. If the user wants to re-bridge (ticket was updated), close the old issue with a comment and create a new one
77+
78+
## Batch Mode
79+
80+
When bridging multiple tickets (`--batch`):
81+
82+
1. Fetch all matching Jira tickets
83+
2. Score each against agent-readiness
84+
3. Present a summary table:
85+
86+
```markdown
87+
| # | Jira Key | Summary | Score | Target Repo | Action |
88+
|---|----------|---------|-------|-------------|--------|
89+
| 1 | RHIDP-123 | Fix auth redirect | 11/12 | owner/repo | Bridge |
90+
| 2 | RHIDP-456 | Update notification | 6/12 | owner/repo | Needs grooming |
91+
| 3 | RHIDP-789 | Add dark mode | 10/12 | owner/repo | Bridge |
92+
```
93+
94+
4. Ask: "Bridge {n} ready tickets? [y/N]"
95+
5. Create issues sequentially, report each URL

‎skills/jira-bridge/references/repo-mapping.md‎

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
# Repo Mapping
2+
3+
Maps Jira components, labels, and keywords to GitHub repositories. This file is the single source of truth for repo detection when `--repo` is not specified.
4+
5+
## How Detection Works
6+
7+
The bridge tries these sources in order:
8+
9+
1. **`repo:` label** on the Jira ticket (e.g., `repo:backstage-plugins`) → look up in the table below
10+
2. **Component field** → look up in the table below
11+
3. **Keywords in description** → fuzzy match against repo descriptions below
12+
4. **Ask the user** → present the table and let them pick
13+
14+
## RHDH Repositories
15+
16+
<!-- Update this table when repos are added to or removed from fullsend -->
17+
18+
| Jira Component | `repo:` label | GitHub Repo | Description |
19+
|----------------|---------------|-------------|-------------|
20+
| TBD | TBD | TBD | TBD |
21+
22+
**Instructions**: Populate this table with your team's repositories. Each row maps a Jira component or label to a GitHub `owner/name` where fullsend is installed.
23+
24+
Example:
25+
26+
```markdown
27+
| Jira Component | `repo:` label | GitHub Repo | Description |
28+
|----------------|---------------|-------------|-------------|
29+
| backstage-plugins | repo:backstage-plugins | redhat-developer/rhdh-plugins | RHDH plugins monorepo |
30+
| backstage-core | repo:backstage | redhat-developer/rhdh | RHDH core |
31+
| operator | repo:rhdh-operator | redhat-developer/rhdh-operator | RHDH Operator |
32+
```
33+
34+
## Adding a New Repo
35+
36+
When your team adds a new repo to fullsend:
37+
38+
1. Add a row to the table above
39+
2. Ensure the repo has the `fullsend` label created (`gh label create fullsend --repo owner/name`)
40+
3. Verify fullsend is installed on the repo (check GitHub App installations)

0 commit comments

Comments
 (0)