Initial commit

commands/solve.md

@@ -0,0 +1,133 @@
+---
+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.