Merge pull request #2 from RedHatInsights/update-instructions

justinorringer · web-flow · commit f3c4209ea195 · 2026-04-07T13:05:17.000-04:00
Add dynamic persona selection
diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md
@@ -89,7 +89,7 @@ The actual intelligence. Claude Code is spawned as a subprocess by the Agent SDK
 - **Prompt**: `"Your primary label is: <label>. Follow the instructions in CLAUDE.md."`
 - **CLAUDE.md**: detailed behavioral instructions covering the full workflow (priority system, PR maintenance, ticket claiming, implementation guidelines, memory usage, progress tracking)
 - **Tools**: Built-in (Read, Write, Edit, Bash, Grep, Glob, LSP) + MCP tools (Jira, memory, browser)
-- **Persona prompts**: Loaded from `personas/<type>/prompt.md` based on which repo it's working in
+- **Persona prompts**: Loaded from `personas/<type>/prompt.md` based on the ticket's nature and repo tech stack
 
 The agent has no persistent state between cycles. All state is stored in the memory server (task records) and reconstructed at the start of each cycle.
 
@@ -132,16 +132,17 @@ Runs as two Docker containers:
 
 Domain-specific guidelines that tell the agent how to work in different types of repos. Each persona is a markdown file with coding standards, testing commands, and conventions.
 
-| Persona | Repos | Key Details |
-|---------|-------|-------------|
+| Persona | Applies to | Key Details |
+|---------|------------|-------------|
 | `frontend` | React/TS/PatternFly apps | `npm run lint/test`, visual verification via browser MCP, PatternFly component MCP |
 | `backend` | Go and Node.js services | `make test` / `npm test`, Go conventions |
 | `rbac` | insights-rbac (Django/DRF) | Docker Compose dev env, `make unittest-fast`, PostgreSQL + Redis + Celery |
 | `operator` | Kubernetes operators | Go, controller-runtime patterns |
-| `config` | app-interface | GitLab fork workflow, read-only or MR-based |
-| `cve` | CVE remediation | Dependency upgrades, grype scanning |
+| `config` | Config/YAML repos (e.g. app-interface) | GitLab fork workflow, read-only or MR-based |
+| `cve` | CVE remediation (any repo) | Dependency upgrades, base image updates, grype scanning |
+| `tooling` | Build/dev infrastructure | Dockerfiles, shell scripts, proxy configs |
 
-A repo can have multiple personas (e.g. `["frontend", "cve"]`). The agent picks the best fit based on the ticket description.
+Personas are NOT hardcoded to repos. The bot dynamically selects the best-fit persona(s) based on the ticket description and the repo's tech stack (e.g. `package.json` → frontend, `go.mod` → backend/operator, Dockerfile-only → tooling). CVE persona layers on top of the base persona.
 
 ### Target Repos (`repos/`)
 
@@ -150,13 +151,11 @@ Cloned on demand when the bot picks up a ticket. Repo metadata is in `project-re
 ```json
 {
   "notifications-frontend": {
-    "url": "git@github.com:RedHatInsights/notifications-frontend.git",
-    "personas": ["frontend", "cve"]
+    "url": "git@github.com:RedHatInsights/notifications-frontend.git"
   },
   "app-interface": {
     "url": "git@gitlab.cee.redhat.com:yourfork/app-interface.git",
     "upstream": "git@gitlab.cee.redhat.com:service/app-interface.git",
-    "personas": ["config"],
     "host": "gitlab"
   }
 }
