.md
พัฒนา & ตั้งค่าเครื่องมือต้องเคยใช้มาบ้างอัปเดต 2026-10-08

Monthly Project Review by a Stronger Model

ตรวจสุขภาพโปรเจคประจำเดือน ด้วยโมเดลที่สูงกว่าตัวที่ทำงานประจำ

พรอมป์เดือนละครั้งสำหรับโปรเจคที่ทำงานประจำวันด้วยโมเดลถูก ๆ — ให้โมเดลที่สูงกว่ากวาดทั้ง repo เปิด GitHub issue ทีละข้อพร้อมใบสารบัญ แล้วถามว่าจะสลับกลับไปโมเดลประจำวันให้ไล่ทำตามแผน ให้ตัวแพงแก้ข้อยากเองก่อน หรือให้ตัวแพงเป็นวาทยกรกระจายงานไป 2-3 tab ของโมเดลถูก

พรอมป์นี้ทำอะไร

What this prompt does

โปรเจคที่ vibe code ส่วนใหญ่ทำงานประจำวันด้วยโมเดลถูก ๆ เพื่อประหยัด แต่โมเดลตัวนั้นมองไม่เห็นจุดบอดของตัวเอง พรอมป์นี้เปลี่ยน session เดือนละครั้งบนโมเดลที่สูงกว่าให้เป็นการตรวจที่มีโครง: อ่านอย่างเดียว เทียบกับสารบัญรอบก่อน ให้เจ้าของตัดข้อที่ตั้งใจให้เป็นแบบนั้นออกก่อน แล้วค่อยเปิด GitHub issue ทีละ finding ติด label ความรุนแรงกับ "ใครควรทำ" พร้อมใบสารบัญที่ pin ไว้เรียงลำดับให้ จบด้วยคำถามบังคับเลือกผ่านเครื่องมือถามผู้ใช้ของ harness ว่าจะสลับกลับไปโมเดลประจำวันแล้วไล่ทำตามสารบัญ ให้ตัวแพงเคลียร์ข้อยากก่อน หรือถ้าอยู่ใน terminal ที่เปิด tab ให้ agent อื่นได้อย่าง Herdr ก็ให้ตัวแพงเป็นวาทยกร เปิด 2-3 tab ของโมเดลถูก แจก issue ไม่ให้ชนไฟล์กัน ตรวจรายงานทีละ tab แล้วปิด tab ที่ตัวเองเปิด หลักคือตัวแพงวางแผน ตัวถูกลงมือ

Most vibe-coded projects run on a cheaper model every day to keep costs down, and that model cannot see its own blind spots. This prompt turns one session a month on a stronger model into a structured review: read only, compare with last month's index, let the owner strike out deliberate choices before anything is filed, then open one GitHub issue per finding with severity and who-should-fix labels, plus a pinned index issue that lists them in order. It ends with a forced choice via the harness's ask-user tool: switch back to the daily model and work the index, let the stronger model clear the hard items first, or, in a terminal that can open tabs for other agents such as Herdr, have the stronger model conduct two or three cheaper-model tabs through the index, verify each report, and close the tabs it opened. The expensive model plans; the cheap model executes.

ใช้ตอนไหน

  • ใช้โมเดลถูกทำงานประจำวันมาทั้งเดือน แล้วเริ่มไม่แน่ใจว่าข้างในมีอะไรซ้ำซ้อนหรือขัดกันเองบ้างที่มันมองไม่ออก
  • อยากใช้โมเดลแพงให้คุ้ม คือให้มันคิดและวางแผน ไม่ใช่ให้มันพิมพ์โค้ดธรรมดาที่ตัวถูกก็ทำได้
  • เคยให้ AI รีวิวแล้วได้ข้อความยาว ๆ ในแชทที่หายไปเมื่อปิด session อยากได้ของที่ค้างอยู่บน GitHub แล้วค่อย ๆ ปิดทีละใบได้
  • มีหลาย session คนละวันแตะโปรเจคเดียวกัน เริ่มเห็น pattern เดียวกันเขียนคนละแบบในคนละไฟล์
  • CLAUDE.md หรือ README โตขึ้นเรื่อย ๆ จนไม่แน่ใจว่ากฎในนั้นยังตรงกับโค้ดจริงอยู่ไหม
  • ใช้ herdr อยู่แล้ว อยากให้โมเดลแพงนั่งคุม แล้วเปิดหลาย tab ของโมเดลถูกช่วยกันปิด issue พร้อมกัน แทนที่จะไล่ทีละข้อใน tab เดียว

