Added code review skills.

.github/skills/rezolve-oof-pr-auto-review/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: 'rezolve-oof-pr-auto-review'
+description: 'Request GitHub Copilot review on one open PR in Bluedot-Innovation, and optionally generate a local standardized review report.'
+allowed-tools:
+  - edit/editFiles
+  - edit/createFile
+  - github/*
+  - atlassian-rovo/*
+---
+
+# Rezolve OOF PR Code Review
+
+## Primary Outcome
+
+Given a PR, request **GitHub Copilot review** so Copilot is added/review-requested and posts comments/suggestions directly in GitHub.
+
+## Setup
+
+0. Preflight MCP check (mandatory):
+   - Confirm GitHub MCP PR tools are available for this session before doing any PR work.
+   - Confirm Atlassian MCP issue search tools are available if Jira enrichment may be needed.
+   - If required MCP tools are missing or not configured, abort immediately and report the missing MCP capability.
+   - Do not use gh CLI or any terminal/API fallback for PR operations.
+
+1. Determine the target PR in `Bluedot-Innovation`:
+   - If user provides `{owner}/{repo}#{number}`, use it.
+   - Otherwise, list open PRs in `Bluedot-Innovation` and ask the user to pick one.
+2. Fetch PR data via GitHub MCP:
+   - PR details (`get`)
+   - PR files (`get_files`)
+   - PR diff (`get_diff`)
+3. Extract a Jira ticket key by checking the PR head branch name first (e.g. `BD-7425` from `BD-7425-some-change`). If no key is found in the branch, use the PR title as a fallback source. If a ticket key is found from either source, fetch issue fields with this exact sequence:
+   - Run `mcp_com_atlassian_getAccessibleAtlassianResources` to resolve cloudId and site URL.
+   - Run `mcp_com_atlassian_searchJiraIssuesUsingJql` with `jql: key = <TICKET_KEY>`, `fields: ["summary", "description", "status", "issuetype", "priority"]`, and `responseContentFormat: "markdown"`.
+   - If description is missing, retry with `responseContentFormat: "adf"`.
+   - Do not use transitions APIs for issue content.
+4. If the PR body is empty or near-empty (blank or shorter than 40 non-whitespace characters) and a Jira ticket was found, update the PR main body by inserting the following `AI Development Checklist` section immediately before the `Jira Context` block, then request Copilot review.
+   - Template (insert as-is):
+
+     ## AI Development Checklist
+     - [ ] Spec/requirement linked: <!-- link here -->
+     - [ ] AI tool used: <!-- Copilot / Claude / Agent / Other -->
+     - [ ] Tests generated/refined with AI
+     - [ ] AI review pass completed
+     - [ ] Repo context files still accurate (update if not)
+
+   - Preferred content: Jira summary, description excerpt, acceptance criteria bullets, Jira URL.
+   - If Jira description is unavailable, still add fallback context with ticket key and Jira URL (`{siteUrl}/browse/{TICKET_KEY}`).
+   - If Jira fetch fails entirely, still add fallback context and include the fetch failure note.
+   - Do not overwrite substantial existing body text; append context only if missing.
+5. Trigger GitHub-native Copilot review:
+   - Validate the PR is open.
+   - Call `mcp_github_request_copilot_review` with `owner`, `repo`, and `pullNumber`.
+   - Confirm success and provide the PR URL.
+   - If Copilot review request fails, report the error clearly and stop.
+6. Inspect the diff to understand what types of changes are involved.
+7. Apply the **Doc Routing Table** in `.github/copilot-instructions.md` — use the change types you identified to determine which architecture docs to load. Use those docs as your source of truth throughout the review.
+8. If `.github/copilot-instructions.md` is missing, use `docs/ai/resources/*.md` as fallback architecture guidance and explicitly mention this fallback in the review.
+9. If the codebase contradicts the docs, the **docs represent the target state** — flag the discrepancy rather than normalising the legacy pattern.
+
+---
+
+## Review
+
+Evaluate the changes across these areas. Let the loaded architecture docs govern the specific standards — do not invent rules not found there.
+
+1. **Code Quality** — single responsibility principle, clarity, naming, redundancy, complexity, consistency with documented patterns
+2. **Regressions** — silent breakage, unexpected behaviour changes, altered logic outside of the stated scope of the ticket, downstream impact
+3. **Security** — input validation, sensitive data handling, auth correctness
+4. **Performance** — inefficient or unnecessarily expensive code, unnecessary re-renders, missing cleanups, over-importing
+5. **Error handling** — async error paths covered, error messaging in place, graceful degradation, no swallowed errors
+6. **Accessibility** — semantic HTML, ARIA attributes, keyboard navigation, focus management
+7. **Testing** — coverage of new logic, edge cases, error paths; flag superfluous tests
+8. **Documentation** — non-obvious logic commented; docs updated where needed, architecture docs updated if the change introduces a new pattern or deviates from existing ones
+
+---
+
+## Output Format
+
+- First, report GitHub Copilot review request status:
+   - PR URL
+   - Review request result (success/failure)
+   - PR body enrichment result (updated/skipped + reason)
+
+- **Inline comments** for specific lines or blocks.
+- **Top-level observations** for broad themes or praise.
+- Prioritise by severity: 🔴 blocking / 🟡 important / 🔵 minor.
+- Do **not** include your reasoning steps or to-do list.
+- Close with a witty quatrain summarising the PR. 🎭
+
+If local analysis is requested, save the review to `docs/code-reviews/<branch-name>-code-review.md` (use the full PR head branch name from Setup). Confirm the file has been written.

.github/skills/rzlv-algorithm-precision-handling/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: 'rzlv-algorithm-precision-handling'
+description: 'Review Flutter/Dart code for algorithm precision issues: edge cases, floating-point handling, boundary conditions, and correct mathematical formulas.'
+allowed-tools:
+  - edit/editFiles
+  - edit/createFile
+  - github/*
+---
+
+# rzlv: Algorithm Precision Handling
+
+## Purpose
+
+Review code changes for algorithm correctness, mathematical precision, and robust edge case handling. Flag subtle bugs caused by approximations, incorrect formulas, or unvalidated boundary conditions that surface only under specific conditions.
+
+## When to Apply
+
+Trigger this skill when a PR introduces or modifies:
+- Mathematical calculations or formulas
+- String parsing or splitting logic
+- Division, rounding, or floating-point arithmetic
+- Validation functions that check numeric constraints
+- Coordinate or geometry calculations
+
+## Key Practices
+
+- **Use `substring()` over `split()` for string processing** when precise prefix control is needed — `currentLabel.substring(baseLabel.length)` avoids issues when the base pattern appears multiple times in the string.
+- **Apply correct unit conversions** with mathematical constants — e.g., `event.rotation = (double)state->rotation * (M_PI / 180)` for degrees-to-radians conversion.
+- **Handle floating-point precision in division** — use `lerpValue.round()` after render-level calculations rather than redundant division-based rounding.
+- **Validate all edge cases**, especially zero values and boundary conditions — check for `metrics.physical_width == 0` and tight constraint relationships.
+- **Fix mathematical formulas to use correct operations** — e.g., `(math.max(first.bottom, second.bottom) - math.min(first.top, second.top))` for proper area height calculation (`min` for top, not `max`).
+
+## Review Checklist
+
+- [ ] Are all numeric inputs validated before use (zero, negative, infinite)?
+- [ ] Are mathematical formulas using the correct operations (min vs max, etc.)?
+- [ ] Is string splitting done safely when the delimiter may appear multiple times?
+- [ ] Are unit conversions explicit and correct (degrees → radians, etc.)?
+- [ ] Are boundary conditions (empty, zero-size, max values) tested?
+
+## Output
+
+Raise findings as:
+- 🔴 **Blocking** — incorrect formula that produces wrong output
+- 🟡 **Important** — missing edge case that could cause runtime failure in production
+- 🔵 **Minor** — precision improvement or safer alternative available
+

.github/skills/rzlv-avoid-breaking-changes/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: 'rzlv-avoid-breaking-changes'
+description: 'Review Flutter/Dart APIs for backward compatibility: flag breaking parameter changes, missing deprecations, and altered default values that would force consumers to update code.'
+allowed-tools:
+  - edit/editFiles
+  - edit/createFile
+  - github/*
+---
+
+# rzlv: Avoid Breaking Changes
+
+## Purpose
+
+Review API changes to ensure backward compatibility. Flag changes that would force developers to maintain separate code paths for different SDK versions, and recommend safer alternatives such as deprecation with migration paths or optional parameters with sensible defaults.
+
+## When to Apply
+
+Trigger this skill when a PR:
+- Modifies a public method signature (adds/removes/reorders parameters)
+- Changes an existing default value
+- Removes or renames a public API
+- Adds a required parameter to an existing method
+- Changes the behavior of an existing API
+
+## Key Practices
+
+- **Make new parameters optional with defaults** instead of required:
+  ```dart
+  // Instead of breaking change:
+  void getHandleAnchor(TextSelectionHandleType type, double textLineHeight, {required double cursorWidth})
+
+  // Use optional with default:
+  void getHandleAnchor(TextSelectionHandleType type, double textLineHeight, {double cursorWidth = 2.0})
+  ```
+
+- **Use `@Deprecated` with a migration message** rather than direct removal:
+  ```dart
+  @Deprecated(
+    'Use sendAnnouncement instead. '
+    'This API is incompatible with multiple windows. '
+    'This feature was deprecated after 3.35.0-0.1.pre.'
+  )
+  static Future<void> announce(String message) { ... }
+  ```
+
+- **Never change existing default values** — this is a silent breaking change. Add new options while preserving existing defaults.
+
+- **Design new APIs to be explicit** — avoid implicit assumptions that would require breaking changes when those assumptions need updating.
+
+## Review Checklist
+
+- [ ] Does the PR add any required parameters to existing public methods?
+- [ ] Are any existing default values changed?
+- [ ] Are removed/renamed APIs replaced with properly annotated `@Deprecated` wrappers?
+- [ ] Do deprecation messages include the target replacement and the version deprecated after?
+- [ ] Are new parameters optional with sensible defaults?
+
+## Output
+
+Raise findings as:
+- 🔴 **Blocking** — change breaks existing consumers without a migration path
+- 🟡 **Important** — change is technically breaking but could be mitigated with deprecation
+- 🔵 **Minor** — default value choice or API design suggestion for future-proofing
+

.github/skills/rzlv-code-review/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: rzlv-code-review
+description: 'Performs an extended code review of the current branch vs a target branch, applying all rzlv- coding standards as review lenses plus a general code review. Outputs all findings as actionable items to a Markdown report file. Invoke as: /skill:rzlv-code-review <target-branch>'
+---
+
+Follow the instructions in ./workflow.md.
+

.github/skills/rzlv-code-review/steps/step-01-gather-changes.md

@@ -0,0 +1,110 @@
+---
+target_branch: ''       # set from invocation argument
+current_branch: ''      # set at runtime via git
+diff_output: ''         # set at runtime
+changed_files: ''       # set at runtime
+report_path: ''         # set at runtime
+jira_ticket_key: ''     # set at runtime if branch contains a ticket number (e.g. BD-7558)
+jira_ticket_summary: '' # set at runtime from Jira API
+jira_ticket_body: ''    # set at runtime — full ticket description + acceptance criteria
+jira_ticket_status: ''  # set at runtime
+---
+
+# Step 1: Gather Changes
+
+## RULES
+
+- Do not modify any source files. This step is read-only.
+- All git commands must be run in the project root.
+- **ALWAYS** use `git --no-pager` for every git command. Never omit `--no-pager`. Git may invoke a pager (`less`, `more`) on any command that produces output, which will block the terminal indefinitely.
+
+## INSTRUCTIONS
+
+### 1. Confirm target branch
+
+- Set `{target_branch}` from the value parsed in workflow initialization.
+- Run `git --no-pager branch -a | cat` to list branches, then check whether `{target_branch}` appears.
+  - If not found locally, also run `git --no-pager ls-remote --heads origin {target_branch} | cat` to check remote.
+  - If neither check finds the branch, HALT and tell the user: "Branch `{target_branch}` was not found. Please check the branch name and try again."
+
+### 2. Identify current branch
+
+- Run `git rev-parse --abbrev-ref HEAD` (no pager needed — single-line output) and store as `{current_branch}`.
+- If the result is `HEAD` (detached HEAD state), HALT and warn the user.
+
+### 3. Produce the diff
+
+- Run: `git --no-pager diff {target_branch}...HEAD`
+  - This shows all commits on `{current_branch}` that are **not** on `{target_branch}` (three-dot diff = changes introduced by this branch).
+- Store the full output as `{diff_output}`.
+- If `{diff_output}` is empty, HALT and tell the user: "No changes found between `{current_branch}` and `{target_branch}`. Nothing to review."
+
+### 4. Build changed-files list and summary stats
+
+- Run: `git --no-pager diff --name-only {target_branch}...HEAD`
+- Store as `{changed_files}` (newline-separated list).
+- Run: `git --no-pager diff --stat {target_branch}...HEAD | tail -1`
+  - This produces the summary line only (e.g. `12 files changed, 340 insertions(+), 45 deletions(-)`). Using `tail -1` avoids piping the full per-file table.
+- Present a short summary to the user:
+  > Reviewing `{current_branch}` vs `{target_branch}`:
+  > - **Files changed:** <count>
+  > - **Lines added:** <+N>
+  > - **Lines removed:** <-N>
+
+### 5. Large diff warning
+
+- If `{diff_output}` exceeds approximately 3000 lines, warn the user:
+  > ⚠️ This diff is large (~N lines). The review will proceed but may take a while. Consider chunking if context limits are hit.
+- Continue regardless — do not block.
+
+### 6. Detect Jira ticket number
+
+- Scan `{current_branch}` for a pattern matching a Jira ticket key: one or more uppercase letters, a hyphen, then one or more digits (regex: `[A-Z]+-\d+`).
+  - Examples: `ak/BD-7558` → `BD-7558` | `feature/PROJ-123-some-description` → `PROJ-123`
+- If a match is found:
+  - Set `{jira_ticket_key}` to the matched value (e.g. `BD-7558`).
+  - Announce: "🎫 Jira ticket detected: `{jira_ticket_key}`. Fetching ticket details…"
+  - Proceed to instruction 6a.
+- If no match is found:
+  - Set `{jira_ticket_key}` = `""` (empty).
+  - Announce: "ℹ️ No Jira ticket number found in branch name. Skipping Jira compliance review."
+  - Skip to instruction 7.
+
+#### 6a. Fetch Jira ticket via Atlassian MCP
+
+1. Call `mcp_atlassian_getAccessibleAtlassianResources` to discover the available Jira cloud ID.
+   - Use the first Jira resource returned and store its `id` as `{jira_cloud_id}`.
+   - If the call fails or returns no resources, note the failure, set `{jira_ticket_key}` = `""`, and skip to instruction 7.
+
+2. Call `mcp_atlassian_getJiraIssue` with:
+   - `cloudId`: `{jira_cloud_id}`
+   - `issueIdOrKey`: `{jira_ticket_key}`
+   - `responseContentFormat`: `"markdown"`
+
+3. If the call succeeds:
+   - Set `{jira_ticket_summary}` = the issue `summary` field.
+   - Set `{jira_ticket_status}` = the issue `status.name` field.
+   - Set `{jira_ticket_body}` = the full issue `description` field (markdown). If the issue has an `Acceptance Criteria` custom field or a section labelled "Acceptance Criteria" in the description, extract and preserve it verbatim — it will be a primary review lens.
+   - Announce:
+     > 🎫 **Jira ticket loaded:** [`{jira_ticket_key}`] {jira_ticket_summary}
+     > **Status:** {jira_ticket_status}
+
+4. If the call fails (ticket not found, permission denied, network error):
+   - Warn the user: "⚠️ Could not fetch Jira ticket `{jira_ticket_key}`: <error>. Jira compliance review will be skipped."
+   - Set `{jira_ticket_key}` = `""`.
+
+### 7. Determine report output path
+
+- Set `{report_path}` = `.github/reviews/code-review-{current_branch}-{date}.md`
+  - Replace `/` characters in `{current_branch}` with `-` to keep it filesystem-safe.
+  - Format `{date}` as `YYYY-MM-DD`.
+  - If `{jira_ticket_key}` is non-empty, include it for clarity:
+    `.github/reviews/code-review-{jira_ticket_key}-{date}.md`
+- Announce the output path to the user:
+  > 📄 Report will be written to: `{report_path}`
+
+
+## NEXT
+
+Read fully and follow `./step-02-rzlv-review.md`
+