เริ่มใช้งาน

ผู้อ่าน: ผู้ใช้โปรเจกต์ หน้านี้อธิบายสิ่งที่ต้องตรวจและตัดสินใจ ส่วน agent ดูแลขั้นตอนระบบตามปกติ

ตัวอย่างนี้เพิ่มความสามารถให้เจ้าของบัญชีแก้ชื่อที่แสดงได้ เริ่มจากโปรเจกต์ที่ ติดตั้งแล้ว และเปิด coding agent ในโปรเจกต์ พิมพ์ slash command ใน session ของ agent ไม่ใช่ terminal

คุณกำหนดพฤติกรรม อนุมัติข้อตกลง ตรวจผล และอนุญาต Land Agent ดูแล setup การตรวจ และการกู้คืนตามปกติ อยากเห็นภาพรวมก่อน ดู หนึ่ง change ตั้งแต่ต้นจนจบ

0. เช็คก่อนว่าโปรเจกต์พร้อม

ให้ agent ตรวจว่า Change Loop พร้อมใช้งาน โดย agent เรียก claude-foundation doctor --stage change และแก้ setup ได้เอง ตัวอย่างแรกนี้ยังไม่ต้องตั้งค่า quality gate ที่เป็นตัวเลือก

ถ้ายังไม่รู้สาเหตุหรือพฤติกรรมที่ต้องการ ให้เริ่มด้วย /investigate <คำถาม> ก่อนสร้าง change

1. ตกลงขอบเขต

/change ให้เจ้าของบัญชีแก้ชื่อที่แสดงได้

Agent ตรวจพฤติกรรมเดิมและเขียนข้อตกลงใน openspec/changes/<change-id>/ ใช้ ID ที่ agent แจ้งกลับมาในขั้นต่อไป

อ่าน proposal และ scenario ที่เกี่ยวข้อง แล้วตรวจว่า:

• ใครแก้ชื่อได้ และรับค่าแบบไหนบ้าง?
• ถ้าข้อมูลไม่ถูกต้องหรือบันทึกไม่ได้ จะเกิดอะไรขึ้น?
• งานครอบคลุมอะไร และจะตรวจผลอย่างไร?

อนุมัติข้อตกลงที่ compile แล้วก่อน Build หากต้องการแก้ความเข้าใจให้แจ้งตรงนี้ คุณไม่ต้องเขียน draft ภายในหรือตั้งค่า evidence เอง

สิ่งที่ควรเห็น: change ID คำถามขออนุมัติ และลิงก์ไปแพ็กเกจอนุมัติที่อ่านง่าย มีขอบเขต scenario และความเสี่ยง

2. ลงมือแบบแยกพื้นที่

/build <change-id>

Agent เขียนโค้ดและ test ในพื้นที่แยก ดูแลคำสั่งและการแก้ไขตามปกติ และถามเมื่อมีเรื่องสำคัญที่ต้องตัดสินใจ โค้ดที่พัฒนายังอยู่ในพื้นที่แยกจนถึง Land

Build อาจทำต่อถึงขั้นพิสูจน์โดยอัตโนมัติ ถ้าสถานะถึง proven แล้ว อ่านผลได้เลย โดยไม่ต้องสั่งรัน checks ชุดเดิมใหม่

สิ่งที่ควรเห็น: ความคืบหน้า แล้วจึงเป็นสถานะ proven หรือคำถามที่ต้องให้คุณตัดสินใจ

3. พิสูจน์

/prove <change-id>

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

ตรวจสรุปและ diff ผลที่สรุปไม่ได้หรือยังไม่มีหลักฐานไม่ถือว่าผ่าน หากกำหนดให้คุณตรวจยอมรับผลลัพธ์ ให้ตัดสินใจส่วนนั้นแยกจากการอนุมัติ spec ตอนต้น

สิ่งที่ควรเห็น: สรุปว่าอะไรผ่าน ไม่ผ่าน หรือตรวจไม่ได้ และสถานะ proven เมื่อทุกอย่างที่จำเป็นผ่านแล้ว

4. นำเข้าโปรเจกต์

เมื่อคุณต้องการนำ change ปัจจุบันเข้าโปรเจกต์ ให้อนุญาตอย่างชัดเจน:

/land <change-id>

Harness นำงานปัจจุบันจากพื้นที่แยกเข้าโปรเจกต์ ปรับ spec และ archive change โดยรักษาการแก้ไขอื่นที่ไม่เกี่ยวข้อง ผลลัพธ์เป็น diff ที่ยังไม่ commit และ Git HEAD กับ index ไม่เปลี่ยน

สิ่งที่ควรเห็น: สถานะ archived และ change เป็น diff ที่ยังไม่ commit ใน git status

สถานะ archived หมายถึงส่งมอบโค้ดครบแล้ว ไม่ได้หมายถึง deploy หรือผ่านการตรวจใน production การอนุญาต Land อย่างเดียวไม่ commit, push หรือเปิด PR

Land เป็นด่านบังคับเพียงด่านเดียว: จะ Land เฉพาะ proof ของ workspace ปัจจุบันที่ผ่าน และจะ prove ใหม่ก่อนถ้า proof นั้นเก่าแล้ว ก่อนถึง Land agent จะหยุดเฉพาะเรื่องที่คุณต้องตัดสินใจ ต้องแก้ conflict ของไฟล์ปลายทางก่อน apply ดูข้อกำหนดละเอียดใน Land

ย้อนกลับได้

ถ้า requirement เปลี่ยน ให้แจ้ง agent โดยใช้ change ID เดิม Agent แก้ข้อตกลงและตรวจงานที่ได้รับผลกระทบ ถ้า session หรือ Land หยุดกลางทาง ให้ agent ทำ change เดิมต่อ ไม่ต้องสร้างใหม่หรือแก้ runtime record ด้วยมือ

ดูสถานะ

/changes

แสดง change ที่กำลังทำ อุปสรรค และขั้นถัดไป โดยไม่เปลี่ยนสถานะ

เมื่อ change พิสูจน์ไม่ได้

Agent รายงานสิ่งที่ขาดและทางเลือก คุณขอให้ทำต่อ พักงาน หรือ waive check ที่คุณตัดสินว่าไม่จำเป็นได้ (เป็นการตัดสินใจที่บันทึกไว้ และไม่เปลี่ยนผลที่ล้มให้เป็นผ่าน) การยุติ change ก็ต้องมีการตัดสินใจชัดเจน ให้ agent ใช้ขั้นตอนกู้คืนที่ระบบรองรับ แทนการลบไฟล์

อ่าน การอนุมัติโดยคน และ สัญญา lifecycle สำหรับขอบเขตอำนาจและการกู้คืนแบบละเอียด

ทำอะไรต่อ

• ส่งงานเป็น PR — /deliver <change-id> ให้อำนาจแยกสำหรับ commit ในพื้นที่แยก, push branch และส่ง PR โดยไม่ merge หรือ deploy
• ไฟล์ที่ Change Loop สร้าง — อะไรเป็นของคุณ และอะไรที่ harness ดูแล
• หลาย repository — กำหนด scope ก่อนเริ่ม งานที่ใช้หลาย repository
• Quality gate ของโปรเจกต์ — checks เสริม ที่ตั้งค่าได้หลังจากใช้ workflow พื้นฐานได้แล้ว