feature-spec

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 ใหม่