Squashed 'docs/standards/playbook/' changes from b529012..a854534
a854534 ✨ feat(plan_progress): auto-detect env for blocked plans 0d9a8ec 🐛 fix(playbook): honor no_backup for sync 2d401fa ✅ test(templates): update prompts validation e23474e 📝 docs(playbook): update prompts and sync notes 60ff3cd 🐛 fix(playbook): sync templates per file 816f036 ✅ test(playbook): add sync and vendor coverage 625cabb 📝 docs(memory_bank): reformat templates 2554c87 📝 docs(prompts): refresh prompt templates 6774a9d ✨ feat(plan_progress): track plan status in progress.md 73d5c26 🔧 chore(playbook): split sync_templates into sections 278750e ✨ feat(playbook): add plan progress tracking and rules updates 6efd637 🐛 fix(sync): keep agents block blank lines ea00d43 🐛 fix(playbook): support toml without tomllib ab0dd11 📝 docs(playbook): drop docs/plans snapshots 398696c ✨ feat(playbook): merge unified cli d959f80 🎨 style(docs): format markdown b4f712a 🗑️ remove(legacy): drop old scripts and tests 0c4cd0e ✨ feat(actions): add install_skills and format_md 3d1582c ✨ feat(sync): add templates and standards actions 49bbfa1 ✨ feat(vendor): add playbook snapshot generation 8cfcc25 ✨ feat(cli): parse toml config and dispatch actions 05903c3 ✨ feat(cli): add toml config and dispatch order 65d216e ✅ test(cli): add basic playbook cli tests f0bcf54 📝 docs(plans): add unified playbook cli plan 0885309 📝 docs(plans): add unified playbook cli design 3483d8a 🔧 chore(git): ignore .worktrees dir eb75036 🔧 chore(templates): align agent templates and docs efb93f1 📝 docs(playbook): drop todo/confirm mentions 4a85306 🗑️ remove(workflow): drop todo/confirm artifacts 9c5ee9f 🎨 style(markdown): format docs with prettier 5a2925f 🐛 fix(scripts): repair windows script parsing 26a35e0 ✅ test(ci): update required skills list 8df3883 🐛 fix(test): skip external root doc links b067fc1 📦 deps(skills): sync superpowers c03cda0 🔧 chore(ci): sync from origin main 55e05cb 🔧 chore(ci): use superpowers sync script 73c97f3 🔧 chore(ci): centralize superpowers sync 945704f 🔧 chore(ci): add superpowers sync workflow e5d2c93 🗑️ remove(skills): drop duplicate workflows 3ae9708 🐛 fix(ci): update tests for flag-only scripts c44b9aa 🔧 chore(scripts): require flag-driven args e4e1d14 🔧 chore(scripts): unify single-dash options b2eb475 ✅ test(templates): add template coverage fc230b7 🎨 style(markdown): format markdown files 8dc8924 🔧 chore(markdown): add prettier config and usage 2045dd4 ✨ feat(vendor_playbook): add apply-templates option 872d8cf ✨ feat(templates): add sync templates scaffolding 5b1ca45 📝 docs(skills): clarify todo-plan template 054967a ✨ feat(skills): add todo-plan skill cc340f1 🔧 chore(ci): align standards-check workflow template e9de0aa 🔧 chore(ci): drop removed skill check e5dd7d9 🔧 fix(sync): avoid backtick expansion 087b0b9 🔧 chore(sync): align agents block across ps1/bat 9481510 🔧 chore(sync): scope agents block to existing langs b0ca842 🔧 fix(sync): rewrite docs path in agents c98d65c 🔧 chore(sync): rewrite agents docs paths c33611c 🗑️ remove(skills): drop unused skills and update references 2b37860 🎨 style(markdown): format markdown files e3ecd26 📝 docs(tsl): align syntax annotations and examples 37546fe 🐛 fix(playbook): enforce rulesets to agents flow f2df89d 🐛 fix(scripts): include language list in AGENTS.md c0d0737 🐛 fix(playbook): add agents mirror for sync 3b8b99b 🎨 style(markdown): normalize md headings and lists 31f3000 ♻️ refactor(playbook): rename agents template directory to rulesets 11b2bed ✨ feat(markdown): add ruleset and sync support 5b89580 ✅ test(scripts): quiet git init warnings 5822a87 ♻️ refactor(playbook): streamline agents and refresh tsl docs git-subtree-dir: docs/standards/playbook git-subtree-split: a85453439f65b0c0aa05a5bbece773a02216ce76
This commit is contained in:
@@ -0,0 +1,213 @@
|
||||
---
|
||||
name: receiving-code-review
|
||||
description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
|
||||
---
|
||||
|
||||
# Code Review Reception
|
||||
|
||||
## Overview
|
||||
|
||||
Code review requires technical evaluation, not emotional performance.
|
||||
|
||||
**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
|
||||
|
||||
## The Response Pattern
|
||||
|
||||
```
|
||||
WHEN receiving code review feedback:
|
||||
|
||||
1. READ: Complete feedback without reacting
|
||||
2. UNDERSTAND: Restate requirement in own words (or ask)
|
||||
3. VERIFY: Check against codebase reality
|
||||
4. EVALUATE: Technically sound for THIS codebase?
|
||||
5. RESPOND: Technical acknowledgment or reasoned pushback
|
||||
6. IMPLEMENT: One item at a time, test each
|
||||
```
|
||||
|
||||
## Forbidden Responses
|
||||
|
||||
**NEVER:**
|
||||
- "You're absolutely right!" (explicit CLAUDE.md violation)
|
||||
- "Great point!" / "Excellent feedback!" (performative)
|
||||
- "Let me implement that now" (before verification)
|
||||
|
||||
**INSTEAD:**
|
||||
- Restate the technical requirement
|
||||
- Ask clarifying questions
|
||||
- Push back with technical reasoning if wrong
|
||||
- Just start working (actions > words)
|
||||
|
||||
## Handling Unclear Feedback
|
||||
|
||||
```
|
||||
IF any item is unclear:
|
||||
STOP - do not implement anything yet
|
||||
ASK for clarification on unclear items
|
||||
|
||||
WHY: Items may be related. Partial understanding = wrong implementation.
|
||||
```
|
||||
|
||||
**Example:**
|
||||
```
|
||||
your human partner: "Fix 1-6"
|
||||
You understand 1,2,3,6. Unclear on 4,5.
|
||||
|
||||
❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
|
||||
✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
|
||||
```
|
||||
|
||||
## Source-Specific Handling
|
||||
|
||||
### From your human partner
|
||||
- **Trusted** - implement after understanding
|
||||
- **Still ask** if scope unclear
|
||||
- **No performative agreement**
|
||||
- **Skip to action** or technical acknowledgment
|
||||
|
||||
### From External Reviewers
|
||||
```
|
||||
BEFORE implementing:
|
||||
1. Check: Technically correct for THIS codebase?
|
||||
2. Check: Breaks existing functionality?
|
||||
3. Check: Reason for current implementation?
|
||||
4. Check: Works on all platforms/versions?
|
||||
5. Check: Does reviewer understand full context?
|
||||
|
||||
IF suggestion seems wrong:
|
||||
Push back with technical reasoning
|
||||
|
||||
IF can't easily verify:
|
||||
Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
|
||||
|
||||
IF conflicts with your human partner's prior decisions:
|
||||
Stop and discuss with your human partner first
|
||||
```
|
||||
|
||||
**your human partner's rule:** "External feedback - be skeptical, but check carefully"
|
||||
|
||||
## YAGNI Check for "Professional" Features
|
||||
|
||||
```
|
||||
IF reviewer suggests "implementing properly":
|
||||
grep codebase for actual usage
|
||||
|
||||
IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
|
||||
IF used: Then implement properly
|
||||
```
|
||||
|
||||
**your human partner's rule:** "You and reviewer both report to me. If we don't need this feature, don't add it."
|
||||
|
||||
## Implementation Order
|
||||
|
||||
```
|
||||
FOR multi-item feedback:
|
||||
1. Clarify anything unclear FIRST
|
||||
2. Then implement in this order:
|
||||
- Blocking issues (breaks, security)
|
||||
- Simple fixes (typos, imports)
|
||||
- Complex fixes (refactoring, logic)
|
||||
3. Test each fix individually
|
||||
4. Verify no regressions
|
||||
```
|
||||
|
||||
## When To Push Back
|
||||
|
||||
Push back when:
|
||||
- Suggestion breaks existing functionality
|
||||
- Reviewer lacks full context
|
||||
- Violates YAGNI (unused feature)
|
||||
- Technically incorrect for this stack
|
||||
- Legacy/compatibility reasons exist
|
||||
- Conflicts with your human partner's architectural decisions
|
||||
|
||||
**How to push back:**
|
||||
- Use technical reasoning, not defensiveness
|
||||
- Ask specific questions
|
||||
- Reference working tests/code
|
||||
- Involve your human partner if architectural
|
||||
|
||||
**Signal if uncomfortable pushing back out loud:** "Strange things are afoot at the Circle K"
|
||||
|
||||
## Acknowledging Correct Feedback
|
||||
|
||||
When feedback IS correct:
|
||||
```
|
||||
✅ "Fixed. [Brief description of what changed]"
|
||||
✅ "Good catch - [specific issue]. Fixed in [location]."
|
||||
✅ [Just fix it and show in the code]
|
||||
|
||||
❌ "You're absolutely right!"
|
||||
❌ "Great point!"
|
||||
❌ "Thanks for catching that!"
|
||||
❌ "Thanks for [anything]"
|
||||
❌ ANY gratitude expression
|
||||
```
|
||||
|
||||
**Why no thanks:** Actions speak. Just fix it. The code itself shows you heard the feedback.
|
||||
|
||||
**If you catch yourself about to write "Thanks":** DELETE IT. State the fix instead.
|
||||
|
||||
## Gracefully Correcting Your Pushback
|
||||
|
||||
If you pushed back and were wrong:
|
||||
```
|
||||
✅ "You were right - I checked [X] and it does [Y]. Implementing now."
|
||||
✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
|
||||
|
||||
❌ Long apology
|
||||
❌ Defending why you pushed back
|
||||
❌ Over-explaining
|
||||
```
|
||||
|
||||
State the correction factually and move on.
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
| Mistake | Fix |
|
||||
|---------|-----|
|
||||
| Performative agreement | State requirement or just act |
|
||||
| Blind implementation | Verify against codebase first |
|
||||
| Batch without testing | One at a time, test each |
|
||||
| Assuming reviewer is right | Check if breaks things |
|
||||
| Avoiding pushback | Technical correctness > comfort |
|
||||
| Partial implementation | Clarify all items first |
|
||||
| Can't verify, proceed anyway | State limitation, ask for direction |
|
||||
|
||||
## Real Examples
|
||||
|
||||
**Performative Agreement (Bad):**
|
||||
```
|
||||
Reviewer: "Remove legacy code"
|
||||
❌ "You're absolutely right! Let me remove that..."
|
||||
```
|
||||
|
||||
**Technical Verification (Good):**
|
||||
```
|
||||
Reviewer: "Remove legacy code"
|
||||
✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
|
||||
```
|
||||
|
||||
**YAGNI (Good):**
|
||||
```
|
||||
Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
|
||||
✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
|
||||
```
|
||||
|
||||
**Unclear Item (Good):**
|
||||
```
|
||||
your human partner: "Fix items 1-6"
|
||||
You understand 1,2,3,6. Unclear on 4,5.
|
||||
✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
|
||||
```
|
||||
|
||||
## GitHub Thread Replies
|
||||
|
||||
When replying to inline review comments on GitHub, reply in the comment thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment.
|
||||
|
||||
## The Bottom Line
|
||||
|
||||
**External feedback = suggestions to evaluate, not orders to follow.**
|
||||
|
||||
Verify. Question. Then implement.
|
||||
|
||||
No performative agreement. Technical rigor always.
|
||||
Reference in New Issue
Block a user