pstack
รายงานวิจัยฉบับเต็ม ฉบับภาษาไทย

จุดเข้าหลัก (router) ของ pstack ทั้งชุด คือ style การทำงานของ Lauren Tan ('poteto') สำหรับ coding agent: ตอบกระชับแบบประโยคสั้น, ใช้ subagent อย่างมีสติ, prose ไม่เป็น AI-slop, โค้ดเรียบง่าย และงานทุกชิ้นต้องพิสูจน์ว่าใช้งานได้จริง เมื่อ user เรียก /poteto-mode <task> มันจะอ่าน Principles ให้ครบก่อน จับคู่งานกับ playbook 1 แบบจาก 23 แบบ คัดลอก step ของ playbook ลง todolist แบบคำต่อคำ แล้ว chain skill อื่นของ pstack (how, why, tdd, swarm, arena, interrogate ฯลฯ) ตามที่ playbook กำหนด

แก่นคือสถาปัตยกรรม router + playbook ที่ทำให้เจตนาของมนุษย์กลายเป็นขั้นตอนที่ agent ทำตามได้แบบ deterministic ไม่ใช่แค่ 'สไตล์ที่ดี' ลอย ๆ กลไกที่จับต้องได้: (1) step ของ playbook ต้องถูก copy เข้า todolist แบบคำต่อคำ 'ก่อน' จะคิดวิเคราะห์ task — ตัด failure mode ที่ agent อ่าน playbook แล้วเขียนแผนเองจนทำ step สำคัญ (architect, throughput checkpoint) หายไป และห้าม skip เงียบ ๆ ต้องใส่บรรทัด skip: <เหตุผล> (2) principle-* ทั้ง 21 ตัว (Core 9, Architecture 6, Verification 3, Delegation 2, Meta 1) เป็นกฎแบบมี trigger กำกับ และทุก citation ต้อง trace ไปยังการตัดสินใจจริง — 'citation ที่ไม่มี decision อยู่เบื้องหลัง = คุณข้าม leaf skill ไป' (3) กฎตัดสิน fork แบบ empirical ก่อนถามมนุษย์: ถ้าคำตอบหาได้จากการรันจริง (พฤติกรรม, timing, layout, perf) ห้าม AskUserQuestion — sketch ผ่าน Prototype playbook แล้วให้ผลลัพธ์เป็นคนตัดสิน (4) กฎ Autonomy ชัดเจน: reversible ทำเลย หยุดเฉพาะ irreversible writes (force-push, deploy, ลบ data, ส่งข้อความถึงลูกค้า) (5) กฎเขียน reply แบบ anti-slop ที่วัดผลได้ เช่น ห้ามอักษร long-dash, ห้าม colon คั่นกลางประโยค, สร้างประโยคให้สะอาดตั้งแต่แรกเพราะ 'cleanup ทีหลังถูกวัดแล้วว่าพัง' (6) เจ้าของงานคือ agent หลักเสมอ — review diff ของ subagent เอง ไม่ pass-through คำพูดของ subagent

เรียกใช้: /poteto-mode <task description> เช่น /poteto-mode fix this bug หรืออธิบายงานต่อท้ายคำสั่ง สิ่งที่เกิดขึ้นตามลำดับ: (1) todolist แรกของทุก task หลายขั้นคืออ่านส่วน Principles ให้ครบทั้งไฟล์ (2) agent จับคู่ task กับ playbook จาก 23 แบบ: Investigation (คำถาม read-only), Bug fix (repro ก่อนแก้), Perf issue (วัด baseline), Hillclimb (ปรับ metric ต่อเนื่อง), Runtime forensics (diagnose จาก live instrumentation), Trace forensics (diagnose จาก cpuprofile/trace ที่ capture แล้ว), Feature, Refactoring, Prototype (sketch ตัดสินใจถูก), Visual parity (UI เป๊ะพิกเซล), Authoring a skill, Eval, Babysit (ดัน PR/stack ให้ green), Shipping (verify แล้ว land), Autonomous run (รุดจนจบ), Orchestrate (โปรเจกต์หลายวันหลาย PR ใต้ coordinator เดียว), Autopilot-full (คิว PR รันถึง merged), Autopilot-stack (สร้าง stack ให้ operator กด land เอง), Session pickup (รับงานค้างจาก agent ก่อนหน้า), Pause safely (พักงานให้ resume ได้), Multi-phase or multi-PR plan, Worktree and simulator cleanup, Opening a PR — ถ้าไม่มี playbook ไหน fit ใช้ skill figure-it-out ออกแบบ playbook เฉพาะงานให้ (3) copy step ของ playbook ลง todolist คำตอบคำ แล้วทำตาม โดย playbook แต่ละแบบจะสั่ง chain skill เอง เช่น Bug fix จะ fan-out how + why แบบขนาน, ใช้ architect ก่อนแก้ที่ข้าม function boundary, ใช้ tdd เมื่อมี test path ถูก, แล้วจบด้วย Opening a PR (4) redirect กลางทางได้: เรียก principle ด้วยชื่อตรง ๆ (เช่น สั่ง 'apply principle-laziness-protocol') หรือสั่งเปลี่ยน playbook (5) แนวคิด sticky mode: บน Cursor field mode: true ทำให้ style นี้ค้างเป็นโหมดของ session และ field reminder จะยัด nudge 'New task? Playbook match or rigor needed -> apply /poteto-mode. Casual turn or user opts out -> don't.' เพื่อดันให้ agent กลับมาใช้โหมดนี้กับ task ใหม่ทุกครั้ง บน ZCode กลไก nudge นี้อาศัย description ของ skill แทน

เป็น hub ที่ chain skill อื่นเกือบทั้งชุด: how, why, tdd, swarm (fan-out ขนาน), arena (design/code bakeoff), interrogate (adversarial review), architect, reflect, unslop, no-comments, technical-writing, show-me-your-work, figure-it-out, create-verification-skill โหลด principle-* 21 ตัวเป็นกฎพื้นฐาน ใช้ subagent_type poteto-agent เป็น default สำหรับ code delegate (ปรับได้ผ่าน ~/.zcode/pstack-roles.md ที่ /setup-pstack เขียนให้) คู่ควรรัน /setup-pstack ก่อนหนึ่งครั้งเมื่อติดตั้ง pstack

Skill ตั้งค่าครั้งแรก (first-run configuration) ของ pstack บน ZCode: ตรวจจับ subagent type ที่มีอยู่จริงใน session, map มันเข้ากับ role ต่าง ๆ ที่ pstack ใช้ (code delegate, critic, investigator, arena runner ฯลฯ) แล้วเขียนลง ~/.zcode/pstack-roles.md เป็น override layer ที่ skill อื่นอ่านเมื่อต้อง spawn subagent และปิดท้ายด้วยการเสนอสร้าง project-local verification skill ถ้าโปรเจกต์ยังไม่มี

แก้ปัญหาเฉพาะตัวของ ZCode: ทุก subagent รันบน session model เดียวกัน จึงไม่มี per-role model choice — diversity ที่เหลืออยู่คือ subagent type และ prompt ซึ่ง skill นี้ทำให้ 'ตั้งค่าได้' อย่างเป็นระบบ เพราะ reviewer type อ่าน diff ไม่เหมือน architect type หรือ general-purpose delegate จุดเด่นจากกลไกจริง: (1) เป็น override layer ไม่ใช่ข้อบังคับ — บรรทัดไหนไม่มีในไฟล์ = fallback ไป inline default ของ skill นั้นทันที (2) กัน config พังตั้งแต่ต้นทาง: 'Never write a type you have not confirmed exists' เพราะ role line ที่ชี้ type ที่ Agent tool ไม่รู้จักจะ break ทุก delegation ที่อ่านไฟล์นี้ (3) idempotent — rerun แล้ว overwrite ทั้งไฟล์ ไม่มี state ค้าง (4) panel role (how critics, arena runners, interrogate reviewers) รับเป็น list ทำให้ความยาว list = จำนวน fan-out และใส่ type เดิมซ้ำได้ถ้าอยากได้ volume แทน diversity (5) step 7 เสนอ /create-verification-skill ให้โปรเจกต์ที่ยังไม่มีวิธี drive app จริงเพื่อพิสูจน์งาน — ปิด loop verification ตั้งแต่วันแรก

เรียกใช้: /setup-pstack หรือพิมพ์ 'configure pstack agents' / บอกว่าจะเปลี่ยน subagent choice ของ pstack ขั้นตอนที่ agent ทำ 7 ขั้น: (1) Detect — enumerate subagent_type ที่ session นี้ใช้ได้จริง จาก 3 แหล่งตามลำดับ: built-ins ที่มีเสมอ (general-purpose, Explore, code-architect, code-explorer, code-reviewer), type จาก plugin ที่เปิดใช้ (pstack ให้ poteto-agent และ comment-sicko), และ agent definitions นอก plugin เช่น ~/.zcode/cli/agents/ (2) Load current state — ถ้า ~/.zcode/pstack-roles.md มีอยู่แล้วใช้ค่าเดิมเป็น current, ไม่มีก็เริ่มจาก default mapping (3) Map and confirm — โชว์ตาราง role ทุกตัวกับ type ปัจจุบัน ถาม user ผ่าน AskUserQuestion ว่ารับตามนี้หรือจะเปลี่ยน role ไหน โดย role แบบ panel เป็น list (4) Validate — type ทุกตัวที่จะเขียนต้องอยู่ในชุดที่ detect เจอ ไม่งั้นหยุดถามใหม่ (5) Write — เขียน ~/.zcode/pstack-roles.md ทับทั้งไฟล์ รูปแบบบรรทัดละ role: 'how critics: code-reviewer, poteto-agent, general-purpose' (6) Confirm — อ่านไฟล์ซ้ำแล้ว echo ตารางสุดท้าย พร้อมแจ้ง fallback rule และว่า rerun ปลอดภัย (7) Offer verification skill — เช็คว่าโปรเจกต์มี verify-* skill หรือ harness อยู่ไหม ถ้าไม่มีเสนอสร้างผ่าน /create-verification-skill หนึ่งครั้ง ไม่ต้องดันถ้าปฏิเสธ

ควรรันหลังติดตั้ง pstack ก่อน /poteto-mode ครั้งแรก เพราะกำหนด subagent type ให้ role ทั้งหมดที่ poteto-mode และ routed skills (how, why, arena, swarm, architect, interrogate, reflect) ใช้ spawn งาน และใน step สุดท้ายจะเสนอ /create-verification-skill ต่อเองถ้าโปรเจกต์ไม่มี verification skill

Skill จิ๋ว (267 bytes) แบบ one-shot ของ pstack: สั่งให้ agent พูดซ้ำข้อความล่าสุดของตัวเองใหม่เป็นภาษามนุษย์ธรรมดา ตัด jargon ทิ้ง เล่าให้กระชับและเข้าใจง่ายเหมือนคนสองคนคุยกัน ไม่มี logic หรือขั้นตอนใด ๆ ทั้งไฟล์

ความเจ๋งคือความเรียบ: เป็น 'ปุ่ม reset น้ำเสียง' ที่แก้ failure mode ที่พบบ่อยที่สุดของ agent คือตอบยาว เทคนิคัล และอ่านไม่รู้เรื่อง ทั้งที่ตัวไฟล์ไม่มีอะไรเลยนอกจากคำสั่งตรง ๆ หนึ่งประโยค (Restate your last message. Stop using jargon and speak coherently.) — เป็นตัวอย่างว่า skill ไม่จำเป็นต้องซับซ้อนจึงมีประโยชน์ และเข้ากับปรัชญา anti-slop ของ pstack ที่เห็นเต็ม ๆ ใน poteto-mode แต่ถูกหั่นมาให้เรียกใช้แยกได้ทันทีเมื่อคำตอบก่อนหน้าอ่านแล้วปวดหัว

