@kennethsolomon/shipkit 3.19.0 → 3.21.0

package/skills/sk:perf/SKILL.md

@@ -8,31 +8,28 @@ allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent
 
 ## Purpose
 
-Audit the implementation for performance issues before the final review. This skill identifies issues, produces a findings report, fixes in-scope critical/high findings immediately, and auto-commits. Pre-existing findings outside the branch diff are logged to `tasks/tech-debt.md`.
-
-Run this skill after implementing and passing lint/tests, but before `/sk:review`.
+Audit the implementation for performance issues before `/sk:review`. Produces a findings report, fixes in-scope critical/high findings, auto-commits. Pre-existing findings (outside branch diff) are logged to `tasks/tech-debt.md`.
 
 ## Hard Rules
 
-- **Fix all critical and high in-scope findings** (files in `git diff main..HEAD --name-only`) immediately after the audit. Re-run the audit until critical/high = 0. Once clean, make ONE squash commit: `fix(perf): resolve performance findings`.
-- **Medium/low in-scope findings:** fix them in the same pass if straightforward, otherwise log to `tasks/tech-debt.md`.
-- **Pre-existing findings** (files outside the current branch diff): log to `tasks/tech-debt.md` using this format — do NOT fix inline:
+- Fix all critical and high in-scope findings (files in `git diff main..HEAD --name-only`). Re-run until critical/high = 0. ONE squash commit: `fix(perf): resolve performance findings`.
+- Medium/low in-scope: fix if straightforward, otherwise log to `tasks/tech-debt.md`.
+- Pre-existing findings (outside branch diff): log only — do NOT fix inline:
   ```
   ### [YYYY-MM-DD] Found during: sk:perf
   File: path/to/file.ext:line
   Issue: description of the performance issue
   Severity: critical | high | medium | low
   ```
-- **Squash gate commits** — collect all fixes for the pass, then one commit. Do not commit after each individual fix.
-- **Every finding must cite a specific file and line number.**
-- **Every finding must include an estimated impact** (high/medium/low) and a recommendation.
-- **Auto-detect the stack** — only run checks relevant to what's present.
+- Squash gate commits — one commit per pass, not per fix.
+- Every finding must cite a specific file:line, estimated impact (high/medium/low), and a recommendation.
+- Auto-detect stack — only run checks relevant to what's present.
 
 ## Before You Start
 
-1. Detect the stack: read `CLAUDE.md`, check for `package.json`, `composer.json`, `go.mod`, `requirements.txt`, `Cargo.toml`, etc.
-2. Determine scope: `git diff main..HEAD --name-only` to find changed files.
-3. If `tasks/perf-findings.md` exists, read it — check if prior findings have been addressed.
+1. Detect stack: read `CLAUDE.md`, check for `package.json`, `composer.json`, `go.mod`, `requirements.txt`, `Cargo.toml`.
+2. Determine scope: `git diff main..HEAD --name-only`.
+3. If `tasks/perf-findings.md` exists, read it — check if prior findings were addressed.
 4. If `tasks/lessons.md` exists, read it — apply performance-related lessons.
 
 ## Stack Detection
@@ -120,7 +117,7 @@ Run this skill after implementing and passing lint/tests, but before `/sk:review
 
 ## Generate Report
 
-Write findings to `tasks/perf-findings.md`:
+Write findings to `tasks/perf-findings.md` (never overwrite — append with date header):
 
 ```markdown
 # Performance Audit — YYYY-MM-DD
@@ -167,13 +164,11 @@ Write findings to `tasks/perf-findings.md`:
 | **Total** | **N** | **N**            |
 ```
 
-**Never overwrite** `tasks/perf-findings.md` — append new audits with a date header.
-
-The report is written first, then fixes are applied to in-scope critical/high findings.
+Write the report first, then apply fixes.
 
 ## Fix Critical/High Findings via Agent
 
-If Critical or High findings exist, invoke the **`performance-optimizer` agent** to apply fixes:
+Invoke the **`performance-optimizer`** agent:
 
 ```
 Task: "Read tasks/perf-findings.md. Fix all Critical and High in-scope findings
