Ask Matt

คุณไม่จำเป็นต้องจำ skill ทุกตัว — ถามเอา

flow คือเส้นทางที่เดินผ่าน skill ต่าง ๆ งานส่วนใหญ่วิ่งอยู่บน main flow เส้นเดียว และมี on-ramp (ทางเชื่อมเข้า) สองทางที่มาบรรจบกับมัน ที่เหลือเป็นของ standalone หรือเป็นชั้น vocabulary ที่รองรับอยู่ข้างใต้

Main flow: จากไอเดีย → ship

เส้นทางที่งานส่วนใหญ่ใช้เดิน คุณมีไอเดียและอยากให้มันถูกสร้างขึ้นมา

1. /grill-with-docs — ลับไอเดียให้คมด้วยการสัมภาษณ์ เริ่มที่นี่เมื่อคุณมี codebase อยู่แล้ว: มันเป็นแบบ stateful เก็บสิ่งที่เรียนรู้ไว้ใน CONTEXT.md และ ADR (ไม่มี codebase? ใช้ /grill-me — ดูหัวข้อ Standalone ทั้งคู่รันบน primitive ตัวเดียวกันคือ /grilling แต่ grill-with-docs คือตัวที่ทิ้งหลักฐานเป็นเอกสารไว้)
2. ทางแยก — ทุกคำถามตอบได้ในบทสนทนาไหม? ถ้าคำถามไหนต้องการคำตอบที่รันได้จริง (state, business logic, หรือ UI ที่ต้องเห็นกับตา) ให้แวะไปทาง prototype โดยมี /handoff เป็นสะพานทั้งขาไปและขากลับ (ดูหัวข้อ "ข้าม session"):
   • /handoff ออกไปก่อน แล้วเปิด session ใหม่โดยอ้างอิงไฟล์นั้น
   • /prototype เพื่อตอบคำถามด้วย code แบบใช้แล้วทิ้ง
   • /handoff สิ่งที่เรียนรู้กลับมา แล้วอ้างอิงมันจาก thread ไอเดียเดิม

3. ทางแยก — งานนี้ต้องสร้างข้ามหลาย session ไหม?

   • ใช่ → /to-spec (เปลี่ยน thread ให้เป็น spec) แล้วต่อด้วย /to-tickets เพื่อแตกเป็น ticket แบบ tracer bullet (ticket ที่เจาะทะลุทุกชั้นของระบบแบบบาง ๆ) โดยแต่ละใบประกาศ blocking edges ของตัวเอง ถ้าใช้ tracker แบบ local ก็คือหนึ่งไฟล์ต่อหนึ่ง ticket ใต้ .scratch/<feature>/issues/ แล้วไล่ทำตัวที่เป็น blocker ก่อนด้วยมือ ส่วนบน tracker จริง edge เหล่านั้นจะกลายเป็น blocking link แบบ native ดังนั้น ticket ไหนที่ blocker เสร็จหมดแล้วก็หยิบได้เลย — สั่ง /implement ทีละ ticket โดยเคลียร์ context ระหว่างแต่ละใบ
   • ไม่ → /implement ตรงนี้เลย ใน context window เดิม

   ไม่ว่าทางไหน /implement จะสร้างแต่ละ issue โดยขับ /tdd อยู่ภายใน — ทีละ slice แบบ red-green — แล้วปิดงานด้วยการรัน /code-review ซึ่งเป็นการ review สองแกน (Standards + Spec) ของ diff ก่อน commit หยิบ /tdd มาใช้เดี่ยว ๆ เมื่ออยากสร้างพฤติกรรมที่จับต้องได้แบบ test-first โดยไม่ต้องมี spec เต็มรูปแบบ และหยิบ /code-review เดี่ยว ๆ เมื่อไหร่ก็ตามที่อยาก review branch หรือ PR เทียบกับจุดอ้างอิงที่ตายตัว

สุขอนามัยของ context

คุมขั้น 1–3 ให้อยู่ใน context window เดียวต่อเนื่องไม่ขาดตอน — อย่า compact หรือ clear จนกว่าจะผ่าน /to-tickets — เพื่อให้การ grill, spec และ ticket ทั้งหมดต่อยอดจากความคิดชุดเดียวกัน จากนั้นแต่ละ /implement ค่อยเริ่มสดใหม่ โดยทำงานจาก ticket

