Anthropic เพิ่มคำสั่งใหม่ /goal ใน Claude Code ที่จะเปลี่ยนสไตล์การทำงานกับ AI agent จากเดิมที่เราต้องคอยพิมพ์ prompt สั่งงานทีละ turn มาเป็นการ "กำหนดเงื่อนไขปลายทางไว้ครั้งเดียว แล้วปล่อยให้ Claude ลุยงานต่อเนื่องไปเรื่อยๆ จนกว่าเงื่อนไขจะผ่านจริง"

เบื้องหลังการทำงานคือ ทุกครั้งที่ Claude จบแต่ละ turn ระบบจะส่ง conversation ไปให้โมเดลประมวลผลเร็วขนาดเล็ก (ค่าเริ่มต้นคือ Haiku) ทำหน้าที่เป็น evaluator ตรวจสอบว่าเงื่อนไขที่ตั้งไว้สำเร็จแล้วหรือยัง ถ้ายังไม่ผ่าน Claude ก็จะเริ่ม turn ถัดไปเพื่อแก้ปัญหาต่อทันทีโดยที่เราไม่ต้องพิมพ์สั่งซ้ำ

จุดเด่นของ /goal คือเข้ามาเติมเต็ม autonomous workflow ของ Claude Code ให้สมบูรณ์ขึ้น จากเดิมที่มี /loop ซึ่งทำงานวนลูปตามช่วงเวลา (time interval) และ Stop hook ที่ต้องตั้งค่าไว้ในระดับ settings file โดยคำสั่ง /goal ออกแบบมาสำหรับงานที่มี verifiable end state หรือจุดสิ้นสุดที่ตรวจวัดผลได้ชัดเจน เช่น การ refactor ย้าย module ไปใช้ API ใหม่จนทุก call site compile ผ่าน, การ implement ฟีเจอร์ตาม design doc จน acceptance criteria ผ่านครบทุกข้อ หรือการไล่เคลียร์ issue backlog ตาม label จนหมด queue

ทั้งนี้ Anthropic ระบุว่า /goal ทำงานเสริมกับ auto mode ได้อย่างลงตัว เพราะ auto mode ช่วยอนุมัติ tool call ภายใน turn ส่วน /goal เข้ามาช่วยรันงานข้าม turn ต่อเนื่องอัตโนมัติ

1. /goal คืออะไรและต่างจาก Autonomous Workflow อื่นอย่างไร

คำสั่ง /goal ใช้สำหรับตั้ง completion condition ภายใน session ปัจจุบัน เมื่อระบุเงื่อนไขเสร็จ Claude จะเริ่มลุยงาน turn แรกทันทีโดยใช้เงื่อนไขนั้นเป็น directive หลัก ระหว่างที่ goal กำลังรันอยู่ หน้าจอจะแสดงสถานะ ◎ /goal active พร้อมบอกระยะเวลาที่รันมา และเงื่อนไขจะถูกเคลียร์ออกอัตโนมัติเมื่อโมเดล evaluator ยืนยันว่างานสำเร็จ หรือเมื่อเราสั่ง /goal clear

Claude Code มีกลไก autonomous workflow 3 รูปแบบหลัก ซึ่งแตกต่างกันตรงตัว trigger ให้เริ่ม turn ถัดไป และเงื่อนไขในการหยุดทำงาน:

ข้อแตกต่างสำคัญระหว่าง /goal กับ Stop hook อยู่ที่ระดับ scope: /goal เป็น shortcut ระดับ session ที่กำหนดแล้วมีผลเฉพาะ session ปัจจุบัน ส่วน Stop hook จะถูกบันทึกไว้ใน settings file ครอบคลุมทุก session ตาม scope ที่ระบุ และเลือกใช้ได้ทั้ง script (สำหรับการตรวจเช็กแบบ deterministic) หรือ custom prompt (เพื่อให้โมเดล evaluate)

ขณะที่ auto mode ทำหน้าที่แค่อนุมัติ tool call ภายใน turn เดียวเท่านั้น ไม่ได้เริ่ม turn ใหม่ โดย Claude จะหยุดเมื่อเห็นว่างานใน turn นั้นเสร็จแล้ว แต่สำหรับ /goal จะมี evaluator แยกออกมาตรวจสอบเงื่อนไขหลังจบทุก turn ทำให้ผู้ประเมินว่า "งานเสร็จหรือยัง" เป็นคนละโมเดลกับตัวที่กำลังเขียนโค้ด