@@ -181,43 +176,29 @@ Task: "Read tasks/perf-findings.md. Fix all Critical and High in-scope findings
 pass before AND after. Commit: fix(perf): resolve performance findings"
 ```
 
-The `performance-optimizer` agent works in worktree isolation and runs tests around every fix. After it completes, merge its worktree branch and verify the fix in `tasks/perf-findings.md`.
+Agent works in worktree isolation. After completion, merge its worktree branch and verify fixes in `tasks/perf-findings.md`.
 
-## When Done
+## Fix & Retest Protocol
 
-Tell the user:
+| Fix type | Action |
+|----------|--------|
+| Config/infrastructure (cache headers, compression, CDN config, pool size) | Commit → re-run `/sk:perf`. No test update needed. |
+| Logic change (N+1 fix, algorithm refactor, pagination, data structure) | 1) Update/add failing tests 2) `/sk:test` at 100% 3) Commit tests+fix together 4) Re-run `/sk:perf` |
+
+Logic changes include: N+1 fix (query count/data shape), algorithm change (output correctness), pagination (result set size). Tests must verify the optimized path produces correct results.
+
+## When Done
 
 > "Performance audit complete. Findings saved to `tasks/perf-findings.md`.
 > - **Critical:** N | **High:** N | **Medium:** N | **Low:** N
 >
 > All critical/high in-scope findings have been fixed and committed. Pre-existing issues logged to `tasks/tech-debt.md`. Run `/sk:review` to proceed."
 
-If there are no critical or high findings:
+If no critical/high findings:
 > "No critical or high performance issues found. N medium/low findings noted in `tasks/perf-findings.md`. Run `/sk:review` to proceed."
 
 ---
 
-## Fix & Retest Protocol
-
-When applying a performance fix, classify it before committing:
-
-**a. Config/infrastructure change** (adding cache headers, enabling compression, changing CDN config, adjusting connection pool size) → commit and re-run `/sk:perf`. No test update needed.
-
-**b. Logic change** (fixing N+1 query by changing data-fetching logic, refactoring algorithm, modifying data structure, changing pagination logic) → trigger protocol:
-1. Update or add failing unit tests for the new optimized behavior
-2. Re-run `/sk:test` — must pass at 100% coverage
-3. Commit (tests + fix together in one commit)
-4. Re-run `/sk:perf` to verify the fix resolved the finding
-
-**Common logic-change performance fixes:**
-- N+1 fix: changes how related data is fetched → update tests that assert on query count or data shape
-- Algorithm change: O(n²) → O(n log n) → update tests that assert on output correctness
-- Pagination: adding LIMIT/offset → update tests that assert on result set size
-
-**Why:** Performance fixes often change how data is fetched or processed. Tests must verify the optimized path produces correct results.
-
----
-
 ## Model Routing
 
 Read `.shipkit/config.json` from the project root if it exists.

package/skills/sk:review/SKILL.md

@@ -8,124 +8,102 @@ model: sonnet
 
 ## Overview
 
-Perform a rigorous, multi-dimensional review of all changes on the current branch. This review aims for the quality bar of a senior engineer at a top-tier tech company — thorough, specific, and honest.
+Perform a rigorous, multi-dimensional review of all changes on the current branch. Quality bar: senior engineer at a top-tier tech company — thorough, specific, and honest.
 
-**You are the reviewer, not the cheerleader.** Your job is to find problems, not to praise the code. If you find nothing wrong, look harder. Real code almost always has something worth flagging. Think about what could go wrong in production at scale, under adversarial conditions, and over time as the codebase evolves.
+**You are the reviewer, not the cheerleader.** Find problems, not praise. If you find nothing wrong, look harder. Think about what could go wrong in production at scale, under adversarial conditions, and over time.
 
-This is a **report-only** step. If Critical or Warning issues are found, the user loops back to `/sk:debug` → `/sk:smart-commit` → `/sk:review` until the branch is clean. Once clean, the user runs `/sk:finish-feature` to finalize and create the PR.
+This is a **report-only** step. Critical or Warning issues loop back to `/sk:debug` → `/sk:smart-commit` → `/sk:review` until clean. Then run `/sk:finish-feature`.
 
-**exhaustiveness commitment:** Partial completion is unacceptable. Every dimension (Steps 3–9) must be fully analyzed before generating the report. If you find nothing wrong in a dimension, state it explicitly (`"No issues found"`) — do not skip or leave it blank. Skipping a dimension is a failure.
+**exhaustiveness commitment:** Every dimension (Steps 3–9) must be fully analyzed before generating the report. Skipping a dimension is a failure. If nothing is found in a dimension, state `"No issues found"` explicitly.
 
 ## Allowed Tools
 
 Bash, Read, Glob, Grep, Skill
 
-**Step 0 only:** the `simplify` skill is invoked via the Skill tool, which carries its own Write/Edit permissions. All other steps are read-only — no direct Write or Edit calls. If issues are found in the main review, the user decides what to fix.
+**Step 0 only:** the `simplify` skill carries its own Write/Edit permissions. All other steps are read-only — no direct Write or Edit calls.
 
 ## Steps
 
-You MUST complete these steps in order:
-
 ### 0. Run Simplify First
 
-Before reviewing, invoke the built-in `simplify` skill on the changed files to catch reuse, quality, and efficiency issues automatically:
+Invoke the built-in `simplify` skill on the changed files:
 
 > "Review the changed files on this branch for reuse, quality, and efficiency. Fix any issues found."
 
-Use `git diff main..HEAD --name-only` to identify the changed files, then run simplify on them.
+Use `git diff main..HEAD --name-only` to identify changed files, then run simplify on them.
 
-If simplify makes any changes:
+If simplify makes changes:
 1. Verify the changes are correct
-2. Auto-commit them with message `fix(review): simplify pre-pass` before continuing the review. Do not ask the user.
+2. Auto-commit with `fix(review): simplify pre-pass` — do not ask the user
 3. Note in the review report: "Simplify pre-pass: X files updated"
 
-If simplify makes no changes, proceed directly to step 1.
-
-**Note:** Simplify runs automatically as part of `/sk:review` — users do not need to run it separately.
-
 ### 1. Read Project Context
 
 ```
 CLAUDE.md                  — Coding standards, conventions, known patterns
