@groupby/ai-dev 0.5.9 → 0.5.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@groupby/ai-dev",
-  "version": "0.5.9",
+  "version": "0.5.11",
   "description": "Interactive installer for Rezolve Ai development content",
   "type": "module",
   "bin": {

package/teams/fhr-neowise/commands/address-pr.md

@@ -0,0 +1,120 @@
+---
+description: "Fetch open review threads from the current branch's PR, evaluate each comment's validity, apply fixes for valid findings, and reply to invalid ones."
+---
+
+# Address PR
+
+Argument: `$ARGUMENTS` — optional. Pass `pr=<number>` to target a specific PR number; omit to auto-detect from the current branch.
+
+Works through unresolved GitHub PR review threads: fixes valid ones in the code, and replies to invalid ones with a clear explanation.
+
+## Step 1: Find the PR
+
+```bash
+gh pr view --json number,url,title,headRefName
+```
+
+Extract the PR number and branch name. If no open PR exists, stop and report.
+
+Get owner and repo:
+```bash
+gh repo view --json owner,name --jq '"\(.owner.login)/\(.name)"'
+```
+
+## Step 2: Fetch unresolved review threads
+
+Use the GitHub GraphQL API to list all review threads and their resolved status:
+
+```bash
+gh api graphql -f query='
+  query($owner: String!, $repo: String!, $number: Int!) {
+    repository(owner: $owner, name: $repo) {
+      pullRequest(number: $number) {
+        reviewThreads(first: 100) {
+          nodes {
+            id
+            isResolved
+            isOutdated
+            comments(first: 10) {
+              nodes {
+                id
+                databaseId
+                body
+                path
+                line
+                author { login }
+                createdAt
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+' -f owner=<OWNER> -f repo=<REPO> -F number=<PR_NUMBER>
+```
+
+Filter to threads where `isResolved` is `false`. Skip threads where `isOutdated` is `true` — outdated threads reference lines that have since changed and no longer block review.
+
+If there are no unresolved threads, report "No open review threads" and stop.
+
+## Step 3: Evaluate each unresolved thread
+
+For each unresolved thread, read the full comment text. Load the referenced file at the path/line to understand the context.
+
+Decide for each thread:
+- **Valid** — the comment identifies a real problem or improvement that is technically correct and appropriate for this codebase.
+- **Invalid** — the comment is based on a misunderstanding of the code, the suggested change would be incorrect, or the concern does not apply.
+
+## Step 4: Apply fixes for valid findings
+
+For each valid thread, apply the fix using the appropriate dev agent (follow the module→agent mapping in `.claude/rules/workflow.md`). Collect all code changes before committing.
+
+After all fixes are applied, run tests for each affected module:
+- Java/Groovy: `./gradlew :<module>:test`
+- Scala: `./gradlew :<module>:test`
+- Angular: `cd <module> && npm test`
+- Python: `cd statistical-analysis && PYTHONPATH=main pytest test/ -v`
+
+Run `./gradlew spotlessApply` if any Java or Groovy files were modified.
+
+If tests fail, fix the failure before proceeding.
+
+## Step 5: Commit and push (only if code changed)
+
+Stage and commit all code changes:
+```bash
+git add <changed files>
+git commit -m "FHR-<number>: address review feedback"
+git push
+```
+
+Confirm with the user before pushing.
+
+## Step 6: Reply to all threads
+
+For each **valid** thread that was fixed, post a reply confirming the change:
+```bash
+gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/comments \
+  --method POST \
+  --field body="Fixed — <one-sentence summary of the change made>." \
+  --field in_reply_to=<FIRST_COMMENT_DATABASE_ID>
+```
+
+For each **invalid** thread, post a reply explaining why the current code is correct:
+```bash
+gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/comments \
+  --method POST \
+  --field body="<Clear, professional explanation of why no change is needed.>" \
+  --field in_reply_to=<FIRST_COMMENT_DATABASE_ID>
+```
+
+Use the `databaseId` of the first comment in each thread as `in_reply_to`.
+
+## Step 7: Report
+
+Summarise:
+- How many threads were fixed (with code changes)
+- How many threads received a reply (no code change)
+- Any threads that could not be automatically resolved and need manual attention
+- The commit SHA if code was pushed

package/teams/fhr-neowise/commands/ready-pr.md

@@ -0,0 +1,70 @@
+---
+description: "Check that all PR review threads are resolved, then promote the PR from draft to ready for review. Stops with a clear message if any unresolved threads remain."
+---
+
+# Ready PR
+
+Argument: `$ARGUMENTS` — optional. Pass `pr=<number>` to target a specific PR number; omit to auto-detect from the current branch.
+
+Checks GitHub PR review threads via the GraphQL API. If all threads are resolved, marks the PR ready for review. If any are still open, stops and tells you what to do.
+
+## Step 1: Find the PR
+
+```bash
+gh pr view --json number,url,title,isDraft,state
+```
+
+If no open PR exists, stop and report. Note whether it is currently a draft.
+
+Get owner and repo:
+```bash
+gh repo view --json owner,name --jq '"\(.owner.login)/\(.name)"'
+```
+
+## Step 2: Check for unresolved review threads
+
+```bash
+gh api graphql -f query='
+  query($owner: String!, $repo: String!, $number: Int!) {
+    repository(owner: $owner, name: $repo) {
+      pullRequest(number: $number) {
+        reviewThreads(first: 100) {
+          nodes {
+            isResolved
+            isOutdated
+            comments(first: 1) {
+              nodes {
+                body
+                path
+                line
+                author { login }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+' -f owner=<OWNER> -f repo=<REPO> -F number=<PR_NUMBER>
+```
+
+Filter to threads where `isResolved` is `false` AND `isOutdated` is `false`. Outdated threads reference lines that have since changed — they do not block readiness.
+
+## Step 3: If unresolved threads exist — STOP
+
+Report and do nothing further:
+
+> **Not ready:** N unresolved review thread(s) remain:
+>
+> - `path:line` — "comment text" (by @reviewer)
+> - …
+>
+> Run `/address-pr` to fix or reply to each thread, or resolve them manually on GitHub, then run `/ready-pr` again.
+
+## Step 4: If all threads are resolved — mark ready
+
+```bash
+gh pr ready <PR_NUMBER>
+```
+
+Report the PR URL and confirm it is now ready for review.

package/teams/fhr-neowise/commands/review-pr.md

@@ -0,0 +1,111 @@
+---
+description: "Review the current branch's GitHub PR: fetch its description and diff, compare against spec/plan if available, and submit a GitHub PR review with inline comments for every finding."
+---
+
+# Review PR
+
+Argument: `$ARGUMENTS` — optional. Pass `pr=<number>` to review a specific PR number; omit to auto-detect from the current branch.
+
+Reviews the open GitHub PR for this branch by acting as a code reviewer. Output is a submitted GitHub PR review with inline comments — not a local file.
+
+## Step 1: Find the PR
+
+Locate the open PR for the current branch:
+```bash
+gh pr view --json number,url,title,state,body,headRefName,baseRefName
+```
+
+Extract the PR number, title, description, and base branch. If no open PR exists, stop and ask the user to run `/write-pr` first.
+
+Get the latest commit SHA (required for inline comment anchoring):
+```bash
+gh pr view <PR_NUMBER> --json commits --jq '.commits[-1].oid'
+```
+
+## Step 2: Fetch the diff
+
+```bash
+gh pr diff <PR_NUMBER>
+```
+
+Also list changed files:
+```bash
+gh pr view <PR_NUMBER> --json files --jq '[.files[].path]'
+```
+
+## Step 3: Load spec and plan (if available)
+
+Detect the ticket number from the branch name (pattern `FHR-\d+`).
+
+Search for and read if they exist:
+- `.sprints/*/<ticket>/SPEC.md` — focus on the objective, functional requirements, and acceptance criteria
+- `.sprints/*/<ticket>/PLAN.md` — focus on the planned implementation steps
+
+If neither exists, proceed without them and review code quality only.
+
+## Step 4: Review the PR
+
+Apply the **`code-review`** skill's quality gates and severity classifications (`.claude/skills/code-review/SKILL.md`) to the diff and PR description.
+
+**What to check:**
+
+1. **PR description accuracy** — does the body accurately describe what changed? Are diagrams present and correct for complex changes?
+2. **Spec compliance** (if SPEC.md found) — does the implementation satisfy each acceptance criterion? Are there missing tests for any plan step?
+3. **Code quality** across all eight quality gates:
+   - Correctness and edge cases (nulls, boundary values, empty inputs)
+   - Error handling and resilience (no swallowed exceptions)
+   - Security and input validation (no injection, no hardcoded secrets)
+   - Data handling and transaction safety (ACID guarantees, no duplicate writes)
+   - Test coverage (every new/changed conditional branch has a dedicated test)
+   - Readability, naming, complexity, duplication
+   - Architecture and boundary consistency (layers respected, dependencies flow correctly)
+   - Logging and observability (no secrets or PII in logs)
+
+**For each finding, record:**
+- `path` — relative file path in the repo
+- `line` — absolute line number in the new version of the file
+- `side` — always `"RIGHT"` for lines added or unchanged in this PR
+- `severity` — `BLOCKER` | `MAJOR` | `MINOR` | `NIT`
+- `body` — comment text prefixed with the severity tag, e.g. `BLOCKER: Missing null check. Add a guard before line 42.`
+
+Only raise a finding if the evidence is clear from the diff. Do not speculate about code you cannot see.
+
+## Step 5: Submit the GitHub PR review
+
+Get the repository owner and name:
+```bash
+gh repo view --json owner,name --jq '"\(.owner.login)/\(.name)"'
+```
+
+Build the `comments` JSON array from your findings. Submit the full review in a single API call:
+
+```bash
+gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/reviews \
+  --method POST \
+  --field commit_id=<LATEST_COMMIT_SHA> \
+  --field body="Review: <N> finding(s) — <X> blocker(s), <Y> major, <Z> minor, <W> nit(s)." \
+  --field event="REQUEST_CHANGES" \
+  --raw-field comments='[
+    {"path":"src/Foo.java","line":42,"side":"RIGHT","body":"BLOCKER: …"},
+    {"path":"src/Bar.java","line":17,"side":"RIGHT","body":"MINOR: …"}
+  ]'
+```
+
+If a finding cannot be anchored to a specific file line (e.g. a description-level issue), include it in the `body` field of the review instead of as an inline comment.
+
+If there are **no findings**, submit an approval:
+
+```bash
+gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/reviews \
+  --method POST \
+  --field body="LGTM — all quality gates pass." \
+  --field event="APPROVE"
+```
+
+## Step 6: Report
+
+Output:
+- PR URL
+- Review decision (`REQUEST_CHANGES` or `APPROVE`)
+- Finding counts by severity
+- Any findings included in the review body rather than as inline comments

package/teams/fhr-neowise/commands/tdd-implementation.md

@@ -0,0 +1,86 @@
+---
+description: "Implement a specification section by section using double-loop TDD. Orchestrates the tdd-workflow, agent-routing, and integration-boundaries skills."
+---
+
+# TDD Implementation
+
+Argument: `$ARGUMENTS` — `ticket=<folder-path>` (e.g. `ticket=.sprints/26-21/FHR-7106`).
+
+Parse the `ticket=` value. If missing, stop and ask the user to supply one.
+
+## Step 1: Validate the Spec
+
+Read `SPEC.md` from the ticket folder. Verify:
+- [ ] Folder exists and contains `SPEC.md`
+- [ ] Section 1 (Objective) has a concrete goal — not placeholder text
+- [ ] Section 2 (Out of Scope) is filled in
+- [ ] Section 3 (Context) lists specific file paths
+- [ ] Section 4 (Functional Requirements) has at least one given/when/then requirement
+- [ ] Section 6 (Assumptions & Open Questions) has no unresolved questions
+- [ ] Section 7 (Acceptance Criteria) has at least one checkable criterion
+- [ ] Target module is identified in the spec header
+
+If any item fails, stop and report it before proceeding.
+
+Extract the `Ticket` field (e.g. `FHR-7106`) — use only the primary ticket ID. Store it as `<TICKET>` for all commit messages.
+
+## Step 2: Detect Language and Agents
+
+**Apply the `agent-routing` skill** (`.claude/skills/agent-routing/SKILL.md`) — map the spec's `Module` field to the correct dev agent and test writer agent.
+
+## Step 3: Parse the Plan and Build Todo List
+
+Read `PLAN.md`. Using the routing rules from the `agent-routing` skill, classify each section as outer loop (integration boundary) or inner loop (unit work).
+
+**Resume detection:** read `CHECKLIST.json` and identify steps with `"completed": true`. If any, display a resume notice (with log summaries from `PLAN.log.md`) and wait for confirmation before continuing.
+
+Create todo items in double-loop order:
+1. `[Outer RED] <section>` for each incomplete outer loop section
+2. Inner loop sections in plan order
+3. `[Outer GREEN] <section>` for each incomplete outer loop section
+4. `Final Validation`
+
+Display the full list and wait for user confirmation before starting.
+
+## Step 4: Execute — Double-Loop TDD
+
+**Apply the `tdd-workflow` skill** (`.claude/skills/tdd-workflow/SKILL.md`) throughout execution.
+
+### Phase A — Outer RED
+
+For each `[Outer RED]` item: confirm Docker is running, then invoke the tester agent (via Agent tool with correct `subagent_type`). Run the scoped integration test and confirm it **fails** for the right reason (assertion failure, not compile error).
+
+If Docker unavailable: mark as skipped, log it, block the matching `[Outer GREEN]`, continue to Phase B.
+
+### Phase B — Inner Loop (per section)
+
+**Apply `superpowers:dispatching-parallel-agents`** when a section has independent tester + dev invocations that can run concurrently. Send both in a single message.
+
+**B-i Write failing unit tests:** invoke the tester agent → run unit tests → confirm **fails**.
+
+**B-ii Implement:** invoke the dev agent with the failing test output → run full unit test suite → **invoke `superpowers:verification-before-completion`** before claiming GREEN (run the test command fresh and show the output as evidence; never assert "all pass" without fresh output in the same message) → confirm **all pass, no regressions**. On persistent failure: attempt twice, then stop and report.
+
+**B-iii Validate and record:**
+- Confirm no TODO/FIXME/placeholder remains
+- Mark CHECKLIST.json step `"completed": true` (run `node checklist.mjs --complete-step <step-id>` or Edit the JSON directly)
+- Append entry to `PLAN.log.md`
+- Ask user to review and commit: `<TICKET>: implement step <N> — <step title>`
+- Ask whether to push
+
+### Phase C — Outer GREEN
+
+Run the full integration test suite. **Invoke `superpowers:verification-before-completion`** before declaring outer loop GREEN — fresh integration test output is required as evidence. Confirm all outer loop tests pass, no regressions. On persistent failure: attempt twice with dev agent, then stop and report.
+
+Mark CHECKLIST.json step `"completed": true`, log it, commit: `<TICKET>: <feature title> — outer loop green`.
+
+## Step 5: Final Validation
+
+1. Run the full test suite for the module. **Invoke `superpowers:verification-before-completion`** before reporting the outcome — show fresh command output as evidence.
+2. Check spec Sections 4 and 7 for any requirement or criterion with no corresponding test.
+3. Fill gaps: invoke tester then dev agent.
+4. Fix any regressions with the dev agent.
+5. Mark all Final Validation items `"completed": true` in CHECKLIST.json.
+6. Log, commit: `<TICKET>: complete TDD implementation — all sections validated`.
+7. Report: sections completed, tests added, any open blockers.
+8. **Apply `superpowers:requesting-code-review`** to verify the implementation is ready to merge.
+9. Prompt: "Would you like to add integration tests for the boundaries this feature touches? Run: `/integration-tests ticket=<folder-path>`"

package/teams/fhr-neowise/commands/write-plan.md

@@ -0,0 +1,23 @@
+---
+description: "Read a completed SPEC.md and produce PLAN.md and CHECKLIST.json. Triggers the write-plan skill."
+---
+
+# Write Plan
+
+Argument: `$ARGUMENTS` — path to a `SPEC.md` file (e.g. `.sprints/26-21/FHR-7106/SPEC.md`).
+
+If no spec path is provided, ask for it immediately. Do not search the workspace for spec files.
+
+## Workflow
+
+1. **Read the spec** — confirm the file exists and has no unresolved open questions that would change the plan structure. If open questions remain, stop and ask the user to resolve them first.
+
+2. **Apply the `write-plan` skill** — follow the full planning process defined in `.claude/skills/write-plan/SKILL.md`.
+
+3. **Write the files** — save `PLAN.md`, `CHECKLIST.json`, and `checklist.mjs` next to the `SPEC.md` in the same directory.
+
+4. **Request approval** — ask the user to approve the generated files or request corrections before committing (handled by the skill's Step 9).
+
+5. **Offer to commit** — after approval, ask the user whether to commit the generated files or skip.
+   - If confirmed: stage only `PLAN.md`, `CHECKLIST.json`, and `checklist.mjs` and commit with message `<ticket-number>: add PLAN.md, CHECKLIST.json, and checklist.mjs for <feature>`.
+   - Only push if the user explicitly requests it.

package/teams/fhr-neowise/commands/write-pr.md

@@ -0,0 +1,21 @@
+---
+description: "Classify the current branch's changes, render the matching PR template (with Mermaid diagrams for complex changes), and create a draft GitHub PR titled FHR-XXXX: <Ticket Title>. Triggers the pull-request-authoring skill."
+---
+
+# Write PR
+
+Argument: `$ARGUMENTS` — optional. Pass `type=complex|simple|non-code` to force a PR type, or leave empty to auto-detect. Any other text is treated as extra context for the description.
+
+Run this on the branch you want to open (or update) a PR for. PRs are always created as **drafts** — use `/ready-pr` once review is complete to promote them.
+
+## Workflow
+
+1. **Apply the `pull-request-authoring` skill** — follow the full process in `.claude/skills/pull-request-authoring/SKILL.md`, using the templates in that folder.
+
+2. **Classify and render** — detect the change type (complex / simple / non-code) from the diff vs `master`, confirm it with the user, then render the matching template. For complex PRs, generate the Mermaid diagram(s) via the `mermaid-diagram` skill.
+
+3. **Title** — set the PR title to `FHR-<number>: <Ticket Title>`, using the exact Jira summary for the branch's ticket. If Jira is unavailable, confirm a branch-derived title with the user.
+
+4. **Approve before publishing** — present the title and body and wait for explicit approval. Support correction cycles.
+
+5. **Save and publish** — save `PR.md` next to the ticket's spec/plan, push the branch (only with confirmation), then `gh pr create --draft` (or `gh pr edit` if a PR already exists). Report the PR URL.

package/teams/fhr-neowise/commands/write-spec.md

@@ -0,0 +1,25 @@
+---
+description: "Investigate a feature or Jira ticket and produce a complete SPEC.md. Triggers the spec-investigation skill."
+---
+
+# Write Spec
+
+Argument: `$ARGUMENTS` — feature description or Jira ticket key (e.g. `FHR-7106`).
+
+If the argument is missing or too vague to identify the affected area, ask the user for clarification before doing anything else.
+
+## Explore First
+
+If the argument is a **feature description** — not a Jira ticket key (pattern: `[A-Z]+-\d+`, e.g. `FHR-7106`) — **invoke `superpowers:brainstorming`** before starting the investigation. Brainstorming explores intent, surfaces unknowns, and confirms scope through collaborative dialogue. Proceed to the Workflow below only after the brainstorming design is approved by the user.
+
+If a Jira ticket key is provided, skip brainstorming — the spec-investigation skill's Step 1 ticket clarity check handles collaborative dialogue directly.
+
+## Workflow
+
+1. **Apply the `spec-investigation` skill** — follow the full investigation process defined in `.claude/skills/spec-investigation/SKILL.md`. Use the template at `.claude/skills/spec-investigation/TEMPLATE.spec.md`.
+
+2. **Write the file** — save the completed spec to `.sprints/<sprint-name>/<ticket-number>/SPEC.md`.
+
+3. **Offer to commit** — ask the user whether to commit the generated files or skip.
+   - If confirmed: stage only the generated spec files and commit with message `<ticket-number>: add SPEC.md for <feature>`.
+   - Only push if the user explicitly requests it.

package/teams/fhr-neowise/skills/agent-routing/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: agent-routing
+description: "Apply when delegating implementation or testing work to a specialist agent: determines which dev agent and test writer agent to invoke based on the module name and the type of code being written (service layer vs. infrastructure/boundary layer)."
+user-invocable: false
+---
+
+# Skill: Agent Routing
+
+## When This Applies
+
+Apply this skill whenever Claude needs to delegate work to a specialist dev or test agent — during TDD implementation, integration test writing, or code review orchestration.
+
+## Module → Language → Agent Mapping
+
+| Module | Language | Dev Agent | Test Writer Agent | Reviewer Agent |
+|---|---|---|---|---|
+| `insights-dashboard`, `insights-admin-console` | Angular/TypeScript | `Angular Dev` | `Angular Test Writer` | `Angular Code Reviewer` |
+| `configuration-service`, `scheduler-application`, `scheduler-api`, `provisioner-service`, `activity-api-v2`, `activity-enrichments-api`, `reporting-api-v2`, `reporting-product-information`, `reports-summary`, `configuration-common-client`, `sql-writer`, `fas-data-model` | Java | `Java Dev` | `Java Test Writer` | `Java Code Reviewer` |
+| `report-calculation-v3`, `reporting-fas-data`, `reporting-maintenance`, `reporting-cru-history` | Scala | `Scala Dev` | `Scala Test Writer` | `Scala Code Reviewer` |
+| `statistical-analysis` | Python | `Python Dev` | `Python Test Writer` | `Python Code Reviewer` |
+
+If the module is not in any list, stop and ask the developer to confirm the language before proceeding.
+
+**Cross-module features** (changes spanning more than one module): use `Senior Dev` to orchestrate. Senior Dev delegates to the per-module agents per the table above. Do not attempt cross-module implementation with a single language-specific agent.
+
+**Note on mixed-language Spark job modules** (`report-calculation-v3`, `reporting-fas-data`, `reporting-maintenance`, `reporting-cru-history`): these have a Java Spring Boot entry point and Scala Spark logic. Route ALL logic — including entry point wiring — to `Scala Dev`. The Java entry point follows a fixed convention that Scala Dev understands.
+
+## Tester Routing Rules
+
+Use the **section title and description keywords** to determine how many test passes are needed.
+
+### Java
+
+| Keywords in section | Agent | Passes |
+|---|---|---|
+| service, transformer, calculator, validator, handler, processor, mapper, converter, domain, utility, helper, factory, builder | `Java Test Writer` | Unit tests only |
+| controller, endpoint, REST, HTTP, repository, database, JPA, Firehose, Kinesis, S3, outbound, `@RestController`, `@Repository` | `Java Test Writer` | Unit tests first → then integration tests |
+| Ambiguous | `Java Test Writer` | Unit tests only + note assumption |
+
+### Scala
+
+| Keywords in section | Agent | Passes |
+|---|---|---|
+| transformation, case class, schema, column, filter, aggregation, DataFrame, Dataset, Window, join, map, flatMap, UDF, enrichment, linking, attribution | `Scala Test Writer` | Unit tests only |
+| full pipeline, job, Delta Lake, Delta table, S3, read, write, end-to-end, runner, orchestration, sink, source | `Scala Test Writer` | Unit tests first → then integration tests |
+| Ambiguous | `Scala Test Writer` | Unit tests only + note assumption |
+
+### Python
+
+| Keywords in section | Agent | Passes |
+|---|---|---|
+| statistical analysis, calculation, A/B test, metric, transformation, DataFrame, PySpark, UDF, aggregation, significance, p-value | `Python Test Writer` | Unit tests only |
+| database, PostgreSQL, query, SQL, connection, GraphQL, client, psycopg, testcontainers, external | `Python Test Writer` | Unit tests first → then integration tests |
+| Ambiguous | `Python Test Writer` | Unit tests only + note assumption |
+
+### Angular
+
+Always invoke `Angular Test Writer` — single pass, no integration split.
+
+## What to Pass to Each Agent
+
+When invoking a tester agent, always provide:
+- Section title and full description from the plan
+- Path to the ticket folder
+- Relevant requirements from spec Section 4 and acceptance criteria from spec Section 7 that this section addresses
+- Paths of any existing test files in the module (for convention context)
+
+When invoking a dev agent, always provide:
+- The exact failing test output from the tester
+- Section title and full description from the plan
+- Path to the ticket folder
+- The tester's output summary (which test files were written and what each asserts)

package/teams/fhr-neowise/skills/code-review/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: code-review
+description: "Apply when reviewing code for spec compliance, plan compliance, and general quality: classifying findings by severity, building the requirement checklist, and writing a structured review.md using the review template."
+user-invocable: false
+---
+
+# Skill: Code Review
+
+## When This Applies
+
+Apply this skill whenever performing a structured code review — whether triggered by `/review-pr`, by a Senior Code Reviewer agent, or when Claude is asked to audit code quality against a spec or plan.
+
+## Review Template
+
+The review template is at `review-template.md` in this skill folder. Read it before writing any review file.
+
+## Requirement Checklist
+
+Build a checklist table with these ID prefixes:
+- `S-<n>` for spec requirements (from SPEC.md Section 4)
+- `A-<n>` for acceptance criteria (from SPEC.md Section 7)
+- `P-<n>` for plan steps (from PLAN.md, if available)
+
+For each item, determine status:
+- `PASS`: clearly implemented and verifiable
+- `PARTIAL`: implemented but incomplete or ambiguous
+- `FAIL`: missing, incorrect, or regressed
+- `N/A`: not applicable to changed scope
+
+## Quality Gates
+
+Evaluate changed code against all eight gates:
+
+1. **Correctness and edge cases** — logic handles nulls, empty inputs, and boundary values
+2. **Error handling and resilience** — every try/catch handled explicitly; no swallowed exceptions
+3. **Security and input validation** — no SQL injection, XSS, hardcoded secrets, or unvalidated input
+4. **Data handling and transaction safety** — ACID guarantees, no duplicate writes
+5. **Test coverage** — every new/changed conditional branch has a dedicated test
+6. **Readability, naming, complexity, duplication**
+7. **Architecture and boundary consistency** — layers respected, dependencies flow correctly
+8. **Logging and observability** — no secrets or PII in logs
+
+## Severity Classification
+
+| Severity | Meaning |
+|---|---|
+| `BLOCKER` | Must fix before merge: security flaw, data loss risk, missing required test, spec gap |
+| `MAJOR` | Should fix before merge |
+| `MINOR` | Lower-impact; still must be fixed before approval |
+| `NIT` | Style/naming; still must be fixed before approval |
+
+**All severities are blocking in this workflow.** A single NIT is sufficient to produce `REQUEST_CHANGES`.
+
+## Decision Rules
+
+- If implementation conflicts with spec, **spec wins** unless the reviewer explicitly confirms a spec change.
+- If implementation matches spec but diverges from plan, flag as `PLAN DEVIATION` and request either plan update or code correction.
+
+## Finding Format
+
+Every finding must include:
+- Short title
+- Severity (`BLOCKER` | `MAJOR` | `MINOR` | `NIT`)
+- Type (`SPEC_GAP` | `PLAN_DEVIATION` | `BUG` | `SECURITY` | `TEST_GAP` | `DESIGN` | `OTHER`)
+- Affected files with line references in `path:line` format
+- Evidence (what was observed, with line-level refs)
+- Requested change (exact, actionable)
+- Acceptance check (objective verification condition)
+
+## Review Decision
+
+Set one of:
+- `APPROVE`: no findings at any severity
+- `REQUEST_CHANGES`: at least one finding at any severity
+- `COMMENT`: informational review with no blocking request
+
+## Completion Checks
+
+Before finalising the review file, verify:
+- [ ] All findings are written with concrete requested changes and acceptance checks
+- [ ] Every requirement checklist item is marked (PASS/PARTIAL/FAIL/N/A)
+- [ ] No finding is missing line-level file evidence
+- [ ] The summary decision matches the findings (any finding → `REQUEST_CHANGES`)