@@ -165,7 +164,6 @@ Cloned on demand when the bot picks up a ticket. Repo metadata is in `project-re
 Fields:
 - `url` — git clone URL (may be a fork)
 - `upstream` — (optional) original repo URL. Bot syncs from upstream, pushes to fork, opens MRs against upstream
-- `personas` — applicable persona types
 - `host` — `"gitlab"` for GitLab repos (default: GitHub)
 - `readonly` — if `true`, bot reads only, never pushes
 
diff --git a/CLAUDE.md b/CLAUDE.md
@@ -266,7 +266,6 @@ Before starting work on a ticket, use `jira_get_issue` to read the full ticket i
 5. **Prepare the repos**: Collect all `repo:` labels from the ticket. For each one, match it to `project-repos.json` to find the repo config. Each repo has:
    - `url` — the git clone URL (may be a fork — see `upstream` below)
    - `upstream` (optional) — the upstream repo URL. When present, `url` is a **fork** and `upstream` is the original repo. The bot clones from `url`, syncs from `upstream`, and opens MRs targeting the upstream repo.
-   - `personas` — array of applicable persona types (e.g. `["frontend", "cve"]`). A repo can have multiple personas — pick the one most relevant to the ticket at hand.
    - `host` (optional) — `"gitlab"` for GitLab repos. If absent, the repo is on GitHub.
    - `readonly` (optional) — if `true`, do not push or open PRs in this repo, only read it for context
 
@@ -304,15 +303,28 @@ Before starting work on a ticket, use `jira_get_issue` to read the full ticket i
 
    **Read repo-level instructions**: After entering each repo, check if it contains a `CLAUDE.md` file at its root. If it does, read it in full. If that file references other instruction files (e.g. `@AGENTS.md`), read those too. These contain critical repo-specific architectural guidance, coding standards, and constraints. Follow them alongside the persona guidelines. **When repo-level instructions conflict with persona guidelines, the repo-level instructions take precedence** — they are written by the repo maintainers and reflect the ground truth for that codebase.
 
-6. **Load personas**: Each repo in `project-repos.json` has a `personas` array listing all applicable persona types. For the ticket at hand:
-
-   - **Select the best-fit persona** for each repo based on the ticket description. For example, if a repo has `["frontend", "cve"]` and the ticket is about a CVE fix, use the `cve` persona. If it's about a UI change, use `frontend`. If unclear, load all and apply the most relevant guidelines.
-   - For each selected persona, read `personas/<persona>/prompt.md`.
-   - If a ticket spans multiple repos with different personas, load ALL relevant persona prompts upfront.
-
-   **Persona scoping**: Each persona's guidelines apply ONLY when working in repos where that persona was selected. For example:
-   - Frontend persona rules (PatternFly, visual verification, `npm run lint`) apply when using the `frontend` persona.
-   - Backend persona rules apply when using the `backend` persona.
+6. **Load personas**: Personas are NOT hardcoded to repos. Instead, select the right persona(s) dynamically based on the ticket and the repo's tech stack.
+
+   **How to pick personas:**
+   1. List available personas by scanning the `personas/` directory for subdirectories containing `prompt.md`.
+   2. Inspect each repo to determine its tech stack:
+      - Has `package.json` with React/PatternFly dependencies → likely needs `frontend`
+      - Has `go.mod` → likely needs `backend` (Go) or `operator` (if it's a K8s operator)
+      - Has `Pipfile` or `requirements.txt` with Django → likely needs `backend` or a repo-specific persona (e.g. `rbac`)
+      - Has only Dockerfiles, shell scripts, Caddyfiles → likely needs `tooling`
+      - Is a config/YAML repo (e.g. app-interface) → likely needs `config`
+   3. Consider the ticket's nature:
+      - CVE/security vulnerability ticket → also load `cve` persona (applies on top of the repo's base persona)
+      - RBAC-specific ticket for insights-rbac → load `rbac` persona
+      - Ticket about K8s operator CRDs/controllers → load `operator` persona
+   4. Read `personas/<persona>/prompt.md` for each selected persona.
+   5. If a ticket spans multiple repos with different tech stacks, load ALL relevant personas upfront.
+
+   **Persona scoping**: Each persona's guidelines apply ONLY when working in repos where that persona is relevant. For example:
+   - Frontend persona rules (PatternFly, visual verification, `npm run lint`) apply only in React/frontend repos.
+   - Backend persona rules apply only in Go/Node.js service repos.
+   - Tooling persona rules apply only in build/infra repos with Dockerfiles and scripts.
+   - CVE persona guidelines layer on top of the base persona — they don't replace it.
    - Do NOT apply frontend-specific rules (e.g. visual verification) to backend work, or vice versa.
 
    **Cross-repo coordination**: When a ticket requires changes across multiple repos, plan the work holistically before starting:
diff --git a/README.md b/README.md
@@ -138,8 +138,7 @@ The bot is a good developer but has zero tribal knowledge. Don't assume it knows
 1. Add to `project-repos.json`:
    ```json
    "my-repo": {
-     "url": "git@github.com:RedHatInsights/my-repo.git",
-     "personas": ["frontend"]
+     "url": "git@github.com:RedHatInsights/my-repo.git"
    }
    ```
 2. Add a `repo:my-repo` label to the Jira ticket
@@ -154,25 +153,15 @@ If the bot doesn't have push access to the upstream repo, use a fork:
 "app-interface": {
   "url": "git@gitlab.cee.redhat.com:youruser/app-interface.git",
   "upstream": "git@gitlab.cee.redhat.com:service/app-interface.git",
-  "personas": ["config"],
   "host": "gitlab"
 }
 ```
 
 The bot clones from the fork, syncs from upstream, pushes branches to the fork, and opens MRs targeting the upstream repo.
 