เรียกใช้: พิมพ์ /bro ทันทีหลังจากได้รับคำตอบที่เต็มไปด้วย jargon หรืออธิบายซับซ้อนเกินไป ไม่มีพารามิเตอร์และไม่มีโหมดย่อย — agent จะ restate ข้อความล่าสุดของตัวเองใหม่ทั้งก้อน ใช้เมื่อไหร่: หลังคำตอบเทคนิคแน่น ๆ เช่น ผลจาก investigation ยาว ๆ หรืออธิบายสถาปัตยกรรมที่ใช้ศัพท์เยอะ และต้องการย่อเป็นภาษาพูดให้คนไม่ใช่ engineer ฟังเข้าใจ

standalone ไม่ผูกกับ skill ใด ใช้ต่อท้าย reply ใดก็ได้ และมักสมเหตุสมผลหลัง output หนา ๆ ของ pstack เช่น คำตอบจาก Investigation playbook ของ /poteto-mode

Skill สำรวจ codebase เพื่อตอบคำถาม "how does X work" — ผลิตคำอธิบายสถาปัตยกรรมระดับที่ senior engineer onboarding เข้า subsystem ใหม่จะได้ mental model ที่ใช้งานได้จริง (ไม่ใช่ annotated source code) มี 2 โหมด: Explain (default) สำรวจแล้วอธิบายอย่างเดียว และ Critique ที่อธิบายให้เข้าใจก่อน แล้วค่อยปล่อย critic หลายตัวแบบอิสระออกมาหาปัญหาเชิงสถาปัตยกรรม

กลไกที่เจ๋งคือการประเมินความซับซ้อนของคำถามก่อนเสียทรัพยากร: คำถาม Simple (โมดูลเดียว, คำถามแคบ) ส่ง explainer ตัวเดียวทำ explore+explain ใน pass เดียว, คำถาม Complex (ข้ามไฟล์/services) แตกเป็น 2-4 explorer agents ขนานกัน แต่ละตัวรับ slice ไม่ซ้ำกัน (เช่น data model / request path / config+metrics) แล้วให้ explainer ตัวเดียว synthesize + reconcile สิ่งที่ทับซ้อน โดยมีกติกา "When in doubt, lean simple" กันการ over-engineer นอกจากนี้ Critique mode บังคับ "Explain First" — ห้ามวิจารณ์โค้ดก่อนเข้าใจมัน และ critic แต่ละตัวได้คำอธิบายจากขั้นก่อน + รูปแบบเดียวกันจาก critique-rubric ทำให้วิจารณ์ตั้งอยู่บนความเข้าใจเดียวกัน สุดท้าย lead judgment แบ่งผลเป็น Act on / Consider / Noted / Dismissed แบบ "pragmatic lead, not an aggregator" และกฎ "The explainer's communication is the product" ห้าม lead rewrite คำอธิบายจนเสียรสของผู้เขียน

เรียกใช้ด้วย /how หรือถามตรง ๆ "how does X work" — ใช้เมื่อ: จะ walkthrough โค้ดก่อนแก้อะไร, ถาม placement/ownership/layering ("where should this live", "which package owns this", "is this the right layer"), อยากได้ subsystem architecture / runtime flow / onboarding mental model. ขั้นตอนภายใน: (1) parse คำถาม (subsystem / feature flow / architectural overview / runtime trace) — ถ้ากำกวม state best-guess แล้วลุย ห้ามถามกลับ (2a) คำถาม complex → spawn 2-4 Explore agents (read-only) พร้อมกันใน message เดียว แต่ละตัวได้ base prompt จาก references/explorer-prompt.md + angle เฉพาะ โดย explorer ต้องไล่ call chain จนอธิบาย input-to-output ได้ครบไม่มี hand-waving (2b) คำถาม simple → spawn general-purpose explainer ตัวเดียว (3) complex case: ส่ง findings รวมให้ explainer synthesize ตาม references/explainer-prompt.md (4) present ตามโครง: Overview → Key Concepts → How It Works → Where Things Live → Gotchas. โหมดย่อย Critique: trigger เมื่อผู้ใช้ขอ "architectural issues/problems/improvements" โดยรัน explain ครบก่อน แล้ว spawn critic หนึ่งตัวต่อ entry ใน configured how-critics list (default: code-architect, code-reviewer, poteto-agent, general-purpose) ทุกตัวได้คำอธิบาย + file paths + rubric จาก references/critique-rubric.md จบด้วย lead judgment แบ่ง Act on / Consider / Noted / Dismissed โดยนำเสนอคำอธิบายก่อน แล้ววาง verdict วิจารณ์ไว้ข้างล่าง

คู่ตรงข้ามกับ why: how ตอบ what/how ส่วน why ตอบแรงจูงใจ (description ระบุ "Use why for motivation") — ไม่มี requirement ว่าต้องเรียก skill อื่นก่อน; Critique mode ใช้ lead-judgment framework เดียวกับ interrogate และใช้ critic types เดียวกับที่ interrogate ใช้ (code-reviewer, code-architect, poteto-agent, general-purpose)

Skill สืบสวนแรงจูงใจและ intent ที่อยู่เบื้องหลังโค้ด — ทำไมถึงสร้างแบบนี้, พิจารณา edge case อะไร, product/business/operational constraint ไหนหล่อหลอม design, alternative ไหนถูกปฏิเสธและเพราะอะไร ทำงานโดย enumerate MCP ที่มีใน session แล้ว map เข้า 7 evidence categories (source control, issue tracker, long-form docs, real-time chat, infra observability, error tracking, product analytics warehouse) ไล่ query ขนานกันทุก category แล้ว synthesize เป็น narrative ที่อ้าง citation ทุกข้อความพร้อม confidence calibration ชัดเจน

หัวใจคือกลไก "coverage ไม่ใช่ minimalism": ไม่เดาจากคำถามว่าคำตอบซ่อนอยู่ category ไหน แต่ query ทุก category ที่มี MCP ขนานกัน และยก null result เป็น evidence ชั้นหนึ่ง ("a null result from an issue tracker is evidence the decision was not ticketed") — กัน blind spot จากการตัดสินล่วงหน้า ประกอบกับ epistemics framework ที่เข้มงวด: "Evidence before narrative", "Cite everything — ถ้าอ้างไม่ได้คือ inference ไม่ใช่ fact", "Prefer 'appears to' over 'because'" และกฎ "No shortcut by code-reading" (โค้ดบอกว่าทำอะไร แต่แทบไม่เคยบอกว่าทำไม) โครงสร้าง output ก็บังคับความซื่อสัตย์โดย design ผ่านการแยก "What We Found (direct evidence)" / "What We Can Reasonably Infer" / "Competing Hypotheses" / "What We Don't Know" / "Sources Consulted" โดย Sources Consulted ต้องรายงานทุก investigator รวมตัวที่ว่างเปล่าและตัวที่ skip พร้อมเหตุผล ทำให้ผู้อ่านตัดสินความกว้างของการสืบค้นได้ทันที ส่วน failure modes ที่ระบุไว้ตรงจุดมาก: confident storytelling, อ้างโค้ดเป็นหลักฐาน intent ของตัวเอง, recency bias และ sycophantic agreement

