| name | to-spec |
| description | เปลี่ยนบทสนทนาปัจจุบันให้เป็น spec แล้ว publish ขึ้น issue tracker ของโปรเจกต์ — ไม่มีการสัมภาษณ์ แค่สังเคราะห์จากสิ่งที่คุยกันมาแล้ว |
| disable-model-invocation | true |
skill นี้เอา context ของบทสนทนาปัจจุบันและความเข้าใจใน codebase มาผลิตเป็น spec (บางคนอาจรู้จักเอกสารแบบนี้ในชื่อ PRD) ห้ามสัมภาษณ์ user — แค่สังเคราะห์จากสิ่งที่รู้อยู่แล้ว
ข้อมูล issue tracker และชุดคำศัพท์ของ triage label ควรถูกเตรียมมาให้แล้ว — ถ้ายังไม่มีให้รัน /setup-matt-pocock-skills
ขั้นตอน
-
สำรวจ repo เพื่อทำความเข้าใจสถานะปัจจุบันของ codebase ถ้ายังไม่ได้ทำ ใช้คำศัพท์จาก domain glossary ของโปรเจกต์ให้สม่ำเสมอตลอดทั้ง spec และเคารพ ADR ที่มีอยู่ในบริเวณของ codebase ที่กำลังแตะ
-
ร่างว่าจะ test feature นี้ที่ seam (จุดต่อสาธารณะที่เราใช้ test พฤติกรรม) ไหนบ้าง ควรเลือกใช้ seam ที่มีอยู่แล้วก่อนสร้างใหม่ ใช้ seam ที่อยู่สูงที่สุดเท่าที่เป็นไปได้ ถ้าจำเป็นต้องมี seam ใหม่ ให้เสนอไว้ที่จุดสูงสุดเท่าที่ทำได้ ยิ่งทั้ง codebase มี seam น้อยยิ่งดี — จำนวนในอุดมคติคือหนึ่งเดียว
เช็คกับ user ว่า seam เหล่านี้ตรงกับที่เขาคาดหวังไว้
- เขียน spec ตาม template ด้านล่าง แล้ว publish ขึ้น issue tracker ของโปรเจกต์ ติด triage label
ready-for-agent — ไม่ต้อง triage เพิ่มอีก
โจทย์ปัญหา
ปัญหาที่ user กำลังเจอ เล่าจากมุมมองของ user
แนวทางแก้
วิธีแก้ปัญหา จากมุมมองของ user
User Stories
รายการ user story แบบมีเลขกำกับ ยาว ๆ แต่ละ user story ต้องอยู่ในรูปแบบ:
- ในฐานะ ฉันต้องการ เพื่อ
1. ในฐานะลูกค้าธนาคารบนมือถือ ฉันต้องการเห็นยอดเงินในบัญชีของฉัน เพื่อให้ตัดสินใจเรื่องการใช้จ่ายได้อย่างมีข้อมูลมากขึ้น
รายการ user story นี้ต้องละเอียดครอบคลุมสุด ๆ และแตะทุกแง่มุมของ feature
ข้อตัดสินใจด้าน implementation
รายการการตัดสินใจด้าน implementation ที่เกิดขึ้น ซึ่งอาจรวมถึง:
- module ที่จะสร้าง/แก้ไข
- interface ของ module เหล่านั้นที่จะถูกแก้ไข
- ข้อชี้แจงเชิงเทคนิคจาก developer
- การตัดสินใจเชิงสถาปัตยกรรม
- การเปลี่ยน schema
- API contract
- interaction เฉพาะจุด
ห้ามใส่ file path หรือ code snippet แบบเจาะจง เพราะพวกมันอาจล้าสมัยเร็วมาก
ข้อยกเว้น: ถ้า prototype ให้ snippet ที่บันทึกการตัดสินใจได้แม่นยำกว่าคำบรรยาย (state machine, reducer, schema, รูปร่างของ type) ให้แทรกมันไว้ในข้อตัดสินใจที่เกี่ยวข้อง พร้อมโน้ตสั้น ๆ ว่ามาจาก prototype ตัดให้เหลือเฉพาะส่วนที่อัดแน่นด้วยการตัดสินใจ — ไม่ใช่ demo ที่รันได้ เอาแค่ส่วนสำคัญ
ข้อตัดสินใจด้านการ test
รายการการตัดสินใจด้านการ test ที่เกิดขึ้น ให้ใส่:
- คำอธิบายว่า test ที่ดีเป็นอย่างไร (test เฉพาะพฤติกรรมภายนอก ไม่ใช่รายละเอียดของ implementation)
- module ไหนบ้างที่จะถูก test
- ตัวอย่างที่มีอยู่ก่อนแล้วสำหรับ test พวกนี้ (เช่น test แนวเดียวกันที่มีอยู่ใน codebase)
นอกขอบเขต
คำอธิบายสิ่งที่อยู่นอกขอบเขตของ spec นี้
โน้ตเพิ่มเติม
โน้ตอื่น ๆ เกี่ยวกับ feature นี้
