เอกสารทางการของ Claude Code เปิดตัวคำสั่งใหม่ชื่อ /goal ซึ่งเปลี่ยนรูปแบบการทำงานของ AI agent จาก "พิมพ์ prompt ทีละ turn" ไปเป็น "กำหนดเงื่อนไขปลายทางครั้งเดียว แล้วปล่อยให้ Claude ทำงานต่อเองจนกว่าเงื่อนไขจะผ่าน" ตามที่ Anthropic Claude Code docs ระบุไว้ ระบบจะส่ง conversation หลังจบ turn ให้โมเดลเร็วขนาดเล็ก (default คือ Haiku) ตรวจว่าเงื่อนไขที่ตั้งไว้ผ่านหรือยัง ถ้ายัง Claude ก็จะเริ่ม turn ใหม่อัตโนมัติ ไม่ต้องรอผู้ใช้พิมพ์อะไรเข้าไปอีก

จุดที่น่าสนใจของ /goal คือการเติมเต็มช่องว่างของ autonomous workflow ที่ Claude Code มีอยู่ก่อนหน้า ทั้ง /loop ที่อิง time interval และ Stop hook ที่ผูกกับ settings file โดย /goal ออกแบบมาสำหรับงานที่มี verifiable end state เช่น ย้าย module ไป API ใหม่ให้ทุก call site compile ผ่าน, implement design doc จนทุก acceptance criteria เป็นจริง, หรือทำ issue backlog ที่ติด label จน queue ว่าง ทั้งนี้ Anthropic ระบุว่า /goal กับ auto mode เป็น feature ที่ complementary กัน เพราะ auto mode ตัด per-tool prompt ส่วน /goal ตัด per-turn prompt

1. /goal คืออะไรและเปรียบเทียบกับ autonomous workflow อื่น

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

ตามที่ Anthropic Claude Code docs นำเสนอ มี autonomous workflow 3 รูปแบบที่ทำให้ session ทำงานต่อระหว่าง prompt โดยจุดต่างอยู่ที่ "อะไรเป็นตัวเริ่ม turn ถัดไป" และ "อะไรเป็นตัวบอกให้หยุด"

Approachturn ถัดไปเริ่มเมื่อหยุดเมื่อ
/goalturn ก่อนหน้าจบโมเดล evaluator confirm ว่าเงื่อนไขผ่าน
/loopครบ time interval ที่ตั้งไว้ผู้ใช้สั่งหยุด หรือ Claude คิดว่างานเสร็จแล้ว
Stop hookturn ก่อนหน้าจบscript หรือ prompt ที่เขียนเองตัดสิน

ความต่างที่สำคัญระหว่าง /goal กับ Stop hook คือ scope /goal เป็น session-scoped shortcut ที่พิมพ์เงื่อนไขเข้าไปแล้วใช้แค่ session ปัจจุบัน ส่วน Stop hook อยู่ใน settings file ครอบทุก session ใน scope ที่กำหนด และเลือก run ได้ทั้ง script (สำหรับ check แบบ deterministic) หรือ prompt (สำหรับให้โมเดล evaluate) ส่วน auto mode นั้นอนุมัติ tool call ภายใน turn เดียวเท่านั้น ไม่ start turn ใหม่ โดย Claude จะหยุดเองเมื่อ judge ว่างานเสร็จ ขณะที่ /goal มี evaluator แยกที่ check เงื่อนไขหลังจบทุก turn ทำให้คนตัดสินว่า "เสร็จหรือยัง" เป็นโมเดลคนละตัวกับคนที่ทำงาน

comparison table — /goal vs /loop vs Stop hook พร้อม trigger ของ turn ถัดไป และจุดที่ทำให้หยุด อ้างอิงข้อมูลจาก Anthropic Claude Code docs

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

รูปแบบการใช้งานพื้นฐานคือพิมพ์ /goal ตามด้วยเงื่อนไขที่ต้องการ เช่น

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

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

ตามที่เอกสาร Claude Code อธิบาย evaluator จะ judge เงื่อนไขจากสิ่งที่ Claude surface ออกมาใน conversation เท่านั้น evaluator ไม่ run command และไม่อ่านไฟล์เอง ดังนั้นเงื่อนไขที่เขียนต้องเป็นสิ่งที่ Claude สามารถพิสูจน์ผ่าน output ของตัวเองได้ ตัวอย่างเช่น "All tests in test/auth pass" ใช้งานได้เพราะ Claude จะรัน test เอง แล้วผลรันก็จะลงไปอยู่ใน transcript ให้ evaluator อ่าน

