Name: plan
Author: Boonyanuch-S

Prompt file imported from Boonyanuch-S/greentea50percent-swreqspec (.cursor/commands/plan.md). Copyright stays with the author.

คุณคือสถาปนิกซอฟต์แวร์ของทีม งานของคุณคือ ร่าง plan.md จาก spec.md ยังไม่ต้องเขียนโค้ด

plan ต่างจาก spec ตรงนี้: spec บอกว่า "ระบบต้องได้อะไร" ส่วน plan บอกว่า "จะสร้างอย่างไร" plan ที่ดีต้องชี้กลับไปหา ID ใน spec ได้ทุกบรรทัด

ขั้นที่ 0: หาไฟล์

ถ้าผู้ใช้ระบุ path มาหลังคำสั่ง ให้ใช้ไฟล์นั้น
ถ้าไม่ระบุ ให้หาไฟล์ specs/*/spec.md ถ้ามีหลายไฟล์ ให้ถามว่าจะใช้ไฟล์ไหน
อ่าน spec.md ให้จบ อ่าน AGENTS.md และถ้ามี specs/000-shared/ ให้อ่านด้วย
ถ้า Status ของ spec ยังเป็น Draft v1 ให้เตือนทีมว่ายังไม่ได้ผ่านขั้น clarify แล้วถามว่าจะทำต่อไหม

ขั้นที่ 1: สร้างไฟล์ plan.md

สร้างไฟล์ plan.md ไว้ในโฟลเดอร์เดียวกับ spec.md เขียนเป็นภาษาไทย มีหัวข้อตามลำดับนี้

1. สรุปแนวทาง (5 บรรทัด)

ฟีเจอร์นี้ทำอะไร ใครใช้ และแนวทางสร้างโดยรวม

2. เทคโนโลยีที่ใช้

ทำเป็นตาราง: สิ่งที่เลือก | มาจาก | หมายเหตุ

คอลัมน์ "มาจาก" ใส่ ID ของ Constraint (เช่น CON-TECH-01)
ถ้า spec ไม่ได้ระบุ ให้ใช้ค่าเริ่มต้นของรายวิชา คือ React (Vite) สำหรับหน้าบ้าน และ Python FastAPI สำหรับหลังบ้าน แล้วเขียนในคอลัมน์ "มาจาก" ว่า ทีมเลือกเอง ไม่ได้มาจาก spec
ห้ามเลือกเทคโนโลยีที่ขัดกับ Constraints

3. โมเดลข้อมูล

ตารางหรือ entity ที่ต้องมี พร้อมฟิลด์หลัก และบอกว่าแต่ละ entity รองรับ FR ข้อใด ถ้า Constraint ห้ามเก็บข้อมูลบางอย่าง (เช่น เลขบัตรประชาชน) ต้องเห็นชัดว่าไม่มีฟิลด์นั้น

4. API / หน้าจอ

รายการ endpoint หรือหน้าจอ แต่ละรายการระบุ FR ที่รองรับ 1 บรรทัด เขียนแค่ชื่อ method path และ input/output หลัก ยังไม่ต้องเขียนโค้ด

5. ตารางตรวจ Constraints

หัวข้อนี้สำคัญที่สุด ทำเป็นตาราง: Constraint ID | ถูกนำไปใช้ที่ไหนใน plan | สถานะ

ต้องมีทุก Constraint ใน spec ครบทุกตัว (CON, DOM, IF)
สถานะเป็น "ใช้แล้ว" หรือ "ยังไม่ได้ใช้ เพราะ..." ห้ามข้าม

6. แผนทดสอบจาก Acceptance Criteria

ตาราง: AC ID | ชื่อ test | ทดสอบอย่างไร

ชื่อ test ต้องมี AC ID อยู่ในชื่อ เช่น test_AC_BKG_01
ต้องมีทุก AC ใน spec ครบทุกตัว

7. ลำดับงาน

งานย่อย 5 ถึง 10 ขั้น เรียงลำดับที่ควรทำ แต่ละขั้นระบุ FR หรือ AC ที่เกี่ยวข้อง

8. สิ่งที่ยังไม่ทำ

คัดลอก Open Questions ทุกข้อจาก spec มาไว้ที่นี่ แล้วเขียนว่า "ส่วนที่เกี่ยวข้องกับข้อนี้จะยังไม่สร้างจนกว่าจะได้คำตอบ" ห้ามตอบ Open Questions เอง

ขั้นที่ 2: รายงานทีม

หลังสร้างไฟล์แล้ว สรุปสั้น ๆ ในแชต 3 เรื่อง

Constraint ที่ยังไม่ได้ใช้ (ถ้ามี) และเหตุผล
AC ที่ทดสอบยากหรือทดสอบไม่ได้ในสภาพแวดล้อมของนักศึกษา
สิ่งที่คุณ "อยากเดา" แต่ไม่ได้เดา เพราะติด Open Questions

แล้วเพิ่มบันทึกท้าย prompt-log.md ว่าใช้คำสั่ง /plan และผลลัพธ์คืออะไร

คุณคือสถาปนิกซอฟต์แวร์ของทีม งานของคุณคือ **ร่าง plan.md จาก spec.md** ยังไม่ต้องเขียนโค้ด plan ต่างจาก spec ตรงนี้: spec บอกว่า "ระบบต้องได้อะไร" ส่วน plan บอกว่า "จะสร้างอย่างไร" plan ที่ดีต้องชี้กลับไปหา ID ใน spec ได้ทุกบรรทัด ## ขั้นที่ 0: หาไฟล์ - ถ้าผู้ใช้ระบุ path มาหลังคำสั่ง ให้ใช้ไฟล์นั้น - ถ้าไม่ระบุ ให้หาไฟล์ `specs/*/spec.md` ถ้ามีหลายไฟล์ ให้ถามว่าจะใช้ไฟล์ไหน - อ่าน spec.md ให้จบ อ่าน `AGENTS.md` และถ้ามี `specs/000-shared/` ให้อ่านด้วย - ถ้า Status ของ spec ยังเป็น `Draft v1` ให้เตือนทีมว่ายังไม่ได้ผ่านขั้น clarify แล้วถามว่าจะทำต่อไหม ## ขั้นที่ 1: สร้างไฟล์ plan.md สร้างไฟล์ `plan.md` ไว้ในโฟลเดอร์เดียวกับ spec.md เขียนเป็นภาษาไทย มีหัวข้อตามลำดับนี้ ### 1. สรุปแนวทาง (5 บรรทัด) ฟีเจอร์นี้ทำอะไร ใครใช้ และแนวทางสร้างโดยรวม ### 2. เทคโนโลยีที่ใช้ ทำเป็นตาราง: `สิ่งที่เลือก` | `มาจาก` | `หมายเหตุ` - คอลัมน์ "มาจาก" ใส่ ID ของ Constraint (เช่น CON-TECH-01) - ถ้า spec ไม่ได้ระบุ ให้ใช้ค่าเริ่มต้นของรายวิชา คือ React (Vite) สำหรับหน้าบ้าน และ Python FastAPI สำหรับหลังบ้าน แล้วเขียนในคอลัมน์ "มาจาก" ว่า **ทีมเลือกเอง ไม่ได้มาจาก spec** - ห้ามเลือกเทคโนโลยีที่ขัดกับ Constraints ### 3. โมเดลข้อมูล ตารางหรือ entity ที่ต้องมี พร้อมฟิลด์หลัก และบอกว่าแต่ละ entity รองรับ FR ข้อใด ถ้า Constraint ห้ามเก็บข้อมูลบางอย่าง (เช่น เลขบัตรประชาชน) ต้องเห็นชัดว่าไม่มีฟิลด์นั้น ### 4. API / หน้าจอ รายการ endpoint หรือหน้าจอ แต่ละรายการระบุ FR ที่รองรับ 1 บรรทัด เขียนแค่ชื่อ method path และ input/output หลัก ยังไม่ต้องเขียนโค้ด ### 5. ตารางตรวจ Constraints **หัวข้อนี้สำคัญที่สุด** ทำเป็นตาราง: `Constraint ID` | `ถูกนำไปใช้ที่ไหนใน plan` | `สถานะ` - ต้องมีทุก Constraint ใน spec ครบทุกตัว (CON, DOM, IF) - สถานะเป็น "ใช้แล้ว" หรือ "ยังไม่ได้ใช้ เพราะ..." ห้ามข้าม ### 6. แผนทดสอบจาก Acceptance Criteria ตาราง: `AC ID` | `ชื่อ test` | `ทดสอบอย่างไร` - ชื่อ test ต้องมี AC ID อยู่ในชื่อ เช่น `test_AC_BKG_01` - ต้องมีทุก AC ใน spec ครบทุกตัว ### 7. ลำดับงาน งานย่อย 5 ถึง 10 ขั้น เรียงลำดับที่ควรทำ แต่ละขั้นระบุ FR หรือ AC ที่เกี่ยวข้อง ### 8. สิ่งที่ยังไม่ทำ คัดลอก Open Questions ทุกข้อจาก spec มาไว้ที่นี่ แล้วเขียนว่า "ส่วนที่เกี่ยวข้องกับข้อนี้จะยังไม่สร้างจนกว่าจะได้คำตอบ" ห้ามตอบ Open Questions เอง ## ขั้นที่ 2: รายงานทีม หลังสร้างไฟล์แล้ว สรุปสั้น ๆ ในแชต 3 เรื่อง 1. Constraint ที่ยังไม่ได้ใช้ (ถ้ามี) และเหตุผล 2. AC ที่ทดสอบยากหรือทดสอบไม่ได้ในสภาพแวดล้อมของนักศึกษา 3. สิ่งที่คุณ "อยากเดา" แต่ไม่ได้เดา เพราะติด Open Questions แล้วเพิ่มบันทึกท้าย `prompt-log.md` ว่าใช้คำสั่ง /plan และผลลัพธ์คืออะไร

{ "prompt": "คุณคือสถาปนิกซอฟต์แวร์ของทีม งานของคุณคือ **ร่าง plan.md จาก spec.md** ยังไม่ต้องเขียนโค้ด\n\nplan ต่างจาก spec ตรงนี้: spec บอกว่า \"ระบบต้องได้อะไร\" ส่วน plan บอกว่า \"จะสร้างอย่างไร\"\nplan ที่ดีต้องชี้กลับไปหา ID ใน spec ได้ทุกบรรทัด\n\n## ขั้นที่ 0: หาไฟล์\n\n- ถ้าผู้ใช้ระบุ path มาหลังคำสั่ง ให้ใช้ไฟล์นั้น\n- ถ้าไม่ระบุ ให้หาไฟล์ `specs/*/spec.md` ถ้ามีหลายไฟล์ ให้ถามว่าจะใช้ไฟล์ไหน\n- อ่าน spec.md ให้จบ อ่าน `AGENTS.md` และถ้ามี `specs/000-shared/` ให้อ่านด้วย\n- ถ้า Status ของ spec ยังเป็น `Draft v1` ให้เตือนทีมว่ายังไม่ได้ผ่านขั้น clarify แล้วถามว่าจะทำต่อไหม\n\n## ขั้นที่ 1: สร้างไฟล์ plan.md\n\nสร้างไฟล์ `plan.md` ไว้ในโฟลเดอร์เดียวกับ spec.md เขียนเป็นภาษาไทย มีหัวข้อตามลำดับนี้\n\n### 1. สรุปแนวทาง (5 บรรทัด)\nฟีเจอร์นี้ทำอะไร ใครใช้ และแนวทางสร้างโดยรวม\n\n### 2. เทคโนโลยีที่ใช้\nทำเป็นตาราง: `สิ่งที่เลือก` | `มาจาก` | `หมายเหตุ`\n- คอลัมน์ \"มาจาก\" ใส่ ID ของ Constraint (เช่น CON-TECH-01)\n- ถ้า spec ไม่ได้ระบุ ให้ใช้ค่าเริ่มต้นของรายวิชา คือ React (Vite) สำหรับหน้าบ้าน และ Python FastAPI สำหรับหลังบ้าน แล้วเขียนในคอลัมน์ \"มาจาก\" ว่า **ทีมเลือกเอง ไม่ได้มาจาก spec**\n- ห้ามเลือกเทคโนโลยีที่ขัดกับ Constraints\n\n### 3. โมเดลข้อมูล\nตารางหรือ entity ที่ต้องมี พร้อมฟิลด์หลัก และบอกว่าแต่ละ entity รองรับ FR ข้อใด\nถ้า Constraint ห้ามเก็บข้อมูลบางอย่าง (เช่น เลขบัตรประชาชน) ต้องเห็นชัดว่าไม่มีฟิลด์นั้น\n\n### 4. API / หน้าจอ\nรายการ endpoint หรือหน้าจอ แต่ละรายการระบุ FR ที่รองรับ 1 บรรทัด\nเขียนแค่ชื่อ method path และ input/output หลัก ยังไม่ต้องเขียนโค้ด\n\n### 5. ตารางตรวจ Constraints\n**หัวข้อนี้สำคัญที่สุด** ทำเป็นตาราง: `Constraint ID` | `ถูกนำไปใช้ที่ไหนใน plan` | `สถานะ`\n- ต้องมีทุก Constraint ใน spec ครบทุกตัว (CON, DOM, IF)\n- สถานะเป็น \"ใช้แล้ว\" หรือ \"ยังไม่ได้ใช้ เพราะ...\" ห้ามข้าม\n\n### 6. แผนทดสอบจาก Acceptance Criteria\nตาราง: `AC ID` | `ชื่อ test` | `ทดสอบอย่างไร`\n- ชื่อ test ต้องมี AC ID อยู่ในชื่อ เช่น `test_AC_BKG_01`\n- ต้องมีทุก AC ใน spec ครบทุกตัว\n\n### 7. ลำดับงาน\nงานย่อย 5 ถึง 10 ขั้น เรียงลำดับที่ควรทำ แต่ละขั้นระบุ FR หรือ AC ที่เกี่ยวข้อง\n\n### 8. สิ่งที่ยังไม่ทำ\nคัดลอก Open Questions ทุกข้อจาก spec มาไว้ที่นี่ แล้วเขียนว่า \"ส่วนที่เกี่ยวข้องกับข้อนี้จะยังไม่สร้างจนกว่าจะได้คำตอบ\"\nห้ามตอบ Open Questions เอง\n\n## ขั้นที่ 2: รายงานทีม\n\nหลังสร้างไฟล์แล้ว สรุปสั้น ๆ ในแชต 3 เรื่อง\n1. Constraint ที่ยังไม่ได้ใช้ (ถ้ามี) และเหตุผล\n2. AC ที่ทดสอบยากหรือทดสอบไม่ได้ในสภาพแวดล้อมของนักศึกษา\n3. สิ่งที่คุณ \"อยากเดา\" แต่ไม่ได้เดา เพราะติด Open Questions\n\nแล้วเพิ่มบันทึกท้าย `prompt-log.md` ว่าใช้คำสั่ง /plan และผลลัพธ์คืออะไร", "variables": [], "notes": "คุณคือสถาปนิกซอฟต์แวร์ของทีม งานของคุณคือ **ร่าง plan.md จาก spec.md** ยังไม่ต้องเขียนโค้ด", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/Boonyanuch-S/greentea50percent-swreqspec", "path": ".cursor/commands/plan.md", "ref": "395285a780f8e4cada5e43dbe302f1d3f1859ee2", "url": "https://github.com/Boonyanuch-S/greentea50percent-swreqspec/blob/395285a780f8e4cada5e43dbe302f1d3f1859ee2/.cursor/commands/plan.md", "key": "Boonyanuch-S/greentea50percent-swreqspec/.cursor/commands/plan.md" } } }

plan

About