-### Multi-persona repos
+### Persona selection
 
-A repo can support multiple personas. The bot selects the best fit based on the ticket:
-
-```json
-"insights-rbac": {
-  "url": "git@github.com:RedHatInsights/insights-rbac.git",
-  "personas": ["backend", "rbac"]
-}
-```
-
-If a ticket is about RBAC-specific Django work, the bot loads the `rbac` persona. For generic backend work, it uses `backend`.
+Personas are NOT hardcoded to repos. The bot dynamically selects the best-fit persona(s) based on the ticket description and the repo's tech stack (e.g. `package.json` → `frontend`, `go.mod` → `backend`/`operator`, Dockerfile-only → `tooling`, config repo → `config`). For CVE tickets, the `cve` persona layers on top of the base persona.
 
 ## Running the services
 
@@ -262,7 +251,8 @@ Each repo has one or more personas that provide domain-specific guidelines. Pers
 | `rbac` | Django/DRF RBAC service (insights-rbac). Docker Compose dev env, `make unittest-fast`. |
 | `operator` | Kubernetes operators (Go). |
 | `config` | Config repos (app-interface). Read-only or GitLab MR workflow. |
-| `cve` | CVE remediation — dependency upgrades and security scanning. |
+| `cve` | CVE remediation — dependency upgrades, base image updates, security scanning. |
+| `tooling` | Build/dev infrastructure — Dockerfiles, shell scripts, proxy configs. |
 
 ## Memory system
 
diff --git a/bot/config.py b/bot/config.py
@@ -113,6 +113,7 @@ def sanitize_env() -> None:
     "mcp__mcp-atlassian__jira_get_sprints_from_board",
     "mcp__mcp-atlassian__jira_add_issues_to_sprint",
     "mcp__mcp-atlassian__jira_create_issue",
+    "mcp__mcp-atlassian__jira_create_issue_link",
     "mcp__mcp-atlassian__jira_get_field_options",
     # Wildcard MCP tools
     "mcp__hcc-patternfly-data-view__*",
