Design: $ARGUMENTS
ทำตาม docs/design-process.md ทุกขั้น — ไฟล์นั้นคือกติกา skill นี้แค่ลำดับงาน ถ้าขัดกันให้ยึดไฟล์นั้น
- ต้อง design ไหม — เทียบกับตารางหัวข้อ 1 ของ
docs/design-process.md- ไม่ต้อง: บอกเหตุผล 1 บรรทัด แล้วกลับไปใช้
new-feature - ไม่แน่ใจ: ถามคนก่อน
- ไม่ต้อง: บอกเหตุผล 1 บรรทัด แล้วกลับไปใช้
- เริ่ม (หัวข้อ 3.0): epic issue (label
design), branchdocs/<id>-design-<slug>, คัดลอกdocs/design/template.md→docs/design/<slug>.md(system.mdหรือ<เลข epic>-<slug>.md) ตั้งstatus: draftและเพิ่มแถวในdocs/design/README.md - อ่านก่อนถาม:
CONTEXT.md,docs/adr/,docs/architecture.md, design อื่นในdocs/design/— ข้อเท็จจริงที่หาเองได้ไปหาเอง ห้ามถาม - สัมภาษณ์เป็นรอบ (หัวข้อ 3.1) รูปแบบ
Qn — หัวข้อ: คำถาม+แนะนำ: …ทุกข้อ, เหตุการณ์ขอบ 1–2 ข้อทุกรอบ — เดินกิ่ง A–H (หัวข้อ 3.2) ให้ครบ และหยุดรอคนที่จุดอนุมัติ 1, 2 (system), 3 - เขียนลงไฟล์หลังทุกรอบ: หัวข้อในไฟล์ design, คำใหม่ใน
CONTEXT.md, ADRproposedในdocs/adr/(+ ดัชนี), รูป C4 ในdocs/architecture.mdถ้า container/ระบบภายนอกเปลี่ยน - ตรวจ (หัวข้อ 3.3):
make docs-checkต้องผ่าน (repo ที่ Makefile ยังไม่มี target นี้:python3 <path ของ web-template>/scripts/check-docs.py <repo>— ทีม Hermes:/home/opc/projects/web-template) + เช็คลิสต์ด้วยตัวเอง แล้วตั้งstatus: proposed - PR เอกสารอย่างเดียว:
docs(design): <slug>, body มีRefs #<epic>, สรุปทางเลือกที่ยังเปิด และหัวข้อ## CHANGELOGเป็น-— ห้ามมีโค้ด ห้าม merge - อนุมัติ (หัวข้อ 3.4): เมื่อคนอนุมัติ commit
status: approved+approved-by+ ADR เป็นacceptedใน PR เดียวกัน (make docs-checkต้องผ่าน) แล้วให้คน merge - หลัง merge (หัวข้อ 3.5): เปิด issue ย่อยตามหัวข้อ 13 ทีละชิ้น แต่ละใบลิงก์ epic และไฟล์ design — งานโค้ดเริ่มด้วย
new-feature