รีวิว pstack ของ Cursor: 51 skill ที่มีหัวหน้างานในตัว แต่เราหยิบแค่ 5 ชิ้น

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

pstack ก็เป็นหนึ่งในนั้น เป็นปลั๊กอินของ Cursor ที่ Lauren Tan (คนในวงการรู้จักในชื่อ poteto) เขียนและแจกแบบ MIT มี 51 skill อ่าน README จบแล้วอยากได้ทุกตัว

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

เราคือ Productize บล็อกที่คุณอ่านอยู่ ใช้ Claude Code กับ AI agent ทำงานจริงทุกวัน และมีระบบคุมงานของตัวเองอยู่แล้ว ระบบนี้พางานทุกชิ้นผ่านขั้นวางแผน ลงมือ และตรวจ แต่ละขั้นใช้โมเดลที่กำหนดไว้ ผลตรวจใช้ได้กับ commit ตัวที่ตรวจเท่านั้น และต้องมีคนกดอนุมัติก่อนรวมโค้ด Productize อ่าน pstack ของ Cursor ครบทั้ง 51 skill แล้วหยิบมา 5 ชิ้น กรณีของเราอาจไม่เหมือนของคุณ แต่วิธีคิดตอนเลือกน่าจะใช้ได้กับทุกคนที่มีวิธีทำงานของตัวเองอยู่แล้ว

ช่วงที่ 1pstack คืออะไร ต่างจาก mattpocock กับ 9arm ยังไง

เปิด pstack รุ่น 0.15.15 ครั้งแรก เราเจอ skill 51 ตัว แบ่งเป็น 2 กอง 24 ตัวชื่อขึ้นต้นด้วย principle- เป็นหลักคิดสั้นๆ ตัวละเรื่อง เช่น แก้ที่ต้นเหตุไม่ใช่ที่อาการ อีก 27 ตัวลงมือทำงาน อธิบายโค้ด หาผลกระทบ จดบันทึกการตัดสินใจ ตัวที่ทำให้เราสะดุดคือ poteto-mode ซึ่งเป็น orchestrator พอได้งานมาก็หยิบสูตรจาก playbook 23 แบบ (แก้บั๊ก ทำฟีเจอร์ ส่ง PR ปล่อยวิ่งทั้งคืน ฯลฯ) ที่อยู่ในตัวมันเอง ไม่ใช่ skill แยก แล้วให้แชตหลักแจกงานต่อให้ subagent ถึงตรงนี้ก็ชัดว่า pstack คือวิธีทำงานทั้งระบบของ Lauren Tan

ในตาราง "โมเดลหยิบเอง" แปลว่า AI เลือกเรียก skill เองเมื่อเห็นว่าเข้ากับงานที่สั่ง ส่วน "ต้องเรียกด้วย slash" แปลว่าคุณต้องพิมพ์ /ชื่อ skill เอง mattpocock กับ 9arm ยื่นเครื่องมือให้ แล้วปล่อยให้เราตัดสินใจเอง pstack ยื่นทั้งเครื่องมือและคนตัดสินใจมาด้วย

ช่วงที่ 24 คำถาม ที่เราใช้คัด

ก่อนดูทีละ skill เราตั้งคำถามไว้ 4 ข้อ ชิ้นไหนผ่านเกือบหมดถึงได้ไปต่อ

1. มันจะมาแย่งงานตัดสินใจไหม ถ้ามีระบบที่ตัดสินอยู่แล้วว่างานไหนไปทางไหน ใครตรวจ ใครกด merge ชิ้นที่ตัดสินเรื่องเดียวกันจะชนกันเอง
2. มีโค้ดที่รันได้ไหม และมีกฎที่บอกว่าผลของมันแปลว่าอะไรหรือเปล่า อธิบายต่อด้านล่าง
3. มันอุดช่องว่างที่มีอยู่จริงไหม 2 ตัวที่ทำเรื่องเดียวกันจะค่อยๆ เพี้ยนออกจากกัน
4. ย้ายมาใช้กับเครื่องมือของเราได้คุ้มไหม pstack เขียนมาเพื่อ Cursor