ได้อะไรกลับมา

  • GitHub issue ต่อ 1 finding ที่โมเดลถูกเปิดอ่านแล้วลงมือได้ทันที — มีไฟล์:บรรทัด ควรเป็นอย่างไร และวิธีพิสูจน์ว่าแก้แล้ว
  • issue สารบัญ 1 ใบที่ pin ไว้ มี task list เรียงตามลำดับที่ควรทำ และลิงก์ย้อนไปรอบก่อน
  • label 3 ชั้นบนทุกใบ: monthly-review · severity:* · needs:strong-model หรือ ok:daily-model
  • docs/review/YYYY-MM.md ใน repo ที่บอกด้วยว่าตรวจอะไรแล้วไม่พบปัญหา และอะไรที่เจ้าของตัดออกเพราะตั้งใจให้เป็นแบบนั้น
  • ตารางเทียบกับรอบก่อน ว่าข้อไหนปิดจริง ข้อไหนค้าง ข้อไหนกลับมาพังซ้ำ
  • ข้อความสั้น ๆ พร้อมแปะใน session ใหม่ของโมเดลประจำวัน ให้มันไล่ทำตามสารบัญได้เลย
  • ในโหมดวาทยกร: ตาราง [issue | tab ไหนทำ | ผล | ต้องตัดสินใจอะไรต่อ] หลัง tab ทุกตัวรายงานกลับและถูกปิดแล้ว

วิธีใช้

How to use

  1. 1เปิด session ใหม่ในโฟลเดอร์โปรเจค แล้วตั้งโมเดลให้สูงกว่าตัวที่ใช้ทำงานประจำวันอย่างน้อยหนึ่งขั้น — ตัวพรอมป์ไม่ระบุชื่อโมเดล จะได้ใช้ซ้ำได้แม้รุ่นเปลี่ยน
  2. 2วางพรอมป์ แล้วแทน [ชื่อโปรเจค] กับ [ลิงก์ issue สารบัญรอบก่อน] ด้วยของจริง รอบแรกเขียนว่า "รอบแรก"
  3. 3ปล่อยให้มันอ่านอย่างเดียวในขั้น 1-2 อย่าใจร้อนสั่งแก้ ถ้ามันเริ่มแตะโค้ดก่อนขั้น 6 ให้หยุดทันที
  4. 4ขั้น 3 คือจุดที่ต้องใช้เวลา — ตัดข้อที่เป็นทางลัดที่เลือกเองออก ไม่งั้นมันจะเปิด issue ให้แก้ของที่ตั้งใจให้เป็นแบบนั้น
  5. 5เมื่อมันถามตอนจบ ถ้าเลือกสลับโมเดล ให้ก๊อปข้อความแปะที่มันเตรียมไว้ ไปเปิด session ใหม่บนโมเดลประจำวัน
  6. 6ถ้าใช้ herdr ให้แทน [herdr] ด้วยชื่อเครื่องมือจริง แล้วเลือกข้อ 3 ตอนจบ มันจะเปิด tab ของโมเดลประจำวันเอง แจกงาน รอรายงาน ตรวจ แล้วปิด tab ให้ — ถ้าไม่ได้ใช้ terminal แบบนี้ ให้ตัดข้อ 3 ทิ้งก่อนวางพรอมป์
  7. 7เดือนถัดไป ส่งลิงก์สารบัญรอบนี้ให้รอบใหม่ มันจะเทียบให้เองว่าอะไรกลับมาพังซ้ำ

ตัวพรอมป์

The prompt · 84 บรรทัด

ให้ AI อ่านเอง: madebytle.com/prompt/monthly-project-review-stronger-model.md

Mission: ตรวจสุขภาพโปรเจคประจำเดือน ด้วยโมเดลที่สูงกว่าตัวที่ทำงานประจำ