-tasks/lessons.md           — Recurrent bug patterns for this project (if exists)
+tasks/lessons.md           — Recurrent bug patterns (if exists)
 tasks/security-findings.md — Prior security audit results (if exists)
 ```
 
-Understand what "correct" looks like for this project — the tech stack, conventions, and known pitfalls.
-
-If `tasks/lessons.md` exists, read it in full. Use each active lesson's **Bug** field
-as an additional targeted check during analysis — treat each lesson as a known failure
-mode to explicitly scan for across all review dimensions.
+If `tasks/lessons.md` exists, treat each active lesson's **Bug** field as an additional targeted check across all dimensions.
 
-If `tasks/security-findings.md` exists, read the most recent audit. Use any unresolved
-Critical/High findings as additional targeted checks — verify the current diff doesn't
-reintroduce previously flagged vulnerabilities.
+If `tasks/security-findings.md` exists, verify the current diff doesn't reintroduce previously flagged unresolved Critical/High vulnerabilities.
 
 ### 2. Collect Changes + Blast Radius
 
-Instead of reading the entire codebase or only the diff, build a **blast radius** — the minimal set of files that could be affected by the changes. This produces focused, high-signal context that leads to better review quality.
+Build a **blast radius** — the minimal set of files that could be affected by the changes.
 
 **2a — Baseline git info:**
 
 ```bash
-# Determine base branch
 BASE=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "main")
-
-# Changed files and stats
 CHANGED_FILES=$(git diff $BASE..HEAD --name-only)
 git diff $BASE..HEAD --stat
 git log $BASE..HEAD --oneline
-
-# Full diff for reference
 git diff $BASE..HEAD
-
-# Check for uncommitted changes
 git status --short
 ```
 
-If there are uncommitted changes, warn:
+If uncommitted changes exist, warn:
 > **Warning:** You have uncommitted changes. These will NOT be included in the review. Commit or stash them first.
 
 **2b — Extract changed symbols:**
 
-Use **git hunk headers** as the primary extraction method. Git already parses the enclosing function/class name into every `@@` header — this is more reliable than regex or AST tools:
+Use git hunk headers as the primary extraction method:
 
 ```bash
