Skills และ agents

DWP เป็นกลางต่อเอเจนต์ แต่มันคาดหวังบล็อกสร้างที่เกิดขึ้นซ้ำสองอย่าง — skill และ agent — และวิธีอันจงใจในการทำความเข้าใจ repository ก่อนเริ่มงานใด ๆ

skill เทียบกับ agent

องค์ประกอบ

สกิล

ทำอย่างไร — กระบวนการที่นำกลับมาใช้ซ้ำได้

fix-lint
add-component
translate-sync
dwp-create

เอเจนต์

ใครทำ — ผู้ปฏิบัติงานเฉพาะทาง

reviewer
executor
architect
i18n-guardian

.claude .agents ลิงก์สัญลักษณ์ → ความเข้ากันได้ย้อนหลัง

สกิลกำหนดวิธีดำเนินงานที่เกิดซ้ำ ส่วนเอเจนต์กำหนดผู้รับผิดชอบ ทั้งสองอยู่ภายใต้ `.agents/` ซึ่ง `.claude` อ้างถึงเป็นนามแฝงเพื่อความเข้ากันได้ย้อนหลัง

ทั้งสองสับสนกันได้ง่ายแต่มีจุดประสงค์ต่างกัน

Skills คือกระบวนการที่ใช้ซ้ำได้ซึ่งเรียกใช้ตามชื่อ skill บรรจุเวิร์กโฟลว์ที่ทำซ้ำได้ — การรันการทดสอบ การแก้ lint การสร้างคอมโพเนนต์ — เพื่อให้เอเจนต์และมนุษย์เรียกใช้มันในแบบเดียวกันทุกครั้ง
Agents คือผู้ทำงานเฉพาะทางที่มีบทบาทกำหนดไว้ — ผู้ทบทวน ผู้ดำเนินการ สถาปนิก แต่ละ agent มีความรับผิดชอบที่จดจ่อและทำงานภายในขอบเขตของตน

คำย่อที่มีประโยชน์ skill คือ วิธี ทำงานที่เกิดขึ้นซ้ำ ส่วน agent คือ ผู้ ที่รับผิดชอบงานประเภทหนึ่ง

kit ที่มีชีวิต: repository ปลูก skill ของตัวเอง

การออนบอร์ดเปลี่ยน repository ให้เป็น agent harness มันไม่ได้แช่แข็งมันไว้ kit มีไว้เพื่อ เติบโต ตามที่เวิร์กโฟลว์ของ repository ชัดเจนขึ้น DWP มอบ sub-skill ชื่อ author — เรียกใช้ผ่าน /skill-create และ /agent-create — ที่ให้เหตุผลเกี่ยวกับเลย์เอาต์ .agents/ และข้อตกลงที่มีอยู่ของ repository จากนั้นเขียน skill, agent หรือตัวส่งต่อคำสั่งบาง ๆ ใหม่ที่เข้ากันกับสิ่งเหล่านั้น repository เป็นผู้เขียน kit ของตัวเองแทนที่จะรับ kit ทั่วไปสืบทอดมา

sub-skill author จงใจในเรื่องความเหมาะสม มันสร้าง skill สำหรับกระบวนการที่ทำซ้ำได้ซึ่งคนรันด้วยมือ สร้าง agent สำหรับบทบาทที่เกิดซ้ำซึ่งมีความต้องการด้านโมเดลหรือเครื่องมือที่ต่างออกไป และสร้างคำสั่งเฉพาะในฐานะจุดเข้าบาง ๆ ที่ส่งต่อไปยัง skill หรือ agent มันข้ามสิ่งทั่วไปใด ๆ ที่ไม่ตรงกับเวิร์กโฟลว์จริง และคงแคตตาล็อก .agents/docs/ ให้สอดคล้องกับสิ่งที่มันเพิ่มเข้าไป sub-skill เดียวกันนี้หนุนหลังงานการค้นพบ Skills และ Agents ที่บังคับ ซึ่งกระทบยอดแคตตาล็อกเทียบกับสิ่งที่อยู่บนดิสก์จริง ๆ — และ /dwp-verify ยืนยันการกระทบยอดนั้นอย่างเป็นวัตถุวิสัย โดยล้มเหลวหากแคตตาล็อกและไฟล์แตกต่างกัน

ส่วนเสริมการบำรุงรักษา

