/bug
Context
- This command helps create comprehensive bug reports for the OpenShift Console project
- Bug reports should be created in the OCPBUGS JIRA project with the "Management Console" component
- Bug branches should be created from the main branch (named
main in OpenShift projects)
- The codebase uses both frontend (TypeScript/React) and backend (Go) code
- SAFETY: This command should ONLY create new issues and branches - NEVER delete, modify, or overwrite existing JIRA issues or git branches
- Bug reports should follow Red Hat's issue reporting standards, which include these required sections:
- Description of problem: Clear explanation with technical details
- Version-Release number of selected component: OpenShift version where bug is observed
- How reproducible: Always, Sometimes, Rarely, or Unknown
- Steps to reproduce: Numbered list of exact steps
- Actual results: What actually happens
- Expected results: What should happen
- Additional info: Technical details, code references, impact, workarounds
Instructions
You are a senior engineer helping to document and fix bugs in the OpenShift Console. When the user invokes this command, follow these steps:
Step 0: Check for Bug Description
If no bug description was provided as an argument:
- Use the AskUserQuestion tool to ask the user to describe the bug they want to report
- Ask: "What bug would you like to report? Please provide a short description of the observed behavior."
- Wait for their response before proceeding to Step 1
If a bug description was provided, proceed directly to Step 1.
Step 1: Investigate the Issue
- Use the codebase as reference to understand and confirm the observed behavior
- Search for relevant code that relates to the reported issue
- Identify the root cause or likely cause of the problem
- Determine which component(s) are affected (frontend/backend)
Step 2: Write a Complete Bug Report
Create a detailed bug report with the following sections:
Title: A concise, descriptive title (max 100 characters)
Description of problem:
- Clear explanation of what the issue is
- Include technical details about what's happening incorrectly
- Reference specific files and line numbers when possible (use format
file_path:line_number)
Version-Release number:
- Ask for the earliest OpenShift version this bug is observed in, if none is provided through the command arguments
How reproducible:
- Always
- Sometimes
- Rarely
- Unknown
(Choose based on the nature of the bug)
Steps to Reproduce:
- Numbered list of exact steps to reproduce the issue
- Be specific about UI interactions, API calls, or system states
- Include any necessary preconditions
Actual results:
- What actually happens when following the steps
- Include error messages, incorrect UI states, console errors, etc.
Expected results:
- What should happen instead
- Reference correct behavior from similar features if applicable
Additional info:
- Any relevant technical details (stack traces, network requests, etc.)
- Related code references with file:line format
- Potential impact on users
- Any workarounds that exist
Step 3: Check for Jira CLI
After writing the bug report, check if the jira CLI command is available:
- Run
which jira to check for the Jira CLI
- If available, offer to create the bug in JIRA using the command:
jira issue create --project OCPBUGS --type Bug --component "Management Console" --summary "<title>" --body "<description>"
- If not available, inform the user they'll need to create the issue manually in JIRA
CRITICAL SAFETY RULES:
- ONLY use
jira issue create to create NEW issues
- NEVER use commands that modify existing issues (like
jira issue edit, jira issue update, jira issue delete)
- NEVER overwrite or delete existing JIRA issues
- If an issue already exists, reference it but do not modify it
Step 4: Offer to Create a Branch
If the user wants to proceed with a fix:
- Offer to create a new git branch from main
- Suggest a branch name in the format:
OCPBUGS-<issue-number>-<short-description>
- If the JIRA issue doesn't exist yet, suggest a descriptive branch name and note that it should be renamed after JIRA issue creation
CRITICAL SAFETY RULES:
- ONLY create NEW branches
- NEVER delete existing branches (like
git branch -D or git push --delete)
- NEVER force push (like
git push --force or git push -f)
- If a branch with the suggested name already exists, suggest a different name instead of overwriting
Step 5: Propose a Fix
After creating the branch (if requested):
- Analyze the root cause based on your investigation
- Propose a specific fix with code changes
- Explain why this fix addresses the issue
- Consider adding a test case when appropriate:
- If the bug is in testable logic, suggest writing a test that would have caught this bug
- The test should include a comment with a link to the JIRA issue
- For frontend tests: Add a comment like
// Regression test for OCPBUGS-XXXXX: https://issues.redhat.com/browse/OCPBUGS-XXXXX
- For backend Go tests: Add a comment like
// Regression test for OCPBUGS-XXXXX: https://issues.redhat.com/browse/OCPBUGS-XXXXX
- Explain what edge case or scenario the test covers
- Ensure the test fails before the fix and passes after the fix
- If a test is not practical (e.g., pure UI/styling bugs, race conditions, or integration issues), explain why and suggest manual testing steps instead
- Highlight if the fix requires both frontend and backend changes
- Remind about running tests and linting before creating a PR
Output Format
Present the bug report in a clear, formatted markdown block that can be easily copied to JIRA. Use this structure:
## [BUG TITLE]
**Description of problem:**
[Description]
**Version-Release number:**
[Version]
**How reproducible:**
[Always/Sometimes/Rarely/Unknown]
**Steps to Reproduce:**
1. [Step 1]
2. [Step 2]
3. [Step 3]
**Actual results:**
[What happens]
**Expected results:**
[What should happen]
**Additional info:**
[Technical details, code references, etc.]
Important Notes
Safety and Permissions
- CRITICAL: This command should ONLY perform CREATE operations - NEVER delete, modify, or overwrite existing resources
- JIRA Safety: Only use
jira issue create - NEVER use edit, update, or delete commands on existing issues
- Git Safety: Only create new branches - NEVER delete branches or force push
- User Confirmation: Don't create branches or JIRA issues without explicit user confirmation
- If any resource already exists (issue, branch, etc.), suggest alternatives instead of modifying or overwriting
Investigation and Reporting
- Be thorough in your investigation before writing the bug report
- Use the Task tool with subagent_type=Explore if you need to explore the codebase extensively
- Always verify your findings by reading actual code files
- Include specific file paths and line numbers in your references
- Consider both frontend and backend implications
- Follow the Red Hat style guide for all text in the bug report
- Consider adding a test case when appropriate - When the bug involves testable logic, suggest a regression test that:
- Would have caught the bug if it existed before the bug was introduced
- Includes a comment linking to the JIRA issue (e.g.,
// Regression test for OCPBUGS-12345: https://issues.redhat.com/browse/OCPBUGS-12345)
- Documents the specific edge case or scenario being tested
- For frontend: Use React Testing Library patterns, following existing test conventions in the codebase
- For backend: Follow Go testing conventions with descriptive test names and table-driven tests where appropriate
- If automated testing is not practical, explain why and suggest manual testing steps instead
- After proposing a fix, remind the user about the standard development workflow:
- Run linting:
cd frontend && yarn lint (for frontend changes)
- Run tests:
cd frontend && yarn test (for frontend changes)
- Run backend tests:
./test-backend.sh (for backend changes)
- Update i18n:
cd frontend && yarn i18n (if user-facing text changed)
- Create commit with descriptive message
- Push and create PR
Example Interaction
User: /bug The namespace selector dropdown shows duplicates
1---2name: bug3description: Bug4---56# /bug78## Context9- This command helps create comprehensive bug reports for the OpenShift Console project10- Bug reports should be created in the OCPBUGS JIRA project with the "Management Console" component11- Bug branches should be created from the main branch (named `main` in OpenShift projects)12- The codebase uses both frontend (TypeScript/React) and backend (Go) code13- **SAFETY**: This command should ONLY create new issues and branches - NEVER delete, modify, or overwrite existing JIRA issues or git branches14- Bug reports should follow Red Hat's issue reporting standards, which include these required sections:15 - **Description of problem**: Clear explanation with technical details16 - **Version-Release number of selected component**: OpenShift version where bug is observed17 - **How reproducible**: Always, Sometimes, Rarely, or Unknown18 - **Steps to reproduce**: Numbered list of exact steps19 - **Actual results**: What actually happens20 - **Expected results**: What should happen21 - **Additional info**: Technical details, code references, impact, workarounds2223## Instructions2425You are a senior engineer helping to document and fix bugs in the OpenShift Console. When the user invokes this command, follow these steps:2627### Step 0: Check for Bug Description2829If no bug description was provided as an argument:301. Use the AskUserQuestion tool to ask the user to describe the bug they want to report312. Ask: "What bug would you like to report? Please provide a short description of the observed behavior."323. Wait for their response before proceeding to Step 13334If a bug description was provided, proceed directly to Step 1.3536### Step 1: Investigate the Issue371. Use the codebase as reference to understand and confirm the observed behavior382. Search for relevant code that relates to the reported issue393. Identify the root cause or likely cause of the problem404. Determine which component(s) are affected (frontend/backend)4142### Step 2: Write a Complete Bug Report4344Create a detailed bug report with the following sections:4546**Title**: A concise, descriptive title (max 100 characters)4748**Description of problem**:49- Clear explanation of what the issue is50- Include technical details about what's happening incorrectly51- Reference specific files and line numbers when possible (use format `file_path:line_number`)5253**Version-Release number**:54- Ask for the earliest OpenShift version this bug is observed in, if none is provided through the command arguments5556**How reproducible**:57- Always58- Sometimes59- Rarely60- Unknown61(Choose based on the nature of the bug)6263**Steps to Reproduce**:641. Numbered list of exact steps to reproduce the issue652. Be specific about UI interactions, API calls, or system states663. Include any necessary preconditions6768**Actual results**:69- What actually happens when following the steps70- Include error messages, incorrect UI states, console errors, etc.7172**Expected results**:73- What should happen instead74- Reference correct behavior from similar features if applicable7576**Additional info**:77- Any relevant technical details (stack traces, network requests, etc.)78- Related code references with file:line format79- Potential impact on users80- Any workarounds that exist8182### Step 3: Check for Jira CLI8384After writing the bug report, check if the `jira` CLI command is available:851. Run `which jira` to check for the Jira CLI862. If available, offer to create the bug in JIRA using the command:87 ```88 jira issue create --project OCPBUGS --type Bug --component "Management Console" --summary "<title>" --body "<description>"89 ```903. If not available, inform the user they'll need to create the issue manually in JIRA9192**CRITICAL SAFETY RULES:**93- ONLY use `jira issue create` to create NEW issues94- NEVER use commands that modify existing issues (like `jira issue edit`, `jira issue update`, `jira issue delete`)95- NEVER overwrite or delete existing JIRA issues96- If an issue already exists, reference it but do not modify it9798### Step 4: Offer to Create a Branch99100If the user wants to proceed with a fix:1011. Offer to create a new git branch from main1022. Suggest a branch name in the format: `OCPBUGS-<issue-number>-<short-description>`1033. If the JIRA issue doesn't exist yet, suggest a descriptive branch name and note that it should be renamed after JIRA issue creation104105**CRITICAL SAFETY RULES:**106- ONLY create NEW branches107- NEVER delete existing branches (like `git branch -D` or `git push --delete`)108- NEVER force push (like `git push --force` or `git push -f`)109- If a branch with the suggested name already exists, suggest a different name instead of overwriting110111### Step 5: Propose a Fix112113After creating the branch (if requested):1141. Analyze the root cause based on your investigation1152. Propose a specific fix with code changes1163. Explain why this fix addresses the issue1174. **Consider adding a test case when appropriate**:118 - If the bug is in testable logic, suggest writing a test that would have caught this bug119 - The test should include a comment with a link to the JIRA issue120 - For frontend tests: Add a comment like `// Regression test for OCPBUGS-XXXXX: https://issues.redhat.com/browse/OCPBUGS-XXXXX`121 - For backend Go tests: Add a comment like `// Regression test for OCPBUGS-XXXXX: https://issues.redhat.com/browse/OCPBUGS-XXXXX`122 - Explain what edge case or scenario the test covers123 - Ensure the test fails before the fix and passes after the fix124 - If a test is not practical (e.g., pure UI/styling bugs, race conditions, or integration issues), explain why and suggest manual testing steps instead1255. Highlight if the fix requires both frontend and backend changes1266. Remind about running tests and linting before creating a PR127128## Output Format129130Present the bug report in a clear, formatted markdown block that can be easily copied to JIRA. Use this structure:131132```133## [BUG TITLE]134135**Description of problem:**136[Description]137138**Version-Release number:**139[Version]140141**How reproducible:**142[Always/Sometimes/Rarely/Unknown]143144**Steps to Reproduce:**1451. [Step 1]1462. [Step 2]1473. [Step 3]148149**Actual results:**150[What happens]151152**Expected results:**153[What should happen]154155**Additional info:**156[Technical details, code references, etc.]157```158159## Important Notes160161### Safety and Permissions162- **CRITICAL**: This command should ONLY perform CREATE operations - NEVER delete, modify, or overwrite existing resources163- **JIRA Safety**: Only use `jira issue create` - NEVER use edit, update, or delete commands on existing issues164- **Git Safety**: Only create new branches - NEVER delete branches or force push165- **User Confirmation**: Don't create branches or JIRA issues without explicit user confirmation166- If any resource already exists (issue, branch, etc.), suggest alternatives instead of modifying or overwriting167168### Investigation and Reporting169- Be thorough in your investigation before writing the bug report170- Use the Task tool with subagent_type=Explore if you need to explore the codebase extensively171- Always verify your findings by reading actual code files172- Include specific file paths and line numbers in your references173- Consider both frontend and backend implications174- Follow the Red Hat style guide for all text in the bug report175- **Consider adding a test case when appropriate** - When the bug involves testable logic, suggest a regression test that:176 - Would have caught the bug if it existed before the bug was introduced177 - Includes a comment linking to the JIRA issue (e.g., `// Regression test for OCPBUGS-12345: https://issues.redhat.com/browse/OCPBUGS-12345`)178 - Documents the specific edge case or scenario being tested179 - For frontend: Use React Testing Library patterns, following existing test conventions in the codebase180 - For backend: Follow Go testing conventions with descriptive test names and table-driven tests where appropriate181 - If automated testing is not practical, explain why and suggest manual testing steps instead182- After proposing a fix, remind the user about the standard development workflow:183 - Run linting: `cd frontend && yarn lint` (for frontend changes)184 - Run tests: `cd frontend && yarn test` (for frontend changes)185 - Run backend tests: `./test-backend.sh` (for backend changes)186 - Update i18n: `cd frontend && yarn i18n` (if user-facing text changed)187 - Create commit with descriptive message188 - Push and create PR189190## Example Interaction191192User: `/bug The namespace selector dropdown shows duplicates`