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/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 ` | Score and improve a Jira ticket against a 6-dimension agent-readiness rubric | +| `bridge ` | 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). diff --git a/skills/fullsend/SKILL.md b/skills/fullsend/SKILL.md new file mode 100644 index 0000000..7a7ad07 --- /dev/null +++ b/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 `. Default (no args): show the command table below. + +## Commands + +| Command | Description | Reference | +|---------|-------------|-----------| +| `groom ` | Score + improve Jira ticket for agent-readiness | `references/groom.md` | +| `bridge ` | Create GitHub Issue from groomed ticket | `references/bridge.md` | + +### Modes + +- `groom ` — interactive grooming session +- `groom --quick` — score only, no conversation +- `groom --batch ` — score multiple tickets +- `bridge ` — bridge single ticket to GitHub +- `bridge --dry-run` — preview without mutation +- `bridge --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. 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 # Bridge to auto-detected repo +/fullsend bridge --repo owner/name # Bridge to specific repo +/fullsend bridge --dry-run # Preview, no mutations +/fullsend bridge --batch --repo owner/name # Bridge multiple tickets +``` + +## Workflow + +### Step 1 — Fetch and Validate the Jira 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 groom rubric +(see `references/groom.md`). If score < 7: + +> "This ticket scores {score}/12 on agent-readiness. Run `/fullsend 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, 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 --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 #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 \ + --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