ข้อ 2 มีอยู่ 2 ส่วน กฎที่เป็นข้อความล้วน ไม่มีอะไรรันอยู่ข้างหลัง ทำงานได้ก็ต่อเมื่อ AI นึกออกในจังหวะที่ต้องใช้ ใช้ไปนานๆ กฎแบบนี้จะค่อยๆ กลายเป็น "หวังว่ามันจะนึกออก" ส่วนโค้ดที่รันได้เช็กทุกครั้งที่ถูกเรียก แต่สิ่งที่ได้มีแค่สัญญาณ ยกตัวอย่าง watch-pr บอกว่า PR นี้ READY คือพร้อม merge แต่คำว่าพร้อมครอบคลุมอะไรบ้าง เป็นกฎอีกข้อ ช่วงที่ 6 เล่าว่าในงานของเรามันครอบคลุมแค่ไหน

ใน pstack คำสัญญาที่ฟังหนักแน่นที่สุด เช่น "ไม่มีอะไรได้ merge ถ้าทีมตรวจยังไม่ให้ผ่าน" ไม่มีโค้ดตัวไหนคอยกันไว้ เป็นแค่ข้อความที่หวังว่าแชตหลักจะทำตามทุกครั้ง ทั้งปลั๊กอินมีโค้ดที่รันได้จริงอยู่ไม่กี่ชิ้น และแต่ละชิ้นทำงานอื่น watch-pr เฝ้า PR, log.sh ใน show-me-your-work เพิ่มแถวในบันทึก, orch จำสถานะของงาน, check-plan.mjs ตรวจแผน และ worktree-audit.sh เก็บกวาด worktree ไม่มีชิ้นไหนห้าม merge ในนี้มีแค่ 2 ชิ้นที่ใช้ได้โดยไม่ต้องมีตัวคุมงาน คือ watch-pr โปรแกรมบรรทัดคำสั่งที่เฝ้า PR ผ่าน gh (คำสั่งของ GitHub) กับ log.sh สคริปต์เขียนบันทึกการตัดสินใจของ show-me-your-work อีก 3 ชิ้น (orch, check-plan.mjs, worktree-audit.sh) เป็นชิ้นส่วนของตัวคุมงาน ถอดออกมาเดี่ยวๆ ก็ไม่มีงานให้ทำ

2 ชิ้นนี้คือชิ้นที่เราหยิบมา ใน 5 ชิ้นของเราจึงมีโค้ดอยู่ 2 ชิ้น (watch-pr กับ show-me-your-work ที่มี log.sh อยู่ข้างใน) อีก 3 ชิ้นเป็นข้อความที่เราตัดขอบเขตใหม่ บทเรียนคือ หยิบโค้ดพร้อมกฎที่อ่านผลของมัน ถ้ากฎนั้นค้างอยู่ใน pstack ก็เอามาด้วยหรือเขียนเอง และถ้าจะหยิบข้อความ ให้บีบจังหวะที่มันจะถูกเรียกให้แคบ จนไปแย่งงานจากของที่มีอยู่แล้วไม่ได้ ช่วงที่ 5 เล่าว่าเราบีบยังไง

ช่วงที่ 35 ชิ้นที่หยิบ วางตรงไหนใน SDLC

1 · เข้าใจโค้ดเดิม: code-how กับ code-why

ก่อนแตะโค้ดที่ไม่คุ้น code-how อธิบายว่าส่วนนั้นทำงานยังไง เริ่มที่ไหน ข้อมูลผ่านอะไรบ้าง ไฟล์ไหนสำคัญ ส่วน code-why ขุดจาก commit, PR, ticket และเอกสาร ว่าทำไมโค้ดถึงออกมาหน้าตานี้

งานจริงงานแรกของเราเป็นงานเล็กใน repo ทดลองของเราเอง คือเพิ่มเทสต์ให้ตัวอ่านสเปก (โปรแกรมที่อ่านสเปกแบบฟอร์มที่เขียนเป็น markdown แล้วแปลงเป็นข้อมูล) ว่าอ่านไฟล์เดิมกี่รอบก็ได้ผลเหมือนเดิม ก่อนเขียน เราให้ code-how ไล่เส้นทางการอ่านให้ดู เลยรู้ว่าเว้นวรรคกับการขึ้นบรรทัดแบบไหนที่ตัวอ่านไม่สนใจอยู่แล้ว เทสต์จึงลองใส่แบบต่างๆ ได้ และรู้ว่าข้างในไม่มีอะไรอ่านนาฬิกา สุ่มเลข หรือจำค่าเก่าไว้ อ่านรอบสองจึงไม่มีเหตุให้ต่างจากรอบแรก เทสต์มาจากการอ่านโค้ด ไม่ได้มาจากการเดา

