update skills

.agents/skills/code-review/SKILL.md

@@ -1,35 +1,43 @@
 ---
 name: code-review
-description: Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
+description: Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
 ---
 
-Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
+Two-axis review of the changes the user selected, including working changes when requested:
 
 - **Standards** — does the code conform to this repo's documented coding standards?
-- **Spec** — does the code faithfully implement the originating issue / spec?
+- **Spec** — does the code faithfully implement the originating issue / PRD / spec?
 
-Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.
+Use independent **parallel sub-agents** when available, then aggregate their findings. If delegation is unavailable, review both axes directly and disclose the limitation.
 
-The issue tracker should have been provided to you — run `/setup-matt-pocock-skills` if `docs/agents/issue-tracker.md` is missing.
+Use `docs/agents/issue-tracker.md` for remote specs. A missing tracker configuration does not block reviewing local changes or a supplied spec.
 
 ## Process
 
-### 1. Pin the fixed point
+### 1. Pin the requested scope
 
-Whatever the user said is the fixed point — a commit SHA, branch name, tag, `main`, `HEAD~5`, etc. If they didn't specify one, ask for it.
+Honor the user's baseline and file scope. For a pre-commit review, use the implementation's recorded starting commit and task-owned paths; for an ordinary review of uncommitted work, default to `HEAD`. Ask only when an unresolved baseline or scope choice would materially change the review.
 
-Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.
+Resolve the baseline to a commit with `git rev-parse --verify '<ref>^{commit}'`. For a branch/PR review, use its merge-base when the request is for changes introduced on that branch; for an explicit commit-to-commit comparison, use the supplied commit directly.
 
-Before going further, confirm the fixed point resolves (`git rev-parse <fixed-point>`) and the diff is non-empty. A bad ref or empty diff should fail here — not inside two parallel sub-agents.
+Choose and record commands appropriate to the selected scope, adding `-- <task-paths>` where needed:
+
+| Scope | Tracked changes | New files |
+| --- | --- | --- |
+| Committed only | `git diff <base> HEAD` | Included if committed |
+| Current working result, including staged and unstaged | `git diff <base>` | List with `git ls-files --others --exclude-standard` and read each in-scope file |
+| Staged only | `git diff --cached <base>` | Included if staged |
+
+Inspect `git status --short` and distinguish pre-existing user changes from task changes. When ownership overlaps, obtain the task's actual patch or state the limitation; do not attribute the entire dirty checkout to the implementation. Record relevant commits with `git log <base>..HEAD --oneline`. An empty tracked diff is not an empty review until in-scope new files are checked. Report genuinely empty scope directly; resolve invalid refs before dispatch.
 
 ### 2. Identify the spec source
 
 Look for the originating spec, in this order:
 
-1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.) — fetch via the workflow in `docs/agents/issue-tracker.md`.
-2. A path the user passed as an argument.
-3. A spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.
-4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available".
+1. The user's explicit spec, ticket, path, or acceptance criteria in the conversation. Preserve it as authoritative even when commits reference other work.
+2. Issue/MR references in relevant commit messages — fetch via `docs/agents/issue-tracker.md` when no explicit source was supplied.
+3. A PRD/spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.
+4. If nothing is found or the source is inaccessible, continue the Standards review and report the Spec coverage limitation. Ask for a source only when needed to answer the user's request; do not invent requirements or require tracker setup.
 
 ### 3. Identify the standards sources
 
@@ -57,15 +65,17 @@ Each smell reads *what it is* → *how to fix*; match it against the diff:
 
 ### 4. Spawn both sub-agents in parallel
 
+Use the environment's available delegation tool; do not depend on a product-specific `Agent` or `Task` name. Give each reviewer the same resolved baseline, tracked diff commands, in-scope new-file list, task ownership boundaries, and current snapshot. Review-only agents must not modify files or external state.
+
 **Standards sub-agent prompt** — include:
 
-- The full diff command and commit list.
+- The full diff commands, new-file contents or paths, scope, and commit list.
 - The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full — the sub-agent has no other access to it.
 - The brief: "Report — per file/hunk where relevant — (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls — documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
 
 **Spec sub-agent prompt** — include:
 
-- The diff command and commit list.
+- The same diff commands, new files, scope, and commit list as the Standards reviewer.
 - The path or fetched contents of the spec.
 - The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."