diff --git a/personas/tooling/prompt.md b/personas/tooling/prompt.md
@@ -0,0 +1,52 @@
+## Tooling & Build Infrastructure Guidelines
+
+You are working on a build/dev tooling repo — Dockerfiles, shell scripts, proxy configs, CI pipelines, and similar infrastructure that supports frontend and backend applications.
+
+### General
+
+- These repos are NOT application code. They are shared infrastructure used by many teams.
+- Changes here have a wide blast radius — a broken build image or proxy affects all frontend apps.
+- Follow existing patterns. These repos prioritize stability over cleverness.
+- Read the repo's `README.md` and any docs for repo-specific conventions.
+
+### Dockerfiles
+
+- Use multi-stage builds where appropriate.
+- Prefer UBI (Universal Base Image) base images for production.
+- Keep images minimal — only install what's needed.
+- Never hardcode secrets or tokens in Dockerfiles. Use build args or mounted secrets.
+- Pin base image versions to specific tags, not `latest`.
+- Run as non-root user where possible.
+
+### Shell scripts
+
+- Use `set -euo pipefail` at the top of scripts.
+- Quote all variables: `"${VAR}"` not `$VAR`.
+- Use `shellcheck` if available to lint scripts.
+- Add comments explaining non-obvious logic — these scripts are maintained by many people.
+- Test scripts locally before committing.
+
+### Proxy / Caddy / NGINX configs
+
+- Test config changes against a real running instance if possible.
+- Be careful with route ordering — more specific routes before catch-alls.
+- Document any new environment variables or config options.
+
+### Go plugins (e.g. Caddy modules)
+
+- Follow Go conventions: `go vet`, `gofmt`, table-driven tests.
+- Use `go build` to verify compilation.
+- Run `go test ./...` for any Go code.
+
+### Testing
+
+- For shell scripts: test edge cases (missing files, empty vars, special characters).
+- For Dockerfiles: build the image and verify it starts correctly.
+- For config changes: validate syntax before committing.
+- Run any existing test suites: check for `test/`, `Makefile` targets, or CI scripts.
+
+### CVE fixes in these repos
+
+- CVEs here are typically in base images or system packages, not application dependencies.
+- Fix by updating the base image tag or adding explicit `dnf update` / `apk upgrade` for affected packages.
+- Verify the CVE is actually resolved in the new image by checking package versions.
diff --git a/project-repos.json b/project-repos.json
@@ -1,60 +1,79 @@
 {
   "insights-chrome": {
-    "url": "git@github.com:RedHatInsights/insights-chrome.git",
-    "personas": ["frontend", "cve"]
+    "url": "git@github.com:RedHatInsights/insights-chrome.git"
   },
   "astro-virtual-assistant-frontend": {
-    "url": "git@github.com:RedHatInsights/astro-virtual-assistant-frontend.git",
-    "personas": ["frontend"]
+    "url": "git@github.com:RedHatInsights/astro-virtual-assistant-frontend.git"
   },
   "widget-layout": {
-    "url": "git@github.com:RedHatInsights/widget-layout.git",
-    "personas": ["frontend"]
+    "url": "git@github.com:RedHatInsights/widget-layout.git"
   },
   "widget-layout-backend": {
-    "url": "git@github.com:RedHatInsights/widget-layout-backend.git",
-    "personas": ["backend"]
+    "url": "git@github.com:RedHatInsights/widget-layout-backend.git"
   },
   "notifications-frontend": {
-    "url": "git@github.com:RedHatInsights/notifications-frontend.git",
-    "personas": ["frontend", "cve"]
+    "url": "git@github.com:RedHatInsights/notifications-frontend.git"
   },
   "frontend-operator": {
-    "url": "git@github.com:RedHatInsights/frontend-operator.git",
-    "personas": ["operator"]
+    "url": "git@github.com:RedHatInsights/frontend-operator.git"
   },
   "app-interface": {
     "url": "git@gitlab.cee.redhat.com:mmarosi/app-interface.git",
     "upstream": "git@gitlab.cee.redhat.com:service/app-interface.git",
-    "personas": ["config"],
     "host": "gitlab"
   },
   "quickstarts": {
-    "url": "git@github.com:RedHatInsights/quickstarts.git",
-    "personas": ["backend"]
+    "url": "git@github.com:RedHatInsights/quickstarts.git"
   },
   "learning-resources": {
-    "url": "git@github.com:RedHatInsights/learning-resources.git",
-    "personas": ["frontend"]
+    "url": "git@github.com:RedHatInsights/learning-resources.git"
   },
   "payload-tracker-frontend": {
-    "url": "git@github.com:RedHatInsights/payload-tracker-frontend.git",
-    "personas": ["frontend", "cve"]
+    "url": "git@github.com:RedHatInsights/payload-tracker-frontend.git"
   },
   "pdf-generator": {
-    "url": "git@github.com:RedHatInsights/pdf-generator.git",
-    "personas": ["backend", "cve"]
+    "url": "git@github.com:RedHatInsights/pdf-generator.git"
   },
   "chrome-service-backend": {
-    "url": "git@github.com:RedHatInsights/chrome-service-backend.git",
-    "personas": ["backend"]
+    "url": "git@github.com:RedHatInsights/chrome-service-backend.git"
   },
   "astro-virtual-assistant-v2": {
-    "url": "git@github.com:RedHatInsights/astro-virtual-assistant-v2.git",
-    "personas": ["backend"]
+    "url": "git@github.com:RedHatInsights/astro-virtual-assistant-v2.git"
   },
   "insights-rbac": {
-    "url": "git@github.com:RedHatInsights/insights-rbac.git",
-    "personas": ["backend", "rbac"]
+    "url": "git@github.com:RedHatInsights/insights-rbac.git"
+  },
+  "javascript-clients": {
+    "url": "git@github.com:RedHatInsights/javascript-clients.git"
+  },
+  "frontend-components": {
+    "url": "git@github.com:RedHatInsights/frontend-components.git"
+  },
+  "patchman-ui": {
+    "url": "git@github.com:RedHatInsights/patchman-ui.git"
+  },
+  "insights-advisor-frontend": {
+    "url": "git@github.com:RedHatInsights/insights-advisor-frontend.git"
+  },
+  "ocp-advisor-frontend": {
+    "url": "git@github.com:RedHatInsights/ocp-advisor-frontend.git"
+  },
+  "insights-remediations-frontend": {
+    "url": "git@github.com:RedHatInsights/insights-remediations-frontend.git"
+  },
+  "insights-inventory-frontend": {
+    "url": "git@github.com:RedHatInsights/insights-inventory-frontend.git"
+  },
+  "malware-detection-frontend": {
+    "url": "git@github.com:RedHatInsights/malware-detection-frontend.git"
+  },
+  "vuln4shift-frontend": {
+    "url": "git@github.com:RedHatInsights/vuln4shift-frontend.git"
+  },
+  "insights-frontend-builder-common": {
+    "url": "git@github.com:RedHatInsights/insights-frontend-builder-common.git"
+  },
+  "frontend-development-proxy": {
+    "url": "git@github.com:RedHatInsights/frontend-development-proxy.git"
   }
 }
