---
description: Analyze a JIRA issue and create a pull request to solve it.
---

## Name
jira:solve

## Synopsis
```
/jira:solve <jira-issue-id> [remote]
```

## Description

The `jira:solve` command analyzes a JIRA issue and creates a pull request to solve it.

This command takes a JIRA URL, fetches the issue description and requirements, analyzes the codebase to understand how to implement the solution, and creates a comprehensive pull request with the necessary changes.

**Usage Examples:**

1. **Solve a specific JIRA issue**:
   ```
   /jira:solve OCPBUGS-12345 origin
   ```

## Implementation

- The command uses curl to fetch JIRA data via REST API: https://issues.redhat.com/rest/api/2/issue/{$1}
- Parses JSON response using jq or text processing
- Extracts key fields: summary, description, components, labels
- No authentication required for public Red Hat JIRA issues
- Creates a PR with the solution

### Process Flow

1. **Issue Analysis**: Parse JIRA URL and fetch issue details:
   - Use curl to fetch JIRA issue data: curl -s "https://issues.redhat.com/rest/api/2/issue/{$1}"
   - Parse JSON response to extract:
      - Issue summary and description
      - From within the description expect the following sections
         - Required
            - Context
            - Acceptance criteria
         - Optional
            - Steps to reproduce (for bugs)
            - Expected vs actual behavior
   - Ask the user for further issue grooming if the requried sections are missing

2. **Codebase Analysis**: Search and analyze relevant code:
   - Find related files and functions
   - Understand current implementation
   - Identify areas that need changes
   - Use Grep and Glob tools to search for:
      - Related function names mentioned in JIRA
      - File patterns related to the component
      - Similar existing implementations
      - Test files that need updates

3. **Solution Implementation**:
   - Think hard and create a detailed, step-by-step plan to implement this feature. Save it to spec-$1.md within the .work/jira/solve folder, for example .work/jira/solve/spec-OCPBUGS-12345.md
   - Always ask the user to review the plan and give them the choice to modify it before start the implementation
   - Implement the plan:
    - Make necessary code changes using Edit/MultiEdit tools
    - Follow existing code patterns and conventions
    - Add or update tests as needed
    - Update documentation if needed within the docs/ folder
    - If the problem is too complex consider delegating to one of the SME agents.
    - Ensure godoc comments are generated for any newly created public functions
      - Use your best judgement if godoc comments are needed for private functions
      - For example, a comment should not be generated for a simple function like func add(int a, b) int { return a + b}
    - Create unit tests for any newly created functions
  - After making code changes, verify the implementation based on the repository's tooling:
    - **Check for Makefile**: Run `ls Makefile` to see if one exists
    - **If Makefile exists**: Check available targets with `make help` or `grep '^[^#]*:' Makefile | head -20`
    - **Run appropriate verification commands**:
      - If `make lint-fix` exists: Run it to ensure imports are properly sorted and linting issues are fixed
      - If `make verify`, `make build`, `make test` exist: Run these to ensure code builds and passes tests
      - If no Makefile or make targets: Look for alternative commands:
        - Go projects: `go fmt ./...`, `go vet ./...`, `go test ./...`, `go build ./...`
        - Node.js: `npm test`, `npm run build`, `npm run lint`
        - Python: `pytest`, `python -m unittest`, `pylint`, `black .`
        - Other: Follow repository conventions in CI config files (.github/workflows/, .gitlab-ci.yml, etc.)
    - **Never assume make targets exist** - always verify first
    - **You must ensure verification passes** before proceeding to "Commit Creation"

4. **Commit Creation**: 
   - Create feature branch using the jira-key $1 as the branch name. For example: "git checkout -b fix-{jira-key}"
   - Break commits into logical components based on the nature of the changes
   - Each commit should honor https://www.conventionalcommits.org/en/v1.0.0/ and always include a commit message body articulating the "why"
   - Use your judgment to organize commits in a way that makes them easy to review and understand
   - Common logical groupings (use as guidance, not rigid rules):
     - API changes: Changes in `api/` directory (types, CRDs)
       - Example: `git commit -m"feat(api): Update HostedCluster API for X" -m"Add new fields to support Y functionality"`
     - Vendor changes: Dependency updates in `vendor/` directory
       - Example: `git commit -m"chore(vendor): Update dependencies for X" -m"Required to pick up bug fixes in upstream library Y"`
     - Generated code: Auto-generated clients, informers, listers, and CRDs
       - Example: `git commit -m"chore(generated): Regenerate clients and CRDs" -m"Regenerate after API changes to ensure client code is in sync"`
     - CLI changes: User-facing command changes in `cmd/` directory
       - Example: `git commit -m"feat(cli): Add support for X flag" -m"This allows users to configure Y behavior at cluster creation time"`
     - Operator changes: Controller logic in `operator/` or `controllers/`
       - Example: `git commit -m"feat(operator): Implement X controller logic" -m"Without this the controller won't reconcile when Y condition occurs"`
     - Support/utilities: Shared code in `support/` directory
       - Example: `git commit -m"refactor(support): Extract common X utility" -m"Consolidate duplicated logic from multiple controllers into shared helper"`
     - Tests: Test additions or modifications
       - Example: `git commit -m"test: Add tests for X functionality" -m"Ensure the new behavior is covered by unit tests to prevent regressions"`
     - Documentation: Changes in `docs/` directory
       - Example: `git commit -m"docs: Document X feature" -m"Help users understand how to configure and use the new capability"`

5. **PR Creation**: 
   - Push the branch with all commits against the remote specified in argument $2
   - Create pull request with:
     - Clear title referencing JIRA issue as a prefix. For example: "OCPBUGS-12345: ..."
     - The PR description should satisfy the template within .github/PULL_REQUEST_TEMPLATE.md if the file exists
     - The "🤖 Generated with Claude Code" sentence should include a reference to the slash command that triggered the execution, for example "via `/jira-solve OCPBUGS-12345 enxebre`"
     - Always create as draft PR
     - Always create the PR against the remote origin
     - Use gh cli if you need to

6. **PR Description Review**:
   - After creating the PR, display the PR URL and description to the user
   - Ask the user: "Please review the PR description. Would you like me to update it? (yes/no)"
   - If the user says yes or requests changes:
     - Ask what changes they'd like to make
     - Update the PR description using `gh pr edit {PR_NUMBER} --body "{new_description}"`
     - Repeat this review step until the user is satisfied
   - If the user says no or is satisfied, acknowledge and provide next steps


## Arguments:
- $1: The JIRA issue to solve (required)
- $2: The remote repository to push the branch. Defaults to "origin".

The command will provide progress updates and create a comprehensive solution addressing all requirements from the JIRA issue.