บริบท

  • โปรเจค [ชื่อโปรเจค] ในโฟลเดอร์นี้ ถูกสร้างและแก้มาตลอดทั้งเดือนด้วยโมเดลที่ ต่ำกว่านาย เพราะฉันประหยัดค่าใช้จ่ายในงานประจำวัน
  • เดือนละครั้ง ฉันจะเปิด session ด้วยโมเดลระดับนายมากวาดทั้งโปรเจคหนึ่งรอบ นี่คือรอบนั้น
  • นายแพงกว่า งานของนายจึงไม่ใช่ "แก้ทุกอย่างเอง" แต่คือ มองให้เห็นสิ่งที่ตัวประจำวันมองไม่เห็น แล้ววางแผนให้ละเอียดพอที่ตัวประจำวันจะทำต่อได้โดยไม่ต้องคิดใหม่
  • รอบที่แล้ว: [ลิงก์ issue สารบัญรอบก่อน หรือเขียนว่า "รอบแรก"]
  • ห้ามแตะโค้ดจนกว่าจะถึงขั้น 6 และฉันตอบแล้ว

เป้าหมาย

  1. หาสิ่งที่ควรแก้ทั้งโปรเจค เรียงตามความรุนแรง พร้อมหลักฐานที่ชี้ได้ว่าอยู่ไฟล์ไหนบรรทัดไหน
  2. แยกให้ชัดทุกข้อว่า "ตัวประจำวันทำได้ ถ้ามีแผนละเอียดพอ" หรือ "ต้องใช้นายเอง"
  3. เอาแผนขึ้น GitHub เป็น issue ที่ไล่ทำทีละข้อได้ ไม่ว่าใครจะเป็นคนทำ
  4. จบด้วยการถามฉันว่าจะให้ใครทำต่อ

ลำดับการทำงาน (ห้ามข้ามขั้น)

ขั้น 1 อ่านอย่างเดียว: git log --since="1 month ago" --stat, ไฟล์ instruction ของโปรเจค (CLAUDE.md / AGENTS.md / README), โครงสร้างโฟลเดอร์, dependency list, test ที่มี, ไฟล์ที่ถูกแก้บ่อยที่สุดในเดือนนี้, issue ที่เปิดค้างอยู่ และ issue สารบัญรอบก่อน (ถ้ามี) ยังไม่แก้อะไรทั้งสิ้น

ขั้น 2 เทียบกับรอบก่อน: ถ้ามีสารบัญรอบก่อน ให้ตอบสามอย่าง — ข้อไหนปิดไปแล้วจริง (พิสูจน์จากโค้ด ไม่ใช่จากสถานะ issue), ข้อไหนยังค้าง, ข้อไหน กลับมาพังซ้ำ ของที่พังซ้ำสำคัญกว่าของใหม่ เพราะแปลว่าแผนรอบก่อนไม่กันได้จริง

ขั้น 3 ส่ง finding ให้ฉันคัดก่อนเปิด issue: ตารางสั้น ๆ [finding | ความรุนแรง | ใครควรทำ | ทำไมถึงคิดว่าเป็นปัญหา] ตรงนี้ฉันจะตัดข้อที่เป็น policy ที่ฉันเลือกเองออก ถ้านายไม่แน่ใจว่าอะไรคือบั๊กหรือฉันตั้งใจ ให้ถามในขั้นนี้ อย่าเดา

ขั้น 4 เปิด GitHub issue ตามกติกาข้างล่าง เฉพาะข้อที่ฉันอนุมัติ

ขั้น 5 เขียนไฟล์สรุปลงโปรเจค แล้ว commit

ขั้น 6 ถามฉันว่าจะไปต่อทางไหน ด้วยเครื่องมือถามแบบมีตัวเลือก

