ลูปหลัก

DWP นิยามชุดปฏิบัติการขนาดเล็กที่เคลื่อนแผนจากเป้าหมายไปสู่งานที่เสร็จสมบูรณ์และทบทวนได้ ได้แก่ create → execute → refine → resume → status โดยมี verify เป็นการตรวจสอบความสอดคล้องที่ยืนยันผลลัพธ์ เมื่อรวมกันทั้งหมดจึงก่อเป็นลูปที่เอเจนต์ดำเนินตามตลอดอายุของแผน เอเจนต์ดำเนินงานทีละหนึ่งงาน ตรวจสอบแต่ละขั้นก่อนจะไปต่อ

ลูปนี้คือรูปแบบเชิงปฏิบัติการของ spec-driven development แผนคือข้อกำหนดที่เอเจนต์ดำเนินการเทียบกับมัน แต่ละงานมีเกณฑ์การยอมรับที่ชัดเจน และขั้นการตรวจสอบคือ gate ที่เปลี่ยนการกล่าวอ้างว่าเสร็จให้กลายเป็นหลักฐานว่าเสร็จ เพราะแผนและ progress log อยู่ใน repository ลูปจึงดำเนินต่อได้ข้ามเซสชันและข้ามเอเจนต์

ปฏิบัติการต่าง ๆ

สกิลระเบียบวิธีส่งต่อเจตนาไปยังเก้า sub-skill เฉพาะทาง: การดำเนินการหลักหกอย่าง, ตัวช่วยวงจรชีวิตสองอย่าง, และเอ็นจินการประพันธ์:

• create — สร้างแผนใหม่จากเป้าหมาย เอเจนต์วิเคราะห์เป้าหมาย แยกย่อยเป็นงานตามลำดับ และเขียนไฟล์แผน ในโหมด guided เอเจนต์จะทำให้แผน Liteเป็นรูปธรรมโดยตรง (กระชับและอยู่ใน README.md) โดยให้ผู้พัฒนาเลือกเก็บไว้ เลื่อนขั้น หรือแก้ไข; ในโหมด trust จะสร้างรูปแบบที่ขอ (Lite หรือ Full) โดยตรงโดยไม่ต้องถาม การวิเคราะห์ข้อกำหนดและการตรวจคุณภาพแผนทำงานในทั้งสองโหมด
• execute — ดำเนินแผนทีละงานตามลำดับ เอเจนต์อัปเดต progress log รัน validation gate และ commit หลังแต่ละงาน ในโหมด trust การดำเนินงานจะดำเนินต่อโดยอัตโนมัติโดยไม่ถามระหว่างงาน
• refine — ปรับปรุงแผนที่มีอยู่ (เพิ่ม แก้ไข แยก หรือจัดลำดับงานใหม่ หรือเลื่อนขั้นแผน Lite เป็น Full) โดยคงหลักฐานที่เสร็จแล้วไว้อย่างเคร่งครัดและห้ามผ่อนปรนเกณฑ์โดยไม่ยืนยัน
• resume — ดำเนินแผนที่ถูกขัดจังหวะต่อ เอเจนต์อ่าน journal แบบ append-only และไฟล์งานเพื่อสร้างสถานะขึ้นใหม่ จากนั้นดำเนินต่อจากงานที่ยังไม่เสร็จงานแรกโดยไม่ทำซ้ำงานที่เสร็จแล้ว
• status — รายงานความคืบหน้าโดยไม่ดำเนินการ (อ่านอย่างเดียว) เอเจนต์สรุปงานที่เสร็จแล้ว งานที่กำลังทำ และงานที่ค้างอยู่ โดยไม่เปลี่ยนแปลงสิ่งใด
• verify — ตรวจสอบความสอดคล้องโดยไม่เปลี่ยนแปลงสิ่งใด (อ่านอย่างเดียว) เอเจนต์รายงานว่า repository เป็นไปตามมาตรฐาน AI-first หรือไม่ และงานในแผนมีเกณฑ์ที่ชัดเจนและ validation gate หรือไม่
• onboard — ตรวจสอบ repository เป้าหมายเพื่อให้เหตุผล—ไม่คัดลอกแปะ—สำหรับ AGENTS.md ที่ปรับให้เข้ากัน ลำดับชั้น docs/ มาตรฐาน เอกสารโมดูล และชุด .agents/ พร้อม symlink ความเข้ากันได้
• upgrade — ตรวจสอบรีลีสต้นทาง ขอความยินยอมจากผู้พัฒนาก่อนดาวน์โหลด ติดตั้งแท็กเสถียรที่ตรึงไว้ และกระทบยอดการปรับแต่งเฉพาะที่โดยไม่แตะต้องแผน .dwp/ ที่มีอยู่
• author — สร้างหรือพัฒนา skill, agent หรือคำสั่ง slash ประจำ repo ให้ตรงกับเวิร์กโฟลว์จริงที่เกิดขึ้นซ้ำ และดูแลให้แคตตาล็อก .agents/docs/ ซิงค์อยู่เสมอ

ไดเรกทอรีผลลัพธ์ .dwp/

สิ่งประดิษฐ์ทั้งหมดของ DWP อยู่ภายใต้ไดเรกทอรี .dwp/ ที่ถูก gitignore ที่รากของ repository การเก็บพื้นที่ทำงานไว้นอกระบบควบคุมเวอร์ชันหมายความว่าสถานะการทำงานของแผนจะไม่ปนเปื้อนประวัติของโปรเจกต์ การกำหนดค่า addon ระดับ repository จะถูกบันทึกใน .dwp/config.json (dwp-config/v1) ขณะที่แผนต่าง ๆ จะอยู่ในไดเรกทอรีแบบมีหมายเลข:

.dwp/
├── config.json
└── plans/
    └── PLAN_001_<slug>/
        ├── manifest.json
        ├── contract.json
        ├── journal.ndjson
        ├── state.json
        ├── README.md
        ├── PROGRESS.md
        ├── 1.task_<slug>.md
        ├── 2.task_<slug>.md
        └── analysis_results/

โครงสร้างงานสิบส่วน

ไฟล์งาน

1. 01 ชื่อเรื่อง
2. 02 บริบท
3. 03 อ่านก่อนเริ่ม
4. 04 เป้าหมาย
5. 05 พื้นผิวที่แตะต้อง
6. 06 คำแนะนำ
7. 07 เกณฑ์การยอมรับ
8. 08 เอาต์พุต
9. 09 การตรวจสอบ
10. 10 รายการตรวจสอบการดำเนินการและบันทึกการเสร็จสิ้น

ไฟล์งานทุกไฟล์มีสิบส่วนมาตรฐานที่แสดงในแผนภาพด้านบน ตามลำดับที่กำหนดโดยสกิลที่ติดตั้ง

การตรวจสอบ การเสร็จสิ้น และการดำเนินต่อ

การตรวจสอบเป็นส่วนหนึ่งของงาน ไม่ใช่สิ่งที่นึกขึ้นได้ทีหลัง แต่ละงานระบุคำสั่งหรือการทดสอบที่พิสูจน์ว่ามันเสร็จแล้ว และเอเจนต์รันสิ่งเหล่านั้นก่อนทำเครื่องหมายว่าเสร็จ การทดสอบเป็นส่วนสำคัญลำดับแรกตรงนี้ — งานที่เพิ่มฟังก์ชันใหม่หรือเปลี่ยนพฤติกรรมต้องเพิ่มหรืออัปเดตการทดสอบอัตโนมัติสำหรับพฤติกรรมนั้นและรันการตรวจคุณภาพโค้ดทั้งหมดของ repository (การทดสอบพร้อม lint และ type-check) ไม่ใช่เพียงยืนยันว่า build สำเร็จ การทดสอบที่มีอยู่ต้องยังคงผ่าน โดยอัปเดตให้เป็นพฤติกรรมที่ตั้งใจไว้แทนที่จะข้ามมัน ความปลอดภัยเป็นเรื่องสำคัญลำดับแรกในแบบเดียวกัน — งานใดก็ตามที่แตะต้องการพิสูจน์ตัวตน การจัดการ input, secrets, พื้นผิวเครือข่าย หรือ dependencies จะนำพาความคาดหวังด้านความปลอดภัยของการเปลี่ยนแปลงนั้นไว้ในเกณฑ์การยอมรับของมัน และรักษาทุก commit ให้ปราศจาก secrets และทุกแผนปิดท้ายด้วย Final Review — การตรวจความปลอดภัยของชุดการเปลี่ยนแปลงทั้งหมด การตรวจสอบครบวงจรบนสถานะสุดท้าย และการกระทบยอดการตัดสินใจเรื่อง skill การเสร็จสิ้นถูกบันทึกด้วยเครื่องหมายสถานะที่ชัดเจน ([ ] ยังไม่เริ่ม, [~] กำลังทำ, [x] เสร็จ, [!] ติดขัด) ในส่วนการเสร็จสิ้นและ Log การดำเนินต่ออาศัยเครื่องหมายเหล่านี้และ progress log — เอเจนต์สามารถสร้างขึ้นใหม่ได้อย่างแม่นยำว่าแผนหยุดที่ใดและดำเนินต่อจากงานที่ยังไม่เสร็จงานแรกโดยไม่ต้องทำงานที่เสร็จแล้วซ้ำ

v6 และ v7: วิธีการเดิม โครงสร้างเข้มงวดยิ่งขึ้น

มาตรฐาน DWP ปัจจุบันคือ 7.0.0 ซึ่งนำไปใช้โดยสายผลิตภัณฑ์ skill 7.x แพ็กนี้ใช้ v7 สำหรับแผนใหม่ทุกแผนเป็นค่าเริ่มต้น ส่วนคำขอ v6 อย่างชัดเจนยังคงสร้างแผน v6 แผน v1, v2, v5 และ v6 ที่มีอยู่ยังคงรุ่นที่บันทึกไว้และจะไม่ถูกย้ายโดยไม่มีการแจ้ง การย้ายแผน v5 ไป v6 ต้องมีคำขอย้ายอย่างชัดเจน

v6 คงวิธีการแผน → งาน → ประตูตรวจสอบ → เสร็จสิ้น คำสั่ง slash และตำแหน่ง .dwp/plans/ ไว้เหมือนเดิม เพิ่มโครงสร้างวิศวกรรมที่เข้มงวดขึ้นด้วยสัญญา journal, context manifest รายงาน scheduler และการปฏิเสธ allowlist ความสามารถที่ว่างเปล่า v7 คงชั้นบันทึกนั้นไว้และเพิ่มตัวระบุงาน parallel_safe แบบเลือกได้ เหตุการณ์ journal delegation สำหรับงานที่มีขอบเขตซึ่งส่งต่อให้ agent อื่น และทะเบียน addon .dwp/config.json หากไม่ได้เปิดใช้ addon การมอบหมายงานใด ทุกแผนยังคงทำงานตามลำดับในเซสชันปัจจุบัน การตัดสินใจทางสถาปัตยกรรมคือ GO; ยังไม่ได้วัด non-inferiority เชิงประจักษ์ของผลลัพธ์ agent