From 92e5592587c510036ccc35b0c12cc3ce747615f6 Mon Sep 17 00:00:00 2001 From: Marcel Hild Date: Thu, 4 Jun 2026 09:56:43 +0200 Subject: [PATCH 1/5] feat: add jira-groom skill for agent-readiness ticket preparation Conversational grooming skill that scores Jira tickets against a 6-dimension agent-readiness rubric (problem clarity, repo identification, file hints, acceptance criteria, scope, type clarity). Three modes: interactive grooming, quick score, and batch scoring via JQL. Inspired by Rehor's (platform-frontend-ai-dev) grooming workflow, adapted for general use with any autonomous agent. Co-Authored-By: Claude Opus 4.6 --- skills/jira-groom/SKILL.md | 139 ++++++++++++++ .../jira-groom/references/agent-readiness.md | 180 ++++++++++++++++++ 2 files changed, 319 insertions(+) create mode 100644 skills/jira-groom/SKILL.md create mode 100644 skills/jira-groom/references/agent-readiness.md diff --git a/skills/jira-groom/SKILL.md b/skills/jira-groom/SKILL.md new file mode 100644 index 0000000..0d5167c --- /dev/null +++ b/skills/jira-groom/SKILL.md @@ -0,0 +1,139 @@ +--- +name: jira-groom +description: | + Prepare Jira tickets for autonomous agent implementation. Conversational grooming that checks whether an agent can understand and implement the work: clear problem statement, repo identification, file paths, acceptance criteria, scope (single PR), and labels. Inspired by Rehor's grooming workflow. Trigger on "groom ticket", "agent-ready", "prepare for bot", "groom RHCLOUD-1234", or any Jira key with grooming intent. +compatibility: "acli on PATH or jira-cli (jira). Jira Cloud instance." +--- + + + +# Jira Agent Grooming + +Prepare Jira tickets so an autonomous agent can pick them up and implement them successfully. This is NOT sprint readiness or workflow field validation (use `rhdh-jira refine` for that). This checks whether the ticket contains enough information for an agent to: + +1. Understand what to change +2. Find the right files +3. Know when it's done +4. Stay within scope + +The output is an improved ticket description that a bot can act on without asking humans for clarification. + + + + + +## Usage + +``` +jira-groom # Groom a specific ticket +jira-groom --quick # Non-interactive: score + recommendations only +jira-groom --batch # Score multiple tickets, flag worst ones +``` + +**Wait for response before proceeding.** + + + + + +### Routing rules + +1. **Ticket key provided** (e.g., `RHCLOUD-12345`): Fetch the ticket → run the agent-readiness checklist → conversational grooming. +2. **Ticket key + `--quick`**: Fetch → score → print report. No conversation. +3. **`--batch` + JQL**: Fetch all matching tickets → score each → summary table sorted by readiness. No conversation. +4. **No argument**: Ask for a ticket key. + + + +## How It Works + +### Step 1 — Fetch the ticket + +Read the ticket using acli: + +```bash +acli jira workitem view --json +``` + +Extract: summary, description, labels, components, issue links, comments. If acli is not available, fall back to `jira issue view ` (jira-cli). + +### Step 2 — Score against Agent-Readiness Checklist + +Load `references/agent-readiness.md` for the full checklist. Score each dimension 0-2: + +| Dimension | 0 (Fail) | 1 (Partial) | 2 (Pass) | +|-----------|----------|-------------|----------| +| **Problem clarity** | Vague or missing | Has description but ambiguous | Clear current vs expected behavior | +| **Repo identification** | No repo mentioned | Repo implied but not explicit | `repo:` label or explicit repo name | +| **File/path hints** | No file paths | General area mentioned | Specific files, components, or URL paths | +| **Acceptance criteria** | None | Implicit in description | Explicit checklist | +| **Scope** | Unclear or multi-PR | Likely single PR but not stated | Clearly scoped to one PR | +| **Type clarity** | Can't tell bug vs feature | Inferable from context | Explicit (bug with repro, feature with spec, CVE with ID) | + +**Total score**: 0-12. Thresholds: + +- **10-12**: Agent-ready. Proceed. +- **7-9**: Needs minor improvement. Suggest fixes. +- **0-6**: Not agent-ready. Conversational grooming required. + +### Step 3 — Conversational Grooming (interactive mode) + +For each dimension that scored 0 or 1, ask the user targeted questions. One question at a time — don't dump all at once. Follow the question guide in `references/agent-readiness.md`. + +**Rules:** + +- If the user is vague, push back. A vague ticket wastes agent time and compute. +- If the work spans 3+ repos, suggest splitting into multiple tickets. +- If the work requires human judgment (design decisions, UX direction), suggest marking it `needs-investigation` so the agent reports findings instead of guessing. +- If the user doesn't know which files are affected, that's OK — help them narrow it down by asking about the feature/page/service. + +### Step 4 — Produce Improved Ticket + +Generate an updated description using the template in `references/agent-readiness.md`. Present to user: + +```markdown +## Suggested update + +**Title**: + +**Description**: + + +**Labels to add**: +- repo: (if identified) +- + +**Score**: X/12 → Y/12 +``` + +Ask: "Apply this update to the ticket? [y/N/edit]" + +- **y**: Update via `acli jira workitem edit --key --summary "..." --yes` + description update via REST/ADF +- **N**: Done, no changes +- **edit**: Let user modify before applying + +### Step 5 — Bridge hint (optional) + +If the ticket scores 10+ after grooming and the user has mentioned fullsend or GitHub-based agents: + +> "This ticket is agent-ready. To bridge it to a GitHub Issue for fullsend, you'll need the `jira-bridge` skill (coming soon)." + +## Reference Files + +| File | Load when... | +|------|-------------| +| `references/agent-readiness.md` | Always — contains the scoring rubric, question guide, and description template | + +## Relationship to Other Skills + +- **`rhdh-jira refine`**: Checks Jira workflow fields (component, priority, sprint readiness). Complementary — run `refine` for process compliance, `jira-groom` for agent readiness. +- **`jira-bridge`** (planned): Takes a groomed ticket and creates a GitHub Issue. `jira-groom` is the prerequisite step. + +## Error Handling + +| Error | Action | +|-------|--------| +| Ticket not found | "Ticket not found. Check the key and project." | +| acli not available | Fall back to `jira issue view`. If neither available, ask user to paste the ticket description. | +| Description is empty | Score Problem clarity as 0. Ask user to describe the problem from scratch. | +| Ticket is already closed | "This ticket is already closed. Nothing to groom." | diff --git a/skills/jira-groom/references/agent-readiness.md b/skills/jira-groom/references/agent-readiness.md new file mode 100644 index 0000000..bc80bd8 --- /dev/null +++ b/skills/jira-groom/references/agent-readiness.md @@ -0,0 +1,180 @@ +# Agent-Readiness Checklist + +Scoring rubric, question guide, and description template for grooming Jira tickets for autonomous agent implementation. Derived from Rehor's grooming workflow (platform-frontend-ai-dev) and adapted for general use. + +## Scoring Rubric + +### 1. Problem Clarity (0-2) + +What the agent needs: a clear understanding of what is wrong or what should change. + +| Score | Criteria | +|-------|----------| +| 0 | No description, or description is a single sentence with no actionable detail ("fix the notifications page") | +| 1 | Description exists but is ambiguous — multiple interpretations possible, no current/expected behavior distinction | +| 2 | Clear problem statement: current behavior vs expected behavior (bugs), or specific feature spec (features), or CVE ID + affected package (security) | + +**Questions to ask at score 0-1:** + +- "What's the current behavior? What do you see happening now?" +- "What should happen instead? What does 'fixed' look like?" +- "Is this a bug (something broken), a feature (something new), or a change (something works but should work differently)?" +- For bugs: "Can you reproduce it? What are the steps?" +- For CVEs: "What's the CVE ID? Which package/dependency is affected?" + +### 2. Repo Identification (0-2) + +What the agent needs: which repository to clone and work in. + +| Score | Criteria | +|-------|----------| +| 0 | No repository mentioned anywhere in the ticket | +| 1 | Repository implied (e.g., mentions a component name or URL path that maps to a known repo) but not explicit | +| 2 | Explicit `repo:` label, or repo name/URL in description | + +**Questions to ask at score 0-1:** + +- "Which repository does this change belong in?" +- "Which page or URL is affected?" (narrow down frontend repo) +- "Which service handles this?" (narrow down backend repo) +- "Does the fix span multiple repos? If so, which ones?" + +### 3. File/Path Hints (0-2) + +What the agent needs: where to start looking. Without this, the agent wastes tool calls searching the entire codebase. + +| Score | Criteria | +|-------|----------| +| 0 | No file paths, component names, or URL paths mentioned | +| 1 | General area mentioned ("the notification settings page", "the auth module") but no specific files | +| 2 | Specific file paths, component names, function names, or URL routes (e.g., `/settings/notifications`, `src/components/NotificationPrefs.tsx`) | + +**Questions to ask at score 0-1:** + +- "Do you know which file(s) need to change?" +- "What's the URL path where this issue is visible?" (for frontend) +- "Which component or module is involved?" +- "If you've debugged this before, what did you find?" + +**Note:** Score 1 is acceptable for many tickets — the agent can find files from component names. Score 0 means the agent will spend significant time just locating the right code. + +### 4. Acceptance Criteria (0-2) + +What the agent needs: how to know when it's done. + +| Score | Criteria | +|-------|----------| +| 0 | No acceptance criteria, no definition of done | +| 1 | Acceptance criteria implied in description but not explicit (e.g., "the button should be red" buried in a paragraph) | +| 2 | Explicit checklist of verifiable criteria (e.g., "- [ ] Button changes color to red on hover", "- [ ] Unit test added for new validation") | + +**Questions to ask at score 0-1:** + +- "How will you verify this is done? What should a reviewer check?" +- "Are there edge cases to handle?" +- "Should there be tests? What should they cover?" +- "Is there a visual change? Can you attach a screenshot or mockup?" + +### 5. Scope (0-2) + +What the agent needs: confidence that the work fits in a single PR. + +| Score | Criteria | +|-------|----------| +| 0 | Scope unclear — could be a 5-line fix or a 500-line refactor. Or explicitly multi-PR without decomposition | +| 1 | Likely single PR but not stated — reasonable inference from description | +| 2 | Clearly scoped: single concern, single repo, bounded change set. Or explicitly stated "single PR" | + +**Questions to ask at score 0:** + +- "How big do you think this change is? A few lines, a few files, or a larger refactor?" +- "Can this be done in a single PR, or should we split it?" +- "Are there dependencies — does something else need to land first?" + +**When to suggest splitting:** + +- Work spans 3+ repos +- Description contains "and also..." or "while we're at it..." +- Estimated change touches 10+ files across unrelated modules +- Mix of bug fix + feature work + +### 6. Type Clarity (0-2) + +What the agent needs: which problem-solving approach to use. + +| Score | Criteria | +|-------|----------| +| 0 | Can't tell if this is a bug, feature, refactor, CVE, or investigation | +| 1 | Type inferable from context but not explicit | +| 2 | Explicitly stated: bug with reproduction steps, feature with spec, CVE with ID, investigation with questions to answer | + +**Questions to ask at score 0:** + +- "Is this a bug fix, a new feature, a refactor, or a security fix?" +- For unclear bugs: "Can you describe the steps to reproduce?" +- For unclear features: "Is there a design or mockup?" + +## Description Template + +Use this template when rewriting the ticket description. Not all sections apply to every ticket — omit sections that aren't relevant. + +``` +## Problem + + + +## Context + + + +## Location + + + +## Acceptance Criteria + +- [ ] +- [ ] +- [ ] +- [ ] + +## Notes for the Agent + + +``` + +## Batch Scoring Output + +When running `--batch`: + +```markdown +## Agent-Readiness Scores + +| # | Key | Summary | Score | Problem | Repo | Files | AC | Scope | Type | Verdict | +|---|-----|---------|-------|---------|------|-------|----|-------|------|---------| +| 1 | KEY-123 | Fix notification... | 4/12 | 0 | 1 | 0 | 1 | 1 | 1 | Needs grooming | +| 2 | KEY-456 | Add dark mode... | 11/12 | 2 | 2 | 2 | 2 | 1 | 2 | Agent-ready | + +### Summary +- Agent-ready (10+): 3 tickets +- Needs minor work (7-9): 5 tickets +- Needs grooming (0-6): 2 tickets + +### Worst offenders (groom these first) +1. KEY-123 (4/12): Missing problem description and file paths +2. KEY-789 (5/12): No acceptance criteria, scope unclear +``` + +## Anti-patterns + +Things that make tickets bad for agents: + +| Anti-pattern | Why it's bad | Fix | +|--------------|-------------|-----| +| "Fix the X page" | Agent doesn't know what's broken | Add current vs expected behavior | +| Screenshot-only description | Agent can't read screenshots reliably | Add text description alongside screenshot | +| "See Slack thread" with link | Agent may not have Slack access | Copy relevant context into ticket | +| "Similar to PROJ-999" | Agent needs self-contained tickets | Copy the relevant parts, don't just reference | +| Multi-concern tickets | Agent produces unfocused PRs | Split into separate tickets | +| "Refactor X while fixing Y" | Mixes cleanup with bugfix | Separate tickets: fix first, refactor second | +| Implementation instructions | Over-constrains the agent, may be wrong | Describe the problem and outcome, not the solution | From 7633bb7491370e00a812239570d7c55977acd307 Mon Sep 17 00:00:00 2001 From: Marcel Hild Date: Thu, 4 Jun 2026 10:01:43 +0200 Subject: [PATCH 2/5] feat: add jira-bridge skill for Jira-to-GitHub Issue bridging MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- skills/jira-bridge/SKILL.md | 162 ++++++++++++++++++ .../jira-bridge/references/issue-template.md | 95 ++++++++++ skills/jira-bridge/references/repo-mapping.md | 40 +++++ 3 files changed, 297 insertions(+) create mode 100644 skills/jira-bridge/SKILL.md create mode 100644 skills/jira-bridge/references/issue-template.md create mode 100644 skills/jira-bridge/references/repo-mapping.md diff --git a/skills/jira-bridge/SKILL.md b/skills/jira-bridge/SKILL.md new file mode 100644 index 0000000..eb4e749 --- /dev/null +++ b/skills/jira-bridge/SKILL.md @@ -0,0 +1,162 @@ +--- +name: jira-bridge +description: | + 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. +compatibility: "acli or jira-cli on PATH. gh CLI authenticated. Target repos must have fullsend installed." +--- + + + +# Jira-to-GitHub Bridge + +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). + +The skill does three things: + +1. Reads the Jira ticket and extracts structured information +2. Creates a GitHub Issue with fullsend-compatible formatting +3. Links both sides (Jira comment with GH link, GH issue body with Jira link) + + + + + +## Usage + +``` +jira-bridge # Bridge to auto-detected repo +jira-bridge --repo owner/name # Bridge to specific repo +jira-bridge --dry-run # Show what would be created, don't file +jira-bridge --batch --repo owner/name # Bridge multiple tickets +``` + +**Wait for response before proceeding.** + + + + + +### Routing rules + +1. **Ticket key provided**: Fetch Jira ticket → detect target repo → create GitHub Issue → link both sides. +2. **Ticket key + `--repo`**: Skip repo detection, use the specified repo. +3. **Ticket key + `--dry-run`**: Show the GitHub Issue that would be created. No mutations. +4. **`--batch` + JQL + `--repo`**: Bridge multiple tickets to the same repo. Confirm before filing. +5. **No argument**: Ask for a ticket key. + + + +## How It Works + +### Step 1 — Fetch and validate the Jira ticket + +Read the ticket: + +```bash +acli jira workitem view --json +``` + +Fall back to `jira issue view ` if acli is unavailable. + +**Validate agent-readiness**: Run a quick score against the `jira-groom` rubric (load `../jira-groom/references/agent-readiness.md`). If score < 7: + +> "This ticket scores {score}/12 on agent-readiness. Run `jira-groom ` 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 from label value. Map to full `owner/name` using the repo mapping in `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 has fullsend installed: + +```bash +gh repo view --json name,owner +``` + +### Step 3 — Check for existing GitHub Issues + +Search for duplicates before creating: + +```bash +gh issue list --repo --state open --search "" +``` + +If a match exists: + +> "Found existing issue #{number}: '{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. + +### Step 4 — Create the GitHub Issue + +Build the issue using the template in `references/issue-template.md`. + +```bash +gh issue create --repo \ + --title "" \ + --label "fullsend" \ + --body "$(cat <<'EOF' +<body> +EOF +)" +``` + +**Labels**: Always add `fullsend` so the triage agent picks it up. 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: + +``` +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 +``` + +## Reference Files + +| File | Load when... | +|------|-------------| +| `references/issue-template.md` | Always — GitHub Issue body template with fullsend-compatible formatting | +| `references/repo-mapping.md` | Repo detection — maps Jira components/labels to GitHub repos | +| `../jira-groom/references/agent-readiness.md` | Validation — agent-readiness scoring before bridge | + +## Relationship to Other Skills + +- **`jira-groom`**: Prerequisite — grooms tickets to agent-readiness. Bridge validates the score before proceeding. +- **`rhdh-jira`**: Provides Jira infrastructure (acli, fields, workflows). Bridge uses the same tooling but doesn't duplicate it. +- **fullsend triage agent**: Downstream consumer — picks up the GitHub Issue created by this skill. + +## 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. | diff --git a/skills/jira-bridge/references/issue-template.md b/skills/jira-bridge/references/issue-template.md new file mode 100644 index 0000000..f6b6a69 --- /dev/null +++ b/skills/jira-bridge/references/issue-template.md @@ -0,0 +1,95 @@ +# GitHub Issue Template for Fullsend + +Template for creating GitHub Issues that fullsend's triage agent can pick up and route to the coder agent. + +## 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 `jira-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 diff --git a/skills/jira-bridge/references/repo-mapping.md b/skills/jira-bridge/references/repo-mapping.md new file mode 100644 index 0000000..a736154 --- /dev/null +++ b/skills/jira-bridge/references/repo-mapping.md @@ -0,0 +1,40 @@ +# Repo Mapping + +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. + +## How Detection Works + +The bridge tries these sources in order: + +1. **`repo:` label** on the Jira ticket (e.g., `repo:backstage-plugins`) → look up in the table below +2. **Component field** → look up in the table below +3. **Keywords in description** → fuzzy match against repo descriptions below +4. **Ask the user** → present the table and let them pick + +## RHDH Repositories + +<!-- Update this table when repos are added to or removed from fullsend --> + +| Jira Component | `repo:` label | GitHub Repo | Description | +|----------------|---------------|-------------|-------------| +| TBD | TBD | TBD | TBD | + +**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. + +Example: + +```markdown +| Jira Component | `repo:` label | GitHub Repo | Description | +|----------------|---------------|-------------|-------------| +| backstage-plugins | repo:backstage-plugins | redhat-developer/rhdh-plugins | RHDH plugins monorepo | +| backstage-core | repo:backstage | redhat-developer/rhdh | RHDH core | +| operator | repo:rhdh-operator | redhat-developer/rhdh-operator | RHDH Operator | +``` + +## Adding a New Repo + +When your team adds a new repo to fullsend: + +1. Add a row to the table above +2. Ensure the repo has the `fullsend` label created (`gh label create fullsend --repo owner/name`) +3. Verify fullsend is installed on the repo (check GitHub App installations) From 85495f76da5fb877e7b7a6f84ecf62f48078968a Mon Sep 17 00:00:00 2001 From: Marcel Hild <hild@b4mad.net> Date: Thu, 4 Jun 2026 14:43:02 +0200 Subject: [PATCH 3/5] feat: consolidate jira-groom and jira-bridge into fullsend skill (v0.4.0) Merge two separate skills into a single unified `fullsend` skill with `groom` and `bridge` subcommands. This better reflects the workflow: groom a Jira ticket for agent-readiness, then bridge it to GitHub. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --- .claude-plugin/marketplace.json | 4 +- .claude-plugin/plugin.json | 2 +- pyproject.toml | 2 +- skills/fullsend/SKILL.md | 51 ++++ skills/fullsend/references/bridge.md | 223 ++++++++++++++ skills/fullsend/references/groom.md | 278 ++++++++++++++++++ skills/fullsend/references/repo-mapping.md | 60 ++++ skills/jira-bridge/SKILL.md | 162 ---------- .../jira-bridge/references/issue-template.md | 95 ------ skills/jira-bridge/references/repo-mapping.md | 40 --- skills/jira-groom/SKILL.md | 139 --------- .../jira-groom/references/agent-readiness.md | 180 ------------ 12 files changed, 616 insertions(+), 620 deletions(-) create mode 100644 skills/fullsend/SKILL.md create mode 100644 skills/fullsend/references/bridge.md create mode 100644 skills/fullsend/references/groom.md create mode 100644 skills/fullsend/references/repo-mapping.md delete mode 100644 skills/jira-bridge/SKILL.md delete mode 100644 skills/jira-bridge/references/issue-template.md delete mode 100644 skills/jira-bridge/references/repo-mapping.md delete mode 100644 skills/jira-groom/SKILL.md delete mode 100644 skills/jira-groom/references/agent-readiness.md diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 44bf61c..fae8fcf 100644 --- a/.claude-plugin/marketplace.json +++ b/.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 } ] diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index f27dff9..342541c 100644 --- a/.claude-plugin/plugin.json +++ b/.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" }, diff --git a/pyproject.toml b/pyproject.toml index b4cce0a..e6f9153 100644 --- a/pyproject.toml +++ b/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" diff --git a/skills/fullsend/SKILL.md b/skills/fullsend/SKILL.md new file mode 100644 index 0000000..a4dfe0e --- /dev/null +++ b/skills/fullsend/SKILL.md @@ -0,0 +1,51 @@ +--- +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 | + +## 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. diff --git a/skills/fullsend/references/bridge.md b/skills/fullsend/references/bridge.md new file mode 100644 index 0000000..8e15d8c --- /dev/null +++ b/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. | diff --git a/skills/fullsend/references/groom.md b/skills/fullsend/references/groom.md new file mode 100644 index 0000000..b320272 --- /dev/null +++ b/skills/fullsend/references/groom.md @@ -0,0 +1,278 @@ +# Groom: Agent-Readiness Workflow + +Prepare Jira tickets so an autonomous agent can pick them up and implement them +successfully. This is NOT sprint readiness or workflow field validation (use +`rhdh-jira refine` for that). This checks whether the ticket contains enough +information for an agent to: + +1. Understand what to change +2. Find the right files +3. Know when it's done +4. Stay within scope + +The output is an improved ticket description that a bot can act on without +asking humans for clarification. + +## Usage + +``` +/fullsend groom <KEY> # Interactive grooming session +/fullsend groom <KEY> --quick # Score + recommendations only +/fullsend groom --batch <JQL> # Score multiple tickets, flag worst ones +``` + +## Workflow + +### Step 1 — Fetch the Ticket + +```bash +acli jira workitem view <KEY> --json +``` + +Extract: summary, description, labels, components, issue links, comments. +Fall back to `jira issue view <KEY>` if acli is unavailable. +If neither tool is available, ask the user to paste the ticket description. + +### Step 2 — Score Against Agent-Readiness Rubric + +Score each dimension 0–2: + +| Dimension | 0 (Fail) | 1 (Partial) | 2 (Pass) | +|-----------|----------|-------------|----------| +| **Problem clarity** | Vague or missing | Has description but ambiguous | Clear current vs expected behavior | +| **Repo identification** | No repo mentioned | Repo implied but not explicit | `repo:` label or explicit repo name | +| **File/path hints** | No file paths | General area mentioned | Specific files, components, or URL paths | +| **Acceptance criteria** | None | Implicit in description | Explicit checklist | +| **Scope** | Unclear or multi-PR | Likely single PR but not stated | Clearly scoped to one PR | +| **Type clarity** | Can't tell bug vs feature | Inferable from context | Explicit (bug with repro, feature with spec, CVE with ID) | + +**Total**: 0–12. Thresholds: + +- **10–12**: Agent-ready. Proceed. +- **7–9**: Needs minor improvement. Suggest fixes. +- **0–6**: Not agent-ready. Conversational grooming required. + +### Step 3 — Conversational Grooming (interactive mode only) + +For each dimension that scored 0 or 1, ask the user targeted questions. +**One question at a time** — don't dump all at once. + +**Rules:** + +- If the user is vague, push back. A vague ticket wastes agent time and compute. +- If the work spans 3+ repos, suggest splitting into multiple tickets. +- If the work requires human judgment (design decisions, UX direction), suggest + marking it `needs-investigation` so the agent reports findings instead of guessing. +- If the user doesn't know which files are affected, help them narrow it down by + asking about the feature/page/service. + +Skip this step for `--quick` and `--batch` modes. + +### Step 4 — Produce Improved Ticket + +Generate an updated description using the template below. Present to user: + +```markdown +## Suggested update + +**Title**: <improved title — short, specific> + +**Description**: +<structured description> + +**Labels to add**: +- repo:<name> (if identified) +- <any routing labels> + +**Score**: X/12 → Y/12 +``` + +Ask: "Apply this update to the ticket? [y/N/edit]" + +- **y**: Update via `acli jira workitem edit --key <KEY> --summary "..." --yes` + and description update via REST/ADF +- **N**: Done, no changes +- **edit**: Let user modify before applying + +### Step 5 — Investigation Check + +If the ticket's problem is unclear, spans many repos, or requires human judgment +(design decisions, UX direction, architecture choices), recommend the +`needs-investigation` label instead of trying to groom it into an implementation +ticket. + +**Investigation tickets are fundamentally different from implementation tickets:** + +- The agent should **analyze and report findings**, not implement code +- The output is a detailed comment on the Jira ticket (root cause, affected + repos/files, suggested fix, blockers) — not a PR +- The ticket stays `In Progress` until a human confirms the findings or asks + follow-up questions — never auto-archive +- Remove the `needs-investigation` label only after posting the report, not + before + +**When to suggest investigation:** + +- User says "I don't know what's wrong" or "something is broken but I'm not sure where" +- Problem spans 3+ repos with no clear entry point +- Ticket involves a design decision or UX direction the agent shouldn't make +- User wants the agent to explore options, not implement a specific fix + +If investigation is not needed and the ticket scores 10+ after grooming: + +> "This ticket is agent-ready. Run `/fullsend bridge <KEY>` to create a +> GitHub Issue for fullsend." + +--- + +## Agent-Readiness Question Guide + +### 1. Problem Clarity + +**Questions at score 0–1:** + +- "What's the current behavior? What do you see happening now?" +- "What should happen instead? What does 'fixed' look like?" +- "Is this a bug (something broken), a feature (something new), or a change (something works but should work differently)?" +- For bugs: "Can you reproduce it? What are the steps?" +- For CVEs: "What's the CVE ID? Which package/dependency is affected?" + +### 2. Repo Identification + +**Questions at score 0–1:** + +- "Which repository does this change belong in?" +- "Which page or URL is affected?" (narrow down frontend repo) +- "Which service handles this?" (narrow down backend repo) +- "Does the fix span multiple repos? If so, which ones?" + +### 3. File/Path Hints + +**Questions at score 0–1:** + +- "Do you know which file(s) need to change?" +- "What's the URL path where this issue is visible?" (for frontend) +- "Which component or module is involved?" +- "If you've debugged this before, what did you find?" + +Score 1 is acceptable for many tickets — the agent can find files from +component names. Score 0 means the agent will spend significant time +just locating the right code. + +### 4. Acceptance Criteria + +**Questions at score 0–1:** + +- "How will you verify this is done? What should a reviewer check?" +- "Are there edge cases to handle?" +- "Should there be tests? What should they cover?" +- "Is there a visual change? Can you attach a screenshot or mockup?" + +### 5. Scope + +**Questions at score 0:** + +- "How big do you think this change is? A few lines, a few files, or a larger refactor?" +- "Can this be done in a single PR, or should we split it?" +- "Are there dependencies — does something else need to land first?" + +**When to suggest splitting:** + +- Work spans 3+ repos +- Description contains "and also..." or "while we're at it..." +- Estimated change touches 10+ files across unrelated modules +- Mix of bug fix + feature work + +### 6. Type Clarity + +**Questions at score 0:** + +- "Is this a bug fix, a new feature, a refactor, or a security fix?" +- For unclear bugs: "Can you describe the steps to reproduce?" +- For unclear features: "Is there a design or mockup?" + +--- + +## Description Template + +Use this when rewriting the ticket description. Omit sections that aren't relevant. + +```markdown +## Problem + +<What is wrong or what needs to change. For bugs: current behavior vs expected +behavior. For features: what should exist that doesn't. For CVEs: CVE ID, +affected package, version.> + +## Context + +<Why this matters. Impact on users, systems, or other teams. Any relevant +history or prior attempts.> + +## Location + +<Which repo(s), file(s), component(s), URL path(s) are involved.> + +## Acceptance Criteria + +- [ ] <Verifiable criterion 1> +- [ ] <Verifiable criterion 2> +- [ ] <Tests: what should be tested> +- [ ] <Edge cases to handle> + +## Notes for the Agent + +<Anything that helps the agent avoid wrong turns: "Don't touch the legacy auth +flow", "The test suite uses vitest not jest", "This component uses PatternFly 6". +Only include if non-obvious.> +``` + +--- + +## Batch Scoring Output + +When running `--batch`: + +```markdown +## Agent-Readiness Scores + +| # | Key | Summary | Score | Problem | Repo | Files | AC | Scope | Type | Verdict | +|---|-----|---------|-------|---------|------|-------|----|-------|------|---------| +| 1 | KEY-123 | Fix notification... | 4/12 | 0 | 1 | 0 | 1 | 1 | 1 | Needs grooming | +| 2 | KEY-456 | Add dark mode... | 11/12 | 2 | 2 | 2 | 2 | 1 | 2 | Agent-ready | + +### Summary +- Agent-ready (10+): N tickets +- Needs minor work (7–9): N tickets +- Needs grooming (0–6): N tickets + +### Worst offenders (groom these first) +1. KEY-123 (4/12): Missing problem description and file paths +``` + +--- + +## Anti-patterns + +Things that make tickets bad for agents: + +| Anti-pattern | Why it's bad | Fix | +|--------------|-------------|-----| +| "Fix the X page" | Agent doesn't know what's broken | Add current vs expected behavior | +| Screenshot-only description | Agent can't read screenshots reliably | Add text description alongside screenshot | +| "See Slack thread" with link | Agent may not have Slack access | Copy relevant context into ticket | +| "Similar to PROJ-999" | Agent needs self-contained tickets | Copy the relevant parts, don't just reference | +| Multi-concern tickets | Agent produces unfocused PRs | Split into separate tickets | +| "Refactor X while fixing Y" | Mixes cleanup with bugfix | Separate tickets: fix first, refactor second | +| Implementation instructions | Over-constrains the agent, may be wrong | Describe the problem and outcome, not the solution | + +--- + +## Error Handling + +| Error | Action | +|-------|--------| +| Ticket not found | "Ticket <KEY> not found. Check the key and project." | +| acli not available | Fall back to `jira issue view`. If neither available, ask user to paste the ticket description. | +| Description is empty | Score Problem clarity as 0. Ask user to describe the problem from scratch. | +| Ticket is already closed | "This ticket is already closed. Nothing to groom." | diff --git a/skills/fullsend/references/repo-mapping.md b/skills/fullsend/references/repo-mapping.md new file mode 100644 index 0000000..d81b806 --- /dev/null +++ b/skills/fullsend/references/repo-mapping.md @@ -0,0 +1,60 @@ +# Repo Mapping + +Maps Jira components and labels to GitHub repositories for `bridge` repo +detection. Works with existing rhdh-skill references rather than duplicating them. + +## Existing References + +This skill does NOT maintain its own repo catalog. Use these sibling references: + +- **`../rhdh/references/rhdh-repos.md`** — full repo map with descriptions, tech + stacks, and ecosystem relationships. Covers all `redhat-developer/rhdh-*` repos. +- **`../rhdh-jira/references/fields.md`** — Jira component catalog (RHDH Core, + Backstage, Extension Plugins, Program) with freeze exclusion flags. +- **`../rhdh-jira/references/jql-patterns.md`** — JQL patterns, boards, sprint + naming conventions, and team filtering. + +## How Detection Works + +The bridge tries these sources in order: + +1. **`--repo` flag**: Use as-is. +2. **`repo:` label** on the Jira ticket (e.g., `repo:rhdh-plugins`) → resolve + against the table below. +3. **Jira component** → resolve against the component-to-repo mapping below. +4. **Keywords in description** → fuzzy match against `../rhdh/references/rhdh-repos.md`. +5. **Ask the user** → present known repos from the table below, let them pick. + +## Component-to-Repo Mapping + +Maps Jira components (from `../rhdh-jira/references/fields.md`) to GitHub repos +where fullsend can create issues. Only repos with fullsend installed are listed. + +<!-- Update this table when repos are added to or removed from fullsend --> + +| Jira Component(s) | `repo:` label | GitHub Repo | Notes | +|--------------------|---------------|-------------|-------| +| Dynamic Plugins, RHDH CLI, Plugin Development | repo:rhdh-cli | redhat-developer/rhdh-cli | CLI + plugin export | +| UI, Authentication, Dynamic Plugins, Catalog | repo:rhdh | redhat-developer/rhdh | Core RHDH app | +| Operator | repo:rhdh-operator | redhat-developer/rhdh-operator | K8s/OCP operator | +| Helm Chart | repo:rhdh-chart | redhat-developer/rhdh-chart | Helm deployment | +| RHDH Local | repo:rhdh-local | redhat-developer/rhdh-local | Local dev env | +| Overlay, Extensions | repo:rhdh-plugin-export-overlays | redhat-developer/rhdh-plugin-export-overlays | Plugin packaging | +| Lightspeed, Bulk Import, Orchestrator, Homepage, Topology, Scorecard, Adoption Insights | repo:rhdh-plugins | redhat-developer/rhdh-plugins | Plugins monorepo | + +**Ambiguous components** (may map to multiple repos): `Authentication`, +`Dynamic Plugins`, `Catalog`. When ambiguous, ask the user. + +**Components NOT mappable to a single repo**: `Documentation`, `Quality`, +`Security`, `Support`, `Team Operations`, `UX` — these are program-level +components, not code repos. Flag to the user if a ticket only has these. + +## Adding a New Repo + +When your team adds a new repo to fullsend: + +1. Add a row to the table above +2. Ensure the repo has the `fullsend` label created: + `gh label create fullsend --repo owner/name` +3. Verify fullsend is installed on the repo (check GitHub App installations) +4. Update `../rhdh/references/rhdh-repos.md` if the repo is new to the ecosystem diff --git a/skills/jira-bridge/SKILL.md b/skills/jira-bridge/SKILL.md deleted file mode 100644 index eb4e749..0000000 --- a/skills/jira-bridge/SKILL.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -name: jira-bridge -description: | - 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. -compatibility: "acli or jira-cli on PATH. gh CLI authenticated. Target repos must have fullsend installed." ---- - -<essential_principles> - -# Jira-to-GitHub Bridge - -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). - -The skill does three things: - -1. Reads the Jira ticket and extracts structured information -2. Creates a GitHub Issue with fullsend-compatible formatting -3. Links both sides (Jira comment with GH link, GH issue body with Jira link) - -</essential_principles> - -<intake> - -## Usage - -``` -jira-bridge <TICKET-KEY> # Bridge to auto-detected repo -jira-bridge <TICKET-KEY> --repo owner/name # Bridge to specific repo -jira-bridge <TICKET-KEY> --dry-run # Show what would be created, don't file -jira-bridge --batch <JQL> --repo owner/name # Bridge multiple tickets -``` - -**Wait for response before proceeding.** - -</intake> - -<routing> - -### Routing rules - -1. **Ticket key provided**: Fetch Jira ticket → detect target repo → create GitHub Issue → link both sides. -2. **Ticket key + `--repo`**: Skip repo detection, use the specified repo. -3. **Ticket key + `--dry-run`**: Show the GitHub Issue that would be created. No mutations. -4. **`--batch` + JQL + `--repo`**: Bridge multiple tickets to the same repo. Confirm before filing. -5. **No argument**: Ask for a ticket key. - -</routing> - -## How It Works - -### Step 1 — Fetch and validate the Jira ticket - -Read the 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 `jira-groom` rubric (load `../jira-groom/references/agent-readiness.md`). If score < 7: - -> "This ticket scores {score}/12 on agent-readiness. Run `jira-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 from label value. Map to full `owner/name` using the repo mapping in `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 has fullsend installed: - -```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 #{number}: '{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. - -### Step 4 — Create the GitHub Issue - -Build the issue using the template in `references/issue-template.md`. - -```bash -gh issue create --repo <owner/name> \ - --title "<title>" \ - --label "fullsend" \ - --body "$(cat <<'EOF' -<body> -EOF -)" -``` - -**Labels**: Always add `fullsend` so the triage agent picks it up. 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: - -``` -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 -``` - -## Reference Files - -| File | Load when... | -|------|-------------| -| `references/issue-template.md` | Always — GitHub Issue body template with fullsend-compatible formatting | -| `references/repo-mapping.md` | Repo detection — maps Jira components/labels to GitHub repos | -| `../jira-groom/references/agent-readiness.md` | Validation — agent-readiness scoring before bridge | - -## Relationship to Other Skills - -- **`jira-groom`**: Prerequisite — grooms tickets to agent-readiness. Bridge validates the score before proceeding. -- **`rhdh-jira`**: Provides Jira infrastructure (acli, fields, workflows). Bridge uses the same tooling but doesn't duplicate it. -- **fullsend triage agent**: Downstream consumer — picks up the GitHub Issue created by this skill. - -## 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. | diff --git a/skills/jira-bridge/references/issue-template.md b/skills/jira-bridge/references/issue-template.md deleted file mode 100644 index f6b6a69..0000000 --- a/skills/jira-bridge/references/issue-template.md +++ /dev/null @@ -1,95 +0,0 @@ -# GitHub Issue Template for Fullsend - -Template for creating GitHub Issues that fullsend's triage agent can pick up and route to the coder agent. - -## 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 `jira-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 diff --git a/skills/jira-bridge/references/repo-mapping.md b/skills/jira-bridge/references/repo-mapping.md deleted file mode 100644 index a736154..0000000 --- a/skills/jira-bridge/references/repo-mapping.md +++ /dev/null @@ -1,40 +0,0 @@ -# Repo Mapping - -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. - -## How Detection Works - -The bridge tries these sources in order: - -1. **`repo:` label** on the Jira ticket (e.g., `repo:backstage-plugins`) → look up in the table below -2. **Component field** → look up in the table below -3. **Keywords in description** → fuzzy match against repo descriptions below -4. **Ask the user** → present the table and let them pick - -## RHDH Repositories - -<!-- Update this table when repos are added to or removed from fullsend --> - -| Jira Component | `repo:` label | GitHub Repo | Description | -|----------------|---------------|-------------|-------------| -| TBD | TBD | TBD | TBD | - -**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. - -Example: - -```markdown -| Jira Component | `repo:` label | GitHub Repo | Description | -|----------------|---------------|-------------|-------------| -| backstage-plugins | repo:backstage-plugins | redhat-developer/rhdh-plugins | RHDH plugins monorepo | -| backstage-core | repo:backstage | redhat-developer/rhdh | RHDH core | -| operator | repo:rhdh-operator | redhat-developer/rhdh-operator | RHDH Operator | -``` - -## Adding a New Repo - -When your team adds a new repo to fullsend: - -1. Add a row to the table above -2. Ensure the repo has the `fullsend` label created (`gh label create fullsend --repo owner/name`) -3. Verify fullsend is installed on the repo (check GitHub App installations) diff --git a/skills/jira-groom/SKILL.md b/skills/jira-groom/SKILL.md deleted file mode 100644 index 0d5167c..0000000 --- a/skills/jira-groom/SKILL.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -name: jira-groom -description: | - Prepare Jira tickets for autonomous agent implementation. Conversational grooming that checks whether an agent can understand and implement the work: clear problem statement, repo identification, file paths, acceptance criteria, scope (single PR), and labels. Inspired by Rehor's grooming workflow. Trigger on "groom ticket", "agent-ready", "prepare for bot", "groom RHCLOUD-1234", or any Jira key with grooming intent. -compatibility: "acli on PATH or jira-cli (jira). Jira Cloud instance." ---- - -<essential_principles> - -# Jira Agent Grooming - -Prepare Jira tickets so an autonomous agent can pick them up and implement them successfully. This is NOT sprint readiness or workflow field validation (use `rhdh-jira refine` for that). This checks whether the ticket contains enough information for an agent to: - -1. Understand what to change -2. Find the right files -3. Know when it's done -4. Stay within scope - -The output is an improved ticket description that a bot can act on without asking humans for clarification. - -</essential_principles> - -<intake> - -## Usage - -``` -jira-groom <TICKET-KEY> # Groom a specific ticket -jira-groom <TICKET-KEY> --quick # Non-interactive: score + recommendations only -jira-groom --batch <JQL> # Score multiple tickets, flag worst ones -``` - -**Wait for response before proceeding.** - -</intake> - -<routing> - -### Routing rules - -1. **Ticket key provided** (e.g., `RHCLOUD-12345`): Fetch the ticket → run the agent-readiness checklist → conversational grooming. -2. **Ticket key + `--quick`**: Fetch → score → print report. No conversation. -3. **`--batch` + JQL**: Fetch all matching tickets → score each → summary table sorted by readiness. No conversation. -4. **No argument**: Ask for a ticket key. - -</routing> - -## How It Works - -### Step 1 — Fetch the ticket - -Read the ticket using acli: - -```bash -acli jira workitem view <KEY> --json -``` - -Extract: summary, description, labels, components, issue links, comments. If acli is not available, fall back to `jira issue view <KEY>` (jira-cli). - -### Step 2 — Score against Agent-Readiness Checklist - -Load `references/agent-readiness.md` for the full checklist. Score each dimension 0-2: - -| Dimension | 0 (Fail) | 1 (Partial) | 2 (Pass) | -|-----------|----------|-------------|----------| -| **Problem clarity** | Vague or missing | Has description but ambiguous | Clear current vs expected behavior | -| **Repo identification** | No repo mentioned | Repo implied but not explicit | `repo:` label or explicit repo name | -| **File/path hints** | No file paths | General area mentioned | Specific files, components, or URL paths | -| **Acceptance criteria** | None | Implicit in description | Explicit checklist | -| **Scope** | Unclear or multi-PR | Likely single PR but not stated | Clearly scoped to one PR | -| **Type clarity** | Can't tell bug vs feature | Inferable from context | Explicit (bug with repro, feature with spec, CVE with ID) | - -**Total score**: 0-12. Thresholds: - -- **10-12**: Agent-ready. Proceed. -- **7-9**: Needs minor improvement. Suggest fixes. -- **0-6**: Not agent-ready. Conversational grooming required. - -### Step 3 — Conversational Grooming (interactive mode) - -For each dimension that scored 0 or 1, ask the user targeted questions. One question at a time — don't dump all at once. Follow the question guide in `references/agent-readiness.md`. - -**Rules:** - -- If the user is vague, push back. A vague ticket wastes agent time and compute. -- If the work spans 3+ repos, suggest splitting into multiple tickets. -- If the work requires human judgment (design decisions, UX direction), suggest marking it `needs-investigation` so the agent reports findings instead of guessing. -- If the user doesn't know which files are affected, that's OK — help them narrow it down by asking about the feature/page/service. - -### Step 4 — Produce Improved Ticket - -Generate an updated description using the template in `references/agent-readiness.md`. Present to user: - -```markdown -## Suggested update - -**Title**: <improved title — short, specific> - -**Description**: -<structured description with all agent-relevant info> - -**Labels to add**: -- repo:<name> (if identified) -- <any routing labels> - -**Score**: X/12 → Y/12 -``` - -Ask: "Apply this update to the ticket? [y/N/edit]" - -- **y**: Update via `acli jira workitem edit --key <KEY> --summary "..." --yes` + description update via REST/ADF -- **N**: Done, no changes -- **edit**: Let user modify before applying - -### Step 5 — Bridge hint (optional) - -If the ticket scores 10+ after grooming and the user has mentioned fullsend or GitHub-based agents: - -> "This ticket is agent-ready. To bridge it to a GitHub Issue for fullsend, you'll need the `jira-bridge` skill (coming soon)." - -## Reference Files - -| File | Load when... | -|------|-------------| -| `references/agent-readiness.md` | Always — contains the scoring rubric, question guide, and description template | - -## Relationship to Other Skills - -- **`rhdh-jira refine`**: Checks Jira workflow fields (component, priority, sprint readiness). Complementary — run `refine` for process compliance, `jira-groom` for agent readiness. -- **`jira-bridge`** (planned): Takes a groomed ticket and creates a GitHub Issue. `jira-groom` is the prerequisite step. - -## Error Handling - -| Error | Action | -|-------|--------| -| Ticket not found | "Ticket <KEY> not found. Check the key and project." | -| acli not available | Fall back to `jira issue view`. If neither available, ask user to paste the ticket description. | -| Description is empty | Score Problem clarity as 0. Ask user to describe the problem from scratch. | -| Ticket is already closed | "This ticket is already closed. Nothing to groom." | diff --git a/skills/jira-groom/references/agent-readiness.md b/skills/jira-groom/references/agent-readiness.md deleted file mode 100644 index bc80bd8..0000000 --- a/skills/jira-groom/references/agent-readiness.md +++ /dev/null @@ -1,180 +0,0 @@ -# Agent-Readiness Checklist - -Scoring rubric, question guide, and description template for grooming Jira tickets for autonomous agent implementation. Derived from Rehor's grooming workflow (platform-frontend-ai-dev) and adapted for general use. - -## Scoring Rubric - -### 1. Problem Clarity (0-2) - -What the agent needs: a clear understanding of what is wrong or what should change. - -| Score | Criteria | -|-------|----------| -| 0 | No description, or description is a single sentence with no actionable detail ("fix the notifications page") | -| 1 | Description exists but is ambiguous — multiple interpretations possible, no current/expected behavior distinction | -| 2 | Clear problem statement: current behavior vs expected behavior (bugs), or specific feature spec (features), or CVE ID + affected package (security) | - -**Questions to ask at score 0-1:** - -- "What's the current behavior? What do you see happening now?" -- "What should happen instead? What does 'fixed' look like?" -- "Is this a bug (something broken), a feature (something new), or a change (something works but should work differently)?" -- For bugs: "Can you reproduce it? What are the steps?" -- For CVEs: "What's the CVE ID? Which package/dependency is affected?" - -### 2. Repo Identification (0-2) - -What the agent needs: which repository to clone and work in. - -| Score | Criteria | -|-------|----------| -| 0 | No repository mentioned anywhere in the ticket | -| 1 | Repository implied (e.g., mentions a component name or URL path that maps to a known repo) but not explicit | -| 2 | Explicit `repo:<name>` label, or repo name/URL in description | - -**Questions to ask at score 0-1:** - -- "Which repository does this change belong in?" -- "Which page or URL is affected?" (narrow down frontend repo) -- "Which service handles this?" (narrow down backend repo) -- "Does the fix span multiple repos? If so, which ones?" - -### 3. File/Path Hints (0-2) - -What the agent needs: where to start looking. Without this, the agent wastes tool calls searching the entire codebase. - -| Score | Criteria | -|-------|----------| -| 0 | No file paths, component names, or URL paths mentioned | -| 1 | General area mentioned ("the notification settings page", "the auth module") but no specific files | -| 2 | Specific file paths, component names, function names, or URL routes (e.g., `/settings/notifications`, `src/components/NotificationPrefs.tsx`) | - -**Questions to ask at score 0-1:** - -- "Do you know which file(s) need to change?" -- "What's the URL path where this issue is visible?" (for frontend) -- "Which component or module is involved?" -- "If you've debugged this before, what did you find?" - -**Note:** Score 1 is acceptable for many tickets — the agent can find files from component names. Score 0 means the agent will spend significant time just locating the right code. - -### 4. Acceptance Criteria (0-2) - -What the agent needs: how to know when it's done. - -| Score | Criteria | -|-------|----------| -| 0 | No acceptance criteria, no definition of done | -| 1 | Acceptance criteria implied in description but not explicit (e.g., "the button should be red" buried in a paragraph) | -| 2 | Explicit checklist of verifiable criteria (e.g., "- [ ] Button changes color to red on hover", "- [ ] Unit test added for new validation") | - -**Questions to ask at score 0-1:** - -- "How will you verify this is done? What should a reviewer check?" -- "Are there edge cases to handle?" -- "Should there be tests? What should they cover?" -- "Is there a visual change? Can you attach a screenshot or mockup?" - -### 5. Scope (0-2) - -What the agent needs: confidence that the work fits in a single PR. - -| Score | Criteria | -|-------|----------| -| 0 | Scope unclear — could be a 5-line fix or a 500-line refactor. Or explicitly multi-PR without decomposition | -| 1 | Likely single PR but not stated — reasonable inference from description | -| 2 | Clearly scoped: single concern, single repo, bounded change set. Or explicitly stated "single PR" | - -**Questions to ask at score 0:** - -- "How big do you think this change is? A few lines, a few files, or a larger refactor?" -- "Can this be done in a single PR, or should we split it?" -- "Are there dependencies — does something else need to land first?" - -**When to suggest splitting:** - -- Work spans 3+ repos -- Description contains "and also..." or "while we're at it..." -- Estimated change touches 10+ files across unrelated modules -- Mix of bug fix + feature work - -### 6. Type Clarity (0-2) - -What the agent needs: which problem-solving approach to use. - -| Score | Criteria | -|-------|----------| -| 0 | Can't tell if this is a bug, feature, refactor, CVE, or investigation | -| 1 | Type inferable from context but not explicit | -| 2 | Explicitly stated: bug with reproduction steps, feature with spec, CVE with ID, investigation with questions to answer | - -**Questions to ask at score 0:** - -- "Is this a bug fix, a new feature, a refactor, or a security fix?" -- For unclear bugs: "Can you describe the steps to reproduce?" -- For unclear features: "Is there a design or mockup?" - -## Description Template - -Use this template when rewriting the ticket description. Not all sections apply to every ticket — omit sections that aren't relevant. - -``` -## Problem - -<What is wrong or what needs to change. For bugs: current behavior vs expected behavior. For features: what should exist that doesn't. For CVEs: CVE ID, affected package, version.> - -## Context - -<Why this matters. Impact on users, systems, or other teams. Any relevant history or prior attempts.> - -## Location - -<Which repo(s), file(s), component(s), URL path(s) are involved. Be as specific as possible.> - -## Acceptance Criteria - -- [ ] <Verifiable criterion 1> -- [ ] <Verifiable criterion 2> -- [ ] <Tests: what should be tested> -- [ ] <Edge cases to handle> - -## Notes for the Agent - -<Anything that helps the agent avoid wrong turns: "Don't touch the legacy auth flow", "The test suite uses vitest not jest", "This component uses PatternFly 6". Only include if non-obvious.> -``` - -## Batch Scoring Output - -When running `--batch`: - -```markdown -## Agent-Readiness Scores - -| # | Key | Summary | Score | Problem | Repo | Files | AC | Scope | Type | Verdict | -|---|-----|---------|-------|---------|------|-------|----|-------|------|---------| -| 1 | KEY-123 | Fix notification... | 4/12 | 0 | 1 | 0 | 1 | 1 | 1 | Needs grooming | -| 2 | KEY-456 | Add dark mode... | 11/12 | 2 | 2 | 2 | 2 | 1 | 2 | Agent-ready | - -### Summary -- Agent-ready (10+): 3 tickets -- Needs minor work (7-9): 5 tickets -- Needs grooming (0-6): 2 tickets - -### Worst offenders (groom these first) -1. KEY-123 (4/12): Missing problem description and file paths -2. KEY-789 (5/12): No acceptance criteria, scope unclear -``` - -## Anti-patterns - -Things that make tickets bad for agents: - -| Anti-pattern | Why it's bad | Fix | -|--------------|-------------|-----| -| "Fix the X page" | Agent doesn't know what's broken | Add current vs expected behavior | -| Screenshot-only description | Agent can't read screenshots reliably | Add text description alongside screenshot | -| "See Slack thread" with link | Agent may not have Slack access | Copy relevant context into ticket | -| "Similar to PROJ-999" | Agent needs self-contained tickets | Copy the relevant parts, don't just reference | -| Multi-concern tickets | Agent produces unfocused PRs | Split into separate tickets | -| "Refactor X while fixing Y" | Mixes cleanup with bugfix | Separate tickets: fix first, refactor second | -| Implementation instructions | Over-constrains the agent, may be wrong | Describe the problem and outcome, not the solution | From 64b927d0fe7aea972a80500a87f5159147c723bb Mon Sep 17 00:00:00 2001 From: Marcel Hild <hild@b4mad.net> Date: Thu, 4 Jun 2026 14:54:24 +0200 Subject: [PATCH 4/5] feat(fullsend): add shared context references to SKILL.md Surface cross-skill dependencies (rhdh-repos, jira fields, JQL patterns, acli commands) at the routing level so Claude loads the right context before dispatching to groom or bridge sub-commands. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --- skills/fullsend/SKILL.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/skills/fullsend/SKILL.md b/skills/fullsend/SKILL.md index a4dfe0e..7a7ad07 100644 --- a/skills/fullsend/SKILL.md +++ b/skills/fullsend/SKILL.md @@ -45,7 +45,17 @@ Invoke with `/fullsend <command>`. Default (no args): show the command table bel | `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. From 1194d387b6e85f88de8acd98ce5d241dc523aa10 Mon Sep 17 00:00:00 2001 From: Marcel Hild <hild@b4mad.net> Date: Thu, 4 Jun 2026 15:56:47 +0200 Subject: [PATCH 5/5] docs(fullsend): add README with attribution to platform-frontend-ai-dev Credit the ConsoleDot Rehor bot as the inspiration for the grooming rubric, investigation workflow, and repo-mapping pattern. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --- skills/fullsend/README.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 skills/fullsend/README.md diff --git a/skills/fullsend/README.md b/skills/fullsend/README.md new file mode 100644 index 0000000..00bfa53 --- /dev/null +++ b/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).