สิ่งที่ต้องหาเป็นพิเศษ

  • รอยต่อระหว่าง session: โค้ดที่เขียนคนละวันโดยคนละ session มักมี logic ซ้ำกันคนละที่, pattern เดียวกันแต่เขียนคนละแบบ, abstraction ที่ควรรวมเป็นตัวเดียว, ของที่ copy แล้วแก้ไม่ครบ
  • เอกสารกับโค้ดไม่ตรงกัน: กฎในไฟล์ instruction ที่โค้ดไม่ได้ทำตาม, ฟีเจอร์ที่ถูกถอดไปแล้วแต่เอกสารยังพูดถึง, กฎที่ขัดกันเองในไฟล์เดียวกัน
  • error ที่ถูกกลืน: catch แล้วเงียบ, return สำเร็จทั้งที่ปลายทางไม่เกิดอะไร, fallback ที่ซ่อนปัญหาแทนที่จะฟ้อง
  • test ที่หลอกตา: test ที่ผ่านเพราะไม่ได้ assert อะไรจริง, test ที่ถูก skip ค้างไว้, ส่วนที่สำคัญแต่ไม่มี test เลย
  • ความปลอดภัย: secret ที่หลุดลง git history, input จากภายนอกที่ไม่ถูก validate, สิทธิ์หรือ allowlist ที่กว้างเกินจำเป็น
  • dependency: ของที่มี advisory, ของที่ติดตั้งไว้แต่ไม่มีใคร import, version ที่ pin ไว้โดยไม่มีเหตุผล
  • performance ที่เห็นชัด: query ซ้อนใน loop, โหลดทั้งก้อนเพื่อใช้ชิ้นเดียว, งานที่ทำซ้ำทุก request ทั้งที่ cache ได้
  • repo hygiene: ไฟล์ที่ไม่มีใครเรียก, TODO ที่ค้างเกินเดือน, branch ที่ตายแล้ว, ไฟล์ใหญ่ที่ไม่ควรถูก track

กติกา GitHub (ขั้น 4)

  • ชื่อ issue ขึ้นต้นด้วย [review YYYY-MM] ตามด้วยใจความสั้น ๆ ที่อ่านแล้วรู้ว่าต้องแก้อะไร
  • label ทุกใบต้องมี 3 ชั้น: monthly-review · ความรุนแรง severity:critical / severity:high / severity:medium / severity:low · ผู้ทำ needs:strong-model หรือ ok:daily-model — ถ้า label ไหนยังไม่มีใน repo ให้สร้างก่อน
  • body ของแต่ละ issue ต้องให้โมเดลที่ต่ำกว่านายทำได้โดยไม่ต้องวิเคราะห์ซ้ำ: ไฟล์และบรรทัด, ตอนนี้เป็นอย่างไร, ควรเป็นอย่างไร, วิธีพิสูจน์ว่าแก้แล้ว (คำสั่งหรือ test ที่รันได้), ขอบเขตที่ห้ามแตะ, issue อื่นที่ต้องทำก่อน (ถ้ามี)
  • issue สารบัญ 1 ใบ ชื่อ [review YYYY-MM] สารบัญ มี task list - [ ] #เลข เรียงตามลำดับที่ควรทำ (ความรุนแรงก่อน แล้วตาม dependency) ลิงก์ไปสารบัญรอบก่อน และสรุปสั้น ๆ ว่ารอบนี้โปรเจคอยู่ในสภาพไหน — pin ไว้
  • ห้ามเปิดซ้ำกับ issue ที่ค้างอยู่แล้ว ถ้าเจอเรื่องเดิม ให้คอมเมนต์เพิ่มหลักฐานใหม่ในใบเดิม แล้วใส่ใบเดิมลงสารบัญรอบนี้แทน
  • ห้ามปิด issue ที่นายไม่ได้เป็นคนแก้ในรอบนี้

ไฟล์สรุป (ขั้น 5)

docs/review/YYYY-MM.md มี: ลิงก์ issue สารบัญ, ภาพรวมสภาพโปรเจคใน 5 บรรทัด, ตารางเทียบรอบก่อน [ข้อ | สถานะรอบก่อน | สถานะรอบนี้], สิ่งที่ตรวจแล้วไม่พบปัญหา (เพื่อให้รอบหน้ารู้ว่าขอบเขตครอบคลุมแค่ไหน), และข้อที่ฉันตัดออกในขั้น 3 พร้อมเหตุผลที่ฉันให้ — commit ด้วยข้อความ chore: monthly review YYYY-MM แยกจาก commit อื่น

ขั้น 6 ถามฉันว่าจะไปต่อทางไหน