-# Phase 1: Enclosing scope names from hunk headers (free from git, no parsing needed)
+# Phase 1: Enclosing scope names from hunk headers
 git diff $BASE..HEAD -U0 | grep '^@@' | sed 's/.*@@\s*//' | \
   grep -oE '[A-Za-z_][A-Za-z0-9_]*\s*\(' | sed 's/\s*(//' | sort -u
 ```
 
-Then supplement with **new/modified definitions** from added lines using language-specific patterns. Only match definition keywords — not `const`, `export`, `type`, or other high-noise terms:
+Supplement with new/modified definitions from added lines:
 
 ```bash
-# Phase 2: Definitions from added lines (supplement, not replace)
-# JS/TS:   function foo(, class Foo, interface Foo
-# Python:  def foo(, class Foo
-# Go:      func foo(, func (r *T) foo(
-# PHP:     function foo(, class Foo
-# Rust:    fn foo(, struct Foo, impl Foo, trait Foo
+# Phase 2: Definitions from added lines
+# JS/TS: function foo(, class Foo, interface Foo
+# Python: def foo(, class Foo
+# Go: func foo(, func (r *T) foo(
+# PHP: function foo(, class Foo
+# Rust: fn foo(, struct Foo, impl Foo, trait Foo
 git diff $BASE..HEAD | grep '^+' | grep -v '^+++' | \
   grep -oE '(function|class|interface|def|fn|func|struct|trait|impl)\s+[A-Za-z_][A-Za-z0-9_]+' | \
   awk '{print $2}' | sort -u
 ```
 
-Combine both phases. Filter out symbols shorter than 3 characters (too generic for blast-radius search).
+Combine both phases. Filter symbols shorter than 3 characters.
 
 Classify each symbol:
-- **Modified/removed** — existed before the branch, changed or deleted now. These can break callers. **Run blast radius on these.**
-- **New** — added in this branch, no prior callers exist. **Skip blast radius** (nothing to break).
+- **Modified/removed** — existed before the branch, changed or deleted. **Run blast radius.**
+- **New** — added in this branch, no prior callers. **Skip blast radius.**
 
-To classify, check if the symbol appears in the base branch:
 ```bash
-# If symbol exists in base branch files, it's modified/removed → needs blast radius
+# If symbol exists in base branch, it's modified/removed → needs blast radius
 git show $BASE:$FILE 2>/dev/null | grep -q "\b$SYMBOL\b"
 ```
 
 **2c — Find blast radius (modified/removed symbols only):**
 
-For each modified/removed symbol, use **import-chain narrowing** to find dependents with minimal false positives:
-
 ```bash
 # Step 1: Find files that import the module containing the changed symbol
 CHANGED_MODULE_PATHS=$(echo "$CHANGED_FILES" | sed 's/\.[^.]*$//' | sed 's/\/index$//')
@@ -141,11 +119,10 @@ for symbol in $MODIFIED_SYMBOLS; do
   rg -wl "$symbol" $(cat /tmp/importers.txt) 2>/dev/null
 done | sort -u > /tmp/dependents.txt
 
-# Remove files already in the changed set
 comm -23 /tmp/dependents.txt <(echo "$CHANGED_FILES" | sort) > /tmp/blast_radius.txt
 ```
 
-**Noise guard:** If a symbol produces >100 matches, it's too generic for grep-based analysis. Note it in the review as "unable to determine blast radius for `symbol` — manual verification recommended."
+**Noise guard:** If a symbol produces >100 matches, note: "unable to determine blast radius for `symbol` — manual verification recommended."
 
 Log the blast radius before reading:
 ```
@@ -165,14 +142,12 @@ Symbol → Dependents:
 **2d — Read context (focused, not exhaustive):**
 
 Read in this priority order:
-1. **Changed files in full** — not just the diff. The full file provides surrounding context (imports, related functions, class-level state) needed to judge whether the change is correct. For files >500 lines, read the changed function + 30 lines of surrounding context instead.
+1. **Changed files in full** — not just the diff. For files >500 lines, read the changed function + 30 lines of surrounding context.
 2. **The diff** — for precise change tracking (already collected above).
-3. **Blast-radius dependent files** — read only the call sites that reference changed symbols. Use `rg -B5 -A10 "\bsymbol\b" dependent_file` to get the call site with surrounding context, not the entire file.
+3. **Blast-radius dependent files** — use `rg -B5 -A10 "\bsymbol\b" dependent_file` to get call sites with context, not the entire file.
 4. **Test files** for changed symbols — verify existing tests still cover the changed behavior.
 
-Do **not** read unchanged files outside the blast radius.
-
-Carry the blast-radius mapping (symbol → dependents) forward into Steps 3-9. When analyzing a changed function, always cross-reference its dependents.
+Do not read unchanged files outside the blast radius. Carry the blast-radius mapping (symbol → dependents) forward into Steps 3–9.
 
 > Before analyzing this dimension, use a `<think>` block to: (1) identify which changed files and blast-radius dependents are most relevant here, and (2) list 3–5 specific things to look for given the nature of the change. This reasoning is not shown to the user — it improves analysis depth.
 
@@ -180,7 +155,7 @@ Carry the blast-radius mapping (symbol → dependents) forward into Steps 3-9. W
 
 The most important dimension. A bug that ships is worse than ugly code that works.
 
-**Blast-radius check (mandatory):** For every modified/removed symbol, verify its dependents (from Step 2c) are still compatible:
+**Blast-radius check (mandatory):** For every modified/removed symbol, verify its dependents (from Step 2c):
 - Do callers pass arguments the changed function still accepts?
 - Do callers depend on return values whose shape/type changed?
 - Do callers rely on side effects the changed code no longer produces?
@@ -219,11 +194,9 @@ The most important dimension. A bug that ships is worse than ugly code that work
 
 ### 4. Analyze — Security
 
-Load `references/security-checklist.md` and apply its grep patterns against the **diff and blast-radius files** (not the entire codebase). Only flag patterns **newly introduced** in the diff — pre-existing issues are out of scope unless they interact with the changed code.
+Load `references/security-checklist.md` and apply its grep patterns against the **diff and blast-radius files** only. Flag only patterns **newly introduced** in the diff.
 
-**Blast-radius check:** If a validation or auth function was modified, check all its callers (from Step 2c) — a weakened check affects every endpoint that depends on it.
-
-Check for:
+**Blast-radius check:** If a validation or auth function was modified, check all its callers — a weakened check affects every endpoint that depends on it.
 
 **Injection (OWASP A03):**
 - SQL, NoSQL, OS command, LDAP, template injection
@@ -233,7 +206,7 @@ Check for:
 **Cross-Site Scripting (OWASP A03):**
 - `dangerouslySetInnerHTML`, `innerHTML`, `v-html` without sanitization
 - URL parameters reflected without encoding
-- User content rendered in `href`, `src`, or event handler attributes
+- User content in `href`, `src`, or event handler attributes
 
 **Authentication & Authorization (OWASP A01, A07):**
 - Hardcoded secrets, API keys, tokens in source code
@@ -244,7 +217,7 @@ Check for:
 **Data exposure (OWASP A02):**
 - Credentials, PII, or tokens in logs
 - Stack traces or internal errors leaked to clients
-- Sensitive data in client-side bundles (secret keys in frontend code)
+- Sensitive data in client-side bundles
 - Missing encryption for sensitive data at rest
 
 **Configuration (OWASP A05):**
@@ -257,7 +230,7 @@ Check for:
 
 ### 5. Analyze — Performance
 
-Think about what happens at 10x, 100x current scale. Performance bugs are often invisible in development but catastrophic in production.
+Think about what happens at 10x, 100x current scale.
 
 **Database & queries:**
 - N+1 query patterns (fetching related data in a loop instead of a join or batch)
@@ -295,7 +268,7 @@ Think about what happens at 10x, 100x current scale. Performance bugs are often
 
 ### 6. Analyze — Reliability & Error Handling
 