นอกเหนือจากการเขียน DWP ยังจัดส่ง ส่วนเสริมการบำรุงรักษาแบบเลือกเข้าร่วม — ไม่เคยจำเป็นต่อการทำให้ repository เป็น AI-first ส่วนเสริม dependency-upgrade คือตัวอย่างมาตรฐาน มันให้เหตุผลเกี่ยวกับตัวจัดการแพ็กเกจ จริง ของ repository (npm, pnpm หรือ yarn พร้อม ncu; pip, poetry หรือ uv; Cargo; Go modules; Bundler; Composer) แทนที่จะสมมติเอาตัวใดตัวหนึ่ง จากนั้นอัปเกรดทีละชุดเล็ก ๆ รัน validation gate จริงของ repository หลังแต่ละชุด ย้อนกลับชุดใด ๆ ที่ล้มเหลว และสรุปผลโดยไม่ commit อัตโนมัติ ส่วนเสริม design-system คือตัวอย่างด้านอินเทอร์เฟซ: เมื่อ repository มีพื้นผิวอินเทอร์เฟซที่ผู้ใช้มองเห็น มันจะสร้าง DESIGN.md (ที่ docs/DESIGN.md อ้างอิงจาก AGENTS.md) ที่จับข้อตกลงจริงของ repository ตามโปรไฟล์ที่ตรวจพบ — UI เชิงภาพ (สี งานพิมพ์ ระยะห่าง คอมโพเนนต์ กฎการเข้าถึง) เอาต์พุต CLI (สไตล์เทอร์มินัลเชิงความหมาย แผงและสปินเนอร์ การลดระดับ TTY/NO_COLOR) และเชิงสนทนา (น้ำเสียงของข้อความ กายวิภาค และการเรนเดอร์ต่อแพลตฟอร์ม) — เพื่อให้เอเจนต์ทุกตัวสร้างเอาต์พุตอินเทอร์เฟซที่ตรงแบรนด์และสอดคล้องกัน โปรไฟล์เชิงภาพเปิดใช้งานเป็นค่าเริ่มต้นเมื่อตรวจพบระบบดีไซน์ โปรไฟล์ CLI และเชิงสนทนาถูกแนะนำเมื่อตรวจพบและถูกถามเสมอ และส่วนเสริมนี้ไม่เคยถูกเสนอให้กับ repository ที่ไม่มีพื้นผิวอินเทอร์เฟซใด ๆ เลย ส่วนเสริมถูกยอมรับอย่างชัดแจ้งระหว่างการออนบอร์ด การปฏิเสธส่วนเสริมหนึ่งทำให้ repository ยังคงสอดคล้องอย่างสมบูรณ์

การออนบอร์ด repository ที่อิงการให้เหตุผล

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

ระหว่างการออนบอร์ด เอเจนต์ระบุ archetype ของ repository (แบบเดี่ยวเทียบกับแบบ orchestrator) คำสั่ง build, test และ lint ข้อตกลงที่มีอยู่สำหรับสไตล์ โครงสร้าง และการตั้งชื่อ และ skill กับ agent ที่มีอยู่แล้ว ความเข้าใจนี้คือสิ่งที่ทำให้เอเจนต์วางแผนและดำเนินการในแบบที่เข้ากันกับ repository แทนที่จะขัดแย้งกับมัน

Toolchain การทดสอบและการตรวจสอบได้รับความใส่ใจเป็นพิเศษ เพราะ validation gate คือสิ่งที่ทำให้ผลลัพธ์ของแผนเชื่อถือได้ เมื่อ repository มีการทดสอบและตัว lint อยู่แล้ว การออนบอร์ดจะบันทึกคำสั่งและข้อตกลงที่มีอยู่จริงของมัน เมื่อมันไม่มีเลย การออนบอร์ดไม่ได้เพียงบันทึกช่องว่างนั้น — มันเสนอการตั้งค่าที่เหมาะกับสแตกและเขียนมันลงในคู่มือการทดสอบของ repository เพื่อให้ทุกแผนในอนาคตมี gate จริงให้รันแทนที่จะเป็น gate ที่ไม่ได้นิยามไว้

ไดเรกทอรี `.agents/` และ symlink `.claude → .agents`

DWP รวบรวมทุกอย่างที่นิยามพฤติกรรมของเอเจนต์ — skill, คำสั่ง, การนิยาม agent, เอกสารภายใน และการตั้งค่า — ไว้ภายใต้ไดเรกทอรีมาตรฐานเดียวคือ .agents/ ชื่อนี้สื่อว่าเนื้อหาถูกใช้ร่วมกันข้ามเอเจนต์แทนที่จะผูกติดกับเครื่องมือใดเครื่องมือหนึ่ง

เพื่อความเข้ากันได้ย้อนหลังกับเครื่องมือที่เคยอ่านจาก .claude/ พาธนั้นคือ symlink ไปยัง .agents/

ls -la .claude
# .claude -> .agents

ทุกพาธ .claude/... แปลงไปยัง .agents/... ที่เทียบเท่าได้อย่างโปร่งใส เครื่องมือเก่าจึงทำงานต่อได้ ในขณะที่เนื้อหาใหม่อ้างอิงตำแหน่งมาตรฐาน .agents/ skill และ agent ถูกแก้ไขผ่านไฟล์จริงภายใต้ .agents/ ไม่ใช่ผ่าน symlink