coding agent ส่งคำถามมาห้าข้อ แต่ละข้อมีตัวเลือกยาวพอ ๆ กับย่อหน้าหนึ่ง เราตอบข้อแรกเสร็จ เลื่อนลงไปข้อสาม แล้วต้องเลื่อนกลับขึ้นไปดูว่าคำตอบก่อนหน้าขัดกันหรือไม่ ถ้าอยากแย้งแค่ครึ่งประโยค ก็ต้องอธิบายใหม่ว่ากำลังพูดถึงข้อความส่วนไหน

นี่คือความติดขัดที่ Matt Pocock ผู้เขียน /grill-me อธิบายไว้: ตัวสกิลตั้งใจถามหลายเรื่องที่พร้อมตัดสินใจในแต่ละรอบ แต่การตอบเรียงกันในเทอร์มินัลทำให้ทบทวนและแก้คำตอบยาว ๆ ได้ไม่เป็นธรรมชาติ

Plannotator ไม่ได้เปลี่ยนตรรกะของ /grill-me และไม่ได้ทำให้คำถามฉลาดขึ้น มันวาง “โต๊ะทบทวน” บนเบราว์เซอร์คร่อมบทสนทนาเดิม ผู้ใช้จึงเห็นคำถามเป็นชุด เลือกหรือปรับคำตอบ ตรวจทั้งรอบ แล้วค่อยส่ง feedback กลับไปยังเอเจนต์

สิ่งที่เปลี่ยนคือพื้นผิวการตัดสินใจ

/grill-me รับไอเดียที่ยังหลวมแล้วถามต่อเป็นรอบ ๆ หนึ่งรอบประกอบด้วยคำถามทั้งหมดที่มีข้อมูลตั้งต้นพร้อมแล้ว สกิลรอคำตอบจากผู้ใช้ก่อนนำการตัดสินใจเหล่านั้นไปสร้างคำถามรอบถัดไป กระบวนการนี้เป็นแบบ stateless: ตัว /grill-me เองไม่เขียนไฟล์หรือทิ้งเอกสารไว้ใน workspace

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

• เลือกคำตอบแนะนำหรือปรับข้อความก่อนส่ง
• annotate หรือ ไฮไลต์ ขีดฆ่า และคอมเมนต์เฉพาะจุด บนคำถามหรือคำตอบ
• มองย้อนทั้งรายการเพื่อเช็กว่าการตัดสินใจในรอบเดียวกันสอดคล้องกันหรือไม่
• กด Send Feedback เมื่อพร้อม เพื่อส่ง annotation ทั้งรอบเป็นอินพุตถัดไปของเอเจนต์

คำว่า “แก้” ในที่นี้มีขอบเขตสำคัญ ผู้ใช้เลือก ปรับ และตรวจรายการที่อยู่บนหน้าจอ ก่อน กด Send Feedback ได้ หลักฐานไม่ได้บอกว่า Plannotator ย้อนสถานะหรือแก้ประวัติของรอบที่ส่งไปแล้วได้

เดินตามหนึ่งรอบ ตั้งแต่คำถามถึง feedback

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

1. เริ่ม /grill-me ในบทสนทนาใหม่

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

2. เปิดข้อความล่าสุดใน Plannotator

ในเอเจนต์ที่รองรับ slash command เอกสารตัวอย่างใช้:

/plannotator-last

คำสั่งนี้เปิดข้อความล่าสุดของเอเจนต์ในเบราว์เซอร์ แต่บน Codex ให้ใช้ skill $plannotator-last หรือรูปแบบ !plannotator … แทน slash command ตามเอกสารปัจจุบัน

3. ตอบและใส่หมายเหตุเฉพาะจุด

อ่านคำถามทั้งรอบก่อน เลือกหรือปรับคำตอบที่ตรงกับการตัดสินใจจริง หากสมมติฐานในคำถามผิด ไม่จำเป็นต้องเขียนคำอธิบายใหม่ทั้งก้อน ให้ไฮไลต์ข้อความนั้นแล้วคอมเมนต์ตรงจุด หากตัวเลือกหนึ่งไม่อยู่ในขอบเขต ก็ขีดฆ่าและบอกเหตุผลสั้น ๆ ได้

จุดนี้สำคัญกว่าการกดเลือกให้ครบ ผู้สร้าง /grill-me มองว่าเซสชันที่ดีไม่ได้วัดจากจำนวนคำถาม แต่ดูจากการที่ผู้ใช้กล้าไม่เห็นด้วย คุม scope และอธิบายเหตุผลของการตัดสินใจได้

4. ส่งทั้งรอบ แล้วทบทวนรอบใหม่

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

วงจรจึงไม่ได้เปลี่ยนจาก “ถามแล้วตอบ” เป็นระบบชนิดอื่น สิ่งที่เพิ่มมาคือจังหวะทบทวนก่อนส่งและตำแหน่งอ้างอิงที่ชัดขึ้นเมื่อผู้ใช้ต้องการแย้งข้อความบางส่วน

ติดตั้งให้ครบทั้งสกิลและหน้าทบทวน

/grill-me กับ Plannotator เป็นคนละส่วนกัน หากยังไม่มีสกิล ติดตั้งจากชุด skills ของ Matt Pocock:

npx skills@latest add mattpocock/skills --skill=grill-me

ติดตั้ง Plannotator บน macOS, Linux หรือ WSL ด้วยตัวติดตั้งหลัก:

curl -fsSL https://plannotator.ai/install.sh | bash

ตัวติดตั้งจะลง binary ตรวจหาเอเจนต์ที่มีอยู่ และตั้งค่า hooks, skills หรือ commands ที่เกี่ยวข้อง สำหรับ Codex เอกสารระบุว่า $plannotator-review, $plannotator-annotate และ $plannotator-last จะถูกติดตั้งมาด้วย ส่วน plan review ใช้ hook ของ Codex บน macOS, Linux และ WSL; บน Windows แบบ native การรองรับ hook ยังเป็น experimental และตัวติดตั้งจะแสดงขั้นตอนตั้งค่าเอง

ถ้าต้องการเพียง binary โดยไม่ลง skills, hooks, slash commands และค่าต่อเอเจนต์ ใช้โหมด minimal:

curl -fsSL https://plannotator.ai/install.sh | bash -s -- --minimal

แต่โหมดนี้ไม่ได้เตรียม workflow กับ coding agent ให้ครบ ผู้ใช้ต้องเชื่อมส่วนที่ต้องการเองภายหลัง

เมื่อไรควรหยุดถามแล้วลงมือทดลอง

Plannotator ช่วยจัดหน้าสำหรับทบทวน แต่ไม่ได้ทำให้ทุกคำถามเหมาะกับการตอบเป็นข้อความ /grill-me เหมาะเมื่อไอเดียมีน้ำหนักพอจะทำจริง แต่การตัดสินใจหลักยังไม่ชัด เช่น ผู้ใช้เป้าหมาย ขอบเขต หรือข้อแลกเปลี่ยนของผลิตภัณฑ์

ถ้าคำถามเริ่มแตะสิ่งที่ต้องเห็นหรือสัมผัสจริง เช่น ฟอร์มแบบไหนอ่านง่าย หรือ interaction แบบใดให้ความรู้สึกถูกต้อง ควรหยุด grilling แล้วทำ prototype ขนาดเล็กก่อน จากนั้นค่อยกลับมาตัดสินใจบนสิ่งที่ลองได้

อีกสัญญาณหนึ่งคือจำนวนคำถามพุ่งเป็นหลักร้อย นั่นมักบอกว่าโจทย์ใหญ่เกินหนึ่งเซสชัน ให้แยกงานเป็นชิ้นเล็กแล้วคุยทีละชิ้น หากยังไม่รู้คำตอบจริง ๆ ให้ตอบว่า “I don't know” แทนการเดา เพราะคำตอบที่ดูครบแต่ไม่มีฐานตัดสินใจไม่ได้ทำให้ requirement ชัดขึ้น

Local ไม่ได้แปลว่าทุกฟีเจอร์ออฟไลน์

Plannotator เป็นโอเพนซอร์สและทำหน้าทบทวนในเบราว์เซอร์บนเครื่อง เอกสารระบุว่าแผน diff, annotation, draft, history และ configuration ถูกเก็บในเครื่องเป็นค่าเริ่มต้น และแอป local ไม่มี telemetry

อย่างไรก็ตาม คำว่า local ไม่ควรถูกขยายเป็น “ข้อมูลไม่ออกจากเครื่องเลย” ฟีเจอร์ที่ต้องดึง URL, รีวิว GitHub หรือ GitLab, ใช้ Ask AI และ sharing อาจส่งข้อมูลไปยังผู้ให้บริการที่เกี่ยวข้อง การติดตั้งแบบเต็มเองก็อาจติดต่อบริการภายนอกเพื่อดาวน์โหลด release และส่วนประกอบเพิ่มเติม

ถ้าโจทย์มีข้อมูลอ่อนไหว ให้ตัดสินใจจากฟีเจอร์ที่จะใช้จริง ไม่ใช่จากป้าย local เพียงคำเดียว ผู้ใช้ปิดการแชร์ URL ได้ด้วย PLANNOTATOR_SHARE=disabled และปิด Ask AI, Review Agents และ Guided Review ได้ด้วย PLANNOTATOR_AI=disabled

สุดท้ายแล้ว Plannotator ไม่ได้มาแทน /grill-me มันเปลี่ยนพื้นที่ที่ผู้ใช้ใช้คิด จากสายข้อความยาวให้กลายเป็นรอบทบทวนที่เห็นสิ่งกำลังจะส่งครบกว่าเดิม ประโยชน์ที่ตรวจสอบได้จึงอยู่ที่วิธีโต้ตอบ: เลือก แก้ และชี้เฉพาะจุดก่อนส่ง ส่วนคุณภาพของการตัดสินใจยังขึ้นกับการคุม scope การยอมรับว่าอะไรยังไม่รู้ และการหยุดไปทำ prototype ในเวลาที่เหมาะสม

ที่มา: An interactive UI for the grill-me skill — Plannotator Blog, GitHub — backnotprop/plannotator, The /grill-me Skill — Matt Pocock และ Show HN: An interactive UI for the grill-me skill