2 · ก่อนลงมือแก้: blast-radius

งานเทสต์ข้างบนดูไม่น่าพังอะไร แต่ blast-radius ยังเจอจุดที่เกือบพลาด (ช่วงที่ 6) เมื่อเลือกวิธีแก้ได้แล้ว blast-radius ถามว่าแก้ตรงนี้แล้วอะไรที่อื่นจะพังตาม หัวใจคือให้หา ข้อเท็จจริงข้อเดียวที่ทำให้การแก้นี้ปลอดภัย แล้วพิสูจน์ด้วยการรันโค้ดจริง และบอกว่าพิสูจน์ไปถึงขั้นไหนของบันได 5 ขั้น

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

เป้าปกติคือขั้นที่ 4 ของบันได เพราะลงแรงไม่มาก แต่ได้หลักฐานที่รันซ้ำได้ blast-radius ไม่มีโค้ดของตัวเองสักบรรทัด แต่เป้าที่มันตั้งไว้คือการรันโค้ด เลยพึ่งความจำของ AI น้อยกว่ากฎทั่วไป

3 · หลังเปิด PR: watch-pr

PR ของงานนี้ขึ้นว่าพร้อม merge ในไม่กี่วินาที แต่เรายังไม่เชื่อ (ช่วงที่ 6) skill เปิด PR ของเราจบตรงที่เปิดเสร็จ หลังจากนั้นต้องมีคนดูว่า CI (ระบบที่รันเทสต์อัตโนมัติ) ผ่านไหม มีรีวิวค้างไหม merge ได้หรือยัง watch-pr ทำงานนี้ด้วยโปรแกรมจริง เฝ้าผ่าน gh แล้วคืนคำตัดสินว่าพร้อมหรือยัง โดยไม่ merge เอง

4 · ปล่อยวิ่งเอง: show-me-your-work

พอปล่อย AI ทำงานตอนเราไม่อยู่ ตื่นมาก็เห็นแค่ผล ไม่เห็นว่ามันเลือกทางไหนเพราะอะไร show-me-your-work ให้ AI จดทุกการตัดสินใจเป็นแถว ว่าทำอะไร ทำไม หลักฐานอยู่ไหน ผลเป็นยังไง เขียนต่อท้ายได้อย่างเดียว ก่อนส่งงานคืนต้องให้โมเดลคนละค่ายมาอ่าน เพราะการตรวจตัวเองไม่นับ ของเราให้ Codex ของ OpenAI อ่านงานที่ Claude ทำ รอบนี้ก็เจอเทสต์ตัวหนึ่งที่ตรวจไม่ได้จริง (ช่วงที่ 6)

ช่วงที่ 4ตารางตัดสิน หยิบอะไร ข้ามอะไร

ตารางนี้เอา 4 คำถามจากช่วงที่ 2 มาไล่ทีละกลุ่มหลัก ไม่ครบ 51 ตัว ช่อง "เหตุผล" เขียนจากตัวชิ้นนั้นเอง เปิด repo ก็เช็กได้ ส่วน 5 ชิ้นที่หยิบผ่านด้วยเหตุผลเดียวกัน คือจบงานในขั้นเดียว จึงไม่แย่งงานตัดสินใจ (คำถามข้อ 1) ใน 5 ชิ้นนี้ มี 4 ชิ้นที่เป็น skill จาก 51 ตัว ส่วน watch-pr ไม่ใช่ skill แยก แต่เป็นสคริปต์ที่อยู่ใน poteto-mode ตัวคุมงานที่เราไม่ได้หยิบ เราดึงสคริปต์ออกมาแล้วห่อด้วย SKILL.md ที่เขียนเอง

