Productivity & Meta — Teach, Handoff, Research, Prototype, เขียน Skill

บทก่อนหน้า (MP-1 ถึง MP-4) เป็นสาย engineering — ใช้ตอนกำลังเขียนโค้ดจริง ในโปรเจกต์เดียวกัน บทนี้เปลี่ยนมุมไปที่โฟลเดอร์ skills/productivity/ กับ skills/engineering/research และ skills/engineering/prototype — skill กลุ่มนี้ไม่ได้ช่วย "เขียนโค้ดฟีเจอร์" ตรง ๆ แต่ช่วยบริหารจัดการ session, ความรู้, และตัว skill เอง ซึ่งเป็นเลเยอร์ meta ที่ทำให้คุณทำงานกับ agent ได้อย่างยั่งยืนในระยะยาว ไม่ใช่แค่ session เดียวจบ

ทำไมสายนี้สำคัญกับ dev ทุกคน? เพราะงานจริงไม่ได้จบใน 1 conversation เสมอไป — บางทีคุณต้องเรียนเทคโนโลยีใหม่ข้ามหลายวัน, บางทีบทสนทนายาวจนใกล้เต็ม context window ต้องส่งไม้ต่อ, บางทีต้องเช็ก API ของ 3rd-party ให้ชัวร์ก่อนเขียนโค้ดจริง, บางทีไม่แน่ใจว่า state machine จะออกมาแบบไหนเลยอยากลองแบบทิ้งได้ก่อน — และสุดท้าย ถ้าทีมคุณอยากมี skill ของตัวเอง ต้องรู้วิธีเขียนให้ agent "เดาพฤติกรรมได้"

1. teach — ห้องเรียนที่มีความจำข้ามหลาย session

frontmatter ของ skill นี้ตรงมาก: description: Teach the user a new skill or concept, within this workspace. พร้อม disable-model-invocation: true — แปลว่านี่เป็น user-invoked skill agent จะไม่เรียกเองอัตโนมัติ คุณต้องพิมพ์เรียกมันตรง ๆ (เช่น /teach) พร้อม argument-hint: "What would you like to learn about?"

หัวใจของ skill นี้คือการ treat โฟลเดอร์ปัจจุบันเป็น teaching workspace ที่เก็บสถานะการเรียนรู้ไว้เป็นไฟล์จริง ไม่ใช่แค่อยู่ในความจำของบทสนทนาเดียว ตามไฟล์จริงมีโครง 6 ส่วน:

• MISSION.md — เหตุผลที่คุณอยากเรียนเรื่องนี้ ใช้ ground การสอนทุกครั้ง
• ./reference/*.html — cheat sheet/glossary แบบย่อ ออกแบบมาให้ print แล้วอ่านเร็ว
• RESOURCES.md — รายการแหล่งข้อมูลคุณภาพสูงที่ใช้ ground ความรู้
• ./learning-records/000N-*.md — บันทึกสิ่งที่เรียนไปแล้ว (คล้าย ADR ของวงการ dev) ใช้คำนวณ zone of proximal development
• ./lessons/000N-*.html — บทเรียนจริงแต่ละบท เป็นหน่วยการสอนหลัก
• NOTES.md — สมุดจดความชอบของผู้เรียน ที่ agent อ้างอิงตอนออกแบบบทถัดไป

ไฟล์ยังเน้นความต่างของ fluency strength (เรียกความรู้ได้ทันทีตอนนั้น แต่ลืมเร็ว) กับ storage strength (จำได้ระยะยาว) — เป้าหมายจริงคือ storage strength ซึ่งต้องอาศัย retrieval practice, spacing, และ interleaving — เหตุผลที่บทเรียนใน teach-me-ai แต่ละบทถึงจบด้วยกล่อง .exercise เสมอ ไม่ใช่แค่อ่านผ่าน

2. handoff — ส่งไม้ต่อให้ agent คนถัดไปแบบไม่ลืมของ

frontmatter: description: Compact the current conversation into a handoff document for another agent to pick up. พร้อม disable-model-invocation: true — เป็น user-invoked เหมือนกัน คุณต้องสั่งเอง เมื่อรู้ตัวว่าบทสนทนากำลังจะจบ (เช่น context ใกล้เต็ม หรือจะพักแล้วมาต่อพรุ่งนี้)

ตามไฟล์จริง กฎของเอกสาร handoff มี 4 ข้อ:

1. เซฟไว้ที่ temporary directory ของ OS — ไม่ใช่ในโปรเจกต์ (เพราะมันเป็นเอกสารชั่วคราว ไม่ใช่ artifact ถาวร)
2. ต้องมีหัวข้อ "suggested skills" — แนะนำว่า agent ตัวถัดไปควรเรียก skill ไหนต่อ
3. ห้ามซ้ำเนื้อหาที่มีอยู่แล้วใน artifact อื่น (spec, plan, ADR, issue, commit, diff) — ให้ชี้ path/URL แทนการ copy มาทั้งดุ้น
4. redact ข้อมูลอ่อนไหว เช่น API key, password, PII ก่อนเขียนลงไฟล์เสมอ

ถ้าคุณพิมพ์ argument ต่อท้ายคำสั่ง (เช่น "เตรียมต่อพรุ่งนี้เรื่อง migration PostgreSQL ไป partition table") ไฟล์บอกให้ agent ตีความมันเป็น "สิ่งที่ session ถัดไปจะโฟกัส" แล้วปรับเนื้อหาเอกสารให้ตรงจุดนั้น ไม่ใช่ dump ทุกอย่างแบบ generic

3. research — ปล่อย background agent ไปขุดของแทนคุณ

skill นี้อยู่ใน engineering/ และไม่มี disable-model-invocation — แปลว่าเป็น model-invoked agent เรียกเองอัตโนมัติได้เมื่อ description ตรงเงื่อนไข: Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.

งานของมันตามไฟล์จริงมี 3 ขั้นตอนตรง ๆ:

1. สั่งงานผ่าน background agent ให้ทำแทน — คุณทำงานอื่นต่อได้โดยไม่ต้องรอ
2. สืบค้นเทียบกับ primary source เท่านั้น — official docs, source code, spec, first-party API — ไม่ใช่บทความ secondary ที่คนอื่นเขียนสรุปมาอีกที ต้องตามทุก claim กลับไปหาต้นตอจริง
3. เขียนผลลัพธ์ลง Markdown ไฟล์เดียว พร้อมอ้างอิงแหล่งที่มาทุก claim — เซฟตามธรรมเนียมที่ repo มีอยู่แล้ว ถ้าไม่มีให้เลือกที่ที่เหมาะสมแล้วบอกว่าเซฟไว้ที่ไหน

4. prototype — โค้ดที่เขียนมาเพื่อทิ้ง

skill นี้ก็อยู่ใน engineering/ และเป็น model-invoked เช่นกัน: Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like. คำนิยามสั้นที่สุดในไฟล์คือ "prototype = throwaway code that answers a question คำถามเป็นตัวกำหนดรูปร่าง"

ก่อนลงมือ ไฟล์บังคับให้เลือก branch ก่อน — 2 ทางเท่านั้น:

คำถาม	Branch	สร้างอะไร
"Does this logic / state model feel right?"	LOGIC.md	terminal app เล็ก ๆ ที่ push state machine ผ่าน case ที่คิดบนกระดาษยาก
"What should this look like?"	UI.md	UI หลายแบบสุดขั้วบน route เดียว สลับด้วย URL search param + floating bottom bar

ถ้าคำถามกำกวมจริง ๆ และถามผู้ใช้ไม่ได้ ไฟล์ให้ default ตามโค้ดรอบข้าง (backend module → logic, page/component → UI) แล้วต้องระบุ assumption นั้นไว้บนสุดของ prototype

กฎที่ใช้กับทั้งสอง branch (คัดจากไฟล์จริง):

• Throwaway ตั้งแต่วันแรก และต้องระบุชัด — วางโค้ดใกล้กับที่จะใช้จริง แต่ตั้งชื่อให้คนอ่านรู้ทันทีว่านี่คือ prototype ไม่ใช่ production
• รันด้วยคำสั่งเดียว — ใช้ task runner ที่โปรเจกต์มีอยู่แล้ว (pnpm, python, bun ฯลฯ)
• ไม่ persist ข้อมูลโดย default — state อยู่ใน memory เท่านั้น (ถ้าคำถามเกี่ยวกับ database จริง ๆ ให้ใช้ scratch DB ที่ตั้งชื่อ "PROTOTYPE — wipe me" ชัดเจน)
• ข้าม polish ทั้งหมด — ไม่มี test, ไม่มี error handling เกินจำเป็น, ไม่มี abstraction
• แสดง state เต็ม ๆ ทุกครั้ง — หลังทุก action (logic) หรือทุกครั้งที่สลับ variant (UI)
• เก็บผลตอนจบ — เอา decision ที่ verify แล้วไปใส่โค้ดจริง แล้ว commit ตัว prototype เองเป็น primary source ลง throwaway branch แยก พร้อมทิ้ง context pointer และคำตัดสิน (verdict) ไว้ใน issue/commit — main branch เก็บแค่ decision ที่ validate แล้ว

5. writing-great-skills — คำศัพท์ที่ทำให้ skill "เดาพฤติกรรมได้"

frontmatter: description: Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable. พร้อม disable-model-invocation: true — user-invoked เช่นกัน เพราะนี่คือเอกสาร reference ล้วน ๆ (ไม่มี step ให้ทำตามลำดับ) สำหรับตอนคุณจะเขียนหรือแก้ skill เอง

ประโยคเปิดของไฟล์คือแก่นทั้งหมด: "A skill exists to wrangle determinism out of a stochastic system. Predictability — agent เดินกระบวนการเดิมทุกรอบ ไม่ใช่แค่ output ออกมาเหมือนเดิม — คือคุณธรรมหลัก ทุก lever ด้านล่างรับใช้เป้าหมายนี้" อธิบายคำศัพท์ สำคัญที่สุด 4 กลุ่มจากไฟล์:

Invocation — 2 แบบที่คุณเจอมาตลอดบทนี้

นี่แหละคือคำอธิบายอย่างเป็นทางการของสิ่งที่คุณเพิ่งเห็นใน 4 skill ก่อนหน้า:

• model-invoked — มี description ให้ agent อ่านแล้วยิงเองอัตโนมัติได้ (skill อื่นก็เรียกมันได้ด้วย) แลกกับ context load เพราะ description ต้องอยู่ใน context ทุก turn — วิธีเขียน: ไม่ใส่ disable-model-invocation แล้วเขียน description แบบมี trigger phrase ชัด ("Use when the user wants…, mentions…") → นี่คือ research กับ prototype
• user-invoked — ตัด description ออกจากสายตา agent เหลือแค่คุณพิมพ์ชื่อเรียกเอง zero context load แต่แลกด้วย cognitive load — คุณต้องเป็นคน "จำเอง" ว่ามันมีอยู่ วิธีเขียน: ใส่ disable-model-invocation: true → นี่คือ teach, handoff, และ writing-great-skills เอง

Information hierarchy — วางเนื้อหาให้ถูกชั้น

ไฟล์แบ่งเนื้อหาของ skill เป็นบันได 3 ชั้นตามว่า agent ต้องใช้ "ด่วนแค่ไหน": (1) in-skill step — ขั้นตอนเรียงลำดับใน SKILL.md ตรง ๆ ต้องจบด้วย completion criterion ที่ตรวจได้ (ไม่งั้นเกิด premature completion — จบงานก่อนที่จะจบจริง); (2) in-skill reference — กฎ/นิยามใน SKILL.md ที่เปิดดูเมื่อจำเป็น; (3) external reference — ผลักออกไปไฟล์แยก เข้าถึงผ่าน context pointer โหลดเฉพาะตอนที่ pointer ถูกกระตุ้นเท่านั้น — ตัวอย่างจริงที่คุณเพิ่งเห็น: prototype/SKILL.md ผลัก 2 กรณีลง LOGIC.md กับ UI.md แทนที่จะเขียนรวมไว้บนสุดหมด

Leading words & Pruning — คำเดียวแทนประโยคยาว, ตัดสิ่งที่ไม่จำเป็น

leading word คือคำที่ model มี prior อยู่แล้วจาก pretraining (เช่น "lesson", "fog of war", "tracer bullets") ใช้แทนคำอธิบายยาว ๆ ได้ในคำเดียว — ไฟล์ยกตัวอย่าง "fast, deterministic, low-overhead" ยุบเหลือคำเดียวว่า tight (a tight loop) ประหยัด token และให้ agent "เกาะ" ความคิดได้แม่นกว่า

ส่วน pruning คือวินัยตัดทิ้ง: เก็บแต่ละความหมายไว้ single source of truth เดียว, เช็คทุกบรรทัดว่ายัง relevant ไหม, และไล่จับ no-op — ประโยคที่ agent ทำตามอยู่แล้วโดย default (เช่น "be thorough" เป็น no-op เพราะ agent thorough-ish อยู่แล้ว แก้ด้วยคำที่แรงกว่า เช่น "relentless" ไม่ใช่เขียนยาวขึ้น)

Failure mode	อาการ	วิธีแก้ตามไฟล์
Premature completion	agent คิดว่าจบแล้วทั้งที่ยังไม่จบ	คม completion criterion ก่อน; ถ้ายังฟุ้งค่อยแยก step ออกจากกัน
Duplication	ความหมายเดียวซ้ำหลายที่	รวมเหลือจุดเดียว (single source of truth)
Sediment	ชั้นเก่าที่ทับถม เพราะเพิ่มง่ายลบยาก	ทำ pruning เป็นวินัย ไม่ใช่ทำครั้งเดียว
Sprawl	skill ยาวเกินไปทั้งที่ทุกบรรทัดยัง live	ผลัก reference ออกไปไฟล์แยก + แตกตาม branch
Negation	สั่งห้าม กลับยิ่งเรียกความสนใจไปที่สิ่งนั้น	บอกพฤติกรรมที่ต้องการตรง ๆ (positive) แทนคำสั่งห้าม

6. เลือกใช้ให้ถูกงาน

5 skill นี้ตอบคำถามคนละแบบ — เก็บตารางนี้ไว้เป็น cheat sheet เวลาลังเลว่าจะสั่งอะไร:

สถานการณ์	ใช้ skill	invoke
อยากเรียนเทคโนโลยีใหม่ยาว ๆ ข้ามหลายวัน/หลาย session	teach	พิมพ์เรียกเอง
บทสนทนายาวใกล้เต็ม context ต้องพักหรือส่งต่อ agent อื่น	handoff	พิมพ์เรียกเอง
ต้องเช็ก API/docs 3rd-party ให้ชัวร์ ไม่อยากรอ หรือปล่อยให้ทำเบื้องหลัง	research	agent เรียกเองได้
ไม่แน่ใจว่า state machine/logic หรือหน้าตา UI จะออกมาแบบไหน	prototype	agent เรียกเองได้
จะเขียน skill ของทีมตัวเอง หรือแก้ skill ที่มีอยู่ให้ predictable ขึ้น	writing-great-skills	พิมพ์เรียกเอง (อ่านเป็น reference)