Menü
งานเขียน โหมด exploit — ปั้นวัตถุดิบดิบให้เป็นบทความ ทีละย่อหน้า
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | writing-shape |
| description | งานเขียน โหมด exploit — ปั้นวัตถุดิบดิบให้เป็นบทความ ทีละย่อหน้า |
| disable-model-invocation | true |
user ได้ส่ง (หรือกำลังจะส่ง) ไฟล์ markdown ของวัตถุดิบดิบมาให้ ให้มองมันเป็นกอง input — จะเป็น list ของ fragment ที่เรียบเรียงมาแล้ว กำแพง prose ไร้โครงสร้าง หรือ transcript ก็ได้ format ไม่สำคัญ อ่านให้จบตั้งแต่ต้นจนท้ายก่อนทำอย่างอื่น
จากนั้นรัน session ปั้นรูปทรง (shaping) ที่ผลิตเอกสารบทความแยกออกมาอีกไฟล์ นี่คือโหมด exploit: ช่วงสำรวจจบไปแล้ว กองวัตถุดิบนิ่งแล้ว — ให้ commit กับโครงสร้างหนึ่งโครง แล้วขุดจากกองมาเติมให้เต็ม ห้ามแก้ไฟล์วัตถุดิบ — สำหรับ skill นี้ไฟล์นั้นเป็น read-only
ถ้า user ไม่ได้บอกว่าให้เซฟบทความไว้ที่ไหน ถามครั้งเดียวแล้วจำ path นั้นไว้
ทุก concept ต้องถูก ground ก่อนที่ block ไหนจะพิงมันได้: ผู้อ่านต้องรู้มันมาก่อนตอนเปิดอ่าน หรือได้เจอมันใน block ก่อนหน้าแล้ว block ที่เอื้อมไปหา concept ที่ยังไม่ grounded จะทำผู้อ่านหลุด หน่วยของเรื่องนี้คือตัว concept ไม่ใช่คำที่ใช้เรียกมัน — block อาจพิง idea ที่ผู้อ่านไม่มีได้ทั้งที่ไม่มี jargon สักคำ ส่วน concept ที่มีชื่อเรียก — มี term — การ ground มันหมายถึงส่งทั้ง idea และ term ลงจอดพร้อมกัน
concept ถูก ground ได้สองทาง:
เก็บ list ของสิ่งที่ grounded แล้วไว้ตลอด เวลาถามว่า "ผู้อ่านต้องได้ยินอะไรต่อ?" ถ้า move ถัดไปต้องใช้ concept ที่ยังไม่ grounded คำตอบก็คือตัว concept นั้นเอง: ต้อง ground มันก่อน — ตรงนี้เลยหรือใน block ก่อนหน้า — ไม่งั้นเดิน move นั้นไม่ได้ นี่คือการชี้ช่องว่างแบบเดียวกับ Pulling from the pile แต่ยกขึ้นมาอีกชั้น: ที่นั่นกองวัตถุดิบขาดเนื้อหา ที่นี่บทความขาดฐานราก
คานงัดอยู่ที่การเลือกว่าอะไรเป็น prerequisite และอะไรถูก ground ในตัวบทความ เรียกร้องจากผู้อ่านมากไปตั้งแต่ต้นก็เท่ากับปิดประตูใส่คนอ่าน แต่ถ้า ground ในบทความมากไป opening ก็จมอยู่กับนิยาม ตกลงเรื่องนี้กับ user ตอนตั้ง prerequisite
นี่คือ grilling session แบบกลับด้าน ตอน ideation คำถามคือ "จริง ๆ แล้วคุณกำลังสังเกตเห็นอะไร?" ที่นี่คำถามคือ "บทความนี้กำลัง argue อะไรกันแน่ และผู้อ่านต้องได้ยินมันเรียงลำดับแบบไหน?" ดันกลับด้วย อย่าปล่อย transition อ่อน ๆ ผ่านไปเฉย ๆ ถ้าย่อหน้าไหนไม่คู่ควรกับที่ของมัน ตัดทิ้ง
moves ที่ควรใช้ซ้ำ ๆ:
มองวัตถุดิบดิบเป็นเหมืองหิน ไม่ใช่ script ดึง fragment ออกมา ปรับให้เข้ากับย่อหน้ารอบ ๆ แล้ววางลงไป fragment ชิ้นหนึ่งอาจถูกหั่นกระจายไปหลายย่อหน้า ถูกควบรวมกับอีกชิ้น หรือถูก paraphrase ก็ได้ หน้าที่ของกองคือถูกขุด หน้าที่ของบทความคืออ่านแล้วเป็นเสียงเดียวกันทั้งเรื่อง
ถ้ากองวัตถุดิบขาดสิ่งที่บทความต้องการ ให้ชี้ช่องว่างออกมาตรง ๆ: "ตรงนี้ต้องมีตัวอย่าง แต่ในกองไม่มี — ให้มาเดี๋ยวนี้ หรือไม่ก็ตัด section นี้ทิ้ง"
เวลาเลือกว่าจะ render block ออกมาแบบไหน ให้ชั่ง tradeoff เหล่านี้ออกมาดัง ๆ กับ user อย่าตัดสินใจเงียบ ๆ:
> [!TIP], > [!NOTE]) — แต่เฉพาะกรณีที่ถ้าปล่อยไว้ inline แล้วมันจะลากประเด็นหลักออกนอกเรื่องจริง ๆ ไม่งั้นปล่อยไว้ inlineเขียนต่อท้ายไฟล์บทความทุกครั้งที่ block ตกลงกันได้ อ่านไฟล์จาก disk ใหม่ก่อนเขียนทุกครั้ง — user อาจแก้ไฟล์ระหว่างเทิร์น ห้ามเขียนทับสุ่มสี่สุ่มห้า ถ้า user อยากให้ rewrite ย่อหน้าไหน แก้เฉพาะย่อหน้านั้นตรงที่เดิม ที่เหลืออย่าไปแตะ
วางแผนงานก้อนใหญ่ — ใหญ่เกินกว่าหนึ่ง 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 นี้