2. วิธีตั้ง Goal และเขียนเงื่อนไขให้วัดผลได้จริง

ไวยากรณ์พื้นฐานคือการพิมพ์ /goal ตามด้วยเงื่อนไขปลายทาง เช่น

/goal all tests in test/auth pass and the lint step is clean

หลังจากสั่ง goal แล้ว Claude จะเริ่ม turn แรกทันทีโดยนำเงื่อนไขนี้ไปเป็นเป้าหมายหลัก หาก session นั้นมี goal เดิมรันอยู่ก่อน คำสั่งใหม่จะเข้าไปแทนที่ทันที เมื่อจบแต่ละ turn ตัว evaluator จะส่ง reason สั้นๆ กลับมาว่าทำไมเงื่อนไขถึงยังไม่ผ่าน หรือผ่านเพราะอะไร โดยเหตุผลล่าสุดจะแสดงให้เห็นทั้งบน status view และใน transcript เพื่อให้เราติดตามได้ตลอดเวลาว่า Claude กำลังพยายามแก้อะไรอยู่

ตัว evaluator จะประเมินเงื่อนไขจากข้อความและ output ที่ Claude แสดงออกมาในบทสนทนาเท่านั้น (evaluator ไม่ได้รัน command หรืออ่านไฟล์ด้วยตัวเอง) ดังนั้นเงื่อนไขที่ดีต้องเป็นสิ่งที่ Claude สามารถพิสูจน์ผลผ่าน output ของตัวเองได้ เช่น การระบุว่า "All tests in test/auth pass" ใช้งานได้ดีเพราะ Claude จะสั่งรัน test เอง แล้วนำ test report ที่ได้มาปรากฏใน transcript ให้ evaluator ตรวจ

โครงสร้างของเงื่อนไขที่มีประสิทธิภาพข้ามหลาย turn ควรประกอบด้วย 3 ส่วน:

1. One measurable end state: จุดหมายปลายทางที่วัดผลได้ชัดเจนจุดเดียว เช่น ผล test ผ่านหมด, build exit code เป็น 0, จำนวนไฟล์ลดลงตามเป้า หรือ backlog queue ว่างเปล่า
2. A stated check: ระบุคำสั่งหรือวิธีตรวจสอบที่ Claude ต้องรันเพื่อพิสูจน์ผล เช่น "npm test exits 0" หรือ "git status is clean"
3. Constraints that matter: ข้อจำกัดหรือเงื่อนไขห้ามเปลี่ยนระหว่างทาง เช่น "no other test file is modified"

ความยาวของเงื่อนไขรองรับได้สูงสุด 4,000 ตัวอักษร นอกจากนี้แนะนำให้เพิ่มเงื่อนไขควบคุมจำนวนรอบหรือเวลาเข้าไปด้วย เช่น or stop after 20 turns เพื่อป้องกันไม่ให้ agent วนลูปไม่รู้จบ ซึ่ง Claude จะคอยสรุปความคืบหน้าเทียบกับเงื่อนไขนี้ในทุก turn

3. การเช็ก Status, เคลียร์ Goal, Resume และโหมด Non-Interactive

หากต้องการตรวจสอบสถานะของ goal ปัจจุบัน ให้พิมพ์ /goal เดี่ยวๆ โดยไม่ต้องใส่ argument ระบบจะแสดงรายละเอียดทั้งหมด ทั้งตัวเงื่อนไข, เวลาที่รันไปแล้ว, จำนวน turn ที่ evaluate ไปแล้ว, token spend สะสม และเหตุผลล่าสุดจาก evaluator หากไม่มี goal ที่กำลังรันอยู่ แต่เคยรัน goal สำเร็จใน session นั้น ระบบจะแสดงประวัติของ goal ล่าสุดให้ดูย้อนหลัง

หากต้องการยกเลิก goal กลางคัน ให้ใช้คำสั่ง /goal clear (หรือใช้คำสั่ง alias อย่าง stop, off, reset, none และ cancel) หรือหากสั่ง /clear เพื่อเริ่มบทสนทนาใหม่ goal ปัจจุบันก็จะถูกลบออกไปด้วยเช่นกัน

เมื่อปิด session ไปแล้วกลับมาเปิดใหม่ด้วย --resume หรือ --continue ตัว goal ที่ยังทำไม่เสร็จจะถูก restore กลับมาให้ทำงานต่อ โดยตัวนับ turn, timer และค่า baseline ของ token spend จะถูกรีเซ็ตใหม่ ส่วน goal ที่สำเร็จหรือเคลียร์ไปแล้วจะไม่ถูกนำกลับมา