ขีดจำกัดของเรื่องนี้คือ smart zone: ช่วงหน้าต่าง (~120k token บนโมเดลระดับ state-of-the-art) ที่โมเดลยังคิดได้คมอยู่ ถ้า session เข้าใกล้ขีดนี้ก่อนถึง /to-tickets อย่าฝืนลุยต่อทั้งที่คุณภาพตกแล้ว — /handoff แล้วไปต่อใน thread ใหม่

On-ramps

สถานการณ์ตั้งต้นที่ก่อให้เกิดงาน แล้วไหลมารวมกับ main flow

• บั๊กกับ request กองพะเนิน → /triage มันพา issue ผ่านบทบาทต่าง ๆ ของการ triage แล้วผลิต issue ที่พร้อมให้ agent ทำงาน ซึ่ง /implement จะหยิบไปทำทีหลัง

  triage มีไว้สำหรับ issue ที่คุณไม่ได้สร้างเองเท่านั้น — bug report, feature request ที่เข้ามา, อะไรก็ตามที่มาถึงแบบดิบ ๆ ส่วน ticket ที่ /to-tickets ผลิตออกมานั้นพร้อมให้ agent ทำอยู่แล้ว ดังนั้นอย่าเอาไป triage ซ้ำ

• มีอะไรบางอย่างพัง → /diagnosing-bugs สำหรับเคสยาก ๆ: บั๊กที่มองแวบแรกแล้วไม่เจอ, flake ที่เป็น ๆ หาย ๆ, regression ที่แอบเล็ดลอดเข้ามาระหว่างสอง state ที่รู้ว่าดี มันจะปฏิเสธการตั้งทฤษฎีจนกว่าจะมี feedback loop ที่แน่น — คำสั่งเดียวที่แดงอยู่แล้วบนบั๊กตัวนี้ — แล้วค่อยแก้พร้อม regression test ส่วน post-mortem ของมันจะส่งไม้ต่อให้ /improve-codebase-architecture เมื่อสิ่งที่ค้นพบจริง ๆ คือไม่มี seam (จุดต่อสาธารณะที่ใช้ test พฤติกรรมได้) ดี ๆ ให้ล็อกบั๊กนั้นไว้
• งานก้อนมหึมาที่ยังมองไม่เห็นทาง — โปรเจกต์ greenfield หรือ feature ใหญ่เกินกว่าจะจบใน session เดียว → /wayfinder เมื่อเส้นทางจากตรงนี้ไปถึงปลายทางยังมองไม่เห็น มันจะร่าง แผนที่ที่ใช้ร่วมกัน เป็น ticket สำหรับการสืบสวนบน issue tracker แล้วไล่แก้ทีละใบ — ผลลัพธ์คือ การตัดสินใจ ไม่ใช่ deliverable — จนหมอกถูกผลักออกไปและเส้นทางชัดเจน จากนั้นมันจะมารวมกับ main flow ที่ /to-spec (หรือถ้างานกลายเป็นเล็กพอ ก็ตรงไป /implement เลย) ขณะที่ /grill-with-docs ลับไอเดียที่ถือไว้ได้ใน session เดียว wayfinder มีไว้สำหรับไอเดียที่ถือไม่ไหว

สุขภาพของ codebase

ไม่ใช่งาน feature — เป็นงานบำรุงรักษา

• /improve-codebase-architecture — รันเมื่อไหร่ก็ได้ที่มีเวลาว่าง เพื่อรักษา codebase ให้เป็นที่ที่ agent ทำงานได้ดี มันจะขุด โอกาสทำให้ module ลึกขึ้น ออกมา การเลือกสักอัน ก่อให้เกิดไอเดีย ที่พาเข้า main flow ที่ /grill-with-docs ได้ มันคือการสำรวจที่หาตัวเลือกมาให้ ส่วน /codebase-design (ด้านล่าง) คือโต๊ะทำงานที่ใช้ออกแบบตัวที่เลือกแล้ว

Vocabulary ที่อยู่ข้างใต้

reference แบบ model-invoked สองตัวที่ทำงานอยู่ ใต้ skill ตัวอื่น — แต่ละตัวเป็น single source of truth ของ vocabulary ของตัวเอง หยิบมาใช้ตรง ๆ เมื่อปัญหาอยู่ที่ คำศัพท์ ไม่ใช่กระบวนการ หรือจะปล่อยให้ skill ข้างบนดึงมันเข้ามาเองก็ได้

