القائمة
เปลี่ยนบทสนทนาปัจจุบันให้เป็น spec แล้ว publish ขึ้น issue tracker ของโปรเจกต์ — ไม่มีการสัมภาษณ์ แค่สังเคราะห์จากสิ่งที่คุยกันมาแล้ว
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
วางแผนงานก้อนใหญ่ — ใหญ่เกินกว่าหนึ่ง agent session จะรับไหว — เป็นแผนที่ร่วมของ ticket สำหรับการ investigate บน issue tracker ของคุณ แล้วไล่ resolve ทีละใบจนกว่าเส้นทางไปยังจุดหมายจะชัด
สร้าง interface design หลายแบบที่ต่างกันสุดขั้วสำหรับ module หนึ่ง โดยใช้ sub-agent แบบ parallel ใช้เมื่อ user อยากออกแบบ API, สำรวจตัวเลือกของ interface, เปรียบเทียบรูปทรงของ module หรือพูดถึง "design it twice"
QA session แบบ interactive ที่ผู้ใช้เล่าบั๊กหรือปัญหาแบบคุยกันธรรมดา แล้ว agent เปิด GitHub issue ให้ พร้อมสำรวจ codebase เบื้องหลังเพื่อเก็บ context และภาษา domain ใช้เมื่อผู้ใช้อยากรายงานบั๊ก ทำ QA เปิด issue แบบคุยกัน หรือพูดถึง "QA session"
สร้างแผน refactor แบบละเอียดที่ซอยเป็น commit เล็ก ๆ ผ่านการสัมภาษณ์ user แล้วเปิดเป็น GitHub issue ใช้เมื่อ user อยากวางแผน refactor สร้าง refactoring RFC หรือแตก refactor ออกเป็นขั้นเล็ก ๆ ที่ปลอดภัย
สกัด glossary ภาษากลางสไตล์ DDD จากบทสนทนาปัจจุบัน พร้อมชี้จุดกำกวมและเสนอ term มาตรฐาน เซฟลง UBIQUITOUS_LANGUAGE.md ใช้เมื่อผู้ใช้อยากนิยามศัพท์ domain สร้าง glossary ทำ terminology ให้แน่น สร้าง ubiquitous language หรือพูดถึง "domain model" หรือ "DDD"
ถามว่า skill หรือ flow ไหนเหมาะกับสถานการณ์ของคุณ เป็น router ที่ครอบ skill ทั้งหมดใน repo นี้
| 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 เหล่านี้ตรงกับที่เขาคาดหวังไว้
ready-for-agent — ไม่ต้อง triage เพิ่มอีกปัญหาที่ user กำลังเจอ เล่าจากมุมมองของ user
วิธีแก้ปัญหา จากมุมมองของ user
รายการ user story แบบมีเลขกำกับ ยาว ๆ แต่ละ user story ต้องอยู่ในรูปแบบ:
รายการ user story นี้ต้องละเอียดครอบคลุมสุด ๆ และแตะทุกแง่มุมของ feature
รายการการตัดสินใจด้าน implementation ที่เกิดขึ้น ซึ่งอาจรวมถึง:
ห้ามใส่ file path หรือ code snippet แบบเจาะจง เพราะพวกมันอาจล้าสมัยเร็วมาก
ข้อยกเว้น: ถ้า prototype ให้ snippet ที่บันทึกการตัดสินใจได้แม่นยำกว่าคำบรรยาย (state machine, reducer, schema, รูปร่างของ type) ให้แทรกมันไว้ในข้อตัดสินใจที่เกี่ยวข้อง พร้อมโน้ตสั้น ๆ ว่ามาจาก prototype ตัดให้เหลือเฉพาะส่วนที่อัดแน่นด้วยการตัดสินใจ — ไม่ใช่ demo ที่รันได้ เอาแค่ส่วนสำคัญ
รายการการตัดสินใจด้านการ test ที่เกิดขึ้น ให้ใส่:
คำอธิบายสิ่งที่อยู่นอกขอบเขตของ spec นี้
โน้ตอื่น ๆ เกี่ยวกับ feature นี้