ส่วนชิ้นที่ข้าม แทบทุกชิ้นอยากคุมหลายขั้นพร้อมกัน ไม่ก็ผูกกับ Cursor จนแกะไม่ออก

แล้วชิ้นที่ถอดออกมาเสียอะไรไปบ้าง? สคริปต์ของ watch-pr ตัดสิน READY (คำตัดสินว่าพร้อม merge) จากเช็กของ PR กับเธรดรีวิวที่ยังค้าง READY จึงครอบคลุมแค่เท่าที่ repo ของคุณตั้งเช็กไว้ ส่วนสูตรดูแล PR ใน playbook ของ pstack เป็นตัวตัดสินว่าพอได้ READY แล้วจะทำอะไรต่อ และเราไม่ได้เอาสูตรนั้นมา ชุด principle-* 24 ตัว ซึ่งเป็นกฎที่ตัวคุมเปิดอ่านก่อนเริ่มงานทุกครั้ง ก็ค้างอยู่ใน pstack เหมือนกัน ในชุดนั้นมีหลักว่าให้ตรวจของจริง อย่าเชื่อผลผ่านที่ยังไม่เคยเห็นมันตก (principle-prove-it-works บอกให้ตรวจตัวงานจริง ห้ามเดาเอาจากตัวแทน) พอไม่ได้เอาชุดนั้นมา เราเลยเขียนหลักข้อนี้เป็นกฎของเราเอง คือให้ show-me-your-work บันทึกตัวตรวจว่ายังไม่พิสูจน์ จนกว่าจะเคยเห็นมันตก (ช่วงที่ 5 ข้อ 6) และการกด merge ก็ยังเป็นของคน เพราะ READY แปลว่าอะไรจริงๆ ช่วงที่ 6 เล่าไว้

ช่วงที่ 5ใช้ pstack กับ Claude Code ได้ไหม

ได้ แต่ต้องแปลงทีละ skill ไม่ใช่ลงทั้งปลั๊กอิน (ถ้าใช้ Cursor ลงด้วย /add-plugin pstack ได้ตรงๆ) ไฟล์ SKILL.md ของ pstack ใช้รูปแบบเดียวกับ Claude Code อยู่แล้ว ที่ต้องแก้คือเนื้อใน กับช่อง name และ disable-model-invocation ใน frontmatter (ส่วนหัวของไฟล์) และแต่ละ skill ต้องแก้ไม่เหมือนกัน อย่าง 5 ชิ้นของเรา how กับ why ต้องเปลี่ยนชื่อเป็น code-how กับ code-why จะได้ไม่ไปแย่งงานของ skill อื่น และ code-how ต้องเปลี่ยนการเรียก subagent ไปใช้เครื่องมือ Agent ของ Claude Code จาก poteto-mode เราดึงมาแค่สคริปต์ watch-pr ซึ่งต้องมี bun ส่วน show-me-your-work ตัด path แชตของ Cursor ออก แล้วเปิดให้ระบบอัตโนมัติเรียกได้

ทางลัดที่ดีคือ backnotprop/pstack ซึ่งเป็นสำเนาจากต้นทางเดียวกัน ต่างกัน 26 ไฟล์ ที่เพิ่มมาคือหัวข้อ Harness บอกว่าชื่อไหนใช้แทนกันในเครื่องมือไหน เช่น Task ตัวเรียก subagent ของ Cursor เป็น Agent ของ Claude Code หรือ spawn_agent ของ Codex และ AskQuestion ที่ใช้ถามผู้ใช้ เป็น AskUserQuestion แต่ยังมีชื่อโมเดลกับค่ารันบนคลาวด์ที่ผูกกับ Cursor ค้างอยู่ สคริปต์ในสำเนานั้นเรารันแล้ว bun test orch watch-pr ผ่าน 52 ตก 0

ถ้าจะแปลงเอง ทำตามนี้ได้ เราอ่านรุ่น 0.15.15 แต่ต้นทางตอนนี้ขึ้นไป 0.15.21 แล้ว เลยควรดูก่อนว่าอะไรเปลี่ยน แต่ละ skill ไม่ได้ต้องแก้ครบทุกข้อ