-Production code must handle failure gracefully. The question isn't "does it work?" but "what happens when things go wrong?"
+The question isn't "does it work?" but "what happens when things go wrong?"
 
 **Blast-radius check:** If error handling changed (e.g., function now throws instead of returning null, or error type changed), check all callers from Step 2c — they may not have matching try/catch or null checks.
 
@@ -307,7 +280,7 @@ Production code must handle failure gracefully. The question isn't "does it work
 - Cleanup logic missing in error paths (connections, file handles, locks)
 
 **Graceful degradation:**
-- What happens when an external service is down? Does the whole feature break?
+- What happens when an external service is down?
 - Missing fallback behavior for optional dependencies
 - Timeout handling on external calls (HTTP, database, third-party APIs)
 - Missing retry logic with backoff for transient failures
@@ -327,7 +300,7 @@ Production code must handle failure gracefully. The question isn't "does it work
 
 ### 7. Analyze — Design & Best Practices
 
-Think about the next engineer who reads this code. Is the intent clear? Does the design scale with the codebase?
+Think about the next engineer who reads this code.
 
 **Separation of concerns:**
 - Business logic mixed with presentation/routing/data access
@@ -336,7 +309,7 @@ Think about the next engineer who reads this code. Is the intent clear? Does the
 
 **API design (if endpoints or function signatures changed):**
 - Breaking changes to existing API contracts without versioning
-- **Blast-radius check:** If a function signature changed, the blast radius from Step 2c is the definitive answer to whether it's a breaking change — every dependent file that calls the old signature will break
+- **Blast-radius check:** If a function signature changed, every dependent file that calls the old signature will break
 - Inconsistent response format across endpoints
 - Missing or inconsistent HTTP status codes
 - Unclear or missing error response schema
@@ -349,7 +322,7 @@ Think about the next engineer who reads this code. Is the intent clear? Does the
 - Deeply nested logic (>3 levels) that should be flattened with early returns
 
 **Dependency management:**
-- New dependencies added — are they necessary? Well-maintained? License-compatible?
+- New dependencies — necessary? Well-maintained? License-compatible?
 - Are there lighter alternatives for heavy imports?
 - Lock file updated when dependencies change?
 
@@ -357,12 +330,10 @@ Think about the next engineer who reads this code. Is the intent clear? Does the
 
 ### 8. Analyze — Framework-Specific
 
-Based on what the project uses:
-
 **React/Next.js:**
 - Missing keys in list rendering (or using array index as key for dynamic lists)
 - `useEffect` dependency arrays — missing deps cause stale data, unnecessary deps cause infinite loops
-- Client vs server component boundaries (Next.js App Router) — using hooks in server components, importing server-only code in client
+- Client vs server component boundaries (Next.js App Router) — hooks in server components, server-only code in client
 - State updates on unmounted components
 - Missing `Suspense` boundaries for async components
 - Missing `ErrorBoundary` for component-level error isolation
@@ -399,18 +370,16 @@ Based on what the project uses:
 
 If the diff includes test files, review them with the same rigor as production code.
 
-- **Coverage gaps:** Are all new code paths exercised? Happy path AND error paths?
-- **Edge cases:** Do tests cover boundary conditions, empty inputs, invalid data?
+- **Coverage gaps:** All new code paths exercised? Happy path AND error paths?
+- **Edge cases:** Boundary conditions, empty inputs, invalid data?
 - **Test isolation:** Do tests depend on external state, order, or other tests?
-- **Assertion quality:** Are assertions specific enough to catch regressions? (not just `toBeTruthy`)
+- **Assertion quality:** Specific enough to catch regressions? (not just `toBeTruthy`)
 - **Test naming:** Do test names describe the behavior being verified?
-- **Mocking:** Are mocks minimal and realistic? Over-mocking hides real bugs.
+- **Mocking:** Minimal and realistic? Over-mocking hides real bugs.
 - **Flakiness risks:** Timing-dependent assertions, network calls, random data without seeding
 
 ### 10. Generate Review Report
 
