feat(agents): absorb Karpathy LLM coding guidelines into AGENTS.md and skills

Absorb behavioral patterns from andrej-karpathy-skills project to reduce
common agent coding mistakes, without changing core workflow.

AGENTS.md:
- Add 'Behavioral Guidelines' section with 4 principles:
  - Think Before Coding: surface assumptions, ask before assuming
  - Simplicity First: anti-overengineering, YAGNI for abstractions
  - Surgical Changes: no drive-by refactoring, match existing style
  - Goal-Driven Execution: vague-to-verifiable task transformation

skills/pb-build/SKILL.md:
- Add anti-pattern quick reference table (6 patterns) for Evaluator

skills/pb-test-driven-development/SKILL.md:
- Add 'Bug Fix: Reproduce First' example (RED exposes bug, GREEN fixes)

skills/pb-systematic-debugging/SKILL.md:
- Add concrete Phase 1 example: wrong (symptom patch) vs right (root cause)

Author: Akagi201

AGENTS.md

@@ -194,6 +194,70 @@ cachetools >= 7.0.5
 - Mixing unrelated changes: keep one logical change per commit.
 - Using `# type: ignore` without a specific error code and justification comment.
 
+## Behavioral Guidelines
+
+Adapted from [Karpathy's LLM coding observations](https://x.com/karpathy/status/2015883857489522876). These reduce common agent coding mistakes.
+
+### Think Before Coding
+
+Don't assume. Don't hide confusion. Surface tradeoffs.
+
+- State assumptions explicitly. If uncertain, ask.
+- If multiple interpretations exist, present them — don't pick silently.
+- If a simpler approach exists, say so. Push back when warranted.
+- If something is unclear, stop. Name what's confusing. Ask.
+
+**Self-check:** "Did I list my assumptions before coding?"
+
+### Simplicity First
+
+Minimum code that solves the problem. Nothing speculative.
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for impossible scenarios.
+- If you write 200 lines and it could be 50, rewrite it.
+
+**Self-check:** "Would a senior engineer say this is overcomplicated?"
+
+### Surgical Changes
+
+Touch only what you must. Clean up only your own mess.
+
+When editing existing code:
+
+- Don't "improve" adjacent code, comments, or formatting.
+- Don't refactor things that aren't broken.
+- Match existing style, even if you'd do it differently.
+- If you notice unrelated dead code, mention it — don't delete it.
+
+When your changes create orphans:
+
+- Remove imports/variables/functions that YOUR changes made unused.
+- Don't remove pre-existing dead code unless asked.
+
+**Self-check:** "Does every changed line trace to the user's request?"
+
+### Goal-Driven Execution
+
+Define success criteria. Loop until verified.
+
+Transform tasks into verifiable goals:
+
+- "Add validation" → "Write tests for invalid inputs, then make them pass"
+- "Fix the bug" → "Write a test that reproduces it, then make it pass"
+- "Refactor X" → "Ensure tests pass before and after"
+
+For multi-step tasks, state a brief plan:
+```
+1. [Step] → verify: [check]
+2. [Step] → verify: [check]
+3. [Step] → verify: [check]
+```
+
+**Self-check:** "Can I verify this change succeeded without asking the user?"
+
 ## Development Workflow
 
 When fixing failures, identify root cause first, then apply idiomatic fixes instead of suppressing warnings or patching symptoms.

skills/pb-build/SKILL.md

@@ -551,6 +551,21 @@ Use `- [ ]` and `- [x]` inside the task block as evidence checkboxes, not as a s
 
 ---
 
+## Anti-Pattern Quick Reference
+
+The Evaluator should watch for these common agent mistakes:
+
+| Anti-Pattern | Example | Correct Behavior |
+|---|---|---|
+| **Drive-by refactoring** | Fixing a bug but also reformatting adjacent code, adding type hints nobody asked for | Only change lines that fix the reported issue |
+| **Over-abstraction** | Strategy pattern + ABC + config class for a single `calculate_discount()` function | One function until complexity is actually needed |
+| **Silent assumptions** | Implementing "export users" without clarifying scope, format, fields | List assumptions, ask for clarification |
+| **Speculative features** | Adding caching, validation, notifications to a "save preferences" request | Build only what was asked; add later when needed |
+| **Vague success criteria** | "I'll review and improve the code" | "Write test for bug X → make it pass → verify no regressions" |
+| **Style drift** | Changing quote style, whitespace, or return logic while adding logging | Match existing code style exactly |
+
+---
+
 ## Key Principles
 
 1. **Small, focused, sequential, independent.** Each task is self-contained.

skills/pb-systematic-debugging/SKILL.md

@@ -130,6 +130,21 @@ You MUST complete each phase before proceeding to the next.
    - Keep tracing up until you find the source
    - Fix at source, not at symptom
 
+**Example — Wrong vs Right:**
+
+```
+User reports: "Empty emails crash the validator"
+
+Wrong: Immediately patches validate_user() to handle empty strings.
+  → May fix symptom, may not fix root cause.
+
+Right:
+  1. Reproduce: call validate_user({'email': ''}) → confirms crash
+  2. Trace: empty string → splits on '@' → IndexError
+  3. Root cause: no guard before string operation
+  4. Minimal fix: add empty check before split
+```
+
 ### Phase 2: Pattern Analysis
 
 **Find the pattern before fixing:**

skills/pb-test-driven-development/SKILL.md

@@ -102,6 +102,37 @@ Vague name, tests mock not code.
 - Clear name
 - Real code (no mocks unless unavoidable)
 
+### Bug Fix: Reproduce First
+
+For bugs, the RED phase doubles as a reproducer. Don't fix without confirming the bug exists.
+
+**User reports:** "Sorting breaks when there are duplicate scores"
+
+**Wrong:** Immediately changes sort logic.
+
+**Right:**
+```python
+# 1. RED: Write test that exposes the bug
+def test_sort_with_duplicate_scores():
+    scores = [
+        {'name': 'Alice', 'score': 100},
+        {'name': 'Bob', 'score': 100},
+        {'name': 'Charlie', 'score': 90},
+    ]
+    result = sort_scores(scores)
+    assert result[0]['score'] == 100
+    assert result[1]['score'] == 100
+    assert result[2]['score'] == 90
+
+# Verify RED: run 10 times → inconsistent ordering → bug confirmed
+
+# 2. GREEN: Fix with stable sort
+def sort_scores(scores):
+    return sorted(scores, key=lambda x: (-x['score'], x['name']))
+
+# Verify GREEN: test passes consistently
+```
+
 ### Verify RED - Watch It Fail
 
 **MANDATORY. Never skip.**