ใช้ AskUserQuestion ถ้านายรันใน Claude Code หรือเครื่องมือถามผู้ใช้แบบมีตัวเลือกที่ harness ของนายมี ห้ามพิมพ์คำถามลอย ๆ แล้วรอ ให้มีสามตัวเลือก (ตัดข้อ 3 ออกถ้าเครื่องนี้ไม่มี terminal ที่เปิด tab ให้ agent อื่นได้ เช่น herdr):

  1. สลับไปโมเดลประจำวัน แล้วไล่ทำตามสารบัญ — นายต้องเตรียมข้อความสั้น ๆ ให้ฉันแปะใน session ใหม่ได้ทันที เช่น "อ่าน issue #[เลขสารบัญ] แล้วทำทีละข้อตามลำดับ ปิด issue ได้ต่อเมื่อพิสูจน์ตามวิธีที่ระบุไว้ในใบนั้นแล้ว ข้อที่ติด needs:strong-model ให้ข้ามแล้วบอกฉัน" ถ้าฉันเลือกข้อนี้ นายจบ session โดยไม่แตะโค้ด
  2. ให้นายทำเองเฉพาะข้อ needs:strong-model ก่อน แล้วค่อยสลับ — ทำทีละข้อ commit แยกต่อ issue ปิด issue เมื่อพิสูจน์แล้ว ติ๊กในสารบัญ ทำครบแล้วกลับมาถามข้อ 1 อีกรอบพร้อมข้อความแปะที่อัปเดตแล้ว
  3. นายเป็นวาทยกร กระจายงานให้ tab ของโมเดลประจำวัน — ใช้ได้เมื่อรันใน terminal ที่เปิด tab ใหม่ให้ agent อื่นได้ (เช่น [herdr]) นายไม่แตะโค้ดเอง แต่เปิด 2-3 tab ที่รันโมเดลประจำวันในโฟลเดอร์เดียวกัน แล้วแจก issue จากสารบัญให้ทีละ tab ตามกติกาข้างล่าง

โหมดวาทยกร (ถ้าฉันเลือกข้อ 3)

  • เปิดไม่เกิน 3 tab และแจก issue ให้แต่ละ tab ไม่ชนไฟล์กัน — ถ้าสอง issue แตะไฟล์เดียวกัน ให้อยู่ tab เดียวกันเรียงต่อกัน ไม่แยกขนาน
  • ข้อที่ติด needs:strong-model นายทำเองใน tab นี้ระหว่างรอ ไม่แจกออกไป
  • บรีฟที่ส่งให้แต่ละ tab ต้องมีครบ: เลข issue ที่ต้องทำตามลำดับ, คำสั่งว่า "อ่าน issue ด้วย gh issue view ก่อน ทำตามวิธีพิสูจน์ในใบนั้น commit แยกต่อ issue ห้ามแตะไฟล์นอกขอบเขตที่ใบนั้นระบุ", และรูปแบบรายงานกลับที่นายอยากได้ (issue ไหนเสร็จ commit อะไร พิสูจน์ด้วยอะไร ติดอะไร)
  • ส่งงานแล้วต้องยืนยันว่า tab นั้น เริ่มรันจริง ก่อนไปแจก tab ถัดไป (เช่นใน herdr: pane run แล้ว send-keys Enter แล้วรอสถานะ working — พิมพ์ลงไปเฉย ๆ ยังไม่ถือว่าส่ง) แล้วค่อยรอจนสถานะ idle แล้วอ่านผล
  • tab ไหนรายงานว่าติด ให้นายตัดสินใจเอง: แก้ให้เอง, ส่งคำสั่งเพิ่ม, หรือเอา issue นั้นกลับมาติด needs:strong-model แล้วบอกฉัน — อย่าปล่อยให้มันเดาต่อ
  • tab ที่รายงานเสร็จแล้ว ให้นายตรวจก่อนรับ: git log ว่ามี commit ตามที่บอก, รันวิธีพิสูจน์ในใบ issue ซ้ำเองหนึ่งรอบ แล้วค่อยปิด issue และติ๊กในสารบัญ
  • รับงานแล้ว ปิด tab นั้น — ปิดเฉพาะ tab ที่นายเปิดเองในรอบนี้ ห้ามปิด tab อื่นของฉัน
  • ทุก tab ปิดหมดแล้ว ให้ push, อัปเดตสารบัญ, แล้วสรุปให้ฉันเป็นตาราง [issue | tab ไหนทำ | ผล | ต้องตัดสินใจอะไรต่อ] ใบไหนล้มเหลวให้บอกตรง ๆ อย่าซ่อน

