chore: remove fix-issue skill, superseded by start-work

The fix-issue skill has been replaced by start-work, which covers the same ground (picking up a ticket with a known fix and carrying it through to handoff) with a seven-phase structure and three user-approval gates. Deleted fix-issue/SKILL.md and swept the references.

Updated:
- Makefile SKILLS list: remove fix-issue, add start-work so make install creates the right symlink.
- brainstorm/SKILL.md: implementation-path list points at start-work.
- debug/SKILL.md description: both "do NOT use for ticket-driven work" and "Companion to" references updated.
- review-code/SKILL.md description: "drafting implementation" redirect updated.

No change in meaning. Every old fix-issue context now names start-work.

5 files changed, 4 insertions, 63 deletions

diff --git a/Makefile b/Makefile
index 0c26ea8..aa1163a 100644
--- a/Makefile
+++ b/Makefile
@@ -4,7 +4,7 @@ SHELL := /bin/bash
 SKILLS_DIR := $(HOME)/.claude/skills
 RULES_DIR  := $(HOME)/.claude/rules
 HOOKS_DIR  := $(HOME)/.claude/hooks
-SKILLS     := c4-analyze c4-diagram debug add-tests respond-to-review review-code fix-issue security-check \
+SKILLS     := c4-analyze c4-diagram debug add-tests respond-to-review review-code start-work security-check \
               arch-design arch-decide arch-document arch-evaluate \
               brainstorm codify root-cause-trace five-whys prompt-engineering \
               playwright-js playwright-py frontend-design pairwise-tests \
diff --git a/brainstorm/SKILL.md b/brainstorm/SKILL.md
index 2f84aa6..1b9ad08 100644
--- a/brainstorm/SKILL.md
+++ b/brainstorm/SKILL.md
@@ -155,7 +155,7 @@ After the design is written and agreed:
 
 - **Each open question** → run `arch-decide` to record as an ADR
 - **System-level implications** → run `arch-design` to update the architecture brief
-- **Implementation** → whatever the project's implementation path is (`fix-issue`, `add-tests`, or direct work)
+- **Implementation** → whatever the project's implementation path is (`start-work`, `add-tests`, or direct work)
 
 Link the design doc from wherever it's being implemented (PR description, ticket, commit).
 
diff --git a/debug/SKILL.md b/debug/SKILL.md
index 7b207aa..1a64e82 100644
--- a/debug/SKILL.md
+++ b/debug/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: debug
-description: Investigate a bug or test failure methodically through four phases — understand the symptom (reproduce, read logs, locate failure point, trace data flow), isolate variables (minimal repro, bisect), form and test hypotheses, then fix at the root. Captures evidence before proposing fixes; rejects shotgun debugging; escalates to architectural investigation after three failed fix attempts. Use when the failure mode is unclear, the failure reproduces inconsistently, or you're about to start guessing. Do NOT use for clear local bugs where the fix site is obvious (just fix it), for ticket-driven implementation work with a known fix (use fix-issue), for backward-walking a specific error up the call stack (use root-cause-trace), or for process/organizational root-cause analysis of recurring incidents (use five-whys). Companion to fix-issue / root-cause-trace / five-whys — debug is the broad investigative workflow; the others specialize.
+description: Investigate a bug or test failure methodically through four phases — understand the symptom (reproduce, read logs, locate failure point, trace data flow), isolate variables (minimal repro, bisect), form and test hypotheses, then fix at the root. Captures evidence before proposing fixes; rejects shotgun debugging; escalates to architectural investigation after three failed fix attempts. Use when the failure mode is unclear, the failure reproduces inconsistently, or you're about to start guessing. Do NOT use for clear local bugs where the fix site is obvious (just fix it), for ticket-driven implementation work with a known fix (use start-work), for backward-walking a specific error up the call stack (use root-cause-trace), or for process/organizational root-cause analysis of recurring incidents (use five-whys). Companion to start-work / root-cause-trace / five-whys — debug is the broad investigative workflow; the others specialize.
 ---
 
 # /debug — Systematic Debugging
