บันทึกวิจัย
คู่มือลงและใช้ pstack ใน Claude Code ตั้งแต่พิมพ์คำสั่งแรก ไปจนถึงตั้งระบบที่ให้ agent ตรวจงานตัวเองได้ เรียบเรียงจากทอล์กและคู่มือของผู้สร้าง, ไลฟ์คุยกับ Matt Pocock, คลิปที่ Rob Shocks ลองใช้จริง และ repo ตัวพอร์ต
เผยแพร่ 5 ตุลาคม 2026 อัปเดตล่าสุด 8 ตุลาคม 2026
สไลด์แรกของทอล์กที่ Lauren Tan (ชื่อในเน็ตคือ poteto) ปล่อยบน X เมื่อ 21 กันยายน 2026 เขียนไว้สั้น ๆ ว่า i shipped 2000 PRs last month ส่วนตัวโพสต์ที่แปะคลิปเขียนว่า 2,500 สไลด์ถัดมาบอกว่าตลอดหกเดือนส่งไปแล้วกว่า 5,000 ตัว คำถามที่ทุกคนถามกลับคือแล้วใครรีวิว Lauren ตอบตลอดทั้งทอล์กด้วยคำเดียวคือความไว้ใจ (trust) และเครื่องมือที่ใช้สร้างความไว้ใจนั้นถูกรวมไว้เป็นชุด skill ชื่อ pstack
Lauren อยู่ในทีม React core เคยทำ React Compiler ที่ Meta และเคยอยู่ Netflix ต้นปี 2026 เข้า Cursor ไปช่วยทำ Agents Window ให้เร็วขึ้น หลังจากนั้น Cursor ถูกรวมเข้า SpaceX AI ตอนนี้ Lauren ทำ Grok Bot อยู่ที่นั่น (ข้อมูลตำแหน่งงานมาจากหน้าโปรไฟล์ที่ Rob Shocks เปิดให้ดูในคลิป และจากที่ Lauren เล่าเองในทอล์ก) ตัวต้นฉบับของ pstack เขียนให้ Cursor ใช้ มีคนชื่อ Michael Denyer พอร์ตมาให้ Claude Code, Codex และ Pi บทความนี้ใช้ตัวพอร์ตของ Claude Code เป็นหลัก
แกะคำศัพท์ก่อนเริ่ม
pstack อ่านว่า "พี-สแต็ก" ตัว p มาจาก poteto ส่วน stack แปลว่า "กอง" หรือ "ชุดที่ซ้อนกัน" รวมกันก็คือ "ชุดเครื่องมือของ poteto" ส่วน poteto ("โพเทโต") คือคำว่า potato ที่สะกดเพี้ยนโดยตั้งใจ สกิลหลักของชุดนี้เลยชื่อ poteto-mode หรือ "โหมดมันฝรั่ง" นั่นเอง
skill ("สกิล") ในโลกของ Claude Code คือไฟล์ Markdown ที่สอน agent ว่างานแบบนี้ให้ทำเป็นขั้นตอนอะไร พิมพ์ชื่อมันขึ้นต้นด้วย / เพื่อเรียกใช้ได้ ส่วน agent ("เอเจนต์") แปลตรงตัวว่า "ผู้ทำการแทน" ก็คือตัว AI ที่ลงมือแก้โค้ดให้เรา และ PR ย่อมาจาก pull request คือคำขอเอาโค้ดชุดหนึ่งเข้าไปรวมกับของจริง
ถ้าอ่านจบแล้วยังไม่อยากลงทั้งชุด สองส่วนที่ใช้ได้กับ agent ทุกตัวคือเรื่อง verification และกฎห้าชั้นตอนต้องแก้ agent ซึ่ง Lauren บอกว่าเป็นสไลด์เดียวที่อยากให้จำกลับไปครับ
เปิด repo ดูจะเจอโฟลเดอร์ skills/ ที่มีของอยู่ 57 โฟลเดอร์ อ่านชื่อแล้วงงได้ง่าย แต่จริง ๆ แบ่งเป็นสามกองเท่านั้น
how, why, architect, arena, unslop ใน Claude Code จะขึ้นเป็นคำสั่ง /pstack:ชื่อprinciple- เราไม่ได้เรียกมันเอง agent จะเปิดอ่านเองเมื่อสถานการณ์ตรงกับข้อนั้นpoteto-mode แต่ละเล่มคือขั้นตอนมาตรฐานของงานแต่ละแบบ ทั้งแก้บั๊ก ฟีเจอร์ใหม่ แอปช้า รีแฟกเตอร์ ดูแล PR ไปจนถึงงานยาวข้ามคืนplaybook อ่านว่า "เพลย์บุ๊ก" มาจากวงการอเมริกันฟุตบอล คือสมุดที่โค้ชจดแผนการเล่นไว้ทุกจังหวะ ในที่นี้ก็คือสมุดคู่มือว่าเจองานแบบนี้ให้เดินกี่ขั้น ขั้นละอะไร
สามกองนี้ทำงานต่อกันแบบนี้ครับ เราพิมพ์บอกเป้าหมายเป็นภาษาคน poteto-mode อ่านแล้วเลือก playbook ที่ตรงที่สุด playbook ก็ไล่เรียก skill ย่อยตามขั้น โดยมีหลักคิดคุมวิธีตัดสินใจอยู่ทุกขั้น
ขั้นที่ 1 · ติดตั้ง plugin
เปิด Claude Code ในโปรเจกต์ไหนก็ได้ แล้วพิมพ์สองบรรทัดนี้ บรรทัดแรกเพิ่มร้านค้า (marketplace) ของตัวพอร์ต บรรทัดที่สองลงตัว plugin
/plugin marketplace add michael-denyer/pstack-claude
/plugin install pstack@pstack-claudeขั้นที่ 2 · เลือกโมเดลให้แต่ละบทบาท
pstack ใช้หลายโมเดลพร้อมกันในบางงาน เช่นให้ Opus, Fable, Sonnet แข่งออกแบบกัน คำสั่งนี้จะถามว่าเรามีโมเดลไหนใช้ได้บ้าง อยากให้แต่ละบทบาทใช้ตัวไหน และใช้ความพยายามในการคิด (reasoning effort) ระดับไหน แล้วเขียนผลลงไฟล์ pstack-models.md
/pstack:setup-pstackไฟล์ที่ได้หน้าตาประมาณนี้ ตัวอย่างนี้ลดคนแข่งเหลือสองตัวเพื่อประหยัด token ค่าเริ่มต้นจริงคือสามตัว (opus, fable, sonnet)
# ~/.claude/pstack-models.md (setup-pstack เขียนไฟล์นี้ให้)
arena runners: opus, sonnet
interrogate reviewers: opus, sonnet
session hook: onขั้นที่ 3 · สั่งงานแรก
ขึ้นต้นด้วย /pstack:poteto-mode แล้วบอกสิ่งที่อยากได้ เท่านี้ครับ
/pstack:poteto-mode ฟิลเตอร์ค้นหาเด้งกลับเป็นค่าเริ่มต้นทุกครั้งที่กดเปลี่ยนหน้า ช่วยแก้ให้หน่อย
ถ้าจะใช้ playbook ที่เปิด PR หรือเฝ้า CI ให้ ต้องมี gh (GitHub CLI) ที่ login แล้ว และสคริปต์บางตัวต้องใช้ Bun ส่วน skill automate-me กับ reflect ที่ช่วยเขียน skill ใหม่ ต้องลง plugin plugin-dev ของ Anthropic เพิ่ม งานทั่วไปไม่ต้องใช้สามตัวนี้
plugin นี้ติดตั้ง hook ("ฮุก" แปลว่า "ตะขอ") ไว้ตัวหนึ่ง hook คือคำสั่งที่ Claude Code รันเองอัตโนมัติเมื่อเกิดเหตุการณ์บางอย่าง ตัวนี้เกาะอยู่ตอนเริ่ม session ใหม่ (และตอน resume, /clear, หรือหลังบีบอัดบริบท) มันแปะคำสั่งสั้น ๆ เข้าไปในหัวของ agent ว่า ถ้างานเข้าข่ายข้อใดข้อหนึ่งในสามข้อนี้ ให้เรียก poteto-mode เอง
ถ้ามันไม่เรียกเองตามที่คาด
คำสั่งที่เราพิมพ์เองใน CLAUDE.md หรือในแชตมีสิทธิ์เหนือ hook เสมอ ถ้างานไหนเราอยากได้ความเข้ม ก็พิมพ์ /pstack:poteto-mode นำหน้าเองได้เลย ถ้ารำคาญอยากปิดการเรียกอัตโนมัติ ให้รัน /pstack:setup-pstack แล้วปิด session hook หรือเขียนบรรทัด session hook: off ลงในไฟล์ pstack-models.md
เคล็ดลับของ poteto-mode คือ playbook แต่ละเล่มบังคับว่าต้องจบด้วยคำตอบแบบไหน งานแก้บั๊กต้องจบด้วยหลักฐานก่อนกับหลังแก้ งานแอปช้าต้องจบด้วยตัวเลขที่วัดได้ ข้างล่างนี้คือหกงานที่เจอบ่อยที่สุด กดเลือกดูได้ว่าควรพิมพ์ยังไง และ agent จะเดินกี่ขั้น
playbook ที่ได้ · Bug fix
พิมพ์ประมาณนี้
/pstack:poteto-mode ฟิลเตอร์ค้นหาเด้งกลับเป็นค่าเริ่มต้นทุกครั้งที่กดเปลี่ยนหน้า ช่วยหาสาเหตุแล้วแก้ ใช้ /verify ยืนยัน แนบภาพหน้าจอก่อนและหลังแก้มาด้วย
agent จะเดินแบบนี้
คำตอบสุดท้ายที่ต้องได้อะไรพัง สาเหตุจริงคืออะไร แก้ยังไง และหลักฐานทั้งก่อนแก้กับหลังแก้
playbook ที่ได้ · Feature
พิมพ์ประมาณนี้
/pstack:poteto-mode เพิ่มปุ่ม export รายการเป็น CSV ในหน้ารายงาน ใช้ /verify ยืนยันว่ากดแล้วได้ไฟล์ที่เปิดอ่านได้จริง แนบภาพหน้าจอเป็นหลักฐาน
agent จะเดินแบบนี้
คำตอบสุดท้ายที่ต้องได้สร้างอะไร เลือกทางไหนเพราะอะไร แผนแบ่งงาน และเรื่องที่ยังรอเราตัดสิน
playbook ที่ได้ · Perf issue
พิมพ์ประมาณนี้
/pstack:poteto-mode หน้าแรกโหลดช้า ใช้ /verify จับ trace สภาพตอนนี้ก่อน หาจุดที่ปรับได้ แก้แบบเจาะจุด แล้วใช้ /verify กับ /pstack:swarm วัดซ้ำหลายรอบให้แน่ใจว่าเร็วขึ้นจริง
agent จะเดินแบบนี้
คำตอบสุดท้ายที่ต้องได้ตัวเลขก่อนแก้ ตัวเลขหลังแก้ ส่วนต่าง และไฟล์ trace อยู่ที่ไหน
playbook ที่ได้ · Investigation
พิมพ์ประมาณนี้
/pstack:poteto-mode ระบบ login ของโปรเจกต์นี้ทำงานยังไง แล้วทำไมถึงเก็บ token ไว้สองที่
agent จะเดินแบบนี้
คำตอบสุดท้ายที่ต้องได้คำตอบพร้อมแหล่งที่มา และถ้าโจทย์ที่ถามตั้งอยู่บนความเข้าใจผิด มันจะแย้งกลับ
playbook ที่ได้ · Refactoring
พิมพ์ประมาณนี้
/pstack:poteto-mode แยกไฟล์ OrderService ที่ยาว 3,000 บรรทัดออกเป็นโมดูลย่อย พฤติกรรมต้องเหมือนเดิมทุกอย่าง
agent จะเดินแบบนี้
คำตอบสุดท้ายที่ต้องได้โครงสร้างที่เปลี่ยน หมุดที่ใช้ยึด หลักฐานว่าพฤติกรรมเท่าเดิม และอะไรถูก revert ไปบ้าง
playbook ที่ได้ · Prototype
พิมพ์ประมาณนี้
/pstack:poteto-mode ยังเลือกไม่ได้ว่าหน้า dashboard ควรเป็นการ์ดหรือตาราง ช่วยทำต้นแบบทิ้งได้สองแบบให้กดสลับดู
agent จะเดินแบบนี้
คำตอบสุดท้ายที่ต้องได้แต่ละแบบที่ลอง ภาพหลักฐาน ข้อดีข้อเสีย คำแนะนำ และบอกตรง ๆ ว่าโค้ดชุดนี้ทิ้งได้
สังเกตว่าทุก prompt ที่ต้องแก้โค้ดจะมีท่อน "ใช้ /verify ยืนยัน แนบหลักฐาน" ปิดท้าย ท่อนนี้คือส่วนที่สำคัญที่สุดของทั้งบทความ เดี๋ยวจะมีหัวข้อของมันเองครับ
ใน playbook แอปช้ามีรายการหนึ่งที่เอาไปใช้ได้ทันทีแม้ไม่ได้ใช้ pstack คือลำดับวิธีทำให้เร็วขึ้น เรียงจากถูกสุดไปแพงสุด แล้วหยุดทันทีที่ข้อไหนทำให้ถึงเป้า
agent ส่วนใหญ่กระโดดไปข้อเจ็ดก่อน คือเขียนอัลกอริทึมใหม่ทั้งที่ข้อหนึ่ง (เลิกคำนวณของที่ไม่มีใครใช้) อาจจบเรื่องได้ในสามบรรทัด
ปกติเราไม่ต้องเรียก skill พวกนี้เอง poteto-mode เรียกให้ แต่ถ้าเจตนาเราชัดอยู่แล้ว เรียกตรง ๆ ก็ได้ และรู้ชื่อไว้จะอ่าน log ของ agent ออกว่ามันกำลังทำอะไร
/pstack:how
อธิบายว่าระบบส่วนนี้ทำงานยังไง ระดับที่วิศวกรอาวุโสเล่าให้คนเพิ่งเข้าทีมฟัง งานใหญ่จะแตก subagent ไปสำรวจหลายมุมพร้อมกันแล้วค่อยรวม
/pstack:why
ขุดว่าทำไมโค้ดถึงเป็นทรงนี้ ไม่ได้ดูแค่โค้ด มันไล่ git blame, PR เก่า และ MCP ที่ต่อไว้ทั้งหมด (Slack, Linear, Sentry, Notion) แล้วบอกด้วยว่าข้อไหนรู้แน่ ข้อไหนแค่อนุมาน
/pstack:architect
ร่าง type, signature, โครงโมดูลก่อนเขียนโค้ดจริง บังคับให้มีอย่างน้อยสองแบบที่ต่างกันทั้งทรง ไม่ใช่แค่ปรับจุดเล็กในแบบเดียว ถ้าลงมือแล้วพบว่าร่างผิด ก็ทิ้งแล้วร่างใหม่
/pstack:arena
ให้หลายโมเดลทำโจทย์เดียวกันแยกกัน มีกรรมการต่างค่ายให้คะแนน เลือกตัวที่ดีที่สุดเป็นฐาน แล้วต่อกิ่งจุดเด่นของตัวที่แพ้เข้าไป
/pstack:swarm
แบ่งงานใหญ่เป็นชิ้น แจก worker คนละชิ้น แล้วรวมกลับเป็นรายงานเดียว เหมาะกับงานที่ต้องครอบคลุม เช่นตรวจทุกหน้าของแอป หรือวัดความเร็วซ้ำหลายสิบรอบ
/pstack:interrogate
ให้สามโมเดลรุมหาจุดพังของ diff ชุดเดียวกัน ทุกตัวได้ prompt เดียวกัน มุมมองที่ต่างมาจากตัวโมเดลเอง ผลที่ได้คือคำตัดสินรวม มันจะไม่แก้โค้ดให้เอง
/pstack:tdd
เขียนเทสต์ที่พังก่อน ดูให้แน่ว่าพังด้วยเหตุผลที่ถูก แล้วค่อยแก้ ถ้าการเขียนเทสต์จะแพงหรือเปราะเกินไป มันจะไม่ฝืนเขียน
/pstack:unslop
ล้างกลิ่น AI ออกจากข้อความ ตัดคำอย่าง delve, crucial, pivotal เลิกใช้ em dash ทั้งหมด และเลิกจับทุกอย่างเป็นกลุ่มละสาม ใช้ได้ทั้งเอกสาร คำอธิบาย PR และ commit
/pstack:bro
ให้ agent เล่าข้อความล่าสุดใหม่เป็นภาษาคนธรรมดา ไม่มีศัพท์เทคนิค Rob Shocks หยิบตัวนี้มาใช้ตอนเปิด agent หลายตัวมาทั้งเช้าจนหัวตื้อ
/pstack:recall
กลับมาทำงานต่อหลังหายไปหนึ่งสัปดาห์ มันอ่านแชตเก่าของเราในโปรเจกต์นี้ เช็กสถานะ PR กับ branch จริง แล้วสรุปว่างานค้างอยู่ตรงไหน ทำอะไรต่อ
/pstack:show-me-your-work
ให้ agent จดทุกการตัดสินใจลงไฟล์ตาราง ใช้ตอนปล่อยงานยาวข้ามคืน ตื่นมาจะไล่อ่านได้ว่ามันเลือกอะไรเพราะอะไร
/pstack:correct
หาความผิดที่ agent ทำซ้ำในโปรเจกต์ แล้วทำให้มันเกิดซ้ำไม่ได้อีก ไล่จากแก้โครงสร้างก่อน แล้ว type แล้ว lint แล้วเทสต์ เขียนเอกสารเป็นทางเลือกสุดท้าย
สองตัวนี้ปล่อย agent หลายตัวพร้อมกันเหมือนกัน เลยสับสนง่าย arena ให้ทุกตัวทำโจทย์เดียวกันทั้งชิ้นแล้วคัดตัวดีที่สุด swarm หั่นงานเป็นชิ้นแล้วให้แต่ละตัวทำคนละชิ้น
ในคลิปรีวิว Rob Shocks ลองใช้ pstack บน Cursor ด้วย prompt เดียว ให้สร้างแอป Mac ที่ดูได้ว่าลง skill อะไรไว้บ้าง ใช้บ่อยแค่ไหน และลบหรือจัดการได้ บนจอเห็นว่ามันเดินแบบนี้
figure-it-out ซึ่งเป็นคู่มือสำหรับงานที่ไม่มีเล่มไหนตรง แล้วเขียนไฟล์ grounding.md สรุปสิ่งที่รู้ก่อนเริ่มtdd สร้างชุด unit test ให้ผ่านก่อนไปต่อdecisions.tsv 60 แถว พร้อมเวลา ขั้น และหลักฐานของแต่ละข้อRob เล่าว่าในขั้นตรวจสอบ agent จับได้ว่าตัวเองเคลมไว้สามเรื่องที่ไม่จริง แล้วแก้กลับเอง และตาราง decision มีหัวข้อหนึ่งชื่อ "design changes forced by reality" คือจุดที่แผนเดิมพังเมื่อเจอของจริง Rob มองว่านี่คือเหตุผลที่ pstack ไม่เชื่อในการวางแผนละเอียดล่วงหน้า
ในทอล์ก Lauren แจกทางสร้างความไว้ใจ agent ไว้สามทาง คือ verification เพื่อยืนยันว่าทำงานถูก, skill คุณภาพดีที่สอน agent ให้ทำงานแบบวิศวกรจริง (ยก pstack เป็นตัวอย่าง) และการรื้อสถาปัตยกรรมให้ agent ทำงานด้วยง่าย ทางแรกคือทางที่ Lauren เริ่มก่อนและพูดถึงมากที่สุด คู่มือตอนแรกของ Lauren ใช้หัวข้อว่า Verification is all you need และในไลฟ์ก็ย้ำว่ามันกลายเป็นโครงสร้างพื้นฐาน (infrastructure) ที่ทั้งทีมใช้
verification อ่านว่า "เวริฟิเคชัน" แปลว่า "การพิสูจน์ยืนยัน" มาจากภาษาละติน verus ที่แปลว่า "จริง" ในความหมายของ pstack คือ agent ตรวจงานตัวเองได้ด้วยการเปิดแอปขึ้นมาจริง กดใช้แบบผู้ใช้ จับภาพหน้าจอ อ่าน log แล้วตัดสินเองว่าผ่านหรือยัง poteto เปรียบว่าคือการให้ มือกับตา แก่ agent
ก่อนมีมัน Lauren เล่าว่าตอนทำ Agents Window ของ Cursor ให้เร็วขึ้น ต้องนั่งเปิด Chrome DevTools จับ performance trace และ heap snapshot เองทุกครั้ง ขณะที่ PR จากทีมไหลเข้ามาไม่หยุด และไม่มีทางรู้เลยว่าตัวไหนทำแอปช้าลง ในไลฟ์ Lauren เรียกตัวเองตอนนั้นว่า meat proxy แปลตรง ๆ ว่า "ตัวกลางที่เป็นเนื้อหนัง" (proxy อ่านว่า "พร็อกซี" แปลว่า "ตัวแทน") คือคอยยกผลจากเครื่องมือไปเล่าให้ agent ฟัง skill ตัวแรกที่ Lauren สร้างที่ Cursor จึงเป็น verification skill ชื่อ Control Glass ที่สอน agent เปิดแอปและจับ trace เองผ่าน Chrome DevTools Protocol
Lauren บอกว่า verification มีหลายระดับ ปลายง่ายคือ skill แบบที่บทความนี้สอน ปลายยากคือการพิสูจน์ทางคณิตศาสตร์ (formal verification) ด้วยภาษาอย่าง Lean หรือ TLA+ ว่าโปรแกรมอยู่ในสถานะที่ถูกเสมอ ซึ่งน้อยคนทำได้ แต่แค่ระดับ skill ก็ไปได้ไกลมากแล้ว อีกเรื่องที่ควรแยกให้ออกคือ verification ตอบแค่ว่าทำงานถูกไหม (ปุ่ม checkout กดแล้วจ่ายเงินได้จริงไหม) ไม่ได้บอกว่าโค้ดดีหรือเร็ว ส่วนนั้นเป็นหน้าที่ของ skill ที่สอนวิธีทำงาน
สไลด์ที่ Lauren ใช้อธิบาย verification skill ที่ดี มีของสองชิ้นมาประกอบกัน
pstack ไม่ได้ให้ verification skill สำเร็จรูป เพราะแต่ละแอปขับไม่เหมือนกัน เว็บต้องขับผ่าน browser แอป CLI ต้องขับผ่าน terminal มันจึงให้ skill ที่ สร้าง verification skill ให้แทน รันครั้งเดียวในโปรเจกต์ของเรา
/pstack:create-verification-skill
ตัวพอร์ตของ Claude Code จะเขียนผลไว้ที่ .claude/skills/verify/ และตั้งชื่อว่า verify ทับคำสั่ง /verify ที่ติดมากับ Claude Code (ตัวเดิมเรียกได้แค่คนพิมพ์ ตัวนี้ agent เรียกเองได้) ทุก playbook ที่บอกว่า "ตรวจบนของจริง" จะมาเรียกตัวนี้
ห้าหัวข้อใน SKILL.md คือสิ่งที่ agent ทุกตัวต้องรู้ก่อนขับแอปของเรา
ขั้นที่ 4 ในภาพสำคัญกว่าที่คิด skill ที่ยังไม่เคยถูกรันจริงสักรอบ ตัวสร้างนับว่าเป็นแค่ฉบับร่าง มันต้องเปิดแอป เช็ก ขับหนึ่งฟีเจอร์ เก็บหลักฐาน เก็บกวาด แล้วเช็กว่าหลักฐานยังอยู่ ครบหนึ่งรอบก่อนจะส่งให้เรา
ตอนแรกที่ยังไม่มี CLI poteto สังเกตว่า agent แต่ละตัวพยายามตรวจงานตัวเองด้วยการเขียนสคริปต์ขึ้นมาใหม่ทุกรอบ ตัวที่แล้วเขียนได้ผลแต่ทิ้งไป ตัวถัดมาเขียนใหม่ด้วยวิธีอื่น เปลืองทั้ง token และเวลา ทางแก้คือเอาส่วนที่เป็นกลไกตายตัวไปอัดไว้ในเครื่องมือตัวเดียว แล้วเหลือแค่ส่วนที่ต้องใช้วิจารณญาณให้ agent ตัดสิน
ตัวอย่าง CLI ที่ poteto ยกไว้ในคู่มือ เป็นแอป Electron สมมติ (ผมเปลี่ยน path ให้ตรงกับตัวพอร์ตของ Claude Code)
# เช็กก่อนว่าแอปที่รันอยู่พร้อมให้ขับไหม
node .claude/skills/verify/control-app.mjs doctor
# เปิดหน้าใหม่ แล้วพิมพ์คำสั่งลงช่องค้นหา
node .claude/skills/verify/control-app.mjs new-session
node .claude/skills/verify/control-app.mjs type "#search" "รายงานเดือนกันยา"
# กดคีย์ลัด แล้วรอให้หน้าจอนิ่ง
node .claude/skills/verify/control-app.mjs press "Meta+KeyK"
node .claude/skills/verify/control-app.mjs wait-settle
# ดึงโครงหน้าจอแบบที่ screen reader เห็น (อ่านง่ายกว่าภาพสำหรับ agent)
node .claude/skills/verify/control-app.mjs snapshot
# เก็บภาพไว้เป็นหลักฐาน
node .claude/skills/verify/control-app.mjs screenshot proof/after.pngคำสั่งในตัวอย่างของ poteto ครอบคลุมหกหมวด คือดูสภาพ (snapshot, screenshot) เดินไปหน้าต่าง ๆ (home, scroll) กดและพิมพ์ (click, type, press) วัดความเร็ว (trace, profile) ดู log ที่ไหลออกมา (console, network-log) และดูแลสุขภาพ (doctor, cleanup) ส่วนลักษณะของ CLI ที่ agent ใช้ง่าย poteto ให้ไว้หกข้อ
--dry-run--help อธิบายละเอียดที่มาของมันเล่าไว้ในทอล์ก ทีม Cursor เริ่มใช้ skill ตัวนี้แล้วเจอว่า เวลามีรายงานบั๊กเข้ามาทาง Slack ผู้ใช้มักแปะภาพหน้าจอเสี้ยวเดียวกับเครื่องหมายคำถามสามตัว agent เปิดแอปได้ก็จริง แต่เดาไม่ออกว่าผู้ใช้หมายถึงตรงไหน Lauren จึงทำ แผนที่ฟีเจอร์ (feature map) โดยได้ไอเดียจากแผนผังเว็บไซต์ (sitemap) เป็นไฟล์ Markdown หนึ่งไฟล์ต่อหนึ่งฟีเจอร์ บอกจากมุมผู้ใช้ว่ามันคืออะไร ไปถึงยังไง ขับด้วย CLI ยังไง และมีกับดักอะไร หน้าตาประมาณนี้
# Preferences
หน้าต่างตั้งค่าแบบเต็มจอ กับแท็บย่อยทั้งหมด
## Sub-features
- settings-overlay: เปิดจากรูปเฟือง หรือกด Cmd/Ctrl+,
- settings-nav: แท็บด้านซ้าย (General, Appearance, Models, ...)
- theme-picker: ตัวเลือกธีมในแท็บ Appearance
## How to get to it (user POV)
คลิกรูปเฟืองข้างรูปโปรไฟล์ หรือกด Cmd/Ctrl+, แล้วเลือกแท็บด้านซ้าย
กด Escape เพื่อปิด
## Driving it with control-app
node .claude/skills/verify/control-app.mjs press "Meta+Comma"
node .claude/skills/verify/control-app.mjs snapshot
node .claude/skills/verify/control-app.mjs press "Escape"
## Gotchas
- ปิดหน้าตั้งค่ากลางคันแล้ว focus อาจหลุด สั่ง new-session เพื่อกู้
- บางแท็บเห็นเฉพาะบางบัญชี ถ้าข้ามต้องบอกเหตุผลpoteto เรียกมันว่า "ความจำที่แข็งตัวแล้ว" (materialized memory) และมองว่าตัวโค้ดเองคือความจำที่ดีที่สุดของทีมอยู่แล้ว แผนที่ฟีเจอร์เป็นแค่ฉบับย่อที่ประหยัด token กว่า และเพราะมันอยู่ใน repo ทุกคนที่ทำงานกับโค้ดนี้ได้ใช้ร่วมกัน
แผนที่ที่ไม่ตรงกับแอปจริงอันตรายกว่าไม่มีแผนที่ poteto จึงแนะนำให้รัน /pstack:maintain-verification-skill อย่างน้อยวันละครั้ง ใน Claude Code ตั้งเป็นงานตามเวลาได้ด้วย /schedule หรือ /loop
ทุกเช้า 9 โมง ให้รัน /pstack:maintain-verification-skill
แล้วเปิด PR ถ้าแผนที่ฟีเจอร์ไม่ตรงกับแอปจริง
พอมี /verify แล้ว ทุก prompt ที่สั่งงานแก้โค้ดให้ปิดท้ายด้วยการขอหลักฐาน ตามรูปแบบที่ poteto ใช้เอง
/pstack:poteto-mode เพิ่มปุ่ม export รายการเป็น CSV ในหน้ารายงาน
ใช้ /verify ยืนยันว่ากดแล้วได้ไฟล์ที่เปิดอ่านได้จริง แนบภาพหน้าจอเป็นหลักฐาน
ตัวที่เข้าคู่กับ /verify ได้ดีที่สุดคือ /pstack:swarm เพราะมันแตก agent หลายตัวไปรัน /verify พร้อมกันได้ เช่นวัดความเร็วซ้ำหลายสิบรอบให้ตัวเลขเชื่อได้ หรือให้แต่ละตัวไปกดเล่นแอปคนละมุม (fuzz) หาว่ามีอะไรพังตามมาไหม
ใน 24 ข้อ มีหลายข้อที่ใช้ได้กับ agent ทุกตัว แค่เขียนลง CLAUDE.md ของโปรเจกต์ก็ได้ผลแล้ว ข้างล่างนี้คือข้อที่ทั้ง poteto และ Rob Shocks พูดถึงบ่อยที่สุด
Laziness Protocol ขี้เกียจอย่างมีหลัก
เอียงไปทางลบโค้ดเสมอ เลือกการแก้ที่เล็กที่สุดที่แก้ปัญหาได้ อยากเพิ่ม layer หรือ abstraction ให้หยุดคิดก่อน
Build the Lever สร้างคานงัด
งานที่จะทำมือซ้ำหลายรอบ ให้สร้างเครื่องมือ (สคริปต์, codemod, CLI) มาทำแทน เครื่องมือนั้นยังเป็นสิ่งที่คนรีวิวเอาไปรันซ้ำเพื่อตรวจได้ด้วย
Prove It Works พิสูจน์ให้เห็น
คอมไพล์ผ่านหรือเทสต์เขียวไม่นับว่าเสร็จ ต้องเห็นกับของจริงว่ามันทำงาน
Fix Root Causes แก้ที่ราก
ทำให้เกิดซ้ำก่อน แล้วถามว่าทำไมไปเรื่อย ๆ จนถึงต้นเหตุ ของที่ใส่เผื่อ "อาจจะช่วย" ถือเป็นสมมติฐาน ห้าม ship
Redesign from First Principles ออกแบบใหม่เหมือนมีมาตั้งแต่วันแรก
เจอ requirement ใหม่ อย่าเอาไปแปะต่อท้าย ให้ถามว่าถ้ารู้ตั้งแต่วันแรก โครงสร้างจะหน้าตาแบบไหน แล้วย้ายไปทางนั้น
Minimize Reader Load ลดภาระคนอ่าน
นับชั้นที่คนอ่านต้องไล่ ยุบ wrapper ที่มีคนเรียกแค่ที่เดียว ลดขอบเขตของตัวแปรที่เปลี่ยนค่าได้
Guard the Context Window ถนอมหน้าต่างบริบท
ของก้อนใหญ่ (ไฟล์ยาว, log ยาว) ส่งให้ subagent ไปอ่าน แล้วรับกลับมาแค่ข้อสรุป แชตหลักต้องสะอาดไว้ตัดสินใจ
Never Block on the Human อย่านั่งรอคน
งานที่ย้อนกลับได้ ไม่ต้องถาม "ทำ X ดีไหม" ให้ทำแล้วโชว์ผล ให้คนเป็นฝ่ายปรับทิศ ส่วนคำถามที่ตอบได้ด้วยการลองรัน ให้ลองรันแทนการถาม
Encode Lessons in Structure ฝังบทเรียนลงโครงสร้าง
เจอตัวเองเขียนคำสั่งเดิมเป็นรอบที่สอง ให้เปลี่ยนเป็น lint, runtime check หรือสคริปต์แทนการเขียนข้อความเพิ่ม
Lauren ปิดทอล์กด้วยสไลด์ที่บอกว่าถ้าจำได้อย่างเดียวให้จำอันนี้ ทุกครั้งที่เราต้องเข้าไปแก้ agent ให้ถามว่าจะย้ายบทเรียนนั้นไปไว้ชั้นไหน แล้วเลือกชั้นที่อยู่สูงที่สุดที่ทำได้
ชั้นบนสุดคือตัวโค้ดเบสเอง Lauren เรียกมันว่าความจำที่ดีที่สุดของ agent เพราะ agent ชอบต่อยอดแพตเทิร์นที่เห็นอยู่ในไฟล์ที่มันเปิด ถ้าโครงสร้างดี มันก็ต่อยอดของดี ชั้นที่สองคือ lint, compiler และ CI ซึ่งพังทันทีเมื่อผิด ชั้นสามกับสี่คือกฎกับ skill ซึ่งช่วยได้มาก แต่ agent อาจลืมอ่าน หรือคนที่สั่ง agent อาจสั่งข้าม ชั้นสุดท้ายคือ style guide ที่ต้องรอคนรีวิวจำได้ ซึ่งในวันที่ PR เข้ามาวันละหลายร้อยตัว ไม่มีใครตามไหว Lauren แนะนำให้ใช้รีวิวของคนเป็นแค่จุดเริ่มต้นสำหรับหาว่ายังขาดอะไร แล้วย้ายบทเรียนขึ้นไปชั้นบน
ด้านกลับของ "โค้ดเบสคือความจำ" ก็จริงเหมือนกัน ถ้ามีทางเลี่ยง (workaround) อยู่จุดเดียว หรือมีคอมเมนต์อธิบายทางเลี่ยงไว้ agent ตัวถัดไปจะลอกมันไปใช้ ภายในไม่กี่วันหรือไม่กี่สัปดาห์ ทางเลี่ยงนั้นจะกลายเป็นแพตเทิร์นประจำของทั้งโค้ดเบส
ตัวอย่างที่ Lauren ยกคือคอมเมนต์ในโค้ด ตอนแรกดูไม่มีพิษภัย เพราะคนเองก็เขียนคอมเมนต์อธิบายเคสพิเศษกันมาตลอด แต่ในโค้ดเบสของ Cursor ทีมเห็นว่า agent เอาคอมเมนต์รอบ ๆ โค้ดมาเป็นข้ออ้างว่าทำไมไม่แก้ปัญหาจริง แล้วแปะพลาสเตอร์ปิดไว้แทน ใน Dune ซึ่งเป็นเฟรมเวิร์กที่ทีมสร้างขึ้นมารัน Grok Bot จึงห้ามเขียนคอมเมนต์ไปเลย Lauren เรียกบทบาทนี้ว่า คนทำสวน (gardener) คือคนที่คอยถอนวัชพืชก่อนมันลาม และให้หลักไว้สามข้อเรียงกัน
Lauren ยอมรับว่าโค้ดเบสแบบนี้น่ารำคาญสำหรับคนเขียน เพราะล็อกไว้แน่นมาก แต่เหมาะกับ agent ที่มีบริบทน้อย และกับคนที่ไม่ใช่วิศวกรที่เริ่มเข้ามาแก้โค้ดเอง เช่นดีไซเนอร์หรือ product manager เป้าหมายคือให้โค้ดเบสอยู่ในสภาพที่เราจะยินดี ถ้า agent ตัวไหนจะลอกมันไปทั้งหมด ในไลฟ์ Lauren เล่าเพิ่มว่า Grok Bot เวอร์ชันแรก ๆ มีไฟล์ยักษ์ราวแปดไฟล์ ไฟล์ละหลักหมื่นบรรทัด โฟลเดอร์ต่อฟีเจอร์คือสิ่งที่เกิดขึ้นหลังจากแตกไฟล์พวกนั้นออก
กราฟที่ Lauren วาดในทอล์กมีแกนตั้งเป็นความไว้ใจ แกนนอนเป็นจำนวน agent ที่ทำงานพร้อมกัน จาก 1 ตัว ไปถึงหลักร้อยและหลักพัน ช่วงที่ Lauren บอกว่าหลุดออกมายากที่สุดคือช่วง 1 ถึง 5 ตัว ที่ต้องเฝ้าทุกแชตและคอยแก้ตลอด เหตุผลที่ไปต่อไม่ได้คือยังไม่ไว้ใจงานของ agent ถ้าฝืนเปิด subagent ร้อยตัวตอนนั้น ผลที่ได้คือ PR คุณภาพต่ำกับบั๊กเต็มไปหมด
poteto ไม่ชอบคำว่า "โรงงานผลิตซอฟต์แวร์" (software factory) ในสไลด์ถึงกับขีดฆ่าคำนี้ทิ้ง เพราะคำว่าโรงงานไม่ได้ชวนให้นึกถึงฝีมือ เลยใช้ภาพ ครัวร้านมิชลิน แทน ในไลฟ์กับ Matt Pocock Lauren เล่าการไต่กราฟนี้ด้วยภาพครัวเป็นช่วง ๆ
งานส่วนใหญ่ของ poteto ไม่ได้เริ่มจากการที่ตัวเองพิมพ์สั่ง มันเริ่มจากสองวงที่ต่อกัน วงใน (inner loop) คือ agent ที่ลงมือเขียนและตรวจโค้ด วงนอก (outer loop) คือช่องทางที่ข้อมูลใหม่ไหลเข้ามา เช่นรายงานบั๊กใน Slack, Linear, X หรืออีเมล ถ้าไม่ต่อสองวงนี้เข้าหากัน เราก็ต้องเป็นคนกลางที่คอยยกข้อมูลจากวงนอกไปป้อนวงในเอง ในทอล์ก Lauren ใช้ Grok Bot เป็นวงนอก ต่อเข้ากับ Slack, Datadog, Sentry และ PlanetScale ตั้ง routine ให้ฟังเธรด Slack หรือแจ้งเตือนจาก Sentry แล้วปล่อย cloud agent ไปทำงานเอง ภาพหน้าจอที่โชว์คือบอตที่ทำบั๊กจากรายงานผู้ใช้ให้เกิดซ้ำ แล้วเปิด PR ให้อัตโนมัติ Lauren บอกว่าไม่ต้องสร้างระบบ "company brain" อะไรซับซ้อน แค่ต่อเครื่องมือให้ agent ใช้ก็พอ เพราะ agent ใช้เครื่องมือเก่งอยู่แล้ว
รายละเอียดที่ทำให้ระบบนี้ไม่เละมีสามจุด
poteto เตือนเองว่าขั้นนี้ไปถึงยาก
ในไลฟ์ poteto บอกตรง ๆ ว่าไม่อยากให้ใครเข้าใจว่าลง pstack แล้วจะไปถึงขั้น agent merge เองได้ทันที ต้องใช้เวลาและความตั้งใจมากในการนั่งดูว่า agent พลาดตรงไหนแล้ววางราวกั้นทีละอัน และงานบางประเภทที่ตรวจด้วยโปรแกรมได้ยาก หรือผิดแล้วย้อนกลับไม่ได้ (เช่นงานที่ทำข้อมูลหายถาวร) poteto ก็ยอมรับว่ายังไม่มีคำตอบที่ดี
ช่วงท้ายของไลฟ์ Matt Pocock ถามว่าควรใช้ pstack คู่กับ skill ชุดอื่นยังไง poteto ตอบว่าเชฟทุกคนพกมีดชุดของตัวเองไปทุกร้าน ทางที่ดีที่สุดคือให้ agent อ่านแชตเก่าของเรา หาจุดที่เราต้องเข้าไปแก้ไขมันซ้ำ ๆ แล้วเปลี่ยนจุดเหล่านั้นเป็น lint หรือ skill ใหม่ เพราะแชตเก่าคือขั้นตอนการทำงานที่เกิดขึ้นจริงแล้ว pstack มี skill ทำเรื่องนี้ให้โดยตรง
/pstack:automate-me
ส่วน /pstack:reflect ใช้หลังจบงานยาว เพื่อเก็บบทเรียนของงานนั้นเป็นการแก้ skill และ /pstack:correct ใช้เมื่อเห็นความผิดซ้ำในโปรเจกต์ เพื่อเปลี่ยนมันเป็นสิ่งที่ระบบบังคับ
Rob Shocks สร้างแอปตัวเดียวกับในหัวข้อก่อนหน้าอีกรอบ คราวนี้ใช้ Fable 5.1 เปล่า ๆ ไม่มี plan mode ไม่มี skill ใช้เวลาราว 30 นาที รอบที่ใช้ pstack ใช้ราว 1 ชั่วโมง หรือนานกว่าสองเท่า Rob บอกว่าผลต่างกันมาก ตัวที่ได้จาก pstack แข็งแรงกว่า แต่ในคลิปไม่ได้โชว์ตัวเลขเทียบของสองรอบให้ดู (นี่คือการทดลองครั้งเดียวของคนคนเดียว ใช้เป็นภาพคร่าว ๆ ได้เท่านั้น)
เวลาที่ Rob Shocks ใช้สร้างแอปเดียวกันในวิดีโอรีวิว (ทดลองครั้งเดียว)
ตัวที่เผา token หนักที่สุดคือ skill ที่ปล่อยหลายโมเดลพร้อมกัน ได้แก่ arena, architect (ข้างในเรียก arena) และ interrogate ซึ่งค่าเริ่มต้นใช้สามโมเดลต่อรอบ ถ้างบจำกัด ให้เข้า /pstack:setup-pstack แล้วลดรายชื่อในบทบาทพวกนี้ลงเหลือสองตัว หรือเหลือตัวเดียวก็ได้
งานที่ไม่ต้องโยนมันฝรั่งใส่
แก้ไฟล์เดียวที่รู้อยู่แล้วว่าต้องแก้อะไร ปรับสี ขยับ margin หรือถามคำถามสั้น ๆ ทำตรง ๆ ได้เลย ตัว hook เองก็ออกแบบมาให้ข้ามงานพวกนี้อยู่แล้ว Rob สรุปไว้ว่าถ้าเป็นการปรับดีไซน์เล็ก ๆ หรืองานหน้าบ้าน (UI) ทั่วไป ส่วนใหญ่ไม่จำเป็นต้องใช้ pstack ความเข้มของมันคุ้มกับงานที่ผิดแล้วแพง เช่นบั๊กที่ยังไม่รู้สาเหตุ งานที่แตะหลายระบบ หรืองานที่จะปล่อยให้ agent ทำข้ามคืน
อีกเรื่องที่ควรรู้ก่อนลงคือ pstack ไม่มี skill สำหรับวางแผนหรือเขียน spec ยาว ๆ ก่อนเริ่มงาน Rob เล่าว่าเป็นความตั้งใจของ poteto ที่มองว่า spec ที่ดีที่สุดคือตัวโค้ด และแผนที่ละเอียดก่อนเจอของจริงมักพังเมื่อเริ่มลงมือ มันจึงเหมาะกับโค้ดเบสที่มีอยู่แล้ว มากกว่าการเริ่มโปรเจกต์ใหม่จากกระดาษเปล่า ถ้าอยากได้ขั้นวางแผน ใช้ skill ชุดอื่นคู่กันได้
/pstack:setup-pstack ถ้างบจำกัดให้ลดรายชื่อโมเดลใน arena กับ interrogate ลง/pstack:create-verification-skill ในโปรเจกต์หลักที่ทำอยู่ แล้วนั่งดูให้มันลองรันเองจนจบหนึ่งรอบ.claude/skills/verify/features/ อ่านแผนที่ฟีเจอร์ที่มันเขียน แก้ส่วนที่ผิด ส่วนนี้คือที่ที่ความรู้ของเราช่วยได้มากที่สุด/pstack:poteto-mode นำ แล้วปิดท้ายด้วย "ใช้ /verify ยืนยัน แนบหลักฐาน"/schedule ให้รัน /pstack:maintain-verification-skill ทุกวัน/pstack:automate-me ให้มันอ่านแชตของเรา แล้วร่าง skill ประจำตัวที่เป็นสไตล์ของเราเองขั้นที่สอง สาม และหก คือการลับมีดที่ Lauren พูดถึง ถ้าทำแค่สามขั้นนี้ให้ดี แม้ไม่เคยเรียก arena หรือ swarm เลย ก็ได้ส่วนที่คุ้มที่สุดของ pstack ไปแล้วครับ