กฎตลอดรอบ

  • ทุก finding ต้องมีหลักฐานที่ชี้ได้ (ไฟล์:บรรทัด หรือคำสั่งที่ reproduce ได้) ความรู้สึกว่า "น่าจะไม่ดี" ไม่นับ
  • ห้ามทำเองโดยเด็ดขาด ต้องถามฉันก่อน: ลบไฟล์หรือข้อมูล, อัป dependency ข้าม major, แก้ setting ของ repo, force push, สั่งอะไรที่มีค่าใช้จ่าย
  • ไม่ลบ ให้ archive แล้วบอกว่าย้ายไปไหน
  • tab ที่นายเปิดในโหมดวาทยกร ใช้ hook และ config ชุดเดียวกับโฟลเดอร์นี้ ถ้าโปรเจคมี hook ที่ยิงของจริง (แจ้งเตือน, deploy) ให้บอกฉันก่อนเปิด tab
  • ถ้ารอบนี้ไม่เจออะไรที่ควรแก้ ให้บอกตรง ๆ แล้วเปิดแค่สารบัญที่เขียนว่าตรวจอะไรไปบ้าง อย่าหาเรื่องแก้เพื่อให้มีงาน
  • สรุปให้ฉันเป็นภาษาไทย สั้น ขึ้นต้นด้วยสิ่งที่ต้องตัดสินใจก่อน

ถ้าไม่แน่ใจว่าเป็นบั๊กหรือฉันตั้งใจ ให้ถามในขั้น 3 ถ้าไม่แน่ใจเรื่องอื่น ให้ถามก่อนลงมือ อย่าเดา

ข้อควรรู้

Notes from using it

พรอมป์นี้เป็นคู่กับ "Audit a Running AI System From Another Workspace" แต่คนละสถานการณ์ — ตัวนั้นตรวจระบบที่รันอยู่และปิดไม่ได้ ตัวนี้ตรวจโปรเจคธรรมดาที่หยุดได้ และตั้งใจให้เบากว่า: ไม่มีการทดลองบูตเย็น ไม่มีตาราง before/after เพราะรันทุกเดือน ถ้าหนักเกินจะไม่มีใครรันจริง ส่วนที่สำคัญที่สุดคือการบังคับไม่แตะโค้ดจนกว่าจะถึงขั้น 6 — รอบแรกที่ทดลองโดยไม่มีข้อนี้ โมเดลเริ่ม refactor ตั้งแต่ขั้น 1 แล้ว finding ที่เหลือก็กลายเป็นของที่มันแก้ไปแล้วครึ่งหนึ่ง

คำถามที่เจอบ่อย

FAQ

ทำไมไม่ให้โมเดลแพงแก้ให้เสร็จไปเลยในรอบเดียว?

เพราะส่วนที่แพงจริงคือการมองเห็น ไม่ใช่การพิมพ์โค้ด พอ finding ถูกเขียนเป็น issue ที่มีไฟล์:บรรทัดกับวิธีพิสูจน์แล้ว งานที่เหลือส่วนใหญ่โมเดลถูกทำได้ พรอมป์เลยบังคับให้แยก label ว่าข้อไหนต้องใช้ตัวแพงจริง ๆ แล้วถามตอนจบว่าจะให้ตัวแพงทำเฉพาะข้อนั้นก่อนไหม

ทำไมต้องเป็น GitHub issue ไม่เขียนเป็นไฟล์ markdown ไฟล์เดียวพอ?

เพราะไฟล์เดียวปิดทีละข้อไม่ได้ และ session ถัดไปไม่รู้ว่าข้อไหนทำไปแล้ว issue มีสถานะเปิด/ปิดในตัว มี task list ในสารบัญที่ติ๊กได้ และโมเดลประจำวันอ่านด้วย gh issue view ได้โดยไม่ต้องรู้บริบทอื่น ไฟล์ใน docs/review ยังมีอยู่ แต่ทำหน้าที่เป็นบันทึกภาพรวมของรอบนั้น ไม่ใช่ที่ติดตามงาน