ช่วงที่ 6ใช้จริงแล้วเจออะไร ที่ README ไม่ได้บอก

บอกตรงๆ ก่อนว่าหลักฐานยังน้อย 4 ชิ้นได้ใช้จริงชิ้นละครั้ง ในงานเทสต์จากช่วงที่ 3 code-why ยังไม่ได้ใช้ และเราไม่ได้รัน playbook ตัวคุมงานของ pstack สักตัว แต่ละหัวข้อวางคำสัญญาใน README คู่กับสิ่งที่เกิดจริง

blast-radius: README บอกให้พิสูจน์ข้อที่ทำให้ปลอดภัยด้วยการรันโค้ด

งานนี้เพิ่มแค่เทสต์ จึงไม่มีทางทำตัวอ่านพัง ข้อเท็จจริงที่สำคัญกลับอยู่ที่อื่น คือ ตัวรันเทสต์ตัวจริงของ repo หยิบเทสต์ใหม่ไปรันด้วยหรือเปล่า repo นี้รันเทสต์จริงด้วย npm test บน Node 22 และตัวรันนี้ล้มทันทีถ้ามีเทสต์ไหนถูกข้าม พอรันด้วยคำสั่งนั้นก็ได้ผ่าน 1,652 ตก 0 ข้าม 0 และเทสต์ใหม่ของเราอยู่ในนั้นด้วย (ใน output ขึ้นเป็นเทสต์ลำดับที่ 1424 ถึง 1426) จุดที่เกือบพลาดคือ ก่อนหน้านั้นเรารันแค่ไฟล์เทสต์ไฟล์เดียวด้วย node --test บน Node 20 ซึ่งไม่ใช่วิธีที่ repo รัน ถ้าหยุดแค่นั้น เราจะไม่รู้เลยว่าตัวรันจริงหยิบเทสต์ใหม่ไปรันด้วย เทสต์ที่ตัวรันจริงไม่เคยรัน ไม่ได้ปกป้องอะไรเลย

กฎที่เราเพิ่มเอง: ตัวตรวจที่ไม่เคยเห็นมันตก

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

watch-pr: README บอกว่าพา PR ไปจนพร้อม merge

สคริปต์ของ watch-pr ตอบ READY (พร้อม merge) เมื่อเช็กของ PR ผ่านหมดและไม่มีเธรดรีวิวค้าง ใน repo นี้เช็กที่ว่าคือ CI กับการเช็กรีวิว เราเปิด PR ได้ไม่กี่วินาที READY ก็มา เร็วจนน่าสงสัย เลยเปิดดูว่าเช็กรีวิวนั้นเช็กอะไร ปรากฏว่าขอโน้ตจากคนรีวิวก็ต่อเมื่อไฟล์ที่แก้อยู่ในรายชื่อ path เสี่ยงของ repo งานนี้แก้แค่ไฟล์เทสต์ไฟล์เดียว จึงไม่ต้องมีโน้ต คำว่า READY ไม่ได้โกหก แต่แปลว่า "ไม่ต้องมีใครรีวิว" ไม่ได้แปลว่า "มีคนรีวิวแล้ว" การกด merge ยังเป็นของคน

show-me-your-work: README บอกว่าจดการตัดสินใจลงไฟล์ตารางที่ commit เก็บได้

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

ช่วงที่ 7เลือกยังไง ให้เข้ากับงานของคุณ

ถ้าคุณใช้ Cursor และยังไม่มีวิธีทำงานเป็นระบบ การลอง pstack ทั้งชุดอาจคุ้ม เพราะมันออกแบบมาให้ใช้แบบนั้น (เส้นนี้เราไม่ได้ลอง) แต่ถ้าคุณมีวิธีทำงานอยู่แล้ว แม้เป็นแค่ลำดับขั้นที่ทำจนติดมือ ให้หยิบเครื่องมือ อย่าหยิบหัวหน้างาน

skill pack จะใหญ่แค่ไหน เราก็หยิบมาแค่ชิ้นที่งานต้องใช้ได้ ใน pstack เราเจอ 5 ชิ้น ของคุณอาจเป็นชิ้นอื่น ขอบคุณ Lauren Tan ที่เปิดให้หยิบ