วงจรหลัก: Brainstorm → Plan → Execute

บทที่แล้ว (SP-0) เราเห็นภาพรวมว่า Superpowers คือชุด skill ที่ทำให้ Claude Code ทำงานเป็นระบบมากขึ้น บทนี้เราจะเจาะ "หัวใจ" ของทั้งระบบ — วงจร 3 เฟสที่ skill เกือบทุกตัวใน repo วนกลับมาพึ่งพา: brainstorming → writing-plans → executing-plans

ทำไมต้องรู้เรื่องนี้ก่อนเรื่องอื่น? เพราะถ้าคุณเข้าใจวงจรนี้แน่น การเรียน skill ตัวอื่น ๆ ใน SP-2 เป็นต้นไป จะง่ายขึ้นมาก — ทุก skill แค่ "เสียบ" เข้าไปในจุดใดจุดหนึ่งของวงจรนี้เท่านั้นเอง

ภาพรวม: วงจร 3 เฟส + checkpoint การอนุมัติ

สิ่งที่ทำให้ Superpowers ต่างจากการสั่ง Claude Code แบบ "เขียนโค้ดให้หน่อย" ตรง ๆ คือ ก่อนโค้ดจะถูกเขียนแม้แต่บรรทัดเดียว ต้องผ่าน 2 checkpoint ที่ ผู้ใช้ (user) เป็นคนอนุมัติ เสมอ ไม่ใช่ agent ตัดสินใจเองทั้งหมด

สังเกตว่ามี "ประตู" (gate) 2 จุดที่ agent ต้องหยุดรอผู้ใช้ ก่อนเดินหน้าต่อ: หลัง present design (เฟส 1 จบ) และหลัง plan เสร็จ (เฟส 2 จบ ก่อนเริ่มเฟส 3) นี่คือกลไกที่ป้องกันไม่ให้ agent "หลงทาง" ไปทำในสิ่งที่คุณไม่ได้ต้องการ

เฟส	รับ Input	ผลผลิต (Output)	ใครอนุมัติ
1. Brainstorming	ไอเดีย/คำขอแบบดิบ ๆ	spec ที่ docs/superpowers/specs/YYYY-MM-DD-*-design.md	user (2 จุด: approve design + review spec file)
2. Writing Plans	spec ที่อนุมัติแล้ว	แผนที่ docs/superpowers/plans/YYYY-MM-DD-*.md	user (เลือกวิธี execute)
3. Executing Plans	แผนที่เขียนไว้	โค้ด + test ที่ผ่านจริง + commit	user (ถ้า agent เจอ blocker จะหยุดถามก่อนเสมอ)

เฟส 1: Brainstorming — คุยก่อนเขียนโค้ด

ต้นทางของ skill นี้เขียนไว้ตรง ๆ ใน frontmatter ว่า "You MUST use this before any creative work — creating features, building components, adding functionality, or modifying behavior." และมี HARD-GATE กำกับชัดเจนว่า:

ห้ามเรียก skill สำหรับ implementation ใด ๆ, ห้ามเขียนโค้ด, ห้าม scaffold โปรเจกต์ จนกว่าจะ present design แล้ว user อนุมัติแล้ว — กฎนี้ใช้กับทุกโปรเจกต์ไม่ว่าจะดูง่ายแค่ไหน

จุดที่มือใหม่มักพลาด: คิดว่างานเล็ก ๆ อย่าง "เพิ่ม endpoint คืนค่า user คนเดียว" ไม่จำเป็นต้องคุยก่อน แต่ต้นทางบอกว่านี่คือ Anti-Pattern ชื่อ "This Is Too Simple To Need A Design" — งานเล็กที่สุดก็ยังต้องมี design (อาจสั้นแค่ 2-3 ประโยค) และต้อง present + ได้รับอนุมัติเสมอ เพราะ "assumption ที่ไม่ได้ตรวจสอบ" คือสาเหตุอันดับ 1 ของงานที่เสียเปล่า

ลำดับขั้นในเฟสนี้ (จาก checklist จริง)

1. สำรวจบริบทโปรเจกต์ก่อน (ไฟล์ เอกสาร commit ล่าสุด)
2. ถามคำถามทีละข้อ (one question at a time) — เน้นแบบ multiple choice ให้ตอบง่าย
3. เสนอ 2-3 แนวทาง (approaches) พร้อม trade-off และคำแนะนำของ agent
4. present design เป็นส่วน ๆ ตามความซับซ้อน แล้วถามความเห็นชอบทีละส่วน
5. เขียน design ลงไฟล์ spec แล้ว commit
6. agent self-review spec เอง (เช็ก placeholder, ความขัดแย้งภายใน, scope, ความกำกวม)
7. ให้ user review ไฟล์ spec อีกรอบก่อนไปต่อ
8. เข้าสู่เฟส 2 โดยเรียก writing-plans skill

จุดสำคัญ: ทีละคำถาม ไม่ใช่ยิงคำถาม 5 ข้อพร้อมกัน และ ปลายทางของเฟสนี้มีทางเดียว — ห้ามข้ามไปเรียก skill implementation อื่นเด็ดขาด ต้องไป writing-plans เท่านั้น

เฟส 2: Writing Plans — แผนที่ jr engineer ไม่มี context ก็ทำตามได้

หลัง spec ผ่านการอนุมัติ เฟสนี้จะแปลง spec ให้เป็นแผนปฏิบัติงานละเอียดสุด ๆ ต้นทางเขียนไว้ตรงไปตรงมาว่า ให้เขียนราวกับว่า "engineer มี zero context เกี่ยวกับ codebase ของเราและ taste ที่น่าสงสัย" — พูดง่าย ๆ คือ ห้ามข้ามรายละเอียดใด ๆ แม้จะดูชัดเจนแค่ไหนก็ตาม

หลักการที่ยึดตลอดแผน: DRY, YAGNI, TDD

• DRY — ไฟล์ที่เปลี่ยนพร้อมกันควรอยู่ด้วยกัน แบ่งตาม responsibility ไม่ใช่ตาม technical layer
• YAGNI — แต่ละ task ต้องผลิต deliverable ที่ testable ได้อิสระ ไม่สร้างสิ่งเกินจำเป็น
• true red/green TDD — ทุก task ต้องมีขั้น "เขียน test ที่ fail" → "รันดูว่า fail จริง" → "เขียน implementation ขั้นต่ำ" → "รันดูว่า pass" → "commit"

แต่ละ task ต้องระบุ ไฟล์ที่จะสร้าง/แก้เป๊ะ ๆ, interface ที่ต้อง consume/produce (ชื่อฟังก์ชัน type พารามิเตอร์แบบเป๊ะ เพราะ task อื่นอาจถูกทำโดย agent คนละตัวที่เห็นแค่ task ของตัวเอง) และห้ามมี placeholder แบบ "TBD", "handle edge cases เอง", "เหมือน Task 3" เด็ดขาด — ต้องมีโค้ดจริงทุกขั้น

ตัวอย่างโครง 1 task จากต้นทาง (ปรับให้เห็นภาพ):

### Task 2: POST /users endpoint

**Files:**
- Create: src/users/users.controller.ts
- Test: src/users/users.controller.spec.ts

- [ ] Step 1: เขียน test ที่ fail

it('creates a user and returns 201', async () => {
  const res = await request(app.getHttpServer())
    .post('/users')
    .send({ email: 'a@b.com' });
  expect(res.status).toBe(201);
});

- [ ] Step 2: รัน test ยืนยันว่า fail (route ยังไม่มี)
- [ ] Step 3: เขียน implementation ขั้นต่ำให้ผ่าน
- [ ] Step 4: รัน test ยืนยันว่า pass
- [ ] Step 5: commit

จบเฟสนี้ agent จะ self-review แผนกับ spec อีกรอบ (เช็ก coverage, placeholder, ความสอดคล้องของ type/ชื่อฟังก์ชัน) แล้วเสนอ 2 ทางเลือกให้ user ตัดสินใจ: Subagent-Driven (dispatch subagent แยกทำทีละ task + review 2 ชั้น) หรือ Inline Execution (รันในเซสชันนี้ต่อเนื่องแบบมี checkpoint) — นี่คือ checkpoint ที่ 2 ของวงจร

เฟส 3: Executing Plans — ทำตามแผน ไม่ใช่ทำตามใจ

เฟสสุดท้ายมีขั้นตอนตรงไปตรงมา: โหลดแผน → review แผนอย่างมีวิจารณญาณ (ถ้ามีข้อกังวลให้ยกขึ้นมาคุยก่อน) → สร้าง todo list จาก task ในแผน → ทำทีละ task ตาม step ที่กำหนดเป๊ะ → รัน verification ตามที่ระบุ → จบแล้วรายงาน

ทำไมต้องมีแผนมาก่อนถึงจะเริ่มเฟสนี้ได้? เพราะถ้าไม่มีแผน agent จะต้องตัดสินใจเรื่อง design ไปพร้อมกับ เขียนโค้ดไปพร้อมกัน — นั่นคือจุดที่ context หลุดง่ายที่สุด และเป็นสาเหตุที่งานออกมาไม่ตรงกับที่ user ต้องการ การแยกเฟส plan ออกจาก execute ทำให้ "การตัดสินใจ" อยู่ในเอกสารที่ review ได้ ไม่ได้ฝังอยู่ในหัวของ agent ระหว่างพิมพ์โค้ด

ตัวอย่างผูกจริง: เพิ่ม endpoint ใน NestJS ผ่านวงจรนี้

สมมติคุณอยากได้ endpoint GET /orders/:id/status คืนสถานะออเดอร์ มาดูว่าแต่ละเฟส คุณพิมพ์อะไร/อนุมัติอะไร:

1. คุณพิมพ์: "ช่วยเพิ่ม endpoint เช็กสถานะออเดอร์หน่อย" — agent (brainstorming เริ่มทำงาน): ถามทีละคำถาม เช่น "สถานะที่ต้องมีมีกี่แบบ? (A) pending/paid/shipped/cancelled (B) เพิ่ม refunded ด้วย" → คุณเลือก → agent เสนอ 2-3 แนวทาง เช่น query จาก orders table ตรง ๆ vs เก็บ status log แยกตาราง → present design → คุณอนุมัติ → agent เขียน spec ที่ docs/superpowers/specs/2026-07-11-order-status-design.md แล้วให้คุณ review อีกรอบ
2. คุณอนุมัติ spec แล้ว agent เรียก writing-plans เอง สร้างแผนที่ docs/superpowers/plans/2026-07-11-order-status.md — task แรกอาจเป็น "เขียน unit test ของ OrdersService.getStatus()" task ถัดไปเป็น "เพิ่ม route ใน OrdersController" ทุก task มีโค้ด test จริงให้ก่อน implementation
3. agent ถามคุณ: "จะให้ execute แบบ subagent แยกทีละ task หรือรันในเซสชันนี้ต่อเลย?" — คุณเลือก inline execution → agent ทำ task ที่ 1 (test แดง → เขียน service → test เขียว → commit) → แสดงผลให้ดู → ทำ task ถัดไป จนครบ แล้วรายงานสรุป