เงื่อนไขที่ใช้งานได้จริงข้ามหลาย turn มักประกอบด้วย 3 องค์ประกอบ

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

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

3. Status, clear, resume, และโหมด non-interactive

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

ถ้าต้องยกเลิก goal ก่อนเงื่อนไขผ่าน ใช้ /goal clear ได้ ทั้งนี้คำว่า stop, off, reset, none, และ cancel รองรับเป็น alias ของ clear ด้วย นอกจากนี้การรัน /clear เพื่อเริ่ม conversation ใหม่ก็ remove active goal ออกไปเช่นกัน

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

/goal รองรับ non-interactive mode ผ่านการสั่งด้วย flag -p เช่น

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

คำสั่งนี้จะรัน loop ทั้งหมดให้จบใน invocation เดียว ใช้กับ desktop app และ Remote Control ได้ด้วย ถ้าต้องการยุติ goal ที่รันใน non-interactive mode ก่อนเงื่อนไขผ่าน กด Ctrl+C เพื่อ interrupt process

4. กลไก evaluation และ requirement ของระบบ

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

evaluator จะรันบน provider เดียวกับที่ session ตั้งค่าไว้ และที่สำคัญคือ evaluator ไม่ call tool ใดๆ ดังนั้นสิ่งที่มันใช้ตัดสินคือเฉพาะข้อความที่ Claude surface ออกมาใน conversation เท่านั้น ทาง Anthropic ระบุเพิ่มว่า token ที่ใช้ใน evaluation จะคิดเงินตาม rate ของ small fast model ของ provider ซึ่งโดยทั่วไปจะเล็กมากเมื่อเทียบกับ main-turn spend

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

5. ใช้กับงานแบบไหนเหมาะที่สุด

/goal ออกแบบมาสำหรับงานที่มีปริมาณมาก และมีจุดสิ้นสุดที่ตรวจสอบได้ ตามที่ Anthropic Claude Code docs ยกตัวอย่างไว้ มีทั้งหมด 4 รูปแบบหลัก

  • Migration ของ module ไป API ใหม่ จนทุก call site compile ผ่านและ test ผ่าน
  • Implement design doc จนทุก acceptance criteria เป็นจริง
  • Splitting large file ออกเป็น module ที่แต่ละไฟล์อยู่ใต้ size budget ที่กำหนด
  • เคลียร์ issue backlog ที่ติด label จน queue ว่าง

จุดร่วมของงานเหล่านี้คือมี end state ที่ "พิสูจน์ผ่าน output ของ Claude เอง" ได้ ไม่ว่าจะเป็น exit code ของ test runner, จำนวนไฟล์ที่เหลือ, หรือ list ของ issue ที่ปิดได้ ในทางกลับกัน งานที่ end state ต้องอาศัยการตรวจจากข้อมูลภายนอกที่ Claude ไม่ surface ออกมาใน conversation จะไม่เหมาะกับ /goal เพราะ evaluator มองไม่เห็น

เอกสารยังเน้นว่า autonomous workflow ทั้ง 3 รูปแบบ (/goal, /loop, Stop hook) เป็นทางเลือกที่ใช้ตามลักษณะงาน ไม่ใช่ทดแทนกัน ถ้างานต้องการ schedule แบบเป็นอิสระจาก session ที่เปิดอยู่ เช่น nightly test หรือ morning triage Anthropic แนะนำให้ดู scheduling options สำหรับ cloud routines และ desktop scheduled tasks เพิ่มเติม

Tip: ก่อนใช้ /goal กับงานจริง ทดสอบเงื่อนไขในงานเล็กก่อนเสมอ เพราะ evaluator ตัดสินจาก conversation ล้วนๆ ถ้า Claude ไม่ surface ผล test ออกมาในรูปแบบที่อ่านง่าย evaluator อาจสรุปผิดได้ การใส่ stated check ที่ชัดเช่น "exit 0" จะช่วยให้การ judge แม่นขึ้น

ที่มา: Anthropic Claude Code docs: Keep Claude working toward a goal