Commit 33fc0e2329d1

@@ -0,0 +1,55 @@
+---
+name: review-pr-critically
+description: >-
+  Review a GitHub PR with critical analysis, separating real issues from imaginary ones.
+  USE WHEN user says 'review PR critically', 'critical PR review', 'review this PR',
+  or wants thorough analysis that distinguishes actual bugs from theoretical concerns.
+argument-hint: "<PR-URL>"
+---
+
+# review-pr-critically
+
+You are reviewing a GitHub pull request with thorough critical analysis.
+
+## Process
+
+1. **Fetch PR data using the GitHub CLI (`gh`)**
+   - Use `gh pr view <URL> --json title,body,baseRefName,headRefName,files,reviews,comments` to get PR metadata
+   - Use `gh pr diff <URL>` to get the full diff
+   - Read the diff and changed files carefully before proceeding
+
+2. **Perform a thorough code review**
+   - Review for correctness, security, performance, and maintainability
+   - Note all potential issues you find
+
+3. **Critically self-review your findings**
+   - Question every finding — is it actually a problem or just theoretical?
+   - Separate concerns into two categories:
+     - **Real Issues**: Actual bugs, security problems, incorrect logic, violations of requirements
+     - **Imaginary Issues**: Theoretical concerns, premature optimizations, style preferences that don't matter, worries about edge cases that can't happen
+
+4. **Test your reasoning**
+   - For each "issue", ask: "What would actually break if we shipped this?"
+   - If the answer is "nothing" or "maybe something in theory", it's likely imaginary
+   - Check if the code actually works correctly for the real use cases
+   - Verify concerns against actual code behavior, not assumptions
+
+5. **Present final verdict**
+   - List real issues that need fixing (if any)
+   - Acknowledge imaginary concerns you initially had but ruled out
+   - Give clear recommendation: approve, request changes, or needs discussion
+
+## Key Principles
+
+- **Evidence over assumptions**: Check actual code behavior
+- **Real-world over theoretical**: Focus on actual use cases
+- **Trust the implementation**: If tests pass and logic is sound, it's probably fine
+- **Question yourself**: Your first concerns are often wrong
+
+## Example
+
+After review, you might find:
+
+- Initial concern: "Cache might be stale across jobs"
+- Critical analysis: Actually, GitHub Actions cache behavior makes this expected and harmless
+- Verdict: Imaginary issue, implementation is correct

@@ -0,0 +1,1 @@
+../../../agents/skills/review-pr-critically
\ No newline at end of file

@@ -16,6 +16,7 @@ rule.define = $(eval $(call rule.template,$(1),$(2)))
 $(call rule.define,~/.config,$(dotfiles)/config)
 $(call rule.define,~/.pi,$(dotfiles)/pi)
 $(call rule.define,~/bin,$(dotfiles)/bin)
+$(call rule.define,~/.agents,$(dotfiles)/agents)
 
 ##@ Desktop
 
@@ -93,8 +94,9 @@ emacs-skills : claude-skills
 
 ##@ AI Shared Config
 
-all += agent-skills agent-skill-manager-bin ai-config
+all += agent-skills agent-skill-manager-bin ai-config shared-agent-skills
 agent-skills : ~/.config/agent-skills
+shared-agent-skills : ~/.agents/skills/review-pr-critically
 ai-config : ~/.config/ai/skills ~/.config/ai/path-policies.json
 
 # Skills shared with claude via cross-link