Add general-purpose skills and rules from DeepSat coding-rulesets

Skills (adapted from DeepSat, stripped of project-specific references):
- /review-pr: PR review against engineering standards
- /fix-issue: issue-to-merge TDD workflow
- /security-check: secrets, OWASP, and dependency audit
- /debug: systematic 4-phase debugging
- /add-tests: test coverage analysis and generation
- /respond-to-review: evaluate and implement code review feedback

Rules (general-purpose, copied as-is):
- testing.md: universal TDD standards and anti-patterns
- verification.md: proof over assumption

Makefile updated to install both skills and rules via symlinks.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

1 files changed, 54 insertions, 0 deletions

diff --git a/fix-issue/SKILL.md b/fix-issue/SKILL.md
new file mode 100644
index 0000000..adfed14
--- /dev/null
+++ b/fix-issue/SKILL.md
@@ -0,0 +1,54 @@
+# /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.