-Format findings with severity levels and review dimensions:
-
 ```markdown
 ## Code Review: [branch-name]
 
@@ -444,7 +413,7 @@ Format findings with severity levels and review dimensions:
 **Severity guidelines:**
 - **Critical:** Will cause bugs in production, security vulnerability, data loss, or crash. Must fix.
 - **Warning:** Likely to cause problems at scale, makes future bugs likely, or degrades reliability/performance meaningfully. Should fix.
-- **Nitpick:** Style, conventions, minor improvements. Won't break anything but worth noting.
+- **Nitpick:** Style, conventions, minor improvements. Won't break anything.
 
 **Rules:**
 - Maximum 20 items total (prioritize by severity, then by category)
@@ -452,16 +421,15 @@ Format findings with severity levels and review dimensions:
 - Use `[Blast Radius]` for issues found in dependent files — callers broken by changed signatures, importers affected by removed exports, tests that no longer cover the changed behavior
 - Every item must reference a specific file, line, and symbol using `[FILE:LINE:SYMBOL]` format
 - Every item must explain **why** it matters — the impact, not just the symptom
-- Include a brief "What Looks Good" section (2-3 items) — acknowledge strong patterns so they're reinforced. This isn't cheerleading — it's calibrating signal.
-- If you genuinely find nothing wrong after all 7 dimensions, say so — but that's rare
+- Include "What Looks Good" (2-3 items) — acknowledge strong patterns to reinforce them
 
 ### 11. Fix and Re-run
 
-After presenting the review report, fix **all** findings regardless of severity (Critical, Warning, and Nitpick). Do not ask the user whether to fix nitpicks — fix everything.
+Fix **all** findings regardless of severity. Do not ask whether to fix nitpicks.
 
 **For each finding:**
-- If the issue is in a file **within** the current branch diff (`git diff $BASE..HEAD --name-only`): fix it inline, include in the auto-commit
-- If the issue is in a file **outside** the current branch diff (pre-existing issue found via blast-radius): log it to `tasks/tech-debt.md` — do NOT fix it inline:
+- Issue in a file **within** the current branch diff → fix it inline, include in auto-commit
+- Issue in a file **outside** the current branch diff (pre-existing, found via blast-radius) → log to `tasks/tech-debt.md`, do NOT fix inline:
   ```
   ### [YYYY-MM-DD] Found during: sk:review
   File: path/to/file.ext:line
@@ -469,28 +437,24 @@ After presenting the review report, fix **all** findings regardless of severity
   Severity: critical | high | medium | low
   ```
 
-After all in-scope fixes are applied: make ONE squash commit with `fix(review): address review findings`. Do not ask the user. Re-run `/sk:review` from scratch.
-
-Loop until the review is completely clean (0 findings across all severities for in-scope code).
+After all in-scope fixes: make ONE squash commit `fix(review): address review findings`. Re-run `/sk:review` from scratch. Loop until 0 findings.
 
 When clean:
 > "Review complete — 0 findings. Run `/sk:finish-feature` to finalize the branch and create a PR."
 
-> Squash gate commits — collect all fixes for the pass, then one commit. Do not commit after each individual fix.
-
 ### Fix & Retest Protocol
 
-When applying a fix from this review, classify it before committing:
+Classify each fix before committing:
 
 **a. Style/naming/comment change** (rename variable, add doc comment, reorder imports, extract constant) → commit and re-run `/sk:review`. No test update needed.
 
-**b. Logic change** (fix incorrect condition, add missing null check, change data flow, refactor algorithm, fix async bug) → trigger protocol:
+**b. Logic change** (fix incorrect condition, add missing null check, change data flow, refactor algorithm, fix async bug):
 1. Update or add failing unit tests for the corrected behavior
 2. Re-run `/sk:test` — must pass at 100% coverage
-3. Auto-commit tests + fix together with `fix(review): [description]`.
+3. Auto-commit tests + fix together with `fix(review): [description]`
 4. Re-run `/sk:review` from scratch
 
-**Why:** Review catches logic bugs. Fixing a logic bug without updating tests leaves the test suite asserting on the old (wrong) behavior.
+**Why:** Fixing a logic bug without updating tests leaves the test suite asserting on the old (wrong) behavior.
 
 ---