diff --git a/fix-issue/SKILL.md b/fix-issue/SKILL.md
deleted file mode 100644
index 0b6e208..0000000
--- a/fix-issue/SKILL.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-name: fix-issue
-description: Ticket-driven implementation workflow — fetch issue details from the tracker (Linear / GitHub Issues / Jira), create a branch, implement against acceptance criteria with tests, and commit/push. Reads the issue, verifies the delivery matches intent, handles the full branch lifecycle. Use when you have an issue ID or a well-scoped task ready to implement. Do NOT use for open-ended bug investigation without a clear fix path (use debug first), for tracing an error through a long call stack to its origin (use root-cause-trace), for small unticketed edits (just do them), or when requirements aren't yet clear (use brainstorm or arch-design). Companion to debug — fix-issue is the workflow scaffold around implementing a known fix; debug is the upstream investigative phase.
----
-
-# /fix-issue — Pick Up and Implement an Issue
-
-Create a branch, implement the fix, test, and commit.
-
-## Usage
-
-```
-/fix-issue [ISSUE_ID]
-```
-
-If no issue ID is given, prompt the user to provide one or describe the issue.
-
-## Instructions
-
-1. **Fetch the issue** from the project's issue tracker (Linear, GitHub Issues, Jira, etc.) or ask the user for the issue details (title, description, acceptance criteria).
-
-2. **Create a branch** following the naming convention:
-   - Bug: `fix/ISSUE_ID-short-description`
-   - Feature: `feature/ISSUE_ID-short-description`
-   - Chore: `chore/ISSUE_ID-short-description`
-
-3. **Explore the codebase and find the root cause**:
-   - Do NOT jump to a fix. Read the relevant modules, trace the data flow, and understand how the system works around the issue.
-   - Identify the **root cause**, not just the surface symptom. If a value is wrong in a handler, trace it back through the service, model, schema, or migration — wherever the real problem lives.
-   - Read callers, callees, and related tests to understand the full context of the change.
-   - Follow the project's coding standards and conventions
-   - Keep changes focused — only what the issue requires
-   - If the change involves data flow, confirm API contracts (schemas, typed clients) exist or create them first
-   - No drive-by refactoring or scope creep
-
-4. **Write failing test first (TDD)** — before any implementation code:
-   - Create a test file if one doesn't exist for the module
-   - Write a test that demonstrates the bug or defines the desired behavior — this proves you understand the root cause
-   - Run the test — confirm it **fails**
-   - Commit: `test: Add failing test for [issue]`
-
-5. **Implement the fix**:
-   - Write the minimal code to make the failing test pass
-   - Run the test — confirm it **passes**
-   - Commit: `fix: [description]`
-
-6. **Add edge case tests — be thorough**:
-   - Add boundary and error case tests (normal, boundary, and error categories)
-   - Think through all edge cases: empty inputs, nulls, concurrent access, large data, permission boundaries, and interactions with adjacent modules
-   - Run the full test suite to confirm nothing is broken
-   - Commit: `test: Add edge cases for [issue]`
-
-7. **Refactor if needed**:
-   - Clean up the implementation while all tests stay green
-   - Commit: `refactor: [description]`
-
-All commits must use conventional messages (`feat:`, `fix:`, `chore:`, `test:`, `refactor:`), reference the issue ID in the body, and contain no AI attribution.
-
-8. **Report** what was done: files changed, tests added, and any open questions.
diff --git a/review-code/SKILL.md b/review-code/SKILL.md
index fdf5cfb..f01094c 100644
--- a/review-code/SKILL.md
+++ b/review-code/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: review-code
-description: Review code changes against engineering standards. Accepts a PR number, a SHA range (BASE..HEAD), the current branch's diff against main, staged changes, or a described scope ("the last 3 commits"). Audits CLAUDE.md adherence (reads root + per-directory CLAUDE.md), intent-vs-delivery (when given a plan/ADR/ticket), security, testing (TDD evidence + three-category coverage), conventions (conventional commits + no AI attribution), root-cause discipline, architecture (layering + scope), API contracts. Produces a structured report — Strengths, per-criterion PASS/WARN/FAIL, per-issue Critical/Important/Minor severity — ending with an explicit verdict (Approve / Request Changes / Needs Discussion) plus 1-2 sentence reasoning. Self-filters low-confidence findings; never flags pre-existing issues, lint/typecheck issues (CI handles those), or changes on unmodified lines. Use before merging a PR, before pushing a branch, or when reviewing a teammate's work. Do NOT use for proposing features (use brainstorm or arch-design), drafting implementation (use fix-issue or add-tests), standalone security audits (use security-check), or narrow style-only checks (a linter handles those).
+description: Review code changes against engineering standards. Accepts a PR number, a SHA range (BASE..HEAD), the current branch's diff against main, staged changes, or a described scope ("the last 3 commits"). Audits CLAUDE.md adherence (reads root + per-directory CLAUDE.md), intent-vs-delivery (when given a plan/ADR/ticket), security, testing (TDD evidence + three-category coverage), conventions (conventional commits + no AI attribution), root-cause discipline, architecture (layering + scope), API contracts. Produces a structured report — Strengths, per-criterion PASS/WARN/FAIL, per-issue Critical/Important/Minor severity — ending with an explicit verdict (Approve / Request Changes / Needs Discussion) plus 1-2 sentence reasoning. Self-filters low-confidence findings; never flags pre-existing issues, lint/typecheck issues (CI handles those), or changes on unmodified lines. Use before merging a PR, before pushing a branch, or when reviewing a teammate's work. Do NOT use for proposing features (use brainstorm or arch-design), drafting implementation (use start-work or add-tests), standalone security audits (use security-check), or narrow style-only checks (a linter handles those).
 ---
 
 # /review-code