เรียกด้วย /why หรือถามตรง ๆ "why does X work this way" — ใช้กับ design rationale, "why we picked Y", regressions, postmortems และ data-backed thresholds (เช่น "ตัวเลข limit นี้มาจากไหน") ขั้นตอนภายใน: (1) parse target + question (design rationale / tradeoff / defensive reasoning / ทำไมโค้ดนี้ยังอยู่ / history sweep) — target กำกวมให้เดาจากบริบทแล้วแจ้ง interpretation (2) สร้าง code anchor inline ก่อน spawn: git blame -L, git log --follow -p, git log --oneline -20 และดึง PR bodies/discussion ด้วย gh pr view เพื่อเก็บ PR numbers + ticket IDs เป็น seed context (3) enumerate MCP ทั้งหมด แล้ว map เข้า 7 evidence categories จากนั้น spawn investigator หนึ่งตัวต่อหนึ่ง category ขนานกันใน message เดียว (general-purpose เพราะต้องใช้ MCP tools; ห้ามรวมหลาย MCP ให้ agent เดียว) — ทุกตัวได้ base prompt จาก references/investigator-prompt.md + category playbook จาก references/sources/*.md; ถ้า target ดู defensive (null check, retry, timeout, rate limit, feature flag) ให้แนบ references/sources/incident-postmortem.md เพิ่ม (4) synthesizer ตัวเดียวรวมผลตาม epistemics framework (references/epistemics.md) (5) present โดยห้ามแตะ confidence language เลย. การ skip investigator ทำได้เฉพาะ 2 เหตุผลที่ต้องเขียนลง Sources Consulted: ไม่มี MCP ของ category นั้น หรือ source นั้น provably irrelevant (bar สูงมาก) — ถ้าคำตอบจะถูกใช้แก้โค้ดต่อ ให้แปลง findings เป็น Preserve / Change / Avoid / Risk constraint set

Companion ของ how (เนื้อไฟล์ระบุ "Companion to the how skill" — เป็นคู่เสริม ไม่ใช่ hard requirement): how ตอบ "what the code does and how it works", why ตอบ "what forces led to its shape"; เป็น dependency ของ teach (teach รัน how+why เป็น real skill invocations) และ recall (recall ใช้ investigator + playbooks ของ why ใน step 4)

Skill อธิบายงานหรือ subsystem หนึ่ง ๆ อย่างเรียบง่ายจนคนอ่านเข้าใจจริง — รัน skill how และ why ให้ทำการสืบค้นเบื้องหลัง แล้วถักสิ่งที่ได้มาเป็นคำอธิบายเดียวที่ปรับตามจังหวะของผู้ฟัง เป้าหมายคือให้เข้าใจ ไม่ใช่แก้ไขอะไร ใช้กับ "teach me this", "help me really understand X", "explain this change or subsystem to me"

สถาปัตยกรรมของมันคือการแยกบทบาทให้ขาด: การสืบค้นเป็นของ how + why ทั้งคู่ ("Those are real skill invocations that do their own digging... Let those skills do the investigation. Don't redo it by hand") teach เป็นเพียงชั้นการสื่อสารที่ blend ผลลัพธ์ ทำให้คุณภาพการสืบค้นได้มาตรฐานเดียวกับ skill จริงและไม่ duplicate งาน ด้านการสอนมีกลไกต่อต้าน lecture-theater ที่เจาะจงมาก: อ่านว่าผู้ฟังถามเพราะอะไร (กำลังจะแก้โค้ด / กำลังรีวิว / debug / มือใหม่) จากบทสนทนาแทนการสอบถาม, "Put the depth where their question is", ห้าม print framing labels ("the key insight", "TL;DR", "Pause") และห้าม quiz ที่สำคัญคือกฎ diagram ที่ซื่อสัตย์ต่อ cognitive load — อะไรที่มี 3+ ส่วนต้องห้ามวาดรวดเดียว ให้วาดซ้ำเป็นชุดทีละส่วนจนผู้อ่านเห็นระบบประกอบขึ้น ("Three small growing diagrams beat one crowded diagram") และคุมคุณภาพภาษาด้วย unslop skill ทั้งฉบับ รวมถึงตัวอย่างความหนาแน่นที่ยกมาเป็นตัวอย่าง (virtualization อธิบายเป็นสองส่วน rendering/loading)

เรียกด้วย /teach (มี disable-model-invocation: true ใน frontmatter) ขั้นตอนภายใน: (1) ตัดสินว่าผู้ฟังควร walk away ด้วยความเข้าใจอะไรบ้าง โดยอ่านเจตนา (จะแก้/รีวิว/debug/มือใหม่) และพื้นฐานเดิมของเขาจากบทสนทนา ข้ามสิ่งที่เขารู้แล้วชัดเจน (2) อ่านโค้ดเองเพื่อ orient ก่อน แล้วรัน how (ทำงานยังไง) กับ why (ทำไมเป็นแบบนี้) ขนานกันแล้ว combine — subsystem ใหญ่รันทั้งคู่ เปลี่ยนเล็กอาจตัวเดียวพอ; ให้ keep why narrow โดย default เพราะ full sweep ของ why ช้า โดยใส่การ narrow ไว้ในตัวคำถามที่เรียก (scoped question, git + source คู่) เพื่อให้ why บันทึก skipped categories ตาม contract ของมันเอง (3) เริ่มด้วย plain definition — ตั้งชื่อสิ่งนั้นและบอกว่ามันคืออะไรแบบที่ senior engineer พูดปากเปล่า แล้วผูกกับกรณีตรงหน้า ต่อด้วย how it works → deeper reasons → edge cases; ให้คำตอบที่สมบูรณ์ที่สุดที่เล็กที่สุดก่อน (1-2 ประโยค) แล้วหยุด เพิ่ม layer เมื่อถูกถาม (4) รักษาบรรยากาศบทสนทนา เสนอเจาะลึกหรือย้ายประเด็น ตามที่ผู้ฟังนำ; ไม่มี quiz ไม่มี pacing theater (5) show don't tell — เปิด diff/โค้ด/debugger เมื่อเร็วกว่า และวาด diagram แบบ build-up ทีละชั้น (flow ที่ผ่าน A→B→C วาดสามรอบ: A→B ก่อน แล้ว redraw เพิ่ม C แล้ว redraw เพิ่ม return edge); ไอเดียเชิง spatial (layout, overlap, scroll position, before/after) ใช้ image generation สไตล์ marker-on-whiteboard พร้อม label สั้น ๆ แทน mermaid

ต้องมี how + why — ไฟล์ระบุชัด "Teach sits on top of how and why" และให้รันทั้งคู่เป็น real skill invocations ขนานกัน (โดยยืดหยุ่นได้: เปลี่ยนเล็กอาจเหลือตัวเดียวพอ); คำตอบต้องเขียนผ่าน unslop skill; ต้องคง confidence language ของ why ไว้ครบเวลา reword เพื่อการสอน

Skill สร้าง working context ล่าสุดของผู้ใช้ขึ้นใหม่ก่อนเริ่มหรือกลับมาทำงาน โดยขุดจากสองแหล่ง: chat history ของตัวเอง (session transcripts ใต้ ~/.zcode/cli/, JSONL หนึ่งไฟล์ต่อหนึ่ง session) และ shared record (symptom ที่ user รายงาน, fix ที่ ship แล้วถูก revert, error ที่ยังยิงใน prod) แล้วส่งมอบ brief กระชับ: capsule สถานะรวม, สถานะราย thread, ปัญหาที่พบซ้ำ และ next move เดียวที่ควรทำต่อ

Insight หลักคือการยอมรับว่า transcript ของตัวเองไม่พอ: "A feature with a long bug tail keeps most of its story there, so don't reconstruct it from your transcripts alone" — เรื่องราวส่วนใหญ่ของ feature อยู่ใน shared record ซึ่งเป็นสิ่งที่ why skill ค้นอยู่แล้ว recall จึงยืมกลไกของ why มาใช้แทนการสร้างใหม่ (reuse per-source playbooks, one investigator per source, null results are findings) อีกจุดเด่นคือ context budget ที่ออกแบบดี: heavy reading กระจายไป parallel subagents บน fast cheap model และ "The raw transcripts stay in the subagents. The main thread gets only their findings" รวมถึงการ verify กับ live state เพราะ "A transcript or a stale ticket is history, not current truth" ต้องเช็ค PR/branch/ticket กับ git/gh จริง ส่วน output contract บังคับ status tag ต่อ thread ([merged #N], [open PR #N], [in flight <branch>], [verified, uncommitted], [reverted #N], [planned, not started]) — "A thread with no tag is not done yet, so tag it" และต้องรายงาน fix ที่โดน revert เพื่อให้ attempt ถัดไปเริ่มจากจุดที่ attempt ก่อนล้ม

เรียกด้วย /recall (มี disable-model-invocation: true) — ใช้กับ "recall my work on X", "catch me up", "what have I been working on", "where did I leave off" ก่อนเริ่มหรือ resume งาน ขั้นตอนภายใน: (1) classify ก่อน route: resume จาก chat เดียวจำเพาะคือ playbook session-pickup ไม่ใช่ skill นี้, แปลง habit เป็น skill คือ automate-me, ถ้า user ให้ state capsule มาแล้ว (paths, branch, change) ให้ใช้เลยไม่ต้องขุด (2) lock scope ก่อนค้น: หน้าต่างเวลา (default 7 วัน), topic ถ้าระบุ, workspace (default อันปัจจุบัน — ห้ามอ่าน transcript project อื่นถ้าไม่ได้ร้องขอ) แล้ว state scope กลับให้ user เห็น (3) fan-out ขนานล่า transcript ด้วย subagents บน fast cheap model: จัดลำดับ candidate ด้วย real modification time (ls -t) ไม่ใช่ชื่อ UUID, grep topic ก่อนแล้วอ่านเฉพาะ chat ที่ match เฉพาะช่วงที่เกี่ยว, ข้าม current chat + subagent/eval/test chats; ถ้าเหลือ 1-2 chats ค้นตรงไม่ต้อง fan-out; ทุก subagent รายงาน schema เดียวกัน (topic, goal, decisions, open threads, struggles/corrections, artifacts) พร้อม cite chat UUID (4) sweep shared record ทุกครั้งที่ topic ระบุ feature/file/subsystem/area/bug — เป็น default ไม่ใช่ judgment call: ส่งให้ why skill's source investigators แต่เปลี่ยนคำถามจาก "why was this built" เป็น "สถานะปัจจุบันคืออะไร, เคยลองอะไรที่ไม่อยู่, user ยัง report อะไร" ขนานกับการล่า transcript; ข้ามได้เฉพาะ pure activity recall ที่ไม่มี target ("what did I do this week") (5) verify กับ live state ด้วย git/gh (6) เขียน brief ตาม output contract: Capsule ≤5 bullets, Threads บรรทัดละหนึ่งพร้อม status tag บังคับ, Problems ≤5 อันที่เกิดซ้ำ, Next move หนึ่งอย่างที่ concrete

ยืม source investigators + per-source playbooks จาก why skill ใน step 4 (sweep shared record) แต่เปลี่ยนคำถาม; เขียน brief ผ่าน unslop skill; แยกขาดจาก playbook session-pickup (resume chat เดียวจำเพาะ) และ automate-me (แปลง habit เป็น skill)

Skill ออกแบบ playbook แบบ auditable ขึ้นใหม่เมื่อไม่มี playbook ที่แคบกว่าให้พอดี — งานพวก migration ขนาดใหญ่, งาน multi-part ที่ทะเยอทะยาน หรืองานที่มนุษย์จะรีวิวหลังจากหายตัวไป ตัว deliverable ก่อนโค้ดแรกคือ workflow เอง: ลำดับ phase ที่ scale rigor ตามความเสี่ยง รัน scientific method (hypothesis loop) และทิ้ง decision trail ที่มนุษย์ audit ย้อนได้

มุมมองที่คมคือมอง "งานที่ไม่มี playbook" เป็นงาน design workflow ไม่ใช่โอกาส improvise — "The deliverable before any code is the workflow itself" พร้อมหลัก "Bias toward more rigor. The cost of building the wrong thing dwarfs the cost of being careful" และ rigor ถูกทำให้เป็นรูปธรรม: "Rigor is gates and artifacts, not 'try harder'" — one-way door กับ high blast radius ได้มากขึ้น, reversible low-stakes ได้น้อยลง จุดเด่นกลางคือ Phase C hypothesis loop ที่จริงจัง: ทุก unit เป็น experiment (state hypothesis → smallest change → measure กับ predicate บน real artifact → keep ถ้า advance, revert ถ้าไม่) โดย verdict มีแค่ VERIFIED / NOT VERIFIED / INCONCLUSIVE และ "Inconclusive is not a pass. Don't hide a negative" กลไกกัน fake-verification ตรงจุดมาก: "Verify by inspecting the artifact, never a self-report. When something passes too easily, suspect the observation method before the system. A blank screenshot passes a lazy gate" และ delegated work ต้องจับคู่ judge + audit artifact ด้วยตัวเองก่อนเชื่อ worker สุดท้าย มันประกอบร่างจาก principle skills ของ poteto-mode อย่างเป็นระบบ (prove-it-works, never-block-on-the-human, foundational-thinking, laziness-protocol, separate-before-serializing-shared-state, sequence-verifiable-units, encode-lessons-in-structure) โดยเปิดท้ายด้วยการ encode การแก้ซ้ำเป็น gate/lint/script เพื่อให้ชัยชนะไม่ถูกกลืนกลับ

เรียกด้วย /figure-it-out หรือพูด "figure it out" (มี disable-model-invocation: true) — ใช้เมื่อ: migration ข้าม call sites จำนวนมาก, งาน multi-part ทะเยอทะยาน, งานที่ user รีวิวหลัง step away หรือเมื่อไม่มี playbook ไหนให้พอดี ขั้นตอนภายใน: Start — เปิด todolist ที่ item แรกคืออ่านส่วน Principles ของ poteto-mode แล้วใส่ทุก phase เป็น todos Phase A Frame — นิยาม definition of done เป็น falsifiable predicate (prove-it-works), quantify scope + ปลุก blockers ก่อนเสียเวลาหลายชั่วโมง, เลือก rigor level เอียงสูง แล้ว present framing/tradeoffs ก่อน commit รันยาว (งาน reversible เดินต่อเองตาม never-block-on-the-human แต่ run หลายชั่วโมงได้ checkpoint เดียว) Phase B Design — แตกงานเป็น atomic units ที่ land แยกได้ เรียง riskiest-unknown-first, สร้าง verification harness + baseline จาก pre-change state ก่อนแก้ (ผลอ่านเป็น "old vs new"), one-way-door design ให้รัน architect skill (ที่รัน arena ด้วย candidates หลากหลาย + read-only judge), ตัดสินว่าอะไร fan out ขนานโดยให้ worker แต่ละตัวมี worktree/branch ของตัวเอง, เขียน phase list ลง todolist — นั่นคือสิ่งที่มนุษย์จะรีวิว Phase C Run — ทุก unit เป็น experiment ใน hypothesis loop, verify ทีละ unit ก่อน unit ถัดไป (ไม่ batch ท้าย), delegated work จับคู่ judge และ audit ของ delegate ด้วยตัวเอง; worker เล่นกล gate → reset และ harden contract, gate เองผิด → fix gate เป็น change แยก Phase D — log ผ่าน show-me-your-work (TSV แถวต่อ decision/unit, เขียน row ไปพร้อมกับงานไม่ใช่กองท้าย) Phase E — ตรวจทั้งงานกับ predicate บน real product ไม่ใช่แค่ harness แล้ว encode recurring correction เป็น gate/lint/script; reply: playbook ที่ออกแบบ, rigor level + เหตุผล, path ของ decision trail, สิ่งที่ verified กับ predicate และสิ่งที่ยังเปิด

พึ่ง poteto-mode เป็นฐาน (todo แรกบังคับคืออ่าน Principles section ของ poteto-mode); ใช้ show-me-your-work เป็น audit trail ใน Phase D; ใช้ architect skill (ซึ่งรัน arena) สำหรับ one-way-door design decision; อ้าง principle skills ตรง ๆ: prove-it-works, never-block-on-the-human, foundational-thinking, laziness-protocol, separate-before-serializing-shared-state, sequence-verifiable-units, encode-lessons-in-structure; ขอบเขต: ต่างจาก Orchestrate playbook — figure-it-out ออกแบบ run เดียว (one bespoke run) ส่วน Orchestrate รันโปรแกรมระดับโปรเจกต์

Skill เก็บ decision trail ที่รีวิวย้อนได้สำหรับงานรันยาวหรือ unattended — log TSV ไฟล์เดียว canonical แถวต่อหนึ่ง decision (ts, phase, decision, why, evidence, result) local เป็น default และ commit เมื่อ reviewer ต้องใช้ trail นี้เพื่อเชื่อผล จบทุก run ด้วย self-audit กับ transcript จริงและการ cross-model review ที่ผลลัพธ์ต้องปรากฏเป็น section "Attention" ในทุก reply ของ run นั้น

Format ถูกเลือกด้วยเหตุผลเชิงปฏิบัติครบ: TSV เพราะ GitHub render เป็น sortable table, column -s$'\t' -t อ่านได้ใน terminal, spreadsheet เปิดได้ และ append ได้ด้วยคำสั่งเดียว — evidence ต้องเป็น pointer (commit SHA, PR #, file:line) ไม่ใช่ย่อหน้า จุดที่คมที่สุดคือวินัยเชิงประวัติศาสตร์ของ log: append-only, "A wrong call gets a new row that supersedes it. Never edit or delete history" และตอนจบ run ต้องเปิด transcript จริงมา walk เทียบ — "Every row maps to a real action. Cut invented or aspirational entries" พร้อมคติ "Fix the log, not the story" อีกกลไกที่เกินตัวคือ cross-model review แบบบังคับ: ต้อง spawn subagent คนละ model family มา scan trail + transcript เพื่อหา row ที่ evidence อ่อน, verification ที่อ้างไว้แต่ transcript ไม่มีหลักฐาน และ decision ที่ risky ย้อนหลัง โดยทุก reply จบด้วย Attention section ที่นำด้วย "reviewed by <model>" — "No flags" เป็นค่าที่ valid แต่การไม่ใส่ชื่อ model ไม่ใช่ นอกจากนี้มันถูก design ให้เป็น composable audit trail: skill อื่น (figure-it-out) route มาที่นี่แทนการ invent format ใหม่ ("Reference it by name and let it own the format")

เรียกด้วย /show-me-your-work (มี disable-model-invocation: true) — ใช้กับ autonomous run, multi-phase run หรืองานที่มนุษย์จะรีวิวหลัง step away วิธีใช้: (1) copy header row จาก references/decision-log-template.tsv เพื่อเริ่ม log ใหม่ (2) append แถวด้วย helper: scripts/log.sh <logfile> <phase> <decision> <why> <evidence> <result> — helper ประทับ ts, เขียน header ครั้งแรก, strip tab/newline ที่หลุดมา และ prefix cell ที่ขึ้นด้วย =,+,-,@ ด้วย single quote กัน formula execution เวลา reviewer เปิดใน spreadsheet (printf ตรง ๆ ก็ได้แต่ต้องระวัง byte เหล่านั้นเอง ถ้า cell มาจาก generated/user-supplied text) (3) คอลัมน์: ts (ISO8601), phase, decision (หนึ่งบรรทัด), why (ภาษาพูด plain — ถ้า principle ผลักดันก็บอกเป็นคำพูด เช่น "explored options first, this was a one-way door" ไม่ใช่ jargon tag), evidence (pointer เดียว), result (เช่น tests green, reverted, pixel-diff 0, INCONCLUSIVE, open) (4) log เฉพาะ decision points + checkpoints: fork ที่เลือก, unit จบพร้อมผล verify, pivot/revert พร้อม trigger, blocker ที่ปลุก, gate ที่แก้; loop run = หนึ่ง row ต่อ iteration; ข้ามเรื่อง trivial (5) เก็บที่ decisions.tsv ใน work dir หรือ .audit/<task-slug>.tsv เมื่อหลายงานรันพร้อมกัน — default ไม่ commit; commit เมื่องานใหญ่พงที่ reviewer ต้องใช้ trail เชื่อผล (port ข้ามภาษาใหญ่, migration หลายสัปดาห์) ซึ่ง TSV ใน PR จะ render เป็นตาราง (6) ท้าย run: audit log กับ transcript ของ workspace ปัจจุบัน แล้วรัน cross-model review subagent

เป็น audit-trail skill ที่ skill อื่น route มาหา: figure-it-out (Phase D) เรียกใช้ และ poteto-mode route งาน long/autonomous เข้า skill นี้; log text ต้องผ่าน unslop; อ้าง principle-encode-lessons-in-structure (evidence จาก committed script ที่ reviewer รันซ้ำได้ ดีกว่า hand-made one-off); ใช้ references/decision-log-template.tsv + scripts/log.sh ในตัวเอง

Skill adversarial review ด้วย reviewer subagent หลายตัวที่ spawn อิสระต่อกัน — หนึ่ง reviewer ต่อหนึ่ง subagent type ที่ configured ไว้ ทุกตัวได้ prompt + rubric เดียวกัน แล้ว synthesize เป็น verdict เดียวที่แบ่ง finding เป็น Act on / Consider / Noted / Dismissed พร้อม Agreement Map; deliverable คือ verdict เท่านั้น — ห้าม auto-apply การแก้โค้ด

Insight เฉพาะของ port นี้ (ต่างจากแนว multi-model แบบ upstream) คือ: ZCode รัน subagent ทุกตัวบน session model ดังนั้น adversarial signal ไม่ได้มาจาก model คนละตระกูล แต่มาจาก "the reviewers' distinct postures and tool scopes (a reviewer type reads a diff differently than an architect type), not assigned personas" — ใช้ type จริงที่มี tool scope ต่างกันแทนการสวม persona ประกอบกับ statistical framing ของ review: "Agreement across independently spawned reviewers is high-confidence signal; single-reviewer findings are worth reading but lower confidence" และ synthesize step ทำมันจริง (consensus = raised by 2+ reviewers, dedup, จด disagreement) มี Step 2 "State the Intent" บังคับเขียน intent หนึ่งย่อหน้าก่อน spawn เพื่อชี้ว่า reviewer ท้าทาย "งานบรรลุ intent ดีไหม" ไม่ใช่ "intent ถูกไหม" และ lead judgment ประกาศชัดว่า "You are the lead reviewer, a pragmatic senior engineer, not a neutral aggregator" — ใช้บริบทเต็ม (goal, constraints, timeline, tradeoffs ที่เคยพิจารณาแล้ว) เพราะ reviewer เห็นเพียง slice ของ codebase นอกจากนี้ section Dismissed ที่บังคับแสดงว่าอะไรถูกกรองทิ้งเพราะอะไร (เพื่อให้ user override ได้) และ robust ต่อ misconfiguration: type ที่ spawn ไม่ได้ให้หยิบตัวใกล้เคียงจาก error แล้วเปิด PR แก้ config แยก — "Do not block the review on the type issue"

เรียกด้วย /interrogate (มี disable-model-invocation: true) — trigger ตาม description: "interrogate", "adversarial review", "multi-subagent review", "challenge this", "stress test this code", "find blind spots", "tear this apart" ขั้นตอนภายใน: (1) Determine scope — ใช้ไฟล์/diff ที่ user ชี้, ถ้าอยู่ feature branch รัน git diff main...HEAD, หรือเก็บไฟล์จาก recent work; package diff + context files ที่ reviewer ต้องใช้ (2) State the intent — เขียนย่อหน้าเดียวจาก user message / commit messages / PR description / ตัวโค้ด; ถ้า intent ไม่ชัด ให้ถาม user ก่อน (3) Spawn reviewer ทุกตัวพร้อมกันใน message เดียว — ใช้ list "interrogate reviewers" จาก ~/.zcode/pstack-roles.md ถ้ามี (หนึ่ง reviewer ต่อ entry, ปรับ label A/B/C/D ตามจำนวน) ไม่งั้นใช้ default: Reviewer A = code-reviewer, B = code-architect, C = poteto-agent, D = general-purpose; ทุกตัวได้ template เดียวกัน (references/reviewer-prompt.md) ใส่ intent + diff + rubric (references/rubric.md) + code-quality lens (references/code-quality-review.md) (4) Synthesize — parse ทุก finding, หา consensus (ยกโดย 2+ reviewers = สัญญาณสูงสุด), deduplicate การพูดต่างคำเรื่องเดียวกัน, จด disagreement ที่ reviewer หนึ่ง flag และอีกตัวบอกตรงข้าม (5) Lead judgment — แบ่งทุก finding เป็น Act on / Consider / Noted / Dismissed พร้อมบอก reviewer ที่ยก + rationale หนึ่งบรรทัด (6) Present ตาม format: Intent / Reviewers / Act On / Consider / Noted / Dismissed / Agreement Map

how skill (Critique mode) ใช้ lead-judgment framework เดียวกันกับ interrogate (ไฟล์ how ระบุ "Same framework as the interrogate skill") และใช้ critic types ชุดเดียวกัน (code-reviewer, code-architect, poteto-agent, general-purpose); configurable ผ่าน ~/.zcode/pstack-roles.md ซึ่งเขียนโดย /setup-pstack; ต่างจาก review ทั่วไปตรง deliverable เป็น synthesized verdict — ไม่แก้โค้ดตาม

Design-before-implement skill ของ pstack: sketch types, function signatures, และ module boundary เป็น 'not implemented' bodies ก่อนเขียนโค้ดจริง ผ่าน 5 phase — Ground, Sketch, Agree, Implement, Scrap — โดย Phase Sketch จะรัน arena แบบ 'design it twice' ให้ได้ candidate โครงสร้างคนละแบบอย่างน้อย 2 ตัวมา synthesize เป็น design package เดียว แล้วค่อย implement เติมเนื้อใส่ skeleton ทีหลัง

กลไกเด็ด ๆ จากไฟล์: (1) บังคับ 'Design it twice' — ต้องมี candidate ที่ structurally distinct อย่างน้อยสองตัวก่อน synthesis เสมอ 'even when the first looks sufficient' คือ principle exhaust-the-design-space ทำเป็นขั้นตอนจริง (2) grounding มีมาตรฐานวัด: 'Naming a file isn't grounding' — ต้องได้ traced model ที่ how skill กำหนด ถ้า design แตะ ownership/layering ต้องรัน why ให้ rationale กลายเป็น constraint ไม่ใช่เดา (3) เกณฑ์เทียบ candidate คือ 'interface depth' — เลือก design ที่ซ่อน complexity ได้มากหลัง public surface ที่เล็กและง่าย (4) มีกลไกจับ architecture ที่ผิดตั้งแต่ Phase E ผ่าน pattern ของ friction: workaround รูปเดียวกันเกิดซ้ำข้ามโค้ด, types ที่ต้องใช้ escape hatch (any, casts, optional fields), 'we need a lock' reflex, callers ต้องรู้กฎภายใน — 'The signal is a pattern, not single instances' แล้ว scrap ด้วยหลัก subtract-before-you-add ให้ sketch ใหม่เล็กกว่าเดิม (5) deviation จาก sketch เป็นสัญญาณต้อง surface ไม่ใช่ดูดซับเงียบ ๆ — ต้องถามว่า sketch ผิด, requirement หลุด, หรือ implementation ฝืนเกิน

เรียกด้วย /architect หรือพูด 'architect this' / 'design this' — ใช้กับงาน non-trivial ที่กระโดดลงโค้ดเลยอาจล็อก shape ผิด ขั้นตอน: (A) Ground — รัน how บน subsystem ที่แตะ (critique mode ถ้าโครงเดิมคือ constraint หรือ design ต้อง push back) ข้ามได้เฉพาะ greenfield แท้ ๆ (B) Sketch — รัน arena พร้อม references/runner-prompt.md ให้ runner (default: code-architect, poteto-agent, code-reviewer, general-purpose ปรับได้ที่ ~/.zcode/pstack-roles.md) ผลิต design package ตาม references/rationale-template.md: เขียน caller's usage ก่อนแล้วค่อย derive type sketch, function signatures, module map — คัดทุก candidate ผ่าน references/design-red-flags.md (shallow module, information leakage, temporal decomposition, pass-through method) (C) Agree — default ลุย implement ต่อเลยไม่มี human checkpoint ถ้าจะให้หยุดขอ sign-off ต้องพิมพ์ '/architect with checkpoint' หรือ 'stop and show me before implementing' (D) Implement — เติม body แทน 'not implemented' โดย synthesized sketch คือ contract deviation ต้อง surface (E) Scrap — friction ซ้ำรูปเดียวกัน 2+ จุด = ทิ้ง sketch, รัน how ใหม่บนสิ่งที่สร้างไปแล้ว, ออกแบบใหม่ให้เหมือน constraint ใหม่เป็น day-one assumption แล้วกลับไป Phase B

ต้องมี how (Phase A grounding — 'Naming a file isn't grounding') และ arena (Phase B sketch เรียก arena พร้อม runner-prompt) — ทางเลือกเสริม: why (เมื่อ design แตะ ownership/layering), interrogate (กดดัน design แบบ adversarial ก่อน implement), และ principle skills ที่อ้างในไฟล์: exhaust-the-design-space, foundational-thinking, outcome-oriented-execution, redesign-from-first-principles, fix-root-causes, subtract-before-you-add

Skill แข่งขัน prototype: fan-out N parallel candidates ลง task เดียวกัน แล้วอ่านทุก candidate จบ เลือกตัวแข็งสุดเป็น base graft ไอเดียเด็ดของตัวแพ้อีกที และ verify ผลรวม — 6 phase: Frame, Fan out, Cross-judge, Pick, Graft, Verify ใช้ได้กับทุก artifact ที่พยายามครั้งเดียวอาจล็อก shape ผิด ทั้ง design, โค้ด และเอกสาร

แก้ single-attempt lock-in ด้วยการแข่งจริงและกลไกกันหลอกตัวเองครบ: (1) 'the prompt is the contract' — Phase A ต้อง derive rubric เป็น 3-6 criteria ที่วัดได้จริง ('Adds a --dry-run flag that skips writes' ไม่ใช่ 'code is correct') และ rubric เห็นเฉพาะ picker ไม่ให้ candidate เห็น กันการทำตาม rubric แบบจำใจ (2) mandatory rationale ต่อ candidate — 'Without it, the parent cannot tell whether a candidate's structure is principled or accidental' ทำให้ graft ไม่พัง (3) cross-judge แยกจาก parent: spawn readonly judge (subagent_type: "Explore") โดย prefer type ที่ไม่ได้ผลิต candidate เอง แล้วเทียบกับการอ่านของ parent — 'Disagreement means one of you is biased or the rubric was ambiguous' (4) กฎ graft ที่คม: ตัวแพ้มักมีของดีแค่ 1-2 อย่าง ต้อง fold ด้วยมือไม่ paste กล และ 'The rejection notes are the highest-signal part of the record' (5) จับสัญญาณ meta ได้: candidate เกิดรวมกันเป็น shape เดียว = consensus ส่งได้เลยไม่ต้อง graft, diverge สุด ๆ = Phase A under-specified ให้ reframe แล้ว rerun ไม่ใช่เฉลี่ยความเห็น (6) Phase F ยังต้องพิสูจน์ตามปกติ — 'The arena does not earn you a pass'

เรียกด้วย /arena หรือ 'arena this' / 'throw it in the arena' — ใช้เมื่อ non-trivial artifact ควรลองหลายแบบก่อน หรือถูกเรียกเป็น sub-step ของ architect (design sketch) และ blast-radius (change ใหญ่ให้ถามหลาย model แล้ว merge) ขั้นตอน: (A) Frame — ประกาศ artifact, rubric 3-6 ข้อ, เลือก runner จาก 'arena runners' ใน ~/.zcode/pstack-roles.md (default อย่างละหนึ่ง: poteto-agent, code-reviewer, code-architect, general-purpose — ซ้ำ type ได้ถ้างาน generation-bound), กำหนด output path แยกต่อ candidate (worktree หรือ /tmp/arena-<slug>/candidate-<n>/) (B) Fan out — spawn N ตัวใน message เดียว run_in_background: true พร้อม task + grounding path + output path + บังคับ rationale ตัวไหนตายใช้ N-1 แล้ว note dropout (C) Cross-judge — หลัง candidate จบครบ spawn judge ตัวเดียวแบบ readonly (subagent_type: "Explore") จาก 'arena cross-judge pool' ให้คะแนนตาม rubric และเสนอ base (D) Pick — parent อ่าน candidate ทุกตัวจบ ให้คะแนน criterion ต่อ criterion เทียบกับ judge แล้วบันทึก synthesis note (E) Graft — เด็ดของดีจากตัวแพ้ fold ด้วยมือ (F) Verify — พิสูจน์ artifact สุดท้าย

ถูกเรียกใช้โดย architect (ต้องมี arena เป็น Phase B) และ blast-radius (change ใหญ่ให้รันเป็น arena) — ภายในเรียก principle prove-it-works ตอน Phase F, redesign-from-first-principles ตอน graft, separate-before-serializing-shared-state ผ่าน output path แยกต่อ candidate; arena ของ design ต้องมี grounding artifacts จาก how (ส่งผ่าน architect)

Skill fan-out แบบเบาสุดของ pstack: ปล่อย N background workers ขนานกัน (แบ่ง slice คนละส่วน, แข่ง brief เดียวกัน, หรือผสมทั้งสอง) แล้ว parent รอ รวมผล ส่ง report เดียวกลับ — 4 phase: Frame, Fan out, Aggregate, Report ต่างจาก arena ตรงที่ arena เน้นเลือก-graft artifact เดียวที่ชนะ ส่วน swarm เน้น coverage และรายงานรวม

เรียบแต่คมตรงจุดที่ fan-out พังบ่อย: (1) 'N is total workers, not a concurrency limit' — ตัดสับสนระหว่างจำนวนงานกับ concurrency ตั้งแต่ต้น (2) กำหนด selection rule ก่อน spawn สำหรับ race — ต้องประกาศ 'first pass', 'rank all', หรือ 'best-of' ล่วงหน้า ไม่ใช่มาตัดสินทีหลังให้เข้าทางผล (3) 'Every brief stands alone' — แต่ละ worker ต้องได้ goal, scope, slice/arm, วิธี verify, และรูปแบบ report ตายตัว PASS / ISSUES / BLOCKED พร้อม evidence ทำให้ aggregation อ่าน terminal result จบในตัว (4) แยกผล coverage (ทุก slice ต้องมี result) ออกจาก race (ใช้กฎที่ประกาศไว้) และห้าม paste ดิบ — 'Do not paste raw worker dumps' ต้องย่อเป็น compact result table + one-line evidenced issues + gaps/dropouts (5) dropout ไม่ล้มระบบ: ทำต่อด้วย N-1 แล้ว note ไว้ใน report

เรียกด้วย /swarm หรือ 'swarm this' — เหมาะกับ parallel coverage (ตรวจหลายหน้า/หลาย module), race (หลายวิธีทำงานเดียวกัน), gauntlet และ exploration ขั้นตอน: (A) Frame — ประกาศ done predicate + artifact/report ที่ต้องได้, เลือก shape (partition slices / race N workers / ผสม), ถ้า race ประกาศ selection rule ก่อน spawn, ตั้ง N, เลือก worker type จาก 'swarm workers' ใน ~/.zcode/pstack-roles.md (default poteto-agent), race ต้องตั้งชื่อ approach ของแต่ละ arm ล่วงหน้า, แยก writable output ต่อ worker (worktree / branch / /tmp/swarm-<slug>/worker-<n>/) (B) Fan out — spawn N ตัวพร้อมกันใน message เดียว run_in_background: true, brief ทุกใบ standalone, worker ที่ต้องเริ่มจาก non-default pushed branch จะ checkout เอง (C) Aggregate — อ่าน terminal result, เช็คว่าทุก required slice มี result, ใช้ race rule ที่ประกาศไว้ (D) Report — รายงานเดียวใน chat: table + issue one-liner + gaps/dropouts + race rule ที่ใช้

เป็น skill ปลายทางที่ parent รวมผลเอง ไฟล์ไม่มี require pairing ตรง ๆ — ใช้คู่กับ arena เมื่ออยากได้ artifact ที่ชนะแล้ว graft ต่อ (swarm = coverage/report, arena = race + synthesize artifact เดียว), ถูก poteto-mode chain เป็นหัวหอก fan-out ขนาน และใช้ worker type จาก ~/.zcode/pstack-roles.md ชุดเดียวกับ skill อื่นของ pstack

Skill วิเคราะห์ก่อน ship ว่า change ไปโดนอะไรข้างนอก diff: 'Find what a change breaks somewhere else, before it ships' — เน้นหา 'the one fact it's safe because of' แล้วพิสูจน์ fact เดียวนั้นด้วยการรันโค้ดจริง แทนการเขียน writeup ยาว เป็น companion ของ how (โค้ดทำอะไร) กับ why (ทำไมโครงแบบนี้) โดย blast-radius ตอบว่ามันทำให้อะไรพังที่อื่น

กลไกที่ต่างจาก impact analysis ทั่วไป: (1) 'Listing the callers is not the job. The agent can grep those in a second. The job is the breakage grep won't show you' — สนใจ JSON ที่ API ส่งกลับ, DB column, wire format, ภาษาอื่นที่อ่าน byte เดียวกัน, feature flag, โค้ดสาม hop ถัดไป (2) ต่อต้าน writeup ที่หลอกตัวเอง: 'A blast-radius writeup that sounds right is worthless' — ต้องหา fact ที่ความปลอดภัยทั้งก้อนพิงอยู่แล้ว prove ด้วย script/test ที่เรียกโค้ดจริง 'Words are where you start, not what you ship' (3) มีบันไดความมั่นใจ 5 ขั้น: You said so → pointed at the line (file:line จริง) → showed the bad case can't happen → ran it → reproduced it in the running app โดย 'Step 4 is usually one small script' และ fact ไหนไปไม่ถึงขั้น 4 ต้องบอกตรง ๆ ว่า unproven ห้ามเขียนเป็น settled (4) ทุ่มเวลากับ fact เดียวไม่ใช่ list of maybes — 'Most changes that look scary are safe because of a single fact' (5) change ใหญ่ให้รันเป็น arena เพราะ 'Different models catch different real bugs'

เรียกด้วย 'blast radius of X', 'what could this break' หรือเวลารีวิว diff เล็กที่ยังไม่เชื่อ ขั้นตอน 6 ข้อ: (1) อ่าน change — symbols ที่ add/change/delete และสิ่งที่ diff ไม่พิมพ์บอก (pull PR/commits ด้วย why step 2) (2) หา the one safe fact (3) ลงลึกจุดที่ grep ไม่ถึง: อ่าน source ของ library ที่เรียก เช็ค pinned version กับ local patch, ไล่เวลาการรัน (microtasks, unmount/teardown, Solid versus React) (4) ให้ risk แต่ละตัวมี chance จริงกับ cost จริง แยก 'risks ที่ยืนยันแล้ว' ออกจาก 'cleared ที่เช็คแล้วผ่าน' อ้าง file:line เสมอ ห้ามแต่ง caller/API (5) prove the one fact — เขียน script/test รันโค้ดจริง พร้อม paste ผล พิสูจน์ไม่ได้ถูก ๆ ก็ mark unproven ห้าม round up (6) change ใหญ่/กว้าง → รันเป็น arena ส่งกลับ 5 ส่วน: What it does / The one fact (proven หรือ unproven) / Risks / Cleared / Before you merge (test หรือ repro ที่ถูกที่สุดที่จับบั๊กจริง)

บริบทกลุ่ม understand: how (อธิบายว่าโค้ดทำอะไร) + why (pull PR/commits และ rationale ของโครง — ไฟล์ระบุ 'Use why step 2 to pull the PR and commits') — ตัวมันเองถูกกำหนดให้: change ใหญ่รันเป็น arena (step 6), writeup ต้องเขียนผ่าน unslop, และใช้แนวการอ้างหลักฐานเดียวกับ why (file:line จริง, การ search ไม่เจอก็ยังเป็นคำตอบ, ห้ามแต่ง caller)

Skill แก้บั๊กแบบ test-first: เมื่อบั๊กมี test path ที่ชัดและถูก ให้ทำ broken behavior ให้ executable ก่อนแตะ production code — เขียน regression test เล็กที่สุดที่ fail ก่อน fix แล้ว pass หลัง fix พร้อม guardrail ชัดว่าเมื่อไหร่ไม่ควรฝืนเขียน test (แพง, brittle mocks, integration-heavy) ให้ใช้ verification ที่ใกล้ตัวสุดแทน

เป็น TDD ที่รู้จักยอมอย่างมีเหตุผล กันการผลิต test ขยะ: (1) เงื่อนไข fail-for-the-right-reason — 'Run the new test before fixing. Confirm it fails for the intended reason. If it passes or fails for an unrelated reason, correct the test or reproduction before editing the implementation' คือหัวใจ red-green ที่หลายคนข้าม (2) test ต้อง encode intended behavior ไม่ใช่ mirror implementation ปัจจุบัน (3) นิยาม bad test ตรงตัว: test ที่ test mocks เป็นหลัก, encode implementation details, ขึ้นกับ timing หรือ unrelated global state, ต้องใช้ infra แพง หรือจะถูกลบทันทีหลังพิสูจน์ fix — 'Prefer no new test over a bad test' (4) ห้าม skip เงียบ ๆ ถ้า failing test impractical ต้องอธิบายเหตุผลก่อนแล้วเลือก closest executable regression check (script, manual repro, browser automation, snapshot, log assertion) (5) Final response รายงาน evidence ไม่ใช่แค่ผลลัพธ์: ชื่อ test ที่ fail ก่อน, ที่ pass หลัง, และ validation ข้างเคียงที่รันไป

เรียกด้วย /tdd หรือใช้เมื่อ user ขอ TDD, failing test, หรือ regression test โดยตรง หรือเมื่อบั๊กมีจุด test ที่ชัดและถูก — ตัว skill เองกำหนดให้ skip เมื่อ test path ไม่ชัด แพง หรือ integration-heavy ขั้นตอน 7 ข้อ: (1) เข้าใจบั๊ก: intended vs current behavior, affected path, repro เล็กสุดที่ observable (2) เลือก check ที่แคบที่สุดที่ executable ได้ โดยเอา unit/component/integration test ที่ codepath นั้นมีอยู่แล้วถ้าไม่มี practical path อย่าสร้างขึ้นใหม่เพื่อผ่าน workflow (3) เขียน failing test ก่อน (4) รันยืนยันว่า fail ด้วยเหตุผลที่ตั้งใจ (5) แก้ production เปลี่ยนน้อยที่สุดให้ตรง intended behavior โดยคง contract รอบ ๆ (6) รัน regression test ซ้ำให้ผ่าน (7) รัน validation ข้างเคียง (test ใกล้เคียง, type check, lint, scenario check) ถ้า change เสี่ยงกว้าง — ถ้า failing test impractical ห้ามข้ามเงียบ ต้องอธิบายเหตุผลก่อนแล้วใช้ closest executable check แทน

จับคู่ธรรมชาติกับ playbook Bug fix ของ poteto-mode (fan-out how + why แบบขนานก่อน แล้ว tdd ตรงขั้นแก้) — ในไฟล์ไม่มีการเรียก pstack skill อื่นต่อ แต่ guardrail ของมันอยู่หมู่เดียวกับ principle prove-it-works (ต้องมี failing-before/passing-after evidence) และเสริมได้ด้วย verification skill ของโปรเจกต์ (verify-*) เวลาต้อง repro บน app จริง

Skill กำจัด AI-slop ออกจากงานเขียนทุกชนิด: scan pattern 31 กลุ่ม (puffery, AI vocabulary อย่าง delve/landscape/testament, 'Not just X, but Y', rule of three, em dash overuse, chatbot phrases, filler, สำนวนเมตาฟอร์เทคนิคอย่าง substrate/ratchet) แล้วเขียนใหม่ให้คงความหมาย เพิ่มเสียงมนุษย์ และ self-audit ต่อ ใน frontmatter ระบุว่า 'Must always apply' — เป็น skill ที่ทั้ง pstack ชุดและชุมชนภายนอกหยิบไปใช้มากที่สุด

ไม่ใช่แค่ ban list: (1) ครึ่งหลังของงานคือ 'Adding soul' — 'Removing patterns is half the job. Sterile, voiceless writing is just as obvious' ให้มี opinion, ผสมจังหวะประโยค, ยอมรับความซับซ้อน ('Impressive but also kind of unsettling' beats 'impressive'), ปล่อยความไม่เป๊ะบ้างเล็กน้อย (2) กติกาละเอียดถึงระดับ anti-tell ซ้อนกัน: ห้าม em dash ทั้งหมด และห้ามหนีไปใช้ parenthesis แทน ('reaching for parentheses instead just trades one tell for another') (3) กลุ่ม 'Plain speech' เปลี่ยนจากความรู้สึกเป็นกลไก/ตัวเลข: 'Say what it does, not how it feels' — 'SQL you can read' ต้องกลายเป็น '.toSQL() returns the exact string sent to the database' พร้อมเทสความจำเจ: 'if the sentence could appear unchanged in another project's docs, it says nothing about this one. Cut it.' (4) จับ adverb ที่หนุน verb อ่อน ('An adverb propping up a weak verb means the verb is wrong') และ jargon เมตาฟอร์ ('Gold-plating' becomes 'more than the job needs', 'Ratchet' becomes 'a limit that only tightens') (5) เป็น dependency ของ skill หลายตัว — technical-writing บังคับใช้กับทุก doc ที่แตะ, blast-radius ให้เขียนผ่าน unslop, automate-me ใช้เป็น prose discipline ทุกบรรทัด

ไม่ต้องเรียกเองก็ถูกหยิบใช้เวลา agent เขียน/แก้ prose แต่เรียกตรงได้ด้วย /unslop หรือขอให้ไล่ slop ในไฟล์ ขั้นตอน 4 ข้อ: (1) Scan pattern ตามหมวดในไฟล์ — Content (puffery, name-dropping, superficial -ing phrases, promotional language, vague attributions, formulaic challenges), Language (AI vocabulary, fancy ways to say 'is', 'Not just X, but Y', rule of three, synonym cycling, false ranges), Style (em dash, colon คั่นกลางประโยค, boldface, inline-header lists, title case, emoji, curly quotes), Communication artifacts (chatbot phrases, cutoff disclaimers, sycophancy), Filler (In order to → To, excessive hedging), Jargon (abstract metaphor nouns), Plain speech (feelings over mechanisms, dense sentences, passive voice, adverbs, fancy synonyms) (2) Rewrite คงความหมาย ตรง intended tone (3) Add soul ตามหัวข้อ Adding soul (4) Self-audit ด้วยคำถาม 'What makes this obviously AI generated?' แล้วแก้ที่เหลือ

ตัวเสริมกลางของทั้งชุด: technical-writing (คู่บังคับ — unslop เป็นเจ้าของ catalog ของ slop pattern, technical-writing เป็นเจ้าของโครงสร้าง 4 ชั้น และให้เพิ่ม metaphor ใหม่เข้ากฎ abstract-metaphor ของ unslop ต่อ), blast-radius (writeup ต้องผ่าน unslop), automate-me (ใช้กับทุกบรรทัดของ mode skill), poteto-mode (กฎเขียน anti-slop อ้างแนวคิดเดียวกัน) — ตัวมันเองไม่เรียก skill อื่นต่อ

Skill จัดการ comment ในโค้ดแบบ adversarial: spawn subagent 'Comment Sicko' (subagent_type: comment-sicko จาก plugin) มาล่า comment ทั้ง scope/diff, parent ตรวจ report ของมันอย่างไม่เชื่อ, ลบ comment ที่ยอมรับ, แก้ที่ root cause จริงแทนการเก็บ workaround, และถ้า comment ขังข้อจำกัดที่เปลี่ยนไม่ได้จริง ให้ offer encoding เป็น type/lint/test/CI ก่อนแล้วค่อยลบ

สถาปัตยกรรมที่จับ failure mode ของงาน 'ลบ comment' ได้ครบ: (1) 'Authoring agents defend comments. Defer to Comment Sicko's fresh perspective' — แยกผู้โจมตีออกจากผู้เขียนโค้ดเดิม (2) parent ไม่รับของมาทั้งก้อน: ต้อง reject application-code edits, scope escapes, exception-protected deletions, MUST KILL ที่ให้เหตุผลผิด และ flag ที่เล็ง intentional code และกติกาที่คมที่สุด: 'A keep survives only with proof it is about something we cannot change' (3) มีวงจรลงโทษต่อ report พัง: revert แล้ว rerun report ที่ถูก reject หนึ่งครั้งพร้อมระบุความผิด reject ซ้ำ = report เป็น open และ fail /no-comments ทั้ง run (4) ข้อจำกัดที่ลบไม่ได้ต้อง encode ไม่ใช่เก็บ comment ไว้ — offer lint/type/test/CI ที่ถูกที่สุดรอ interactive approval ผ่านแล้ว encode แล้วลบ comment (5) แก้ที่ root cause ใน scope ถ้า root cause อยู่นอก scope ให้ land fix เล็กสุดใน scope แล้ว report ที่เหลือ open — 'Neither authorizes widening the fence nor fixing instances outside it'

เรียกด้วย /no-comments หรือคำตรง ๆ เรื่อง comment ขั้นตอน 6 ข้อ: (1) Spawn Agent ด้วย subagent_type: "comment-sicko" ส่ง scope (ไฟล์/diff ที่ caller ให้ หรือ diff กับ base branch default main รวม working tree) ห้ามสรุปกฎของ Comment Sicko ซ้ำใน prompt (2) ตรวจ report และ diff — reject สิ่งที่เกินขอบเขต/ผิดเหตุผล, audit lint กับ TypeScript suppressions ที่มันข้าม, รัน /how หรือ /why ก่อนยอมรับ kill/keep แบบบาง ๆ (IMPORTANT, do not remove), rerun หนึ่งครั้งถ้า reject (3) Fix accepted flags ง่าย ๆ ตรง ๆ (ลบ dead path, ตัด parameter, ใช้ API จริง) ถ้า fix ต้องการ shape รัน /architect หนึ่งครั้งสำหรับ accepted set — หยุดที่ sketch ให้ขั้น 4 implement (4) Implement fix ที่ root cause ที่เล็กที่สุดใน scope ถอด workaround ทุกตัวที่ถูกชี้ (5) Constraint comment (do not remove / do not change wording / talk to X before changing) → offer encoding ที่ถูกสุด รอ interactive approval ถ้าผ่าน encode แล้วลบ ไม่ผ่านก็ลบ comment แล้ว report constraint เป็น open (6) Report: จำนวนที่ลบ, ที่ restore, reruns, architect sketch, fixes, encoding ที่ offer/ที่ทำ, unenforced constraints และงาน open อื่น

เรียกต่อเอง: comment-sicko (subagent ผู้ล่า comment), /architect (เมื่อ accepted fixes ต้องการ shape — sketch เท่านั้น), /how หรือ /why (ไขข้อกำกวมของ kill/keep ก่อนตัดสิน) — อ้าง principle-fix-root-causes และ principle-redesign-from-first-principles เป็นเจตนาของขั้น implement โดยทั้งคู่ไม่ให้อำนาจขยาย scope

มาตรฐานการเขียนเทคนิค 4 ชั้นที่รวมวิธีเด่นของโลกไว้ในไฟล์เดียว: Diátaxis (เลือกโหมดเอกสารก่อน — tutorial/how-to/reference/explanation), Google developer style (ประโยคคุยกับ reader), STE (โหลด statement ทีละหนึ่ง), และ Global English (ประโยคตีความได้ทางเดียว) มี 3 กฎครอบหัว: ตัดทุกคำที่ไม่ทำงาน, ใช้คำสั้นทั่วไป, และเมื่อกฎทำให้ประโยคแย่ให้แก้อีกทางหรือปล่อย — ใช้กับ docs, RFC, readme, PR description และ commit message

(1) มีเป้าวัดรูปธรรม: 'The goal is writing a tired engineer understands on the first read' และแต่ละชั้นตอบคำถามเดียว (ชนิดเอกสาร / ประโยคพูดกับใคร / ประโยคแบกเท่าไหร่ / อ่านสองทางได้ไหม) (2) กันเอกสารที่ 'ถูกกฎทุกข้อแต่ดูเหมือนเครื่องเขียน' ด้วยส่วน Vary the rhythm — ผสมความยาวประโยคตั้งใจ, มีความเห็นได้เฉพาะใน explanation, เจาะจงเหนือ sterile ('a column rename fails the build' ไม่ใช่ 'schema changes can cause issues') (3) กฎต่อต้าน jargon ปลอม: 'The codebase is the word list' — ใช้ symbol/ไฟล์/flag/command จริง ไม่ใช้คำบรรยายแทน และเจอ metaphor ใหม่ให้เพิ่มเข้ากฎ abstract-metaphor ของ unslop (4) มี worked example ที่ตรวจซอยกลับทีละข้อต่อชั้น ทำให้เป็น checklist ที่สอนได้จริง (5) ขอบเขตยุติธรรมชัด: PR description กับ commit message นับเป็นงานเขียน (ทุกชั้นยกเว้น Diátaxis), UI copy ไม่อยู่ใน scope, ทุก claim จำนวน/tree ต้องจริง ณ commit ที่ land พร้อมคำสั่ง regenerate

เรียกด้วย /technical-writing หรือใช้เวลาเขียน/รีวิว docs, RFC, readme, PR description, commit message กระบวนการ: (1) เลือกโหมด Diátaxis ก่อนด้วยสองคำถาม: บอก action (doing) หรือ understanding (thinking) × ใช้เพื่อ learning หรือ work — หนึ่งเอกสารหนึ่งโหมด ห้ามผสม (ตาราง reference ไม่มีใน tutorial, การโต้แย้งไม่มีใน how-to) ให้ split แล้ว link (2) เขียนประโยคแบบ Google: คุย reader ว่า 'you' present tense, คำสั่งเป็น imperative, เงื่อนไขวางหน้าคำสั่ง ('To delete the document, click Delete.'), common case มาก่อน, ห้าม 'simply/easy/quickly' ใน procedure, heading บอกประเด็น ('Pick the mode first' ไม่ใช่ 'Modes') (3) โหลด statement ทีละอันแบบ STE: หนึ่งคำสั่งต่อประโยค ตัด instruction เกิน ~20 คำ ประโยคอื่นเกิน ~25, เตือนวางหน้า step ที่มันป้องกัน, คง article 'the/a' ที่ตัดแล้วอ่านกำกวม, หนึ่งคำหนึ่งความหมายหนึ่งงาน (4) ปิดช่องสองความหมายแบบ Global English: only/not แนบคำที่มันแก้, แตก noun string ยาว, this/it ชี้สิ่งเดียวที่ชัด, ไม่ใช้ and/or กับ (s), เรียกสิ่งเดียวกันด้วยชื่อเดียวทั้งเอกสาร (5) ผ่าน unslop กับทุก doc ที่แตะ (6) ปิดท้ายด้วย review checklist 8 ข้อในไฟล์

คู่บังคับกับ unslop (unslop ถือ catalog ของ slop pattern, ตัวนี้ถือโครงสร้าง 4 ชั้น — ต้องใช้ร่วมกันเสมอ) — อ้างแหล่งตรง: diataxis.fr, developers.google.com/style, asd-ste100.org (STE Issue 9, 2025), Kohl The Global English Style Guide — ใช้ร่วมกับ automate-me เวลาเขียน mode skill และเป็นมาตรฐานของ writeup ที่ skill ฝั่ง review เช่น blast-radius ผลิต

คู่มือกฎ TypeScript แบบตารางสั้น 16 ข้อที่ให้ apply principle type-system-discipline ก่อนแล้วเกาะ syntax ของ TS: discriminated unions, branded types, constructive modeling (ออกแบบ shape ให้ค่าผิดสร้างไม่ได้), unknown แทน any, ห้าม as cast, narrowing hierarchy, exhaustiveness ด้วย never, satisfies, boundary validation, schema-derived types และอื่น ๆ — examples เต็มอยู่ที่ references/patterns.md

ปรัชญาชัดตั้งแต่แถวแรกของตาราง: 'No optional-field bags' — model ให้ impossible states แทนค่าไม่ได้ (1) Constructive modeling คือหัวใจ: '[T, ...T[]] for non-empty, [T, T][] for even length, start plus duration for a range. Not a runtime guard, not a wish for refinement types' — ให้ type ป้องกันแทนการเขียน guard รอบด้าน (2) ปานกลางอย่างมีเหตุผล: 'Keep T[] while every operation on it stays total. Strengthen to NonEmpty<T> only where the loose type forces !, a cast, or a should never happen throw' — ไม่บังคับ hyper-strict ทุกที่ (3) จัดอันดับ narrowing ให้เลือกได้: discriminant switch > in operator > typeof/instanceof > user-defined type guard > as และเตือนว่า type guard ที่โกหกแย่กว่า as เพราะ 'the bug hides behind a name that says it is safe' (4) ผูกกับงานจริง: 'Don't mock what you can run' ในกฎ Real tests, ไม่มี console.log ใน shipped code (ใช้ structured telemetry), object args ยกเว้น hot path — รวมทั้ง type discipline และ testability ไว้ไฟล์เดียว

ไม่ต้องเรียก — skill ออกแบบให้ apply เมื่ออ่านหรือแก้ไฟล์ .ts/.tsx ใด ๆ (auto-invoke) วิธีใช้ตามไฟล์: apply principle type-system-discipline ก่อน แล้วเดินตารางกฎ: (1) model variant ด้วย discriminated union ที่มี kind literal discriminant (2) brand primitive ด้วย '& { readonly __brand: "X" }' เมื่อต้องกันการสลับกัน โดย validate ครั้งเดียวตอนสร้าง (3) เลือก simplest total type ก่อน ค่อย strengthen เมื่อถูกบังคับ (4) external data เป็น unknown, cast เฉพาะหลัง validation, ใช้ satisfies ก่อน as (5) inline 'const _exhaustive: never = x;' ใน default arm เพื่อให้ compiler error เมื่อเพิ่ม variant ใหม่ (6) derive type ด้วย Pick/Omit/Parameters/ReturnType/Awaited/typeof ก่อนประกาศ interface ใหม่ (7) ส่ง object args แทน positional ยกเว้น hot path (per-frame render, tokenizers, parsers) (8) test ด้วยของจริงของ framework พร้อม leak/disposable checks ลด mock เฉพาะของที่รัน local ไม่ได้

apply principle-type-system-discipline ก่อนเสมอ (ระบุในบรรทัดแรกของ body) และอ้าง principle-boundary-discipline ในกฎ boundary validation — ใช้คู่กับ tdd (กฎ Real tests: 'Don't mock what you can run') และ verification skill ของโปรเจกต์เมื่อต้อง 'verify UI in a running build'; ตัวอย่าง pattern อยู่ที่ references/patterns.md ของมันเอง

Skill เก็บเกี่ยวบทเรียนจาก session ปัจจุบัน: spawn reviewer 3 มุมแบบขนาน (Judgment, Tooling, Divergent) ไล่อ่าน transcript ที่ active อยู่, ส่งผลให้ synthesizer แยกเป็น Accepted/Rejected/Backlog, เช็คซ้ำว่า lesson ไหนควร encode เป็น lint/script/flag มากกว่าข้อความใน skill, แล้วเสนอ user approve ก่อน route เป็น edit ของ skill ที่มีอยู่จริงหรือสร้าง skill ใหม่ผ่าน skill-creator

ปิดวงจร 'เรียนรู้แล้วเก็บจริง' ของทั้งชุด โดยมีราวกันขยะครบ: (1) เกณฑ์ skip ก่อนแรง — 'Skip when the conversation is trivial, off-topic, or already covered by an existing skill the parent followed correctly. One-offs are not learnings' พร้อม trigger ตรวจได้ เช่น 'A complex task (5+ tool calls) just landed cleanly' หรือ 'The user corrected the agent's approach mid-task' (2) กันการข้าม workspace: หา transcript เฉพาะ session ปัจจุบัน 'Do not glob across other projects' session directories. That crosses workspace boundaries and reads private chats from unrelated projects' (3) แบ่ง 3 lens พร้อม reviewer type กำหนดเอง (default: Judgment = general-purpose, Tooling = code-reviewer, Divergent = general-purpose) และ reviewer ห้ามเขียนไฟล์ — parent เป็นคน apply เอง (4) Structural enforcement check: lesson ที่ lint rule/script/metadata flag/runtime check จับได้ดีกว่า ให้เลื่อนจาก Accepted ไป Backlog ตาม principle encode-lessons-in-structure — prose ใน skill เป็นทางสุดท้าย (5) 'Skill changes affect every future agent in the org; do not auto-apply' — ต้อง user เลือก subset ก่อนเสมอ (6) มี routing แยกความยาก: edit เล็ก parent ทำเอง, edit ใหญ่เกิน ~10 บรรทัด / tune description / สร้าง skill ใหม่ ให้ skill-creator ทำตาม draft/test/iterate loop

เรียกด้วย /reflect หรือพิมพ์ 'reflect' — ใช้เมื่องานซับซ้อนเพิ่งจบสวยและสูตรควรเก็บ, agent เจอ dead ends แล้วหาทางที่ใช้ได้ซึ่ง generalize ได้, user แก้วิธีทำงานกลางทาง, หรือ workflow ที่ non-trivial ยังไม่ถูกจับใน skill ไหน ขั้นตอน: (1) หา transcript ของ session นี้ (เช็คบรรทัดแรกของ JSONL ว่าตรง opening user prompt; ถ้าหาไม่เจอให้เขียน digest ย่อแทน) (2) Spawn 3 reviewer ใน message เดียว แต่ละตัวอ่าน references/judgment-reviewer.md, tooling-reviewer.md, divergent-reviewer.md แบบ verbatim (reviewer ต้องเป็น type ที่มี full tool access เพราะอาจต้องเช็ค ticket/trace ผ่าน MCP) (3) ส่งผลทั้งหมดให้ synthesizer 1 ตัว (general-purpose) อ่าน references/synthesizer.md ได้ Accepted/Rejected/Backlog list (4) Structural enforcement check — ย้ายข้อที่ lint/script จับได้ดีกว่าไป Backlog (5) นำเสนอรอ user approve แล้ว apply ตาม Routing field หรือส่ง Backlog เข้า tracker (6) สรุปสั้น ๆ ไม่มี preamble: edit ที่ apply, skill ใหม่, backlog ที่ไฟล์, ที่ drop พร้อมเหตุผล

ปลายทางหลักคือ skill-creator (plugin skill): edit เล็ก parent ทำตรง, edit ใหญ่ (~10+ บรรทัด) / tune description / new skill → skill-creator draft/test/iterate loop — อ้าง principle-encode-lessons-in-structure ที่ขั้น structural check, ใช้ reviewer types จาก pstack-roles.md เหมือน skill fan-out อื่น, และมี SKILL.md validator ให้รันบน skill ที่แตะถ้า environment มี

Flow แนะนำเป็นขั้นเพื่อเปลี่ยนนิสัยการทำงานของ user ให้เป็น -mode skill ส่วนตัว (เช่น jay-mode, priya-mode): เช็ค skill เดิมก่อน, ขุด transcript ของ workspace นี้ด้วย parallel mining subagents, ถามตรงด้วย AskUserQuestion, cluster ผลเป็นหมวด, ร่างผ่าน skill-creator + unslop, แล้ว land ผ่าน worktree/PR — update ซ้ำได้โดยขุดเฉพาะประวัติหลังแก้ครั้งล่าสุด

(1) ตัดสิน update vs สร้างใหม่ด้วยหลักฐาน: ดู git log -1 ของ skill เดิมเพื่อขุดเฉพาะ history หลังจากนั้น และถามแค่ 'what's changed or missing' ไม่ใช่เริ่มจากศูนย์ (2) การขุดประวัติมีเกณฑ์ความเชื่อถือ: 'Patterns seen in 2+ slices are high-confidence; lone signals are weak and usually get dropped' และแบ่งประวัติเป็น 3 slices (เช่น สองสี่สัปดาห์ล่าสุด) กัน overfit บทสนทนาเดียว (3) ใช้ AskUserQuestion แบบมีเหตุผล: หนึ่งสองคำถาม, 4-6 options, allow_multiple สำหรับคำถามหมวด, ตามด้วย free-form หนึ่งคำถาม — 'Don't dump 20 questions' (4) มีตัวอย่างรูปร่างให้อ่าน: poteto-mode คือตัวอย่าง shape แต่ห้ามลอกเนื้อหา ('the user's rules are not the same as poteto-mode's') (5) Guardrail ต่อต้าน skill ฟุ่มเฟือยตรงจุด: 'Reference, don't inline', 'Don't force symmetry' (ไม่มี process rules จริงก็ไม่ต้องมีหมวด Process), '"Communicate clearly" is not a section' แต่ 'Short paragraphs. Tables when comparing options.' ใช่ (6) รู้ว่า output ของตัวเองเป็น subjective — ไม่ทำ benchmark loop เอา vibe-check กับ user แทน และ default ตั้ง disable-model-invocation: true ให้ mode skill เพราะ 'they should only apply when the user explicitly invokes them'

เรียกด้วย 'automate me', 'create/update/refresh my -mode skill' หรือ 'turn my working style into a skill' ขั้นตอน 6 ขั้น: (0) เช็ค -mode skill เดิมใน .zcode/skills/**/*-mode/ และ ~/.zcode/skills/ ถ้ามี ยืนยันผ่าน AskUserQuestion ว่า update หรือเริ่มใหม่ (1) Mine history — หา transcript เฉพาะ workspace ปัจจุบัน (ZCode เก็บใต้ ~/.zcode/cli/) spawn parallel mining subagents ต่อ slice ไล่หา response preferences, delegation habits, verification posture, code/prose discipline, process conventions, meta preferences พร้อม evidence pointer (2) ถาม user ตรงด้วย structured questions สองรอบ + open question หนึ่ง (3) Cluster เป็น sections (Response style, Autonomy, Understand first, Subagents, Prose/code discipline, Review and verify, Process, Skills — ใช้เท่าที่ apply) (4) Draft ด้วย skill-creator — วางที่ .zcode/skills/<handle>-mode/ (หรือ personal ~/.zcode/skills/), description trigger ที่ชื่อ + /<handle>-mode + 'work in their style' ไม่ใช่ keyword generic, ตั้ง disable-model-invocation: true เป็น default (5) Iterate ผ่าน unslop + create-skill writing guidelines ให้ user ตรวจหลายรอบ ตัดอย่างโหด (6) Land ใน worktree เปิด PR ห้าม push main ตรง