ทำไมถึงบังคับให้ถามด้วย AskUserQuestion แทนที่จะพิมพ์ถามในแชท?

เพราะคำถามที่พิมพ์ลอย ๆ ในแชทมักถูกโมเดลตอบเองแล้วทำต่อ หรือจมหายไปในข้อความยาว เครื่องมือถามแบบมีตัวเลือกบังคับให้ session หยุดรอจริง ๆ และคนเลือกได้ด้วยคลิกเดียว ทางเลือกสองทางตอนจบคือจุดที่ตัดสินว่าจะจ่ายเงินต่อหรือไม่ เลยต้องหยุดให้แน่

รันซ้ำเดือนหน้าแล้วจะเปิด issue ซ้ำไหม?

พรอมป์ห้ามเปิดซ้ำกับใบที่ยังค้างอยู่ ถ้าเจอเรื่องเดิมให้คอมเมนต์หลักฐานใหม่ในใบเดิมแล้วใส่ใบเดิมลงสารบัญรอบใหม่แทน และขั้น 2 บังคับให้เทียบกับสารบัญรอบก่อนทุกครั้ง ของที่กลับมาพังซ้ำจะถูกยกความสำคัญขึ้นกว่าของใหม่

ถ้าเดือนนี้มันไม่เจออะไรเลย?

พรอมป์บอกไว้ตรง ๆ ว่าให้รายงานว่าไม่เจอ แล้วเปิดแค่สารบัญที่เขียนว่าตรวจอะไรไปบ้าง ห้ามหาเรื่องแก้เพื่อให้มีงาน ส่วน "สิ่งที่ตรวจแล้วไม่พบปัญหา" ในไฟล์สรุปมีไว้เพื่อเรื่องนี้ รอบหน้าจะได้รู้ว่าขอบเขตเดิมครอบคลุมแค่ไหน

โหมดวาทยกรเปิดกี่ tab ได้ และทำไมถึงจำกัดไว้แค่ 2-3?

เพราะทุก tab แตะโฟลเดอร์เดียวกัน ยิ่งเปิดเยอะยิ่งเสี่ยงแก้ไฟล์ชนกันและ commit ทับกัน พรอมป์เลยบังคับให้แจก issue ที่แตะไฟล์เดียวกันไปอยู่ tab เดียวกันเรียงต่อกัน และให้ตัวควบคุมยืนยันว่า tab เริ่มรันจริงก่อนไปแจกตัวถัดไป ถ้าแค่พิมพ์ลง tab แล้วไม่ได้กด Enter สถานะจะยัง idle และตัวควบคุมจะเข้าใจผิดว่างานเสร็จแล้ว

ตัวควบคุมจะปิด tab ของเราที่เปิดอยู่ก่อนไหม?

ไม่ พรอมป์ระบุว่าปิดได้เฉพาะ tab ที่มันเปิดเองในรอบนี้ และก่อนปิดต้องรับงานจาก tab นั้นก่อน คือเช็ค git log ว่ามี commit จริงและรันวิธีพิสูจน์ในใบ issue ซ้ำเองหนึ่งรอบ ไม่ใช่เชื่อรายงานของ tab

ใช้กับ Codex ได้ไหม ในเมื่อมันไม่มี AskUserQuestion?

ได้ ตัวพรอมป์เขียนว่าให้ใช้ AskUserQuestion ถ้ารันใน Claude Code หรือเครื่องมือถามผู้ใช้แบบมีตัวเลือกที่ harness นั้นมี ส่วน GitHub ใช้ gh CLI ซึ่งทั้งสองฝั่งเรียกได้เหมือนกัน

พรอมป์นี้ใช้ได้ผลไหม

กดบอกไว้หน่อยครับ ไม่ต้องล็อกอิน — ตัวที่คนกดว่าใช้ไม่ได้ผลจะถูกเอาไปขัดใหม่ก่อน

แก้เองแล้วดีขึ้น อยากส่งเวอร์ชันที่ดีกว่ากลับมา หรืออยากให้ทำพรอมป์เรื่องไหนเพิ่ม — แจ้งที่ GitHub · ไม่มีบัญชี GitHub ก็ นัดคุยได้เลย