/goal ยังรองรับการรันแบบ non-interactive ผ่าน flag -p สำหรับ workflow อัตโนมัติ:

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

คำสั่งนี้จะรัน loop ทั้งหมดจนกว่าจะเสร็จในคำสั่งเดียว รองรับทั้งบน CLI, desktop app และ Remote Control หากต้องการหยุดการทำงานระหว่างทางในโหมด non-interactive สามารถกด Ctrl+C ได้ทันที

4. เบื้องหลังกลไก Evaluation และข้อกำหนดของระบบ

ในเชิงสถาปัตยกรรม /goal เป็น wrapper ครอบ prompt-based Stop hook ระดับ session เมื่อ Claude ทำงานจบในแต่ละ turn ระบบจะรวบรวมเงื่อนไขและบทสนทนาทั้งหมดส่งไปให้โมเดลขนาดเล็ก (default คือ Haiku) ประเมินผล โดยโมเดลจะตอบกลับมาเป็น yes/no พร้อมเหตุผลสั้นๆ หากได้ผลเป็น "no" Claude จะนำเหตุผลนั้นไปเป็นแนวทางแก้ปัญหาใน turn ถัดไป แต่หากได้ผลเป็น "yes" ตัว goal จะสิ้นสุดลงพร้อมบันทึกสถานะ achieved ลงใน transcript

กระบวนการประเมินผลจะรันบน provider เดียวกับที่ session ใช้งานอยู่ และตัว evaluator จะ ไม่เรียกใช้ tool ใดๆ เพิ่มเติม จึงตัดสินใจจาก output ที่ Claude พิมพ์ออกมาใน session ล้วนๆ ในแง่ค่าใช้จ่าย token ที่ใช้ในการ evaluate จะคิดตามเรตของโมเดลขนาดเล็ก ซึ่งต่ำมากเมื่อเทียบกับการรันใน turn หลัก

สำหรับข้อกำหนดของระบบ /goal จะทำงานได้เฉพาะใน workspace ที่ผู้ใช้กดยอมรับ trust dialog แล้วเท่านั้น เนื่องจาก evaluator ทำงานผ่านระบบ hook หากมีการตั้งค่า disableAllHooks หรือเปิดใช้ allowManagedHooksOnly ในระดับ managed settings ตัว /goal จะไม่สามารถใช้งานได้ ซึ่งระบบจะแจ้งเตือนเหตุผลให้ทราบอย่างชัดเจน

5. รูปแบบงานที่เหมาะกับ /goal มากที่สุด

/goal เหมาะอย่างยิ่งกับงานที่มีสเกลใหญ่ มีขั้นตอนต่อเนื่อง และมีผลลัพธ์ปลายทางที่ตรวจสอบได้จริง 4 รูปแบบหลักได้แก่:

• การย้าย Module ไปยัง API ใหม่: รันแก้โค้ดไปเรื่อยๆ จนกว่าทุก call site จะ compile ผ่านและ unit test ผ่านทั้งหมด
• การพัฒนาระบบตาม Design Doc: ให้ AI เขียนโค้ดจนกว่าจะผ่านเกณฑ์ acceptance criteria ครบทุกข้อ
• การแยกไฟล์ขนาดใหญ่ (Splitting Large Files): ทยอยแยกโค้ดออกเป็นโมดูลย่อย โดยมีเงื่อนไขว่าแต่ละไฟล์ต้องมีขนาดไม่เกินลิมิตที่กำหนด
• การเคลียร์ Issue Backlog: ดึง task ที่ติด label มารันแก้ทีละตัวจนกว่า queue จะว่าง

หัวใจสำคัญคืองานนั้นต้องมีผลลัพธ์ที่ "ตรวจสอบได้ผ่าน output ของ Claude" เช่น exit code ของ test runner, รายการไฟล์ หรือสถานะ git ในทางกลับกัน งานที่ต้องพึ่งพาการตรวจเช็กจากภายนอกที่ไม่ได้แสดงผลลงใน terminal จะไม่เหมาะกับ /goal

workflow ทั้ง 3 แบบ (/goal, /loop, Stop hook) ถูกออกแบบมาเพื่อตอบโจทย์คนละบริบท หากต้องการตั้งเวลาให้ agent รันงานประจำโดยไม่อิงกับ session เช่น การรัน nightly test หรือ morning triage แนะนำให้เลือกใช้ฟีเจอร์ Cloud Routines หรือ Scheduled Tasks แทน