skills/coding: add Verify Before You Finish discipline (#5961)

* skills/coding: add a Verify Before You Finish section

Claw-swe-bench failure analysis (run 799636ce) shows the remaining
failure shapes are verification gaps, not editing gaps: fixes that pass
the new behavior but break an adjacent previously-passing test in the
same module (e.g. hardcoding Secure=true where the correct fix is
conditional), and fixes shipped without re-running the reproduction.

Distilled from the claude-code bundled verify skill: reproduce first,
re-run the reproduction after the fix, run the sibling/module tests for
every modified file, treat any newly-failing test as your bug, and
re-read the final diff for minimality before finishing.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* skills: tighten code-review and github activation to explicit requests

Both skills were being injected into every claw-swe-bench system prompt
(~7K tokens/call of irrelevant instructions) because their activation
matched generic coding-task text: code-review's bare "review" keyword
and 'review\s.*(changes|commit)' pattern hit the task template's
"FINAL REVIEW ... compare your changes with the base commit" phase and
its "Check diff: git diff" example; github's "repository"/"commit"/
"branch" keywords and 'create\s.*(issue|repo)' pattern hit "Repository:
owner/name" context lines and "create a script that reproduces the
located issue". The selector qualifies any skill with score > 0, so one
generic keyword is enough to burn prompt budget.

Anchor both on explicit requests: determiner-bound review phrases
("review my/this/the changes"), owner/repo#N references, and
github-service-specific keywords. A quick check against the vendored
claw-swe-bench prompt shows zero keyword/pattern hits after the change
while the coding skill still activates on 12 keywords.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* skills/code-review: anchor PR match, drop broad substring keywords

Address bot review on #5961:
- \bPR\b word boundary so "review the private repo" / "review project"
  no longer false-match (was matching the unanchored PR alternative)
- make the determiner optional so bare "review code" / "review PR" match
- drop "review pr" / "review my" keywords (substring-matched
  "review project" / "review my itinerary")

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

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

skills/code-review/SKILL.md

@@ -4,12 +4,14 @@ version: "2.0.0"
 description: Paranoid architect review of code changes for bugs, security, missing tests, and undocumented assumptions. Works on local git diffs OR a GitHub pull request (e.g. `owner/repo N`). For PRs, can post findings as line-level review comments.
 activation:
   keywords:
-    - "review"
     - "code review"
     - "review changes"
+    - "review diff"
+    - "review pull request"
+    - "review commit"
   patterns:
-    - "(?i)review\\s.*(code|changes|diff|PR|pull request|commit)"
-    - "(?i)(check|look at|inspect)\\s.*(changes|diff|code)"
+    - "(?i)review\\s+(?:(this|my|the|these|that|latest|recent)\\s+)?(code|change|changes|diff|\\bPR\\b|pull request|commit)"
+    - "(?i)(check|look at|inspect)\\s+(this|my|the|these)\\s+(changes|diff|code)"
     - "(?i)review\\s+[a-z0-9._-]+/[a-z0-9._-]+\\s+#?\\d+"
   tags:
     - "code-review"

skills/coding/SKILL.md

@@ -33,7 +33,7 @@ activation:
   tags:
     - "development"
     - "coding"
-  max_context_tokens: 1500
+  max_context_tokens: 1900
 ---
 
 # Coding Best Practices
@@ -60,3 +60,13 @@ activation:
 - Preserve existing code style and conventions. Match the indentation, naming, and patterns of surrounding code.
 - Test after changes when test infrastructure exists. Use `shell` to run the project's test command.
 - Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees.
+
+## Verify Before You Finish
+
+A fix is not done when the code looks right — it is done when you have watched it work and watched everything around it keep working.
+
+- **Reproduce first.** Before changing code, reproduce the reported problem (a failing test, a minimal script, a command) and confirm it fails the way the issue describes. If you can't reproduce it, say so instead of fixing blind.
+- **Re-run the reproduction after the fix** and confirm the behavior actually changed.
+- **Run the existing tests for every file you modified** — the sibling/module test suite, not just your reproduction. Fixes that hardcode the new behavior often break the old one (e.g. forcing a flag unconditionally when the correct fix is conditional on context).
+- **A test you broke is your bug.** If a previously-passing test fails after your change, the fix is wrong or too broad — narrow it until both the new and old behavior pass. Never rationalize a newly-failing test as "unrelated" without proving it fails before your change too.
+- **Re-read the final diff before finishing.** Every hunk must be necessary for the fix; revert stray edits, leftover debug output, and drive-by "improvements". Delete any reproduction scripts you created outside the repo's test layout.

skills/github/SKILL.md

@@ -5,17 +5,20 @@ description: GitHub API integration via HTTP tool with automatic credential inje
 activation:
   keywords:
     - "github"
-    - "issues"
     - "pull request"
-    - "repository"
-    - "commit"
-    - "branch"
+    - "github issue"
+    - "github repo"
+    - "pr comment"
+    - "open a pr"
+    - "create a pr"
+    - "my prs"
   exclude_keywords:
     - "gitlab"
     - "bitbucket"
   patterns:
-    - "(?i)(list|show|get|fetch|open|close|create|file|merge)\\s.*(issue|PR|pull request|repo)"
+    - "(?i)(list|show|get|fetch|open|close|create|file|merge|comment on)\\s.*(pull request|\\bPR\\b)"
     - "(?i)github\\.com"
+    - "(?i)[a-z0-9._-]+/[a-z0-9._-]+#\\d+"
   tags:
     - "git"
     - "code-review"