Orchestrates สามอย่างตามที่ไฟล์ประกาศ: inline mining pass (ขุด transcript), skill-creator จาก skill-creator plugin (authoring + YAML rules + description-optimization loop), unslop (prose discipline ทุกบรรทัด) — ใช้ poteto-mode เป็นตัวอย่างรูปร่าง output (อ่านอย่างเดียว ห้ามลอกเนื้อหา) และ -mode skill ที่ได้ออกมาเป็น skill ประเภท disable-model-invocation ที่ user เรียกด้วยชื่อตัวเอง

Generator สร้าง project-local verification skill (.zcode/skills/verify-<app>/) ที่ drive app จริงแบบที่ user ใช้: 6 sections คือ Launch, Doctor, Drive, Evidence, Cleanup, Helpers พร้อม seed feature map (README + ไฟล์ต่อ feature 3-5 ตัวแรก) และบังคับให้รันคำสั่งของ skill ที่ generate ออกมาจนจบหนึ่งรอบก่อนส่งมอบ — รองรับทุก surface: web UI, CLI/TUI, desktop, API, mobile, library

(1) 'Interview the repo, not the user' — ตอบจาก codebase ก่อน ถาม user เฉพาะสิ่งที่มองไม่เห็น ครบ 5 มิติ: Surface (user แตะอะไร), Run (dev command ของ repo + ports/env/seed/auth), Drive (harness ที่มีอยู่ก่อนเสมอ: Playwright specs, expect scripts, PTY helpers แล้วค่อย generic recipe), Observe (evidence อะไรจับได้), Isolate (double-instance ได้ไหม — ถ้าไม่ได้เขียนไว้เลยว่า 'refusing to double-drive a shared instance beats corrupting the user's session') (2) เป้าผู้อ่านชัด: 'You write the generator's output for the next agent, not for a human: it will be read cold, mid-task, by an agent that has never seen the app' — จึงห้าม placeholder ตกค้าง ต้องเป็น selector/command จริงจาก repo นี้ (3) Doctor section คือไอเดียแหลม: one read-only check ตอบ 'is this instance worth driving?' ให้ agent รันก่อนทุกครั้งที่อะไรดูแปลก (4) Evidence มี proof standard ตายตัว: ขับ real user path ไม่ใช่ internal setters/test-only endpoints, จับ side effects (ไฟล์, rows, ข้อความ) คู่กับของที่เห็น และ verify dry-run ด้วยการ observe ไม่ใช่เชื่อชื่อ ('some dry-runs still touch the network or open a browser') (5) กลไกคุณภาพ: 'A generated skill that was never executed is a draft, not a deliverable' และ 'a cleanup that eats the proof fails this step'

เรียกด้วย /create-verification-skill หรือ 'make a control skill for this repo' — ใช้เมื่อโปรเจกต์ยังไม่มีวิธี scripted prove พฤติกรรม UI/CLI/service ขั้นตอน 5 ขั้น: (1) Interview the repo ตาม 5 มิติ — ถ้า checkout build/start ไม่ผ่านให้แก้ก่อน (หรือรายงานให้เป๊ะ) (2) Generate .zcode/skills/verify-<app>/SKILL.md พร้อม frontmatter (name: verify-<app> + description ที่ระบุ app, surface, และเมื่อไหร่ใช้ — ไม่มี frontmatter = skill ไม่ register) ครบ 6 sections: Launch (คำสั่งเริ่ม + สัญญาณ ready + teardown; CLI/TUI สั้นไม่มี server ให้ build ครั้งเดียวแล้ว drive ต่อ PTY/tmux session แยก), Doctor (read-only health check), Drive (harness recipe ด้วย stable handle จริง: ARIA labels, data attributes, prompt strings, route paths — ไม่ใช่ coordinate), Evidence (จับอะไร เก็บที่ไหน, มาตรฐาน proof), Cleanup (teardown สิ่งที่เรา start, ไม่ kill by process name, evidence รอด), Helpers (script ต้อง executable และโชว์ invocation ใน body) (3) Seed feature map: features/README.md + ไฟล์ต่อ feature (top 3-5) ตาม references/feature-map-example มี 4 H2: Sub-features, How to get to it (user POV), Driving it with <harness>, Gotchas (4) Prove: รันคำสั่งของ skill เองจบหนึ่งรอบ — launch, doctor, drive 1 mapped feature, จับ evidence, cleanup แล้วเช็คว่า evidence ยังอยู่; ทำ cleanup หลังทุก iteration ที่ล้มด้วย (5) Offer maintenance loop: ชี้ /maintain-verification-skill

คู่ lifecycle ตรง ๆ กับ maintain-verification-skill (create ครั้งเดียว, maintain เป็นงานประจำ — ไฟล์ปิดท้ายเองว่า 'Point the user at /maintain-verification-skill for keeping the map honest as the app changes') — ถูก setup-pstack เสนอตอนติดตั้ง pstack, ถูก poteto-mode chain ใน playbook ฝั่ง Shipping/verify, และมี principle-prove-it-works เป็นแนวคิดรากของทั้ง skill

งานประจำที่ทำให้ verification skill และ feature map ที่สร้างโดย /create-verification-skill ไม่โกหก: ส่ง read-only subagent ต่อ feature ไล่ source, จากนั้น coordinator ขับ live ครบทุก feature หนึ่งรอบ, แล้วปิดด้วย 1 PR ของ correction ที่พิสูจน์แล้ว — จบด้วย 1 ใน 3 outcomes ที่ต้องประกาศ: clean / changed / blocked

จับความจริงเรื่อง rot ไว้ตรงเป้า: 'A feature map rots the moment the app changes' และกำหนดหน่วยวัดให้เหมาะ — 'The unit of rigor is the feature, not every sentence: cover every feature file from source and exercise every feature live, without terminalising every bullet' (1) ขอบเขตแก้ไขเป็นเกราะ: แก้ได้เฉพาะ directory ของ verification skill 'Never edit product code during a run: a behavior the map describes that the app no longer does is either doc drift (fix the map) or a product regression (report it, don't paper over it in docs)' (2) แยก wave ชัด: source wave เป็น subagent อ่านอย่างเดียว (ต่อ feature ไฟล์ หนึ่งตัว) ที่ไม่ขับ app ไม่แก้ไฟล์ ส่ง summary + drift + recipe, ส่วน live pass อยู่กับ coordinator คนเดียว (3) live pass คุมสาม invariant ตลอดแม้จะพัง: doctor ก่อน drive และ reset/relaunch แทนการหวัง, evidence ที่จับแล้วต้องรอดทุก cleanup (เช็คที่ path ที่ระบุ ไม่ assume), 'nothing a drive started outlives that drive's usefulness' รวมซาก iteration ที่พัง (4) มาตรฐาน unreachable: verified-unreachable ได้เฉพาะเมื่อระบุ prerequisite จริง (auth, entitlement, OS, external state) และ route ที่ลองแล้ว (5) triage แยกสามถังไม่ปน: doc drift → แก้ map, harness gap → แก้ harness แล้ว re-drive, product gap → record ให้ user เท่านั้นห้ามเอาเข้า PR

เรียกด้วย /maintain-verification-skill หรือ 'audit the verify skill' — เป็นงาน periodic หลัง app เปลี่ยน ขั้นตอน: (0) Locate target — หา project-local skill ที่มี launch/drive sections + feature map (ปกติ .zcode/skills/verify-*/) หลายตัวให้ถามเลือก ไม่มีเลยให้หยุดและชี้ /create-verification-skill แทนการแต่งเอง (1) Index hygiene — อ่าน feature map README + glob sibling แก้ entry หาย/เกิน/ซ้ำ/ตาย (2) Source wave — spawn read-only subagent ต่อ feature พร้อมกัน แต่ละตัวตอบ 'how does this user-facing feature work?' จาก source พร้อม cite drift และส่ง live-verification recipe หนึ่งชุด รูปแบบ: summary / source entry points / drift or none / one recipe (3) Reconcile — ทุก feature ต้องมี summary ครบ รวม recipe ที่ซ้อนให้เหลือ app state น้อยที่สุด spot-check drift ที่ถูก cite และสแกน churn ล่าสุดหา user-facing surface ที่หลุดจาก map (ต้องมี source path จริงก่อนเรียกว่า missing) (4) Live pass — บังคับแม้ source ดูสะอาด: ทำตาม launch model ของ skill ตัวเอง (server/UI = instance เดียวขับ serial, CLI สั้น = session สดต่อ drive) ขับทุก feature อย่างน้อยหนึ่งครั้ง, doctor fail ที่มาจาก drift ให้แก้ใต้ edit scope แล้ว retry หนึ่งครั้งก่อนยอม blocked, teardown หลัง drive สุดท้ายของ run รวม re-proof (5) Triage สามถัง (6) Ship or stop — changed: PR เดียวของ proven corrections โดยอ่านทุกไฟล์ที่แก้ซ้ำก่อน, clean/blocked: ไม่มี PR รายงาน outcome กับ coverage อย่างตรงไปตรงมา

ต้องมี verification skill ที่มี launch/drive sections + feature map อยู่ก่อน (จาก /create-verification-skill หรือ project-local skill แบบเดียวกัน) — ภายใน spawn read-only subagents ต่อ feature ใน source wave (ประเภทตาม pstack-roles.md แบบเดียวกับ fan-out อื่น) และอาศัย Doctor/Drive/Evidence/Cleanup sections ของ verification skill เป้าหมายเป็นกติกาการขับใน live pass