md-scaffoldlisted

# md-scaffold — สร้างไฟล์ context ของโปรเจค เป้าหมาย: แปลงสิ่งที่ผู้ใช้ **เล่า** เป็นชุดไฟล์ `.md` ใน `/docs` ที่ Claude Code อ่านแล้ว build ได้ทันที. กฎทอง: "ถ้าอธิบายให้คนเข้าใจได้ใน MD — Claude ก็ build ได้." ## Workflow 0. **เช็ค `docs/discovery.md` ก่อน** — ถ้ามี (มาจาก `/design-thinking`) ให้อ่านก่อนถาม. discovery.md ตอบไปแล้ว: โปรดักต์ / ปัญหา / user หลัก / insight จากลูกค้าจริง. → **อย่าถามซ้ำสิ่งที่ตอบแล้ว** — สรุปให้ user ยืนยัน แล้วถามเฉพาะที่ยังขาด (features/roles/data). ถ้าไม่มี discovery.md → ทำข้อ 1 ตามปกติ. 1. **ถามให้ครบก่อนเขียน** — ห้ามเดา. ถามทีละกลุ่ม สั้นๆ (ข้ามข้อที่ discovery.md ตอบแล้ว): - โปรดักต์คืออะไร / แก้ปัญหาอะไร / ใครคือ user หลัก - user ทำอะไรได้บ้าง (features) — ให้เล่าหมดก่อน แล้วค่อยตัด MVP - มี role กี่แบบ (เจ้าของร้าน / ลูกค้า / แอดมิน) - ข้อมูลอะไรที่ต้องเก็บ (จะกลายเป็น tables) 2. **บังคับ MVP ceiling** — ก่อนเขียน features.md ให้ถาม: > "คอร์สนี้ build ได้จริง ~6 ชม. อะไรคือ MVP ที่เล็กที่สุดที่ยังแก้ปัญหาหลักได้?" - เพดาน: ≤ 3 หน้า detail + 2–3 tables + role หลัก 1 role ทำเต็ม. - **แต่ role อื่นใน roles.md ห้ามหายไปเงียบๆ** — ถ้ามีมากกว่า 1 role ทุก role ต้องมี touchpoint อย่างน้อย 1 จุดใน MVP (เช่น login แยกสิทธิ์ไปหน้า dashboard ของ role นั้น แม้จะยังไม่ทำ feature เต็ม) กันนักเรียนลืมว่าระบบมี role อื่นอยู่ ทำให้ระบบที่ build ออกมาไม่สอดคล้องกับ roles.md ที่วางแผนไว้ 3. **เขียนไฟล์ลง `/docs`** — สร้างครบ 7 ไฟล์ตาม template ด้านล่าง. 4. **สรุปให้ user ยืนยัน** — โชว์ features.md + d