• /domain-modeling — ลับภาษา domain ของโปรเจกต์ให้คม: ท้าทายคำที่คลุมเครือ, คลี่คำที่แบกหลายความหมาย ("account" ที่ทำสามหน้าที่พร้อมกัน), บันทึกการตัดสินใจที่ย้อนกลับยากเป็น ADR มันคือวินัยเชิงรุกที่ /grill-with-docs ใช้ขับเคลื่อนเพื่อรักษา CONTEXT.md ให้เป็น glossary ที่สะอาด
• /codebase-design — vocabulary ของ deep module (module, interface, depth, seam, adapter, leverage, locality) สำหรับออกแบบ รูปทรง ของ module: พฤติกรรมเยอะ ๆ อยู่หลัง interface เล็ก ๆ ที่ seam สะอาด ๆ ทั้ง /tdd และ /improve-codebase-architecture พูดภาษานี้

ข้าม session

• /handoff — เมื่อ thread เต็มหรือคุณต้องแตกสาขาออกไป (เช่น ไปเปิด session /prototype) ตัวนี้จะบีบอัดบทสนทนาเป็นไฟล์ markdown คุณไม่ได้ทำงานต่อที่เดิม — คุณเปิด session ใหม่แล้วอ้างอิงไฟล์นั้นเพื่อพา context ข้ามไป มันคือสะพานระหว่าง context window ใช้ได้ทั้งสองทิศทาง ใช้เมื่ออยากได้ session ใหม่สด ๆ แต่ต้องเก็บบทสนทนาปัจจุบันเอาไว้
• /compact (built-in) — อยู่ในบทสนทนาเดิม โดยยอมให้ turn ก่อนหน้าถูกสรุปย่อ ใช้ตอนหยุดพักอย่างตั้งใจระหว่างเฟส เมื่อไม่ซีเรียสว่าประวัติแบบคำต่อคำจะหายไป อย่า compact กลางเฟส — agent อาจหลงทางได้ /handoff คือแยกสาย ส่วน /compact คือไปต่อ

Standalone

อยู่นอก main flow โดยสิ้นเชิง

• /grill-me — การสัมภาษณ์แบบไม่ปรานีเหมือน /grill-with-docs แต่สำหรับตอนที่ไม่มี codebase เป็นแบบ stateless: ไม่บันทึกอะไรลง local ไม่สร้าง CONTEXT.md หยิบมาใช้ลับแผนหรือ design อะไรก็ได้ที่ไม่ได้อยู่ใน repo
• /prototype — โปรแกรมเล็ก ๆ แบบใช้แล้วทิ้งที่ตอบคำถาม design หนึ่งข้อ: state model แบบนี้รู้สึกใช่ไหม หรือ UI นี้ควรหน้าตาเป็นยังไง ทิ้งตั้งแต่วันแรก — เก็บคำตอบไว้ ลบ code ทิ้ง มันคือทางแวะในขั้น 2 ของ main flow แต่หยิบมาใช้ได้ทุกครั้งที่คำถาม design ตัดสินบนกระดาษได้ยาก
• /research — มอบงานอ่านให้ background agent: มันจะสืบคำถามกับ primary sources แล้วทิ้งไฟล์ Markdown พร้อม citation ไว้ใน repo คุณทำงานต่อได้ระหว่างที่มันอ่าน ไฟล์ที่ได้คือของที่เอาเข้า main flow ที่ /grill-with-docs — research ป้อนความคิด ไม่ได้มาแทนความคิด
• /teach — เรียนรู้ concept ข้ามหลาย session โดยใช้ directory ปัจจุบันเป็น workspace แบบ stateful
• /writing-great-skills — reference สำหรับเขียนและแก้ skill ให้ดี

เงื่อนไขตั้งต้น

/setup-matt-pocock-skills — รันก่อนเริ่ม engineering flow ครั้งแรก เพื่อตั้งค่า issue tracker, label สำหรับ triage และ layout ของเอกสารที่ skill ตัวอื่นคาดหวังไว้ ใช้ issue tracker แบบ custom ก็ได้เช่นกัน