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, 50 insertions, 0 deletions

diff --git a/respond-to-review/SKILL.md b/respond-to-review/SKILL.md
new file mode 100644
index 0000000..c1cc996
--- /dev/null
+++ b/respond-to-review/SKILL.md
@@ -0,0 +1,50 @@
+# /respond-to-review — Evaluate and Implement Code Review Feedback
+
+Evaluate code review feedback technically before implementing. Verify suggestions against the actual codebase — don't implement blindly.
+
+## Usage
+
+```
+/respond-to-review [PR_NUMBER]
+```
+
+If no PR number is given, check the current branch's open PR for pending review comments.
+
+## Instructions
+
+### 1. Gather the Feedback
+
+- Fetch review comments using `gh api repos/{owner}/{repo}/pulls/{number}/comments` (for inline review comments) and `gh api repos/{owner}/{repo}/issues/{number}/comments` (for top-level PR conversation comments)
+- Read each comment in full. Group related comments — reviewers often raise connected issues across multiple comments.
+
+### 2. Evaluate Each Item
+
+For each review comment, before implementing anything:
+
+1. **Restate the suggestion in your own words** — make sure you understand what's being asked. If you can't restate it clearly, ask for clarification before touching code.
+2. **Verify against the codebase** — check whether the reviewer's premise is correct. Reviewers sometimes misread code, miss context, or reference outdated patterns. Read the actual code they're commenting on.
+3. **Check YAGNI** — if the reviewer suggests a "more proper" or "more robust" implementation, grep the codebase for actual usage. If nothing uses the suggested pattern today, flag it: "This would add complexity without current consumers. Should we defer until there's a concrete need?"
+4. **Assess the suggestion** — categorize as:
+   - **Correct and actionable** — implement it
+   - **Correct but out of scope** — acknowledge and create a follow-up issue
+   - **Debatable** — present your reasoning and ask for the reviewer's perspective
+   - **Incorrect** — explain why with evidence (file paths, test results, documentation)
+
+### 3. Respond
+
+- Lead with technical substance, not agreement
+- If you disagree, explain why with code references — not opinion
+- If you're unsure, say so and ask a specific question
+- Never implement a suggestion you don't understand
+
+### 4. Implement
+
+- Address simple fixes first, complex ones after
+- Test each change individually — don't batch unrelated fixes into one commit
+- Run the full test suite after all changes
+- Commit with conventional messages referencing the review: `fix: Address review — [description]`
+
+### 5. Report
+
+- Summarize what was implemented, what was deferred, and what needs discussion
+- Link any follow-up issues created for out-of-scope suggestions