feat: jira - fullsend skill

.claude-plugin/marketplace.json

@@ -5,14 +5,14 @@
   },
   "metadata": {
     "description": "Orchestrator skill for RHDH plugin development - onboard, update, and maintain plugins in the Extensions Catalog",
-    "version": "0.3.1"
+    "version": "0.4.0"
   },
   "plugins": [
     {
       "name": "rhdh",
       "source": "./",
       "description": "Skills for RHDH plugin lifecycle management",
-      "version": "0.3.1",
+      "version": "0.4.0",
       "strict": true
     }
   ]

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "rhdh",
   "description": "All-in-one toolkit for Red Hat Developer Hub (RHDH). Covers plugin development, overlay management, environment setup, version compatibility, CI/CD, and RHDH ecosystem navigation.",
-  "version": "0.3.1",
+  "version": "0.4.0",
   "author": {
     "name": "RHDH Store Manager"
   },

pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "rhdh-skill"
-version = "0.3.1"
+version = "0.4.0"
 description = "Claude Code skill for RHDH plugin development"
 readme = "README.md"
 license = "Apache-2.0"

skills/fullsend/README.md

@@ -0,0 +1,36 @@
+# fullsend
+
+Routing skill for the fullsend agent platform. Groom Jira tickets for
+agent-readiness, then bridge them to GitHub Issues for fullsend processing.
+
+## Commands
+
+| Command | Description |
+|---------|-------------|
+| `groom <KEY>` | Score and improve a Jira ticket against a 6-dimension agent-readiness rubric |
+| `bridge <KEY>` | Create a GitHub Issue from a groomed ticket, linking both sides |
+
+## Attribution
+
+The grooming workflow and agent-readiness rubric are derived from
+[platform-frontend-ai-dev](https://github.com/redhat-developer/platform-frontend-ai-dev),
+the autonomous dev bot built by the ConsoleDot Platform Experience team.
+
+Key inspirations:
+
+- **`prompts/groom.md`** — conversational grooming prompt that walks users
+  through what the bot needs to pick up a ticket. Our 6-dimension scoring
+  rubric formalizes the same checks Rehor performs implicitly.
+- **`needs-investigation` workflow** — Rehor treats investigation tickets as
+  fundamentally different from implementation tickets (report findings, don't
+  code). Our groom workflow adopts this distinction.
+- **`project-repos.json`** — Rehor's repo-to-persona mapping. Our
+  `references/repo-mapping.md` follows the same pattern but uses the existing
+  `rhdh-jira` component catalog as the source of truth.
+- **Primary label routing** — Rehor uses team-specific labels (`hcc-ai-framework`,
+  `hcc-ai-ui`) for triage routing. Our bridge uses the `fullsend` label for the
+  same purpose.
+
+The key architectural difference: Rehor is a monolith (groom + execute + triage
+in one agent), while fullsend separates preparation (this skill) from execution
+(the fullsend agent on GitHub).

skills/fullsend/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: fullsend
+description: |
+  Work with fullsend agent platform: groom Jira tickets for agent-readiness,
+  bridge them to GitHub Issues for fullsend processing. Trigger on "fullsend",
+  "groom ticket", "bridge ticket", "send to fullsend", or any Jira key with
+  agent/fullsend intent.
+---
+
+# fullsend
+
+Support the team's fullsend workflow: prepare work in Jira, feed it to
+fullsend agents via GitHub Issues.
+
+Invoke with `/fullsend <command>`. Default (no args): show the command table below.
+
+## Commands
+
+| Command | Description | Reference |
+|---------|-------------|-----------|
+| `groom <KEY>` | Score + improve Jira ticket for agent-readiness | `references/groom.md` |
+| `bridge <KEY>` | Create GitHub Issue from groomed ticket | `references/bridge.md` |
+
+### Modes
+
+- `groom <KEY>` — interactive grooming session
+- `groom <KEY> --quick` — score only, no conversation
+- `groom --batch <JQL>` — score multiple tickets
+- `bridge <KEY>` — bridge single ticket to GitHub
+- `bridge <KEY> --dry-run` — preview without mutation
+- `bridge <KEY> --repo owner/name` — explicit target repo
+
+## Routing
+
+1. No argument → show the command table above.
+2. First word is `groom` → read `references/groom.md` and follow it.
+3. First word is `bridge` → read `references/bridge.md` and follow it.
+4. Bare Jira key (e.g. `RHCLOUD-1234`) without command → ask: "Groom or bridge?"
+
+## Reference Index
+
+| File | Load when... |
+|------|-------------|
+| `references/groom.md` | `groom` command |
+| `references/bridge.md` | `bridge` command |
+| `references/repo-mapping.md` | `bridge` needs repo detection |
+
+## Shared Context
+
+This skill builds on existing rhdh-skill references — it does not duplicate them:
+
+- **Repo catalog**: `../rhdh/references/rhdh-repos.md` (full ecosystem map)
+- **Jira components**: `../rhdh-jira/references/fields.md` (component catalog, labels, priorities)
+- **JQL patterns**: `../rhdh-jira/references/jql-patterns.md` (queries, boards, sprints)
+- **Jira CLI**: `../rhdh-jira/references/acli-commands.md` (acli usage)
+
+## Relationship to Other Skills
+
+- **`rhdh-jira`**: Provides Jira CLI tooling (`acli`, `jira`), workflow fields, and JQL patterns. fullsend uses the same tooling but checks agent-readiness, not sprint-readiness.
+- **`rhdh-jira refine`**: Complementary — run `refine` for process compliance, `fullsend groom` for agent readiness.
+- **`rhdh`**: Provides the repo map and GitHub reference. fullsend's `bridge` uses it for repo detection.

skills/fullsend/references/bridge.md

@@ -0,0 +1,223 @@
+# Bridge: Jira-to-GitHub Issue Workflow
+
+Create GitHub Issues from Jira tickets so fullsend agents can pick them up and
+implement them. This is the second step after `groom` — it assumes the ticket
+is already agent-ready (score 10+ on the readiness rubric).
+
+Three things happen:
+
+1. Read the Jira ticket and extract structured information
+2. Create a GitHub Issue with fullsend-compatible formatting
+3. Link both sides (Jira comment with GH link, GH issue body with Jira link)
+
+## Usage
+
+```
+/fullsend bridge <KEY>                    # Bridge to auto-detected repo
+/fullsend bridge <KEY> --repo owner/name  # Bridge to specific repo
+/fullsend bridge <KEY> --dry-run          # Preview, no mutations
+/fullsend bridge --batch <JQL> --repo owner/name  # Bridge multiple tickets
+```
+
+## Workflow
+
+### Step 1 — Fetch and Validate the Jira Ticket
+
+```bash
+acli jira workitem view <KEY> --json
+```
+
+Fall back to `jira issue view <KEY>` if acli is unavailable.
+
+**Validate agent-readiness**: Run a quick score against the groom rubric
+(see `references/groom.md`). If score < 7:
+
+> "This ticket scores {score}/12 on agent-readiness. Run `/fullsend groom <KEY>`
+> first to improve it, or proceed anyway? [groom/proceed/cancel]"
+
+If score is 7–9, note the weak dimensions but proceed.
+
+### Step 2 — Detect Target Repository
+
+Resolution order:
+
+1. **`--repo` flag**: Use as-is.
+2. **`repo:` label on Jira ticket**: Extract repo name, map to full `owner/name`
+   using `references/repo-mapping.md`.
+3. **Component field**: Map Jira component to a repo using `references/repo-mapping.md`.
+4. **Ask the user**: Present known repos from the mapping file, let them pick.
+
+Verify the repo exists and the user has access:
+
+```bash
+gh repo view <owner/name> --json name,owner
+```
+
+### Step 3 — Check for Existing GitHub Issues
+
+Search for duplicates before creating:
+
+```bash
+gh issue list --repo <owner/name> --state open --search "<jira key OR summary keywords>"
+```
+
+If a match exists:
+
+> "Found existing issue #N: 'title'. Is this the same work? [skip/link/create-anyway]"
+
+- **skip**: Don't create. Optionally add Jira link to existing issue.
+- **link**: Link Jira ticket to existing issue (comment on both sides). Done.
+- **create-anyway**: Proceed with new issue.
+
+Also check Jira comments for existing "Bridged to GitHub" links. If found, ask
+before creating a second issue.
+
+### Step 4 — Create the GitHub Issue
+
+Build the issue using the template below.
+
+```bash
+gh issue create --repo <owner/name> \
+  --title "<title>" \
+  --label "fullsend" \
+  --body "$(cat <<'EOF'
+<body>
+EOF
+)"
+```
+
+**Labels**: Always add `fullsend`. Add additional labels based on ticket type:
+
+| Jira type | GitHub labels |
+|-----------|--------------|
+| Bug | `fullsend`, `bug` |
+| Story/Task | `fullsend`, `enhancement` |
+| Vulnerability/CVE | `fullsend`, `security` |
+| Investigation (`needs-investigation`) | `fullsend`, `needs-investigation` |
+
+### Step 5 — Link Both Sides
+
+**On Jira** — add a comment:
+
+```bash
+acli jira workitem comment --key <KEY> --comment "Bridged to GitHub: <issue-url>" --yes
+```
+
+**On GitHub** — the Jira link is already in the issue body (from the template).
+
+### Step 6 — Report
+
+```markdown
+Bridged: <JIRA-KEY> → <owner/name>#<number>
+  Jira:   https://redhat.atlassian.net/browse/<KEY>
+  GitHub: <issue-url>
+  Score:  <readiness-score>/12
+```
+
+---
+
+## GitHub Issue Template
+
+```markdown
+## Problem
+
+{problem_description}
+
+## Context
+
+{context}
+
+**Jira ticket**: [{jira_key}]({jira_url})
+**Type**: {issue_type}
+**Priority**: {priority}
+
+## Location
+
+{location_hints}
+
+## Acceptance Criteria
+
+{acceptance_criteria}
+
+## Notes for the Agent
+
+{agent_notes}
+
+---
+*Bridged from Jira by `/fullsend bridge`*
+```
+
+### Field Mapping
+
+How to populate each section from the Jira ticket:
+
+| Template section | Jira source | Fallback |
+|-----------------|-------------|----------|
+| `problem_description` | Description — extract "Problem" or "Current vs Expected" section | Full description if unstructured |
+| `context` | Description — extract "Context" section, plus linked issues | Summary + priority as minimal context |
+| `jira_key` | Issue key (e.g., RHIDP-1234) | — |
+| `jira_url` | `https://redhat.atlassian.net/browse/{key}` | Use `issues.redhat.com` if JQL source differs |
+| `issue_type` | Issue type field (Bug, Story, Task, etc.) | — |
+| `priority` | Priority field | "Undefined" if not set |
+| `location_hints` | Description — extract "Location" section, or `repo:` labels, or component field | Omit section if no location info |
+| `acceptance_criteria` | Description — extract "Acceptance Criteria" section | Omit section if none |
+| `agent_notes` | Description — extract "Notes for the Agent" section, plus any agent-relevant comments | Omit section if none |
+
+### Title Rules
+
+- Use the Jira summary as the GitHub Issue title
+- If the Jira summary is too vague, prepend the type: `fix: {summary}`, `feat: {summary}`
+- Keep under 80 characters
+- Don't include the Jira key in the title (it's in the body)
+
+### Label Mapping
+
+| Condition | Labels to add |
+|-----------|--------------|
+| Always | `fullsend` |
+| Jira type = Bug | `bug` |
+| Jira type = Story or Task | `enhancement` |
+| Jira type = Vulnerability | `security` |
+| Jira label `needs-investigation` | `needs-investigation` |
+| Jira priority = Blocker or Critical | `priority/critical` |
+
+### Idempotency
+
+Before creating, check if the issue already exists:
+
+1. Search for `{jira_key}` in open issues (the Jira link in the body makes this searchable)
+2. If found, report "Already bridged" with the existing issue URL
+3. If the user wants to re-bridge (ticket was updated), close the old issue with a comment and create a new one
+
+---
+
+## Batch Mode
+
+When bridging multiple tickets (`--batch`):
+
+1. Fetch all matching Jira tickets
+2. Score each against agent-readiness
+3. Present a summary table:
+
+```markdown
+| # | Jira Key | Summary | Score | Target Repo | Action |
+|---|----------|---------|-------|-------------|--------|
+| 1 | RHIDP-123 | Fix auth redirect | 11/12 | owner/repo | Bridge |
+| 2 | RHIDP-456 | Update notification | 6/12 | owner/repo | Needs grooming |
+| 3 | RHIDP-789 | Add dark mode | 10/12 | owner/repo | Bridge |
+```
+
+4. Ask: "Bridge {n} ready tickets? [y/N]"
+5. Create issues sequentially, report each URL
+
+---
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| Jira ticket not found | "Ticket <KEY> not found." |
+| Target repo not found | "Repository <owner/name> not found or no access." |
+| `gh issue create` fails | Show error. Common cause: missing labels (create them first). |
+| No repo detected | Ask user to specify with `--repo`. |
+| Ticket already bridged | Check Jira comments for existing "Bridged to GitHub" link. Ask before creating a second issue. |