القائمة
อ้างอิงสำหรับการเขียนและแก้ไข skill ให้ดี — คำศัพท์และหลักการที่ทำให้ skill ทำงานได้อย่างคาดเดาได้
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
วางแผนงานก้อนใหญ่ — ใหญ่เกินกว่าหนึ่ง agent session จะรับไหว — เป็นแผนที่ร่วมของ ticket สำหรับการ investigate บน issue tracker ของคุณ แล้วไล่ resolve ทีละใบจนกว่าเส้นทางไปยังจุดหมายจะชัด
สร้าง interface design หลายแบบที่ต่างกันสุดขั้วสำหรับ module หนึ่ง โดยใช้ sub-agent แบบ parallel ใช้เมื่อ user อยากออกแบบ API, สำรวจตัวเลือกของ interface, เปรียบเทียบรูปทรงของ module หรือพูดถึง "design it twice"
QA session แบบ interactive ที่ผู้ใช้เล่าบั๊กหรือปัญหาแบบคุยกันธรรมดา แล้ว agent เปิด GitHub issue ให้ พร้อมสำรวจ codebase เบื้องหลังเพื่อเก็บ context และภาษา domain ใช้เมื่อผู้ใช้อยากรายงานบั๊ก ทำ QA เปิด issue แบบคุยกัน หรือพูดถึง "QA session"
สร้างแผน refactor แบบละเอียดที่ซอยเป็น commit เล็ก ๆ ผ่านการสัมภาษณ์ user แล้วเปิดเป็น GitHub issue ใช้เมื่อ user อยากวางแผน refactor สร้าง refactoring RFC หรือแตก refactor ออกเป็นขั้นเล็ก ๆ ที่ปลอดภัย
สกัด glossary ภาษากลางสไตล์ DDD จากบทสนทนาปัจจุบัน พร้อมชี้จุดกำกวมและเสนอ term มาตรฐาน เซฟลง UBIQUITOUS_LANGUAGE.md ใช้เมื่อผู้ใช้อยากนิยามศัพท์ domain สร้าง glossary ทำ terminology ให้แน่น สร้าง ubiquitous language หรือพูดถึง "domain model" หรือ "DDD"
ถามว่า skill หรือ flow ไหนเหมาะกับสถานการณ์ของคุณ เป็น router ที่ครอบ skill ทั้งหมดใน repo นี้
| name | writing-great-skills |
| description | อ้างอิงสำหรับการเขียนและแก้ไข skill ให้ดี — คำศัพท์และหลักการที่ทำให้ skill ทำงานได้อย่างคาดเดาได้ |
| disable-model-invocation | true |
skill มีไว้เพื่อรีดความ deterministic ออกจากระบบที่ทำงานแบบ stochastic (สุ่มโดยธรรมชาติ) Predictability — การที่ agent เดิน_กระบวนการ_เดิมทุกครั้งที่รัน ไม่ใช่การผลิต output เหมือนเดิม — คือคุณสมบัติรากฐาน กลไกทุกตัวด้านล่างมีไว้รับใช้สิ่งนี้
คำตัวหนา มีนิยามอยู่ใน GLOSSARY.md เปิดดูที่นั่นเพื่อความหมายฉบับเต็ม
มีให้เลือกสองแบบ แลกกันคนละต้นทุน:
disable-model-invocation และเขียน description ให้ model อ่าน พร้อม trigger phrase ที่ครอบคลุม ("Use when the user wants…, mentions…")disable-model-invocation: true แล้ว description จะกลายเป็นข้อความสำหรับคนอ่าน — สรุปหนึ่งบรรทัด ตัด trigger list ทิ้งเลือก model-invocation ก็ต่อเมื่อ agent ต้องเข้าถึง skill นั้นได้ด้วยตัวเอง หรือ skill อื่นต้องเรียกมัน ถ้ามันถูกเรียกด้วยมือเท่านั้น ให้ทำเป็น user-invoked แล้วไม่ต้องจ่าย context load เลย
เมื่อ user-invoked skill เพิ่มจำนวนจนเกินกว่าจะจำไหว cognitive load ที่กองสะสมนั้นแก้ได้ด้วย router skill: skill แบบ user-invoked ตัวเดียวที่บอกชื่อ skill ตัวอื่น และบอกว่าเมื่อไหร่ควรหยิบตัวไหน
description แบบ model-invoked ทำงานสองอย่าง — บอกว่า skill นี้คืออะไร และไล่รายการ branch ที่ควร trigger มัน ทุกคำที่เพิ่มเข้าไปเพิ่ม context load ดังนั้น description ต้องถูก prune หนักยิ่งกว่าตัว body เสียอีก:
skill ประกอบจากเนื้อหาสองชนิด — step และ reference — ที่ผสมกันได้อิสระ: skill หนึ่งอาจเป็น step ล้วน reference ล้วน หรือทั้งคู่ การตัดสินใจหลักคือจะใช้ชนิดไหน และแต่ละชิ้นควรอยู่ตรงไหนบน information hierarchy — บันไดที่จัดอันดับตามว่า agent ต้องใช้เนื้อหานั้นเร่งด่วนแค่ไหน:
SKILL.md เป็นชั้นหลัก: สิ่งที่ agent ทำ ตามลำดับ แต่ละ step จบด้วย completion criterion เงื่อนไขที่บอก agent ว่างานเสร็จแล้ว ทำให้มัน_เช็คได้_ (agent แยกออกไหมว่าเสร็จหรือยังไม่เสร็จ?) และในจุดที่สำคัญ ให้มัน_ครอบคลุมถ้วนทั่ว_ ("ทุก model ที่ถูกแก้ต้องถูกไล่ครบ" ไม่ใช่ "ทำรายการการเปลี่ยนแปลงออกมา") — criterion ที่คลุมเครือเชื้อเชิญ premature completionSKILL.md ที่เปิดดูเมื่อต้องใช้ บ่อยครั้งเป็นชุดเนื้อหาระนาบเดียวที่เท่ากันโดยชอบธรรม (กฎทุกข้อของ review อยู่บนขั้นเดียวกัน) — เป็นการจัดวางที่ดี ไม่ใช่กลิ่นไม่ดี skill นี้ทั้งไฟล์คือ referenceSKILL.md ไปอยู่ไฟล์แยก เข้าถึงผ่าน context pointer และโหลดเฉพาะตอนที่ pointer ทำงาน (ครอบคลุมตั้งแต่ reference แบบ disclosed — ไฟล์พี่น้องอย่าง GLOSSARY.md ที่ยังเป็นส่วนหนึ่งของ skill — ไปจนถึง external reference เต็มตัวที่อยู่นอกระบบ skill และ skill ไหนก็ชี้ถึงได้)completion criterion ที่เข้มงวดผลักดันให้เกิด legwork ที่ทั่วถึง — การขุดคุ้ยที่ agent ทำระหว่างงาน — ไม่ว่า skill จะมี step หรือไม่ เพราะ "ทุกกฎถูกใช้ครบ" ผูกมัด reference ระนาบเดียวแบบเดียวกับที่ "ทุก step ทำครบ" ผูกมัด sequence
ดันลงไปน้อยเกิน ชั้นบนก็บวม ดันลงมากเกิน ก็ซ่อนเนื้อหาที่ agent ต้องใช้จริง ความตึงนี้แหละคือทั้งหมดของการตัดสินใจ
Progressive disclosure คือการเลื่อนลงบันได — ออกจาก SKILL.md ไปยังไฟล์ที่ link ไว้ — เพื่อให้ชั้นบนยังอ่านง่าย กลไก: ไฟล์ .md ที่ link ไว้ในโฟลเดอร์ของ skill ตั้งชื่อตามสิ่งที่มันเก็บ (skill นี้ disclose นิยามฉบับเต็มของตัวเองไปไว้ที่ GLOSSARY.md) skill บางตัวถูกใช้มากกว่าหนึ่งแบบ และแต่ละแบบที่ต่างกันคือหนึ่ง branch — การรันคนละครั้งเดินคนละเส้นทางผ่าน skill branching คือ disclosure test ที่สะอาดที่สุด: inline สิ่งที่ทุก branch ต้องใช้ และดันสิ่งที่มีแค่บาง branch เข้าถึงไปไว้หลัง pointer สิ่งที่ตัดสินว่า agent จะไปถึงเนื้อหาเมื่อไหร่และแม่นแค่ไหนคือ_ถ้อยคำ_ของ context pointer ไม่ใช่เป้าหมายของมัน
ขณะที่บันไดตัดสินว่าเนื้อหาชิ้นหนึ่งควรอยู่_ลึกลงไปแค่ไหน_ co-location ตัดสินว่า_อะไรควรอยู่ข้างมัน_เมื่อไปถึงตรงนั้นแล้ว: เก็บนิยาม กฎ และข้อควรระวังของ concept หนึ่งไว้ใต้ heading เดียวกัน ไม่ใช่กระจัดกระจาย เพื่อให้การอ่านส่วนหนึ่งพาเพื่อนบ้านของมันมาด้วย
Granularity คือความละเอียดในการแบ่ง skill และการตัดแต่ละครั้งจ่ายด้วย load หนึ่งในสองแบบ ดังนั้น split เฉพาะเมื่อการตัดนั้นคุ้ม การตัดมีสองแบบ:
เก็บแต่ละความหมายไว้ใน single source of truth: ที่ทางการที่เดียว เพื่อให้การเปลี่ยนพฤติกรรมเป็นการแก้ที่เดียวจบ
เช็คทุกบรรทัดเรื่อง relevance: มันยังเกี่ยวกับสิ่งที่ skill ทำอยู่ไหม?
จากนั้นล่า no-op ทีละประโยค ไม่ใช่แค่ทีละบรรทัด: รัน no-op test กับแต่ละประโยคแบบแยกเดี่ยว และเมื่อประโยคไหนสอบตก ให้ลบทั้งประโยคแทนที่จะเล็มคำออกจากมัน จงดุดัน — prose ส่วนใหญ่ที่สอบตกควรถูกลบทิ้ง ไม่ใช่ถูกเขียนใหม่
leading word คือ concept อัดแน่นที่มีอยู่ใน pretraining ของ model อยู่แล้ว ซึ่ง agent ใช้คิดตามระหว่างรัน skill (เช่น lesson, fog of war, tracer bullets) เมื่อถูกใช้ซ้ำทั่วทั้งข้อความ (แม้ไม่จำเป็นเสมอไป — leading word ที่แรงพออาจต้องใช้แค่ครั้งเดียว) มันสะสมนิยามแบบกระจายและตรึงพฤติกรรมทั้งย่านไว้ด้วย token น้อยที่สุด โดยดึง prior ที่ model ถืออยู่แล้วมาใช้งาน
มันรับใช้ predictability สองต่อ ใน body มันตรึง_การ execute_: agent หยิบพฤติกรรมเดิมทุกครั้งที่คำนั้นโผล่มา ใน description มันตรึง_การ invoke_: เมื่อคำเดียวกันอยู่ทั้งใน prompt เอกสาร และ code ของคุณ agent จะโยงภาษาที่ใช้ร่วมกันนั้นเข้ากับ skill และเรียกมันได้แม่นยำขึ้น
ล่าโอกาส refactor skill ให้ใช้ leading word อยู่เสมอ ชุดคุณสมบัติสามคำที่ถูกสะกดออกมาสามจุด (duplication) description ที่เปลืองทั้งประโยคเพื่อชี้ๆ ไปที่ idea เดียว — แต่ละอันคือข้อความที่ร้องขอให้ถูก collapse เป็น token เดียว ตัวอย่างเช่น:
คุณชนะสองต่อ: token น้อยลง และ ได้ hook ที่คมขึ้นให้ agent แขวนความคิด ให้ตั้งข้อสันนิษฐานว่าทุก skill กำลังแบกการพูดซ้ำที่ leading word ปลดระวางได้ — ไปหามันให้เจอ
ใช้รายการนี้วินิจฉัยปัญหาที่ user อาจเจอกับ skill