วงจร Code Review: ขอรีวิว → รับ feedback → ปิด branch

จนถึงตอนนี้เรารู้จัก core loop, skills พื้นฐาน, TDD/debugging และ multi-agent กันไปแล้ว บทนี้จะปิดวงจรการทำงานของ agent ด้วยขั้นตอนที่ dev มืออาชีพทำเป็นประจำแต่ agent ส่วนใหญ่ "ลืม" หรือทำแบบขอไปที คือการ code review และการปิด branch เมื่องานเสร็จ ทั้งสามเรื่องนี้มาจาก skill จริงใน Superpowers: requesting-code-review, receiving-code-review และ finishing-a-development-branch

ทำไมต้องสนใจเรื่องนี้ตอนทำงานกับ agent ทุกวัน? เพราะถ้าไม่มีวินัยตรงนี้ จะเจอสองปัญหาบ่อยมาก: agent เขียนโค้ดเสร็จแล้ว merge เข้า main ทันทีโดยไม่มีใครตรวจ (bug หลุด production) หรือ agent รับ feedback มาแล้ว "ทำตามหมด" แบบไม่คิด จนพังของที่เคยทำงานได้อยู่แล้ว บทนี้จะสอนวิธีป้องกันทั้งสองแบบ

ทำไม Code Review ต้องมี "วินัย" ไม่ใช่แค่ "มี"

หลายทีมมี code review อยู่แล้วในรูปแบบ PR approve ใน GitHub แต่สิ่งที่ Superpowers เพิ่มเข้ามาคือ วินัยสามด้าน ที่ต้องทำให้ครบวงจร:

ด้าน	คำถามที่ต้องตอบ	Skill ที่เกี่ยวข้อง
ขอรีวิว	ขอเมื่อไร ขอยังไงให้ reviewer เห็นบริบทพอดี ไม่มากไม่น้อย	requesting-code-review
รับ feedback	เชื่อ feedback แค่ไหน ตรวจสอบก่อนทำตามหรือเปล่า	receiving-code-review
ปิดงาน	เทสผ่านหรือยัง จะ merge/PR/เก็บไว้/ทิ้ง แบบไหน	finishing-a-development-branch

1. Requesting Code Review — ขอรีวิวให้ถูกจังหวะ

หลักการจาก skills/requesting-code-review/SKILL.md: ให้ dispatch subagent เป็น code reviewer ที่ได้รับ "บริบทที่จัดมาให้เฉพาะ" — ไม่ใช่ history ทั้ง session ของเรา เหตุผลคือ reviewer ต้องโฟกัสที่ "ผลงาน" ไม่ใช่ "กระบวนการคิด" ของเรา และยังช่วยประหยัด context ของ session หลักไว้ทำงานต่อ หลักคิดสั้นๆ ของ skill นี้คือ:

Core principle: Review early, review often.

เมื่อไรควรขอรีวิว

บังคับ (Mandatory)	ควรทำ (Optional แต่มีค่า)
หลังจบแต่ละ task ใน subagent-driven development	ตอนติดปัญหา (อยากได้มุมมองใหม่)
หลังทำ feature ใหญ่เสร็จ	ก่อน refactor (เช็ก baseline ก่อนแก้)
ก่อน merge เข้า main	หลังแก้ bug ที่ซับซ้อน

ขอรีวิวอย่างไร

ขั้นตอนตาม skill มี 3 ก้าว:

1. เอา git SHA ของจุดเริ่มต้นกับจุดจบมาก่อน (BASE_SHA, HEAD_SHA)
2. dispatch subagent แบบ general-purpose พร้อม template code-reviewer.md กรอก placeholder 4 ตัว: {DESCRIPTION}, {PLAN_OR_REQUIREMENTS}, {BASE_SHA}, {HEAD_SHA}
3. ลงมือทำตาม feedback: แก้ Critical ทันที, แก้ Important ก่อนไปต่อ, จด Minor ไว้ทีหลัง, และ push back ได้ถ้า reviewer ผิด (พร้อมเหตุผลทางเทคนิค)

# ตัวอย่างจาก SKILL.md — เตรียม SHA ก่อนขอรีวิว
BASE_SHA=$(git rev-parse HEAD~1)  # หรือ origin/main
HEAD_SHA=$(git rev-parse HEAD)

# dispatch subagent พร้อม context ที่จัดมาให้ ไม่ใช่ history ทั้งหมด
DESCRIPTION: "Added verifyIndex() and repairIndex() with 4 issue types"
PLAN_OR_REQUIREMENTS: "Task 2 from docs/superpowers/plans/deployment-plan.md"
BASE_SHA: a7981ec
HEAD_SHA: 3df7661

2. Receiving Code Review — รับ Feedback แบบมีเหตุผล ไม่ใช่ทำตามหมด

นี่คือส่วนที่หลายคน (และหลาย agent) พลาดบ่อยที่สุด skills/receiving-code-review/SKILL.md บอกไว้ชัดว่า:

Code review requires technical evaluation, not emotional performance.

พูดง่ายๆ คือ feedback ที่ได้รับมา ไม่ใช่คำสั่งที่ต้องทำตามทันที แต่เป็น "ข้อเสนอที่ต้องประเมิน" ก่อนลงมือ core principle ของ skill นี้คือ: Verify before implementing. Ask before assuming. Technical correctness over social comfort.

Response Pattern 6 ขั้น

ทุกครั้งที่ได้ feedback ต้องเดินตามลำดับนี้ ห้ามข้ามขั้น:

1. READ — อ่านให้ครบก่อน อย่าเพิ่งมีปฏิกิริยา
2. UNDERSTAND — พูดทวนความต้องการด้วยคำพูดตัวเอง (หรือถามถ้าไม่ชัด)
3. VERIFY — ตรวจสอบกับโค้ดจริงในโปรเจกต์
4. EVALUATE — เข้าท่ากับโค้ดเบสนี้จริงไหม
5. RESPOND — ตอบแบบเทคนิค หรือ push back อย่างมีเหตุผล
6. IMPLEMENT — ทำทีละข้อ เทสทุกข้อที่แก้

คำตอบต้องห้าม vs คำตอบที่ควรใช้

ห้ามพูด (Performative)	ควรพูด/ทำแทน
"You're absolutely right!"	พูดทวนความต้องการทางเทคนิค
"Great point! / Excellent feedback!"	ถามคำถามที่เจาะจง
"Let me implement that now" (ก่อนตรวจสอบ)	ตรวจสอบก่อน แล้วค่อยลงมือ (action มากกว่าคำพูด)
"Thanks for catching that!"	"Fixed. [อธิบายสั้นว่าแก้อะไร]"

ถ้า Feedback ไม่ชัด — หยุดก่อน อย่าทำบางส่วน

SKILL.md ยกตัวอย่างนี้ไว้ชัดมาก: partner บอกว่า "Fix 1-6" แต่เราเข้าใจแค่ข้อ 1,2,3,6 ส่วนข้อ 4,5 ไม่ชัด

❌ ผิด	✅ ถูก
ทำข้อ 1,2,3,6 ไปก่อน แล้วค่อยถามข้อ 4,5 ทีหลัง	"I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."

เหตุผล: บางข้ออาจเกี่ยวโยงกัน เข้าใจแค่บางส่วนอาจนำไปสู่การ implement ที่ผิดทั้งชุด

Feedback จากใคร ก็ต้องตรวจต่างระดับกัน

แหล่งที่มา	วิธีจัดการ
จาก human partner (เจ้าของงานตัวจริง)	เชื่อได้ แต่ยัง "ถาม" ถ้า scope ไม่ชัด ห้าม agree แบบเสแสร้ง ลงมือทำเลยหลังเข้าใจ
จาก external reviewer (เช่น agent อื่น, GitHub bot)	ต้องเช็ก 5 อย่างก่อนทำตาม: ถูกต้องกับโค้ดเบสนี้จริงไหม, ทำให้ของเดิมพังไหม, มีเหตุผลของ implementation เดิมหรือเปล่า, ใช้ได้ทุก platform/version ไหม, reviewer เข้าใจบริบททั้งหมดจริงหรือเปล่า

ถ้าตรวจสอบไม่ได้เลย ให้พูดตรงๆ ว่า "I can't verify this without [X]. Should I [investigate/ask/proceed]?" และถ้า feedback ขัดกับการตัดสินใจเชิงสถาปัตยกรรมที่ partner เคยตกลงไว้แล้ว ต้องหยุดคุยกับ partner ก่อนเสมอ

เช็ก YAGNI ก่อนทำตาม feedback "ทำให้โปร"

ถ้า reviewer แนะนำให้ "implement อย่างเป็นระบบ" (เช่น เพิ่ม metrics tracking เต็มรูปแบบ) ให้ grep โค้ดเบสก่อนว่ามีคนเรียกใช้ endpoint/ฟังก์ชันนั้นจริงไหม ถ้าไม่มีใครเรียกใช้ — เสนอให้ลบทิ้งแทน (YAGNI) ไม่ใช่เพิ่ม feature ที่ไม่มีใครต้องการ

3. Finishing a Development Branch — ปิดงานให้ถูกวิธี

skills/finishing-a-development-branch/SKILL.md กำหนด core principle ไว้ชัดเจน:

Verify tests → Detect environment → Present options → Execute choice → Clean up.

ข้อสำคัญที่สุดคือ ห้ามเสนอตัวเลือกปิดงานถ้าเทสยังไม่ผ่าน ต้องรันเทสก่อนเสมอ ถ้าพังต้องแจ้งจำนวน failure แล้วหยุด ไม่ไปต่อขั้นถัดไป

4 ตัวเลือกมาตรฐานเมื่องานเสร็จ (repo ปกติ)

ตัวเลือก	Merge	Push	เก็บ Worktree	ลบ Branch
1. Merge กลับ local	✅	-	-	✅
2. Push + สร้าง Pull Request	-	✅	✅	-
3. เก็บ branch ไว้ก่อน	-	-	✅	-
4. ทิ้งงาน (Discard)	-	-	-	✅ (force)

จุดที่พลาดบ่อยตาม SKILL.md: ลบ worktree ของตัวเลือก 2 ทั้งที่ user ยังต้องใช้แก้ตาม PR feedback, หรือลบ branch ก่อนเอา worktree ออก (จะ error เพราะ worktree ยังอ้างอิง branch นั้นอยู่) ลำดับที่ถูกคือ merge สำเร็จก่อน → ลบ worktree → แล้วค่อยลบ branch

สำหรับตัวเลือกที่ 4 (Discard) ต้องขอ confirmation แบบพิมพ์คำว่า discard ก่อนเสมอ ห้ามลบงานทิ้งแบบไม่มีการยืนยัน

ตัวอย่างผูกงานจริง: รอบรีวิว PR ฟีเจอร์ NestJS

สมมติเราให้ agent เพิ่ม endpoint POST /orders/:id/refund ใน NestJS service (มี PostgreSQL เป็น backing store) มาดูว่าวงจรทั้งสาม skill ทำงานร่วมกันยังไง:

// 1. งานเสร็จ agent เรียก requesting-code-review
BASE_SHA: 8a12f3e   // จุดก่อนเริ่ม refund feature
HEAD_SHA: c05e91a   // commit ล่าสุดหลังเขียนเสร็จ
DESCRIPTION: "POST /orders/:id/refund + RefundService + unit tests"
PLAN_OR_REQUIREMENTS: "ticket ORD-142: allow partial refund, must log to audit table"

// 2. reviewer subagent ตอบกลับ
Strengths: DTO validation ครบ, transaction wrap ถูกต้อง
Issues:
  Critical: ไม่ได้ log ลง audit table ตามที่ ticket ระบุ
  Important: refund amount ไม่ตรวจว่ามากกว่ายอดคงเหลือหรือไม่
  Minor: import order ไม่เรียงตาม eslint config

// 3. agent รับ feedback ตาม receiving-code-review
// - Critical: ตรวจโค้ดจริง พบว่าลืมเรียก auditLogService.log() จริง → แก้
// - Important: ตรวจสอบแล้วถูกต้องจริง → เพิ่ม guard clause + เทส
// - Minor: รันเทสแล้วค่อยไล่แก้ import order

หลังแก้ครบ agent รันเทสอีกครั้ง (npm test) ผ่านหมด แล้วเข้าสู่ finishing-a-development-branch เสนอ 4 ตัวเลือกให้ dev ตัดสินใจ — ในเคสนี้ dev เลือก "Push and create PR" เพราะอยากให้ทีมช่วยดูอีกรอบก่อน merge จริง เท่ากับ agent ไม่ merge เองแบบสุ่มสี่สุ่มห้า และ dev ยังมี worktree ไว้แก้ตาม PR feedback รอบถัดไปได้

กรณี Go microservice ก็เหมือนกันทุกขั้นตอน แค่เปลี่ยนคำสั่งเทสเป็น go test ./... และเปลี่ยน SHA เป็น commit ของ Go repo แต่ตรรกะการขอรีวิว-รับ feedback-ปิดงานเหมือนเดิมทุกจุด