| name | feature-spec |
| description | เปลี่ยน "อยากได้ฟีเจอร์ X" เป็น mini-spec หน้าเดียวก่อนเขียนโค้ด — user story, non-goals ที่จงใจไม่ทำ, ตาราง edge cases, API contract, การเปลี่ยน DB, รายการเทสที่นิยามคำว่าเสร็จ — อ่าน codebase จริงก่อนเพื่อให้ spec เข้ากับ pattern เดิม Trigger on "จะทำฟีเจอร์", "feature spec", "เขียน spec", "แตกฟีเจอร์", or when the user describes a feature they want to build. |
feature-spec — คิดให้จบบนกระดาษหน้าเดียว ถูกกว่าคิดกลางทางในโค้ด
Phase 0 — อ่านของเดิมก่อน
spec ที่ดีต้องเข้ากับบ้านหลังเดิม: ก่อนเขียน ไล่ดู codebase จริง —
- Auth ทำแบบไหน (middleware? session? JWT?) — ฟีเจอร์ใหม่ใช้ท่าเดิม
- Error response หน้าตาแบบไหน — ห้าม invent shape ใหม่
- ฟีเจอร์ใกล้เคียงที่มีอยู่ทำโครงยังไง (โฟลเดอร์, ชั้น service/route, การตั้งชื่อ)
- ตาราง DB ที่เกี่ยวข้องมีอะไรอยู่แล้ว
Phase 1 — Spec 7 หัวข้อ (ทั้งหมดรวมกัน ~1 หน้า)
| # | หัวข้อ | กติกา |
|---|
| 1 | เรื่องเล่า | 2 ประโยค: ใคร ทำอะไร แล้วได้อะไร — ถ้าเขียน 2 ประโยคไม่ได้ แปลว่ายังไม่เข้าใจฟีเจอร์ |
| 2 | Non-goals | สิ่งที่จงใจไม่ทำรอบนี้ — หัวข้อที่สำคัญที่สุดในทั้ง spec เพราะเป็นรั้วกัน scope โต ("ไม่ทำ bulk edit, ไม่ทำ undo, mobile ไว้เฟสหน้า") |
| 3 | Happy path | ลำดับเหตุการณ์ปกติ จบใน 5–8 ขั้น |
| 4 | Edge cases | ตาราง กรณี → พฤติกรรมที่ถูก — ไล่ให้ครบ: ค่าว่าง/empty state, ข้อมูลซ้ำ, ใหญ่เกิน, ไม่มีสิทธิ์, กดซ้ำเร็วๆ (race), offline/timeout กลางทาง |
| 5 | API contract | endpoint, method, req/res shape จริง (JSON ตัวอย่าง), error codes ที่เป็นไปได้ |
| 6 | DB | ตาราง/คอลัมน์ที่เพิ่มหรือแก้ + ต้อง migrate ข้อมูลเก่าไหม |
| 7 | Test list | รายการเทสที่ถ้าผ่านครบ = เสร็จ — นี่คือ Definition of Done ของฟีเจอร์ |
Phase 2 — ถามแทนที่จะเดา
ระหว่างเขียน ถ้าเจอทางแยกที่ตัดสินแทนไม่ได้ (พฤติกรรมเมื่อ X? ใครเห็นข้อมูลนี้ได้บ้าง?) — รวบเป็นคำถามชุดเดียว ไม่เกิน 5 ข้อ พร้อมตัวเลือกและ default ที่แนะนำ ให้ user ตอบรอบเดียวจบ ทางแยกเล็กๆ (ชื่อ, ค่า default ที่สมเหตุผล) ตัดสินเองแล้วระบุใน spec ว่าเลือกอะไรไว้
Phase 3 — ส่งมอบ
- บันทึก
docs/specs/<feature-slug>.md ใน repo (สร้างโฟลเดอร์ถ้ายังไม่มี)
- สรุป 3 บรรทัดในแชท: ทำอะไร ไม่ทำอะไร เสี่ยงตรงไหน
- เสนอเริ่ม implement ตาม spec — ไล่จาก test list ท้าย spec ได้เลย
กติกา
- Spec สั้นพอที่จะมีคนอ่านจริง — เกิน 1 หน้าครึ่งแปลว่าฟีเจอร์ใหญ่ไป เสนอหั่นเป็น 2 ฟีเจอร์ก่อนเขียนต่อ
- ถ้า user เล่าฟีเจอร์ที่มีของเดิมซ้อนอยู่แล้วใน codebase — ทักก่อนเขียน spec ใหม่
