Claude Code Prompts: 25 Prompts ที่พร้อมใช้ และวิธีเขียน Prompts ของคุณเอง

ลูกค้าที่ใช้คูปองที่หมดอายุจะได้รับข้อผิดพลาด 500 เมื่อทำการชำระเงิน ตรวจสอบไฟล์ @src/checkout/coupons.ts และชุดทดสอบของมัน พฤติกรรมที่คาดหวังคือแสดงข้อความ "คูปองไม่ถูกต้อง" โดยไม่สร้างคำสั่งซื้อ เขียนการทดสอบที่ล้มเหลวเพื่อจำลองข้อผิดพลาดนั้น แล้วแก้ไขโดยไม่เปลี่ยนแปลงพฤติกรรมของคูปองที่ถูกต้อง รัน [คำสั่งทดสอบ checkout] และแสดงผลลัพธ์ก่อนและหลังการแก้ไข หากไม่สามารถจำลองข้อผิดพลาดได้ ให้รายงานสิ่งที่คุณได้ตรวจสอบก่อนที่จะเปลี่ยนแปลงการดำเนินการ

เพิ่มตัวเลือกวันที่ไปยัง [เส้นทางแบบฟอร์มการจอง] ให้ปฏิบัติตามมาตรฐานของคอมโพเนนต์และระบบตรวจสอบความถูกต้องใน @src/components/TimeSelect.tsx ผู้ใช้ต้องสามารถเลือก [วันที่ที่อนุญาต] ได้ ในขณะที่ [วันที่ที่ไม่สามารถจองได้] ต้องถูกปิดใช้งานไว้ อย่าเพิ่มไลบรารีใดๆ ให้รัน [คำสั่งทดสอบคอมโพเนนต์] และ [คำสั่งตรวจสอบประเภทข้อมูล] แล้วรายงานเกณฑ์ใดๆ ที่การตรวจสอบดังกล่าวไม่ครอบคลุม

แบ่งไฟล์ @src/reports/export.py เป็นฟังก์ชันที่เล็กกว่า โดยรักษาข้อมูลเข้า รูปแบบข้อมูลออก และพฤติกรรมเมื่อเกิดข้อผิดพลาดไว้ รัน [คำสั่งทดสอบ export] ก่อนแก้ไข และรายงานข้อผิดพลาดที่มีอยู่ทั้งหมด หลังจากปรับโครงสร้างแล้ว ให้รันการทดสอบอีกครั้งและแสดงผลลัพธ์ทั้งสองด้าน อย่าเปลี่ยนแปลงอินเทอร์เฟซสาธารณะหรือไฟล์ที่ไม่เกี่ยวข้อง

“Claude ตรวจสอบทุกการเปลี่ยนแปลงที่ผมส่งไปยังclaude.ai/codeโดยใช้ส่วนขยาย Claude สำหรับ Chrome มันจะเปิดเบราว์เซอร์ ตรวจสอบ UI และทำซ้ำจนกว่าโค้ดจะทำงานได้และประสบการณ์ผู้ใช้ (UX) รู้สึกดี ”

ตรวจสอบ README, การตั้งค่าโครงการ และโครงสร้างโฟลเดอร์ระดับบนสุดของรีโพสิตอรีนี้ ให้ติดตามแหล่งอ้างอิงเฉพาะเมื่อจำเป็นเพื่ออธิบาย: สิ่งที่แอปพลิเคชันทำ จุดเข้าหลักและส่วนประกอบสำคัญ สถานที่จัดเก็บการทดสอบ และคำสั่งที่รีโพสิตอรีกำหนดไว้สำหรับการรันการทดสอบเหล่านั้น อ้างอิงเส้นทางไฟล์ที่สนับสนุนคำอธิบายของคุณ ให้แยกแยะระหว่างพฤติกรรมที่บันทึกไว้ในเอกสารกับการสรุปของคุณเอง และทำเครื่องหมายไว้สำหรับสิ่งที่คุณไม่สามารถกำหนดได้ อย่าอ่านไฟล์ข้อมูลลับหรือไฟล์สภาพแวดล้อม อย่าตรวจสอบการพึ่งพาที่ติดตั้งไว้ และอย่าเปลี่ยนแปลงไฟล์ใดๆ จบด้วยสามไฟล์ที่ฉันควรอ่านก่อนและเหตุผล

ตรวจสอบประวัติ Git ของ [ไฟล์, ฟังก์ชัน หรือ คลาส] โดยเน้นไปที่ [คำถามเกี่ยวกับพฤติกรรมหรือการออกแบบ] ระบุการ commit ที่นำพฤติกรรมนี้มาใช้หรือเปลี่ยนแปลงอย่างมีนัยสำคัญ สำหรับการ commit ที่เกี่ยวข้องแต่ละครั้ง ให้ระบุ hash ของมัน สรุปการเปลี่ยนแปลง และอธิบายเหตุผลใดๆ ที่บันทึกไว้ในข้อความ commit หรือการสนทนาที่เชื่อมโยงซึ่งคุณสามารถเข้าถึงได้ ระบุเหตุผลที่สันนิษฐานว่าเป็น "การสันนิษฐาน" หากประวัติไม่ชี้แจงการตัดสินใจ ให้ระบุไว้อย่างชัดเจน อย่าแก้ไขไฟล์หรือประวัติ Git

ติดตามสิ่งที่เกิดขึ้นเมื่อ [การกระทำของผู้ใช้หรือเหตุการณ์ระบบ] โดยเริ่มจาก [เส้นทางที่ทราบ, ตัวจัดการ, หรือโฟลเดอร์] ติดตามการเรียกที่เกี่ยวข้องผ่านขั้นตอนการตรวจสอบความถูกต้อง, ตรรกะธุรกิจ, และการเขียนข้อมูลลงในฐานข้อมูลหรือคำขอภายนอกใดๆ ระบุไฟล์และฟังก์ชันตามลำดับการดำเนินการ พร้อมอ้างอิงบรรทัดโค้ดหากมี อธิบายเส้นทางความล้มเหลวหลักและระบุการทดสอบที่มีอยู่ซึ่งครอบคลุมกระบวนการดังกล่าว ระบุการเชื่อมต่อใดๆ ที่คุณไม่สามารถยืนยันได้จากโค้ด อย่าดำเนินการตามโฟลว์นี้ อย่าเรียกใช้บริการภายนอก หรือแก้ไขไฟล์

วางแผนวิธีการนำ [ฟีเจอร์] ไปใช้ใน [พื้นที่รีโพสิตอรี] พฤติกรรมที่คาดหวังคือ [ข้อกำหนด] และพื้นที่เหล่านี้ต้องไม่เปลี่ยนแปลง: [ข้อจำกัด] ตรวจสอบโค้ดที่เกี่ยวข้องและเทสต์ที่มีอยู่ ระบุไฟล์ที่จำเป็นต้องเปลี่ยนแปลง ลำดับการนำฟีเจอร์ไปใช้ และความเสี่ยงด้านความเข้ากันได้หรือการย้ายข้อมูล จับคู่ข้อกำหนดแต่ละข้อกับเทสต์ที่เสนอหรือขั้นตอนการตรวจสอบอื่น ๆ ระบุคำถามที่ยังไม่ได้รับการแก้ไขและสมมติฐานแยกต่างหาก อย่าดำเนินการพัฒนาฟีเจอร์นี้ในตอนนี้ ส่งแผนกลับมาให้ผมตรวจสอบ

ผมต้องการสร้าง [คำอธิบายสั้น] สำหรับ [ผู้ใช้และกรณีการใช้งาน]. อ่าน [ไฟล์หรือข้อกำหนดที่เกี่ยวข้อง] ก่อน แล้วใช้ AskUserQuestion เพื่อชี้แจงการตัดสินใจที่อาจส่งผลอย่างมีนัยสำคัญต่อการพัฒนา ให้เน้นไปที่กรณีพิเศษ การจัดการข้อมูล สิทธิ์การใช้งาน พฤติกรรม UI ที่คาดการณ์ไว้ และการแลกเปลี่ยนผลประโยชน์ อย่าถามคำถามที่บริบทที่ให้ไว้แล้วได้ตอบไว้แล้ว เมื่อการตัดสินใจสำคัญได้รับการแก้ไขแล้ว ให้ร่างเอกสารข้อกำหนดที่ครอบคลุมข้อกำหนด คุณสมบัติการยอมรับ ข้อจำกัด และสิ่งที่อยู่นอกขอบเขต ระบุสมมติฐานที่ยังเหลืออยู่ แสดงเอกสารข้อกำหนดให้ผมดูก่อนที่จะบันทึกมันลงใน [เส้นทางเอกสารข้อกำหนด] และอย่าเขียนทับไฟล์ที่มีอยู่โดยไม่ได้รับอนุญาต

ประเมินผลกระทบจากการเปลี่ยนแปลง [ฟังก์ชัน, คอมโพเนนต์ หรืออินเทอร์เฟซ] จาก [พฤติกรรมปัจจุบัน] เป็น [พฤติกรรมที่เสนอ] ค้นหา [ในขอบเขตของรีโพสิตอรีหรือไดเรกทอรี] เพื่อหาคำนิยาม, ผู้เรียกโดยตรง, การนำเข้า (imports), และการทดสอบที่เกี่ยวข้อง ระบุไฟล์ที่อาจจำเป็นต้องเปลี่ยนแปลง และอธิบายว่าแต่ละไฟล์อาจได้รับผลกระทบอย่างไร พร้อมอ้างอิงไฟล์และบรรทัดโค้ดหากมี ทำเครื่องหมายการเรียกที่ถูกแก้ไขแบบไดนามิก ผู้ใช้ภายนอก หรือความพึ่งพาอื่น ๆ ที่คุณไม่สามารถตรวจสอบได้ ระบุปัญหาความเข้ากันได้ใด ๆ ที่จำเป็นต้องได้รับคำตอบก่อนการนำไปใช้งาน อย่าเปลี่ยนแปลงไฟล์; ส่งการประเมินผลกระทบกลับมาและรอการตรวจสอบจากผม

เพิ่ม [feature] ไปยัง [file or page] ด้วยพฤติกรรมนี้: [acceptance criteria]. ตรวจสอบ [existing implementation] และปฏิบัติตามหลักเกณฑ์ของมันในการดึงข้อมูล การจัดการข้อผิดพลาด และการจัดระเบียบส่วนประกอบ ใช้เฉพาะไลบรารีที่ติดตั้งไว้ในโครงการแล้วเท่านั้น รักษาการเปลี่ยนแปลงให้อยู่ภายใน [ขอบเขต] และรักษา [พฤติกรรมที่มีอยู่หรืออินเทอร์เฟซสาธารณะ] ไว้ เพิ่มหรืออัปเดตการทดสอบสำหรับเกณฑ์การยอมรับ รัน [คำสั่งทดสอบ] และ [คำสั่งตรวจสอบประเภทหรือ lint] แล้วรายงานไฟล์ที่เปลี่ยนแปลง ผลลัพธ์ และการตรวจสอบใด ๆ ที่ไม่สามารถเสร็จสิ้นได้ หากรูปแบบที่มีอยู่ขัดแย้งกับข้อกำหนด ให้อธิบายความขัดแย้งก่อนดำเนินการต่อ

เขียน [ชื่อฟังก์ชัน] ใน [ไฟล์] เพื่อตอบสนอง [ข้อกำหนด] ให้ครอบคลุม [กรณีปกติ], [กรณีขอบเขต] และ [พฤติกรรมเมื่อข้อมูลเข้าไม่ถูกต้อง] ให้รัน [คำสั่งทดสอบที่เกี่ยวข้อง] ก่อนและรายงานข้อผิดพลาดที่มีอยู่ เขียนการทดสอบสำหรับพฤติกรรมที่ขอไว้ แล้วรันการทดสอบก่อนการเขียนฟังก์ชัน ตรวจสอบว่าการทดสอบใหม่ล้มเหลวด้วยเหตุผลที่คาดไว้ เขียนฟังก์ชันและรันการทดสอบใหม่ อย่าลดความเข้มงวดของการตรวจสอบ (assertions), ข้ามการทดสอบ หรือเปลี่ยนพฤติกรรมที่คาดไว้เพื่อให้การทดสอบผ่าน หากข้อกำหนดขัดแย้งกับการทดสอบที่มีอยู่ ให้หยุดและอธิบายความขัดแย้งดังกล่าว พร้อมแสดงผลลัพธ์ก่อนและหลังการเปลี่ยนแปลง

นำการออกแบบที่แนบมาไปใช้ใน [ส่วนประกอบหรือหน้า] โดยใช้ส่วนประกอบและสไตล์ที่มีอยู่ในโครงการ รักษา [พฤติกรรมที่จำเป็น] และหลีกเลี่ยงการเปลี่ยนแปลงนอก [ขอบเขต] ใช้ [เบราว์เซอร์หรือเครื่องมือจับภาพหน้าจอที่ตั้งค่าไว้] เพื่อจับภาพ [เส้นทางท้องถิ่น] ที่ [ขนาดวิวพอร์ต] พร้อม [ข้อมูลทดสอบและสถานะ UI] หากเครื่องมือหรือแอปพลิเคชันไม่สามารถใช้งานได้ ให้รายงานสิ่งที่จำเป็นแทนที่จะอ้างว่าได้ตรวจสอบทางภาพแล้ว เปรียบเทียบภาพที่บันทึกกับภาพอ้างอิง โดยเน้นที่ [การจัดวาง, ระยะห่าง, การจัดรูปแบบตัวอักษร หรือเกณฑ์การยอมรับอื่นๆ] ดำเนินการแก้ไขได้สูงสุด [จำนวน] ครั้ง แล้วรายงานความแตกต่างที่เหลืออยู่ อย่าแก้ไขภาพอ้างอิง ดำเนินการ [การทดสอบคอมโพเนนต์ที่เกี่ยวข้อง] และ [คำสั่งตรวจสอบประเภทข้อมูลหรือคำสั่งสร้าง] รวมภาพหน้าจอที่บันทึกและผลการตรวจสอบจริงไว้ในสรุปของคุณ

ผู้ใช้พบ [อาการ] เมื่อ [ปัจจัยกระตุ้นหรือข้อมูลนำเข้า] พฤติกรรมที่คาดหมายคือ [ผลลัพธ์ที่คาดหมาย] เริ่มด้วยการตรวจสอบ [โฟลเดอร์, ฟังก์ชัน หรือโฟลว์] และเทสต์ที่เกี่ยวข้อง สร้างเทสต์ที่ล้มเหลวซึ่งสามารถจำลองพฤติกรรมที่รายงานได้ หากไม่สามารถจำลองได้ ให้อธิบายว่าคุณได้ตรวจสอบอะไรแล้ว และข้อมูลใดที่ยังขาดอยู่ ก่อนที่จะปรับเปลี่ยนการดำเนินการ เมื่อจำลองได้แล้ว ให้แก้ไขสาเหตุโดยไม่เปลี่ยนแปลง [พฤติกรรมที่ต้องคงไว้] รันเทสต์ใหม่และ [คำสั่งเทสต์ที่เกี่ยวข้อง] แสดงผลล้มเหลวก่อนการแก้ไข ผลลัพธ์หลังการแก้ไข และผลล้มเหลวที่ยังเหลืออยู่

[คำสั่ง Build] ล้มเหลวใน [สภาพแวดล้อมท้องถิ่นหรือ CI] พร้อมผลลัพธ์ดังนี้: [บันทึกข้อผิดพลาดที่ถูกลบข้อมูลส่วนตัว] ตรวจสอบโค้ดและตั้งค่าที่เกี่ยวข้องเพื่อระบุสาเหตุ หากความล้มเหลวไม่สามารถทำซ้ำได้ในสภาพแวดล้อมท้องถิ่น ให้ตรวจสอบความแตกต่างของสภาพแวดล้อมหรือการพึ่งพา ทำการเปลี่ยนแปลงเล็กน้อยที่สุดที่แก้ไขสาเหตุได้ อย่าปิดการตรวจสอบ, ซ่อนข้อผิดพลาด, ข้ามการทดสอบ หรือปรับการตั้งค่าคอมไพเลอร์ให้หลวมลงเพียงเพื่อให้การสร้างผ่านได้ ให้รันการสร้างใหม่หลังจากทำการเปลี่ยนแปลง หากยังล้มเหลวหลังจาก [จำนวน] ครั้งที่พยายามแก้ไข ให้หยุดและรายงานสิ่งที่คุณได้ลองทำ ข้อผิดพลาดปัจจุบัน และขั้นตอนการวินิจฉัยต่อไป สรุปสาเหตุและแนบผลลัพธ์การสร้างจริง

ช่วยผมจำกัดขอบเขตของข้อผิดพลาดก่อนที่จะเสนอวิธีแก้ไข พฤติกรรมที่สังเกตได้: [สิ่งที่เกิดขึ้น] พฤติกรรมที่คาดไว้: [สิ่งที่ควรเกิดขึ้น] เมื่อเกิดขึ้น: [เงื่อนไขหรือความถี่] สิ่งที่ผมได้ลองแล้ว: [ขั้นตอนและผลลัพธ์] ถามคำถามทีละข้อ โดยเลือกคำถามที่จะช่วยแยกแยะสาเหตุที่เป็นไปได้ได้ดีที่สุด อย่าถามซ้ำคำถามที่ข้อมูลที่ให้ไว้แล้วตอบได้ เมื่อมีหลักฐานเพียงพอ ให้สรุปคำอธิบายที่เป็นไปได้มากที่สุด สิ่งที่ยังไม่ชัดเจน และการทดสอบที่เล็กที่สุดที่สามารถยืนยันหรือตัดทิ้งได้ อย่าแก้ไขไฟล์ในขั้นตอนนี้

ใช้ subagent เพื่อตรวจสอบ [ความแตกต่างหรือสาขาที่เปรียบเทียบกับฐาน] กับ [แผนที่ได้รับการอนุมัติหรือไฟล์ข้อกำหนด] หากข้อกำหนดขาดหายไปหรือไม่ชัดเจน ให้รายงานก่อนที่จะประเมินความครบถ้วน ตรวจสอบว่าข้อกำหนดแต่ละข้อได้รับการนำไปใช้แล้วหรือไม่ กรณีขอบเขตที่เกี่ยวข้องมีการทดสอบแล้วหรือไม่ และการเปลี่ยนแปลงใดๆ อยู่นอกขอบเขตที่ตกลงกันไว้หรือไม่ ตรวจสอบโค้ดรอบข้างเมื่อจำเป็นเพื่อเข้าใจความแตกต่าง รายงานปัญหาความถูกต้องและข้อกำหนดที่ยังไม่ได้รับการปฏิบัติตาม พร้อมอ้างอิงไฟล์และบรรทัด ผลกระทบ และหลักฐานที่สนับสนุนแต่ละข้อค้นพบ แยกปัญหาที่ได้รับการยืนยันออกจากคำถามที่ยังไม่ได้รับการแก้ไข อย่าสร้างข้อค้นพบขึ้นมาเพื่อเติมโควตา หรือรวมความชอบด้านสไตล์ที่ไม่เกี่ยวข้อง อย่าแก้ไขไฟล์

ตรวจสอบ [ไฟล์หรือ diff] เพื่อหาความเสี่ยงจากการฉีดข้อมูล (injection), การตรวจสอบสิทธิ์ที่ขาดหายไป, ข้อมูลลับที่ถูกเปิดเผย และการจัดการข้อมูลผู้ใช้ที่ไม่ปลอดภัย ตรวจสอบผู้เรียกฟังก์ชันที่เกี่ยวข้องและตรรกะการตรวจสอบความถูกต้องก่อนรายงานผลการตรวจสอบ สำหรับแต่ละปัญหา ให้ระบุไฟล์และบรรทัดที่ได้รับผลกระทบ เงื่อนไขที่จำเป็นเพื่อก่อให้เกิดปัญหา ผลกระทบที่อาจเกิดขึ้น และวิธีแก้ไขที่แนะนำ ให้แยกแยะระหว่างเส้นทางที่ได้รับการยืนยันว่ามีช่องโหว่ กับประเด็นที่ยังต้องทดสอบเพิ่มเติม อย่าคัดลอกค่าข้อมูลลับลงในรายงาน อย่าแก้ไขไฟล์ หรือทดสอบกับบริการที่ใช้งานจริง ให้ระบุชัดเจนว่าคุณได้ตรวจสอบพื้นที่ใดบ้าง และส่วนใดที่อยู่นอกขอบเขตการตรวจสอบ

สรุปวิธีการที่คุณได้ตรวจสอบการเปลี่ยนแปลงที่เสร็จสิ้นแล้วเทียบกับ [เกณฑ์การยอมรับ] สำหรับแต่ละเกณฑ์ ให้ระบุการตรวจสอบที่ดำเนินการ คำสั่งที่แม่นยำ (หากมี) และผลลัพธ์ที่สังเกตได้ รวมถึงผลลัพธ์ที่เกี่ยวข้อง โดยต้องลบข้อมูลลับและข้อมูลที่ละเอียดอ่อนออก ให้ระบุข้อผิดพลาดที่มีอยู่ก่อนนั้นแยกต่างหาก แยกแยะอย่างชัดเจนระหว่างการตรวจสอบที่ผ่าน การตรวจสอบที่ล้มเหลว และการตรวจสอบที่ยังไม่ถูกดำเนินการ อธิบายการตรวจสอบที่ข้ามไปหรือข้อจำกัดในความครอบคลุม อย่าระบุว่าเปลี่ยนแปลงทั้งหมดได้รับการตรวจสอบแล้ว หากยังมีเกณฑ์บางข้อที่ยังไม่ได้รับการตรวจสอบ

ปรับโครงสร้าง [ไฟล์หรือโมดูล] เพื่อ [เป้าหมายเฉพาะ เช่น การแบ่งฟังก์ชันขนาดใหญ่หรือการลบ callback ที่ซ้อนกัน] รักษาอินเทอร์เฟซสาธารณะ ค่าที่คืนกลับ พฤติกรรมเมื่อเกิดข้อผิดพลาด และผลข้างเคียงไว้ ดำเนินการ [คำสั่งทดสอบที่เกี่ยวข้อง] ก่อนการแก้ไขเพื่อกำหนดจุดอ้างอิง หากการทดสอบล้มเหลว ให้รายงานข้อผิดพลาดก่อนดำเนินการต่อ ระบุพฤติกรรมใดที่การทดสอบที่มีอยู่ไม่ครอบคลุม และเพิ่มการทดสอบที่มุ่งเน้นตามความจำเป็น ปรับโครงสร้างโดยไม่มีการเปลี่ยนแปลงที่ไม่เกี่ยวข้องหรือการพึ่งพาใหม่ อย่าลดความเข้มงวดของข้อตรวจสอบที่มีอยู่เพื่อให้สอดคล้องกับการดำเนินการใหม่ ให้รันการทดสอบและ [คำสั่งตรวจสอบประเภทหรือ lint] อีกครั้ง แสดงผลลัพธ์ก่อนและหลัง สรุปการเปลี่ยนแปลงโครงสร้าง และทำเครื่องหมายพฤติกรรมใด ๆ ที่ไม่สามารถตรวจสอบได้

ค้นหาการใช้งาน [API หรือไลบรารีเก่า] ภายใน [ขอบเขตไดเรกทอรี] โดยไม่รวมไฟล์ที่สร้างขึ้นอัตโนมัติและไฟล์ที่จัดเก็บใน vendor รายการไฟล์ที่ได้รับผลกระทบ รวมถึงการตั้งค่าหรือการพึ่งพาที่แชร์ซึ่งการย้ายข้อมูลอาจส่งผลกระทบ เสนอไฟล์ตัวอย่างสามไฟล์สำหรับการย้ายข้อมูลแบบทดลองไปยัง [API หรือเวอร์ชันใหม่] โดยใช้ [คู่มือการย้ายข้อมูลหรือตัวอย่างที่มีอยู่] อธิบายเหตุผลที่เลือกไฟล์เหล่านั้นและระบุการเปลี่ยนแปลงพฤติกรรมที่จำเป็น รอการอนุมัติจากผมก่อนที่จะแก้ไข หลังจากได้รับการอนุมัติ ให้ย้ายเฉพาะไฟล์ทดลองและส่วนพึ่งพาที่แชร์ซึ่งได้รับการอนุมัติอย่างชัดเจนเท่านั้น ดำเนินการ [การทดสอบที่เกี่ยวข้อง] และ [คำสั่งสร้างหรือตรวจสอบประเภทข้อมูล] อย่าขยายการย้ายไปยังไฟล์อื่น ๆ รายงานความแตกต่าง (diff), ผลการทดสอบ, ปัญหาความเข้ากันได้ และการเปลี่ยนแปลงใด ๆ ที่จำเป็นต่อวิธีการย้าย หยุดเพื่อตรวจสอบก่อนที่จะดำเนินการกับไฟล์ที่เหลือ

ตรวจสอบสาขาปัจจุบัน สถานะ Git และ diff สำหรับ [ฟีเจอร์หรือการแก้ไข] ระบุไฟล์ที่เกี่ยวข้องกับการเปลี่ยนแปลงนี้ และจัดรายชื่อไฟล์ที่ไม่เกี่ยวข้องหรือไม่ได้ติดตามไว้แยกต่างหาก ร่างข้อความ commit ตามรูปแบบของ commit 10 ครั้งล่าสุด เตรียมคำอธิบาย pull request ที่ครอบคลุมสิ่งที่เปลี่ยนแปลง เหตุผล การทดสอบที่ดำเนินการจริง และข้อจำกัดที่ยังเหลืออยู่ แสดงรายการไฟล์ที่เสนอ ข้อความ commit และคำอธิบาย PR ก่อนที่จะจัดเตรียมหรือเผยแพร่สิ่งใดก็ตาม รอการอนุมัติจากผม หลังจากได้รับการอนุมัติ ให้จัดเตรียมเฉพาะไฟล์ที่ตกลงกันไว้เท่านั้น ทำการ commit บน [feature branch] push ไปยัง [remote] และเปิด pull request ต่อ [base branch] อย่าแก้ไข commit ที่มีอยู่ อย่าใช้ force-push หรือ merge ส่งคืนค่า commit hash และลิงก์ PR

ร่างส่วน README สำหรับ [โมดูล] ที่มุ่งเป้าไปที่ [ผู้อ่าน เช่น วิศวกรแบ็กเอนด์ที่เข้าร่วมโครงการ] ให้ครอบคลุมข้อกำหนดเบื้องต้น การตั้งค่า สามคำสั่งที่พวกเขาจะใช้บ่อยที่สุด และข้อผิดพลาดทั่วไปที่ได้รับการสนับสนุนโดยโค้ดหรือเอกสารที่มีอยู่ ตรวจสอบชื่อคำสั่งและตัวเลือกกับ [สคริปต์แพ็กเกจ Makefile คำแนะนำ CLI หรือการตั้งค่า CI] ระบุสิ่งที่คุณไม่สามารถยืนยันได้ ทดสอบคำสั่งท้องถิ่นที่ปลอดภัยใน [สภาพแวดล้อมการทดสอบ] หากมีอยู่ ก่อนที่จะรันคำสั่งที่ติดตั้งความพึ่งพา ลบไฟล์ ย้ายข้อมูล ติดตั้งระบบ หรือเข้าถึงบริการภายนอก ให้อธิบายผลกระทบของคำสั่งเหล่านั้นและขอการอนุมัติ แยกแยะอย่างชัดเจนระหว่างคำสั่งที่รันสำเร็จกับคำสั่งที่ตรวจสอบเพียงตามการตั้งค่าหรือเอกสาร แสดงส่วน README ที่เสนอไว้ก่อนที่จะแก้ไข [เส้นทางเอกสาร] และรักษาเนื้อหาที่ไม่เกี่ยวข้องไว้

ตรวจสอบ [path to CLAUDE.md] โดยเปรียบเทียบกับโครงสร้าง สคริปต์ และกฎเกณฑ์ปัจจุบันของรีโพสิตอรี อย่าแก้ไขไฟล์ในขั้นตอนนี้ ระบุคำสั่งที่ล้าสมัย ข้อมูลซ้ำซ้อน ความขัดแย้ง และกฎที่สามารถอนุมานได้อย่างน่าเชื่อถือจากโค้ด อธิบายเหตุผลสำหรับการลบแต่ละส่วนที่เสนอ แทนที่จะตัดคำสั่งเพียงเพื่อย่อขนาดไฟล์ ให้เสนอคำสั่ง build หรือ test ที่ขาดหายไปเฉพาะเมื่อสามารถตรวจสอบได้ในสคริปต์ของโครงการ Makefile การตั้งค่า CI หรือเอกสารที่มีอยู่ อ้างอิงแหล่งที่มาสำหรับแต่ละส่วนที่เพิ่มเข้าไป ส่ง diff ที่เสนอมาโดยรักษาข้อจำกัดสำคัญของโครงการไว้ ทำเครื่องหมายคำสั่งเฉพาะงานที่อาจเหมาะสมกว่าหากอยู่ในกฎระดับทักษะหรือระดับเส้นทาง (skill or path-scoped rule) และรอการอนุมัติก่อนที่จะนำไปใช้

เสนอ hook คำสั่ง Claude Code ที่จะเรียกใช้ [คำสั่ง formatter ที่มีอยู่] หลังจากมีการแก้ไขหรือเขียนข้อมูลใน [รูปแบบไฟล์] ตรวจสอบการตั้งค่าที่มีอยู่ใน claude/settings.json และการตั้งค่าของ formatter ก่อน ใช้การตั้งค่า PostToolUse ที่เหมาะสมกับเวอร์ชัน Claude Code ที่ติดตั้งไว้ จัดรูปแบบเฉพาะไฟล์ที่ได้รับผลกระทบ จัดการเส้นทางอย่างปลอดภัย และยกเว้น [ไฟล์ที่สร้างขึ้นหรือเส้นทางอื่น ๆ ที่ถูกยกเว้น] อย่าติดตั้งการพึ่งพาหรือแทนที่ hook ที่มีอยู่ แสดงความแตกต่างของการตั้งค่าที่เสนอและอธิบายวิธีรายงานความผิดพลาดของตัวจัดรูปแบบ รอการอนุมัติก่อนนำไปใช้ หลังจากได้รับการอนุมัติ ให้ทดสอบด้วยไฟล์ชั่วคราวในโครงการและรายงานผลลัพธ์ ระบุเส้นทางแก้ไขที่ครอบคลุมและที่ไม่ครอบคลุม รวมถึงการเปลี่ยนแปลงที่ทำผ่านคำสั่ง shell

ตรวจสอบ [เครื่องมือ] –help และส่วนช่วยเหลือของคำสั่งย่อยที่เกี่ยวข้องกับ [งาน] อย่าติดตั้งเครื่องมือหากมันขาดหายไป; ให้รายงานข้อกำหนดเบื้องต้นนั้นแทน เสนอคำสั่งที่จำเป็นอย่างแม่นยำเพื่อเสร็จสิ้นงาน อธิบายข้อมูลเข้า ข้อมูลออก และว่าคำสั่งเหล่านั้นเขียนไฟล์ เปลี่ยนแปลงทรัพยากรระยะไกล หรือใช้ข้อมูลรับรองหรือไม่ ให้รวมตัวเลือก dry-run หากเครื่องมือมีเอกสารระบุไว้ แจ้งให้ทราบหากมีการตั้งค่าหรือสิทธิ์ที่ขาดหายไป และขอคำชี้แจงแทนที่จะเดาชื่อทรัพยากรหรือจุดหมายปลายทาง รอการอนุมัติก่อนที่จะรันคำสั่งงาน หลังจากได้รับการอนุมัติ ให้รันเฉพาะคำสั่งที่ตกลงกันไว้และรายงานผลลัพธ์จริง รวมถึงข้อผิดพลาดหรือขั้นตอนที่ยังไม่เสร็จสมบูรณ์

เปรียบเทียบ [invoices.csv] และ [payments.csv] โดยใช้ [ID ใบแจ้งหนี้ หรือ คีย์การจับคู่] อย่าแก้ไขไฟล์ต้นฉบับ ให้ปฏิบัติตามกฎต่อไปนี้: [สกุลเงินและค่าความคลาดเคลื่อนในการปัดเศษ], [การจัดสรรการชำระเงินส่วนหนึ่ง], และ [การจัดการการคืนเงิน เครดิต และการชำระเงินเกิน] หากมีกฎที่ขาดหายไปหรือการจับคู่ไม่ชัดเจน ให้ทำเครื่องหมายไว้แทนที่จะจัดสรรการชำระเงินโดยอัตโนมัติ รักษา ID แถวต้นฉบับไว้ สำหรับใบแจ้งหนี้แต่ละใบ ให้แสดงจำนวนเงินที่เรียกเก็บ การชำระเงินที่จัดสรรแล้ว และยอดคงเหลือ รายงาน ID ซ้ำ, ใบแจ้งหนี้ที่ไม่ตรงกัน, การชำระเงินที่ไม่ตรงกัน และยอดคงเหลือที่อยู่นอกช่วงความคลาดเคลื่อน ให้ปรับยอดรวมของใบแจ้งหนี้และการชำระเงินแยกกัน คำนวณแต่ละแถวต้นฉบับโดยไม่นับซ้ำ; หากการชำระเงินถูกแบ่งไปยังใบแจ้งหนี้หลายใบ ให้แสดงการจัดสรรแต่ละรายการและยืนยันว่าการจัดสรรทั้งหมดไม่เกินยอดการชำระเงิน เขียนผลลัพธ์ไปยัง [เส้นทางผลลัพธ์ใหม่] และสรุปข้อยกเว้นที่จำเป็นต้องตรวจสอบ

เขียนสคริปต์เพื่อสรุปข้อมูลใน [export.csv] สำหรับช่วง [วันที่และเวลาเริ่มต้น (รวมวันและเวลาเริ่มต้น)] ถึง [วันที่และเวลาสิ้นสุด (ไม่รวมวันและเวลาสิ้นสุด)] โดยใช้ [เขตเวลา] และ [คอลัมน์วันที่] จัดกลุ่มข้อมูลตาม [กฎหมวดหมู่] และคำนวณ [ตัวชี้วัดที่จำเป็น] จัดการกับ ID ซ้ำและค่าที่ขาดหายไปตาม [กฎ] อย่าแก้ไขไฟล์ข้อมูลต้นทาง ให้เรียกใช้สคริปต์บน [ไฟล์ข้อมูลต้นทางที่ระบุไว้อย่างชัดเจน] รายงานจำนวนแถวที่รวมและที่ถูกละเว้น ยอดรวมตามหมวดหมู่ และบันทึกที่ไม่สามารถจัดประเภทได้ เปรียบเทียบผลลัพธ์สำหรับ [สามหมวดหมู่] กับจำนวนที่ตรวจสอบอย่างอิสระใน [ไฟล์อ้างอิง] หากจำนวนดังกล่าวไม่มี ให้ระบุว่า การตรวจสอบอย่างอิสระยังไม่เสร็จสิ้น แสดงความแตกต่างและบันทึกรายงานไปยัง [เส้นทางผลลัพธ์ใหม่]

อ่าน [ไฟล์หรือโฟลเดอร์ที่ระบุ] และร่าง [ประเภทและ length ของเอกสาร] สำหรับ [กลุ่มเป้าหมาย] โดยครอบคลุม [คำถามหรือหัวข้อ] ให้สนับสนุนข้ออ้างข้อเท็จจริงในเนื้อหาแต่ละข้อด้วยชื่อไฟล์และอ้างอิงหน้า ส่วน หรือบรรทัด หากมี ให้แยกแยะระหว่างคำอ้างอิงโดยตรงกับคำสรุปความ และอย่าถือว่าข้อเสนอหรือเอกสารที่ล้าสมัยเป็นข้อตัดสินใจปัจจุบันที่ได้รับการยืนยัน ให้ทำเครื่องหมายแหล่งข้อมูลที่ขัดแย้ง ข้อมูลที่ขาดหายไป และข้ออ้างที่คุณไม่สามารถตรวจสอบได้ อย่าเติมช่องว่างด้วยสมมติฐานหรือแก้ไขไฟล์ต้นฉบับ ส่งร่างกลับพร้อมแหล่งอ้างอิงและรายชื่อสั้นๆ ของคำถามที่ยังไม่ได้รับการแก้ไขให้ผู้ตรวจสอบ

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

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

กด Shift+Tab จนกว่าโหมด Plan จะปรากฏขึ้น หรือเปิด Claude Code ด้วยคำสั่ง claude --permission-mode plan ในโหมดนี้ Claude สามารถตรวจสอบไฟล์และรันคำสั่งแบบอ่านอย่างเดียวได้โดยไม่แก้ไขโค้ดต้นฉบับของคุณ ตรวจสอบไฟล์ที่เสนอมา ความพึ่งพา และการทดสอบก่อนที่จะอนุมัติการดำเนินการ กด Ctrl+G เพื่อเปิดแผนที่เสนอมาในตัวแก้ไขของคุณ

ให้ Claude ข้อมูลที่จำเป็นเพื่อเข้าใจงาน: การอ้างอิงไฟล์, บันทึกข้อผิดพลาดที่ได้รับการกรอง, ภาพหน้าจอ หรือเอกสารข้อกำหนด ใช้ @ ตามด้วยเส้นทางไฟล์เพื่อรวมเนื้อหาของไฟล์นั้น

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

ตัวอย่างเช่น, cat error.log | claude -p "Explain this error" จะส่งไฟล์บันทึกด้วยคำขอแบบไม่โต้ตอบ ใช้คำสั่งนี้เพียงหลังจากตรวจสอบเนื้อหาของไฟล์แล้วเท่านั้น นี่คือประโยชน์ทางปฏิบัติของAI ที่อิงบริบท: การให้ข้อมูลที่เกี่ยวข้องกับงานแก่โมเดล

เมื่อเพิ่มฟีเจอร์ใหม่ ให้ระบุส่วนประกอบหรือฟังก์ชันที่คล้ายกันในรีโพสิตอรี แจ้งให้ Claude ทราบว่าควรปฏิบัติตามกฎเกณฑ์ใด เช่น API client, ตรรกะการตรวจสอบความถูกต้อง, การจัดการข้อผิดพลาด หรือโครงสร้างการทดสอบ

“ติดตามวิธีที่ @src/widgets/Weather.tsx ดึงข้อมูลและเก็บไว้ในแคช” ให้ Claude มีข้อมูลอ้างอิงที่ชัดเจน นอกจากนี้ ให้ระบุความแตกต่างที่ฟีเจอร์ใหม่ต้องการ เพื่อไม่ให้คัดลอกพฤติกรรมที่ไม่เหมาะสมอีกต่อไป ข้อกำหนดเหล่านี้ควรสะท้อนถึงกระบวนการพัฒนาซอฟต์แวร์ของทีมคุณ

สำหรับการเปลี่ยนแปลงโค้ด ให้ระบุคำสั่ง test, build หรือ lint ที่เกี่ยวข้อง และพฤติกรรมที่คำสั่งนั้นควรตรวจสอบ สำหรับการวิจัย ให้ขอข้อมูลอ้างอิงไฟล์หรือ ID commit สำหรับงาน UI ให้จัดเตรียมภาพอ้างอิงและวิธีการที่ตั้งค่าไว้เพื่อบันทึกการนำไปใช้ในวิวพอร์ตเดียวกัน

ขอให้ Claude รายงานสิ่งที่ได้ตรวจสอบจริง รวมถึงข้อผิดพลาดและการตรวจสอบที่ถูกข้ามไป ตรวจสอบว่าหลักฐานดังกล่าวครอบคลุมข้อกำหนดหรือไม่; การสร้างโค้ดที่ผ่านไม่ได้เป็นการยืนยันว่าทุกพฤติกรรมที่ร้องขอทำงานได้

สำหรับงานที่ใช้เวลานาน Claude Code ยังเสนอเงื่อนไข /goalและ Stop hooks ด้วย ตัวประเมินเป้าหมายจะประเมินหลักฐานที่ปรากฏในบทสนทนา แทนที่จะตรวจสอบไฟล์หรือรันการทดสอบอย่างอิสระ Stop hook ที่กำหนดค่าไว้สามารถบล็อกการเสร็จสิ้นได้ แต่มีข้อจำกัดในการบล็อกซ้ำๆ ทั้งสองอย่างนี้ไม่สามารถแทนที่การทดสอบที่เหมาะสมและการตรวจสอบโดยมนุษย์ได้

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

คู่มือแนวทางปฏิบัติที่ดีที่สุดของ Anthropic แนะนำให้เริ่มต้นใหม่หลังจากแก้ไขปัญหาเดียวกันไม่สำเร็จสองครั้ง ใช้คำสั่ง /clear แล้วให้คำสั่งใหม่ที่รวมสิ่งที่คุณได้เรียนรู้ การล้างการสนทนาจะไม่ยกเลิกการเปลี่ยนแปลงไฟล์

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

บันทึกแนวทางสำหรับทั้งโครงการในไฟล์ CLAUDE.md ขั้นตอนที่สามารถทำซ้ำได้ในส่วน skills และคำสั่งสำหรับไฟล์เฉพาะในกฎที่กำหนดขอบเขตตามเส้นทาง (path-scoped rules) ใช้ hooks สำหรับการดำเนินการที่เชื่อมโยงกับเหตุการณ์เฉพาะ เช่น การเรียกใช้ตัวจัดรูปแบบ (formatter) หลังจากแก้ไข

เลือกตามช่วงเวลาที่คำสั่งควรถูกนำไปใช้:

ข้อกำหนดสำหรับฟีเจอร์หนึ่งมักควรอยู่ในคำสั่งงานหรือเอกสารข้อกำหนดของฟีเจอร์นั้นเอง มากกว่าที่จะอยู่ในไฟล์ CLAUDE.md การเพิ่มคำสั่งชั่วคราวลงในไฟล์ที่ใช้สำหรับทั้งโครงการจะทำให้ยากต่อการแยกแยะจากกฎเกณฑ์ที่ควรใช้ทั่วทั้งรีโพสิตอรี

ตัวอย่างเช่น เก็บคำสั่งทดสอบของโครงการไว้ในไฟล์ CLAUDE.md กำหนดกฎเกณฑ์เฉพาะส่วนประกอบในกฎที่มีขอบเขตตามเส้นทาง (path-scoped rule) และบันทึกขั้นตอนการตรวจสอบที่เกิดขึ้นซ้ำๆ เป็นทักษะ (skill) ตรวจสอบไฟล์เหล่านี้เมื่อคำสั่งหรือกฎเกณฑ์มีการเปลี่ยนแปลง เช่นเดียวกับที่คุณทำกับเอกสารโครงการอื่นๆ

คำสั่ง Prompts, CLAUDE.md และคู่มือทักษะ (skills guide) จะกำหนดพฤติกรรมของ Claude; แต่ไม่รับประกันว่าคำสั่งดังกล่าวจะได้รับการปฏิบัติตาม ฮุก (hooks) สามารถดำเนินการตรวจสอบเมื่อเกิดเหตุการณ์ที่กำหนดไว้ แต่ความน่าเชื่อถือของมันขึ้นอยู่กับประเภทของฮุกและวิธีการนำไปใช้

Command hook ใช้เพื่อเรียกใช้สคริปต์ ส่วน prompt hook หรือ agent hook ขึ้นอยู่กับความตัดสินใจของโมเดลตามที่คู่มือแนวทางปฏิบัติที่ดีที่สุดของ Anthropic อธิบายไว้ว่า: “prompt hook หรือ agent hook ขอให้โมเดลอื่นตัดสินใจ ดังนั้นมันจึงไม่ใช่แบบกำหนดค่าแน่นอนเช่นกัน” สำหรับกฎที่ต้องบังคับใช้ ให้ใช้การควบคุมสิทธิ์ที่เหมาะสม และทดสอบ command hook หรือ HTTP hook ที่เกี่ยวข้อง รวมถึงวิธีที่มันจัดการกับความล้มเหลว

subagent ที่กำหนดเองเป็นอีกวิธีหนึ่งในการจัดระเบียบงานที่ทำซ้ำๆ ให้กำหนดผู้เชี่ยวชาญใน claude/agents/ เมื่อต้องการบทบาทการตรวจสอบหรือขอบเขตเครื่องมือที่เฉพาะเจาะจง แทนที่จะเพิ่มคำสั่งผู้เชี่ยวชาญทุกข้อลงในเซสชันหลัก คู่มือเหล่านี้เกี่ยวกับโมเดล Claude ที่เหมาะสมที่สุดสำหรับงานและ ประเภทของเอเยนต์ AIจะให้บริบทเพิ่มเติม

หากทีมของคุณดูแลพรอมต์ในหลายผลิตภัณฑ์ AI โปรดดูเครื่องมือวิศวกรรมพรอมต์เหล่านี้เพื่อจัดการไลบรารีนอกเหนือจาก Claude Code

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

คำสั่ง “Investigate the repository” ให้ Claude ทิศทางน้อยมากเกี่ยวกับไฟล์ใดที่สำคัญหรือเมื่อใดควรหยุด คุณอาจได้รับสรุปทั่วไปโดยไม่มีคำตอบสำหรับปัญหาที่เป็นสาเหตุของการส่งคำขอ

ระบุพฤติกรรมหรือการตัดสินใจที่คุณต้องการเข้าใจ ระบุจุดเริ่มต้น และกำหนดผลลัพธ์ที่คาดหวัง ตัวอย่างเช่น: “ติดตามวิธีที่จุดปลายนี้ตรวจสอบสิทธิ์การเข้าถึง และระบุฟังก์ชันที่เกี่ยวข้อง” หากใช้ subagents ให้กำหนดคำถามที่มีขอบเขตชัดเจนสำหรับแต่ละ subagent แทนที่จะมอบหมายการค้นหาแบบไม่มีข้อจำกัดเดียวกัน

การเปลี่ยนไปมาระหว่างฟีเจอร์ ข้อบกพร่องที่ไม่เกี่ยวข้อง และคำขอเอกสาร ทำให้การสนทนายังคงมีบริบทที่อาจไม่เกี่ยวข้องกับงานปัจจุบัน การอ้างอิงเช่น “ไฟล์นั้น” หรือ “วิธีการก่อนหน้านี้” จึงกลายเป็นไม่ชัดเจน

ใช้เซสชันแยกกันสำหรับงานที่ไม่เกี่ยวข้องกัน หากมีหลายเซสชันที่จะแก้ไขรีโพสิตอรี ให้ใช้ Git worktrees แยกกัน เพื่อไม่ให้มีการแก้ไขไดเรกทอรีทำงานเดียวกัน สำหรับคำถามสั้นๆ ที่ไม่เกี่ยวข้อง คำสั่ง /btw ของ Claude Code จะช่วยไม่ให้การแลกเปลี่ยนข้อความนั้นปรากฏในประวัติการสนทนาหลัก

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

กำหนดเกณฑ์การยอมรับให้สอดคล้องกับการตรวจสอบเฉพาะ สำหรับการแก้ไขข้อผิดพลาด ให้ขอหลักฐานว่า การทดสอบเพื่อจำลองข้อผิดพลาดล้มเหลวก่อนการเปลี่ยนแปลง และผ่านหลังจากนั้น ให้เก็บบันทึกเกณฑ์ที่ยังไม่ได้รับการทดสอบไว้ให้เห็นได้ชัดเจน แทนที่จะถือว่าการทำงานสำเร็จของคำสั่งเดียวเป็นการยืนยันการเปลี่ยนแปลงทั้งหมด

ไฟล์ CLAUDE.md ที่กำลังขยายตัวอาจมีคำสั่งที่ล้าสมัย กฎที่ซ้ำกัน และคำแนะนำที่ขัดแย้งกับข้อกำหนดเฉพาะของงาน การเพิ่มคำที่ชัดเจนขึ้นจะไม่ช่วยแก้ไขความขัดแย้งเหล่านั้น

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

การตรวจสอบอาจพบข้อบกพร่องที่แท้จริง ปัญหาที่ยังไม่ชัดเจน และข้อเสนอแนะการปรับโครงสร้างโค้ด (refactoring) ที่ไม่จำเป็นได้พร้อมกัน การนำข้อเสนอแนะทุกข้อไปใช้ อาจทำให้การเปลี่ยนแปลงขยายตัวออกไปโดยไม่ปรับปรุงพฤติกรรมที่ต้องการ

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

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

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

กด Shift+Tab จนกว่าโหมด Plan จะปรากฏขึ้น หรือเปิด Claude Code ด้วยคำสั่ง claude --permission-mode plan ในโหมดนี้ Claude สามารถตรวจสอบไฟล์และรันคำสั่งแบบอ่านอย่างเดียวได้โดยไม่แก้ไขโค้ดต้นฉบับของคุณ ตรวจสอบไฟล์ที่เสนอ ความพึ่งพา และการทดสอบก่อนที่จะอนุมัติการดำเนินการ กด Ctrl+G เพื่อเปิดแผนที่เสนอในตัวแก้ไขของคุณ

ให้ Claude ข้อมูลที่จำเป็นเพื่อเข้าใจงาน: การอ้างอิงไฟล์, บันทึกข้อผิดพลาดที่ได้รับการกรอง, ภาพหน้าจอ หรือเอกสารข้อกำหนด ใช้ @ ตามด้วยเส้นทางไฟล์เพื่อรวมเนื้อหาของไฟล์นั้น

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

ตัวอย่างเช่น, cat error.log | claude -p "Explain this error" จะส่งบันทึกด้วยคำขอแบบไม่โต้ตอบ ใช้คำสั่งนี้เฉพาะหลังจากตรวจสอบเนื้อหาของไฟล์แล้วเท่านั้น นี่คือประโยชน์ทางปฏิบัติของAI ที่อิงบริบท: การให้ข้อมูลที่เกี่ยวข้องกับงานแก่โมเดล

เมื่อเพิ่มฟีเจอร์ใหม่ ให้ระบุส่วนประกอบหรือฟังก์ชันที่คล้ายกันในรีโพสิตอรี แจ้งให้ Claude ทราบว่าควรปฏิบัติตามกฎเกณฑ์ใด เช่น API client, ตรรกะการตรวจสอบความถูกต้อง, การจัดการข้อผิดพลาด หรือโครงสร้างการทดสอบ

“ติดตามวิธีที่ @src/widgets/Weather.tsx ดึงข้อมูลและเก็บไว้ในแคช” ให้ Claude มีข้อมูลอ้างอิงที่ชัดเจน นอกจากนี้ ให้ระบุความแตกต่างที่ฟีเจอร์ใหม่ต้องการ เพื่อไม่ให้คัดลอกพฤติกรรมที่ไม่เหมาะสมอีกต่อไป ข้อกำหนดเหล่านี้ควรสะท้อนถึงกระบวนการพัฒนาซอฟต์แวร์ของทีมคุณ

สำหรับการเปลี่ยนแปลงโค้ด ให้ระบุคำสั่ง test, build หรือ lint ที่เกี่ยวข้อง และพฤติกรรมที่คำสั่งนั้นควรตรวจสอบ สำหรับการวิจัย ให้ขอข้อมูลอ้างอิงไฟล์หรือ ID commit สำหรับงาน UI ให้จัดเตรียมภาพอ้างอิงและวิธีการที่ตั้งค่าไว้เพื่อบันทึกการนำไปใช้ในวิวพอร์ตเดียวกัน

ขอให้ Claude รายงานสิ่งที่มันตรวจสอบจริง ๆ รวมถึงการตรวจสอบที่ล้มเหลวและถูกข้ามไป ตรวจสอบว่าหลักฐานดังกล่าวครอบคลุมข้อกำหนดหรือไม่; การสร้างโค้ดที่ผ่านไม่ได้เป็นการยืนยันว่าทุกพฤติกรรมที่ร้องขอทำงานได้

สำหรับงานที่ใช้เวลานาน Claude Code ยังเสนอเงื่อนไข /goalและ Stop hooks ด้วย ตัวประเมินเป้าหมายจะวิเคราะห์หลักฐานที่ปรากฏในบทสนทนา แทนที่จะตรวจสอบไฟล์หรือรันการทดสอบอย่างอิสระ Stop hook ที่ตั้งค่าไว้สามารถบล็อกการเสร็จสิ้นได้ แต่มีข้อจำกัดในการบล็อกซ้ำๆ ทั้งสองอย่างนี้ไม่สามารถแทนที่การทดสอบที่เหมาะสมและการตรวจสอบโดยมนุษย์ได้

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

คู่มือแนวทางปฏิบัติที่ดีที่สุดของ Anthropic แนะนำให้เริ่มต้นใหม่หลังจากแก้ไขปัญหาเดียวกันไม่สำเร็จสองครั้ง ใช้คำสั่ง /clear แล้วให้คำสั่งใหม่ที่ปรับปรุงโดยนำสิ่งที่คุณได้เรียนรู้มาปรับใช้ การล้างการสนทนาจะไม่ยกเลิกการเปลี่ยนแปลงไฟล์

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

บันทึกแนวทางสำหรับทั้งโครงการในไฟล์ CLAUDE.md ขั้นตอนที่สามารถทำซ้ำได้ในส่วน skills และคำสั่งสำหรับไฟล์เฉพาะในกฎที่กำหนดขอบเขตตามเส้นทาง (path-scoped rules) ใช้ hooks สำหรับการดำเนินการที่เชื่อมโยงกับเหตุการณ์เฉพาะ เช่น การเรียกใช้ตัวจัดรูปแบบ (formatter) หลังจากแก้ไข

เลือกตามช่วงเวลาที่คำสั่งควรถูกนำไปใช้:

ข้อกำหนดสำหรับฟีเจอร์หนึ่งมักควรอยู่ในคำสั่งงานหรือเอกสารข้อกำหนดของฟีเจอร์นั้นเอง แทนที่จะอยู่ในไฟล์ CLAUDE.md การเพิ่มคำสั่งชั่วคราวลงในไฟล์ที่ใช้ทั่วทั้งโครงการจะทำให้ยากต่อการแยกแยะจากกฎเกณฑ์ที่ควรใช้ทั่วทั้งรีโพสิตอรี

ตัวอย่างเช่น เก็บคำสั่งทดสอบของโครงการไว้ในไฟล์ CLAUDE.md กำหนดกฎเกณฑ์เฉพาะส่วนประกอบในกฎที่มีขอบเขตตามเส้นทาง (path-scoped rule) และบันทึกขั้นตอนการตรวจสอบที่เกิดขึ้นซ้ำๆ เป็นทักษะ (skill) ตรวจสอบไฟล์เหล่านี้เมื่อคำสั่งหรือกฎเกณฑ์มีการเปลี่ยนแปลง เช่นเดียวกับที่คุณทำกับเอกสารโครงการอื่นๆ

คำสั่ง Prompts, CLAUDE.md และคู่มือทักษะ (skills guide) จะกำหนดพฤติกรรมของ Claude; แต่ไม่รับประกันว่าคำสั่งนั้นจะถูกปฏิบัติตาม ฮุก (hooks) สามารถดำเนินการตรวจสอบเมื่อเกิดเหตุการณ์ที่กำหนดไว้ แต่ความน่าเชื่อถือของมันขึ้นอยู่กับประเภทของฮุกและวิธีการนำไปใช้

Command hook ใช้เพื่อเรียกใช้สคริปต์ ส่วน prompt หรือ agent hook ขึ้นอยู่กับความตัดสินใจของโมเดลตามที่คู่มือแนวทางปฏิบัติที่ดีที่สุดของAnthropic อธิบายว่า: “prompt หรือ agent hook ขอให้โมเดลอื่นตัดสินใจ ดังนั้นมันจึงไม่ใช่แบบกำหนดแน่นอนเช่นกัน” สำหรับกฎที่ต้องบังคับใช้ ให้ใช้การควบคุมสิทธิ์ที่เหมาะสม และทดสอบ command hook หรือ HTTP hook ที่เกี่ยวข้อง รวมถึงวิธีที่มันจัดการกับความล้มเหลว

subagent ที่กำหนดเองเป็นอีกวิธีหนึ่งในการจัดระเบียบงานที่ทำซ้ำๆ ให้กำหนดผู้เชี่ยวชาญใน claude/agents/ เมื่อต้องการบทบาทการตรวจสอบหรือขอบเขตเครื่องมือที่เฉพาะเจาะจง แทนที่จะเพิ่มคำสั่งผู้เชี่ยวชาญทุกข้อลงในเซสชันหลัก คู่มือเหล่านี้เกี่ยวกับโมเดล Claude ที่เหมาะสมที่สุดสำหรับงานและ ประเภทของเอเยนต์ AIจะให้บริบทเพิ่มเติม

หากทีมของคุณกำลังดูแลพรอมต์ในหลายผลิตภัณฑ์ AI โปรดดูเครื่องมือวิศวกรรมพรอมต์เหล่านี้เพื่อจัดการไลบรารีนอกเหนือจาก Claude Code

เมื่อเซสชันให้ผลลัพธ์ที่ไม่สมบูรณ์หรือไม่เหมาะสม ให้ตรวจสอบว่าคำขอได้ทิ้งการตัดสินใจสำคัญไว้โดยไม่ได้รับการแก้ไขหรือไม่ ความผิดพลาดทั้งห้าข้อนี้อาจทำให้การวินิจฉัยและตรวจสอบงานเป็นไปได้ยากขึ้น

คำสั่ง “Investigate the repository” ให้ Claude ทิศทางน้อยมากเกี่ยวกับไฟล์ใดที่สำคัญหรือเมื่อใดควรหยุด คุณอาจได้รับสรุปทั่วไปโดยไม่มีคำตอบสำหรับปัญหาที่เป็นสาเหตุของการส่งคำขอ

ระบุพฤติกรรมหรือการตัดสินใจที่คุณต้องการเข้าใจ กำหนดจุดเริ่มต้น และกำหนดผลลัพธ์ที่คาดหวัง ตัวอย่างเช่น: “ติดตามวิธีที่จุดปลายนี้ตรวจสอบสิทธิ์และระบุฟังก์ชันที่เกี่ยวข้อง” หากคุณใช้ subagents ให้ตั้งคำถามที่มีขอบเขตชัดเจนสำหรับแต่ละ subagent แทนที่จะมอบหมายการค้นหาแบบไม่มีข้อจำกัดเดียวกัน

การเปลี่ยนไปมาระหว่างฟีเจอร์ ข้อบกพร่องที่ไม่เกี่ยวข้อง และคำขอเอกสาร ทำให้การสนทนายังคงมีบริบทที่อาจไม่เกี่ยวข้องกับงานปัจจุบัน การอ้างอิงเช่น “ไฟล์นั้น” หรือ “วิธีการก่อนหน้านี้” จึงกลายเป็นไม่ชัดเจน

ใช้เซสชันแยกกันสำหรับงานที่ไม่เกี่ยวข้องกัน หากมีหลายเซสชันที่จะแก้ไขรีโพสิตอรี ให้ใช้ Git worktrees แยกกัน เพื่อไม่ให้มีการแก้ไขไดเรกทอรีทำงานเดียวกัน สำหรับคำถามสั้นๆ ที่ไม่เกี่ยวข้อง คำสั่ง /btw ของ Claude Code จะช่วยไม่ให้การแลกเปลี่ยนข้อความนั้นปรากฏในประวัติการสนทนาหลัก

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

กำหนดเกณฑ์การยอมรับให้สอดคล้องกับการตรวจสอบเฉพาะ สำหรับการแก้ไขข้อผิดพลาด ให้ขอหลักฐานว่า การทดสอบเพื่อจำลองข้อผิดพลาดล้มเหลวก่อนการเปลี่ยนแปลง และผ่านหลังการเปลี่ยนแปลง ให้เกณฑ์ที่ยังไม่ได้รับการทดสอบยังคงปรากฏอยู่ แทนที่จะถือว่าการสั่งคำสั่งที่สำเร็จเพียงครั้งเดียวเป็นการยืนยันการเปลี่ยนแปลงทั้งหมด

ไฟล์ CLAUDE.md ที่กำลังขยายตัวอาจมีคำสั่งที่ล้าสมัย กฎที่ซ้ำกัน และคำแนะนำที่ขัดแย้งกับข้อกำหนดเฉพาะของงาน การเพิ่มคำที่ชัดเจนขึ้นจะไม่ช่วยแก้ไขความขัดแย้งเหล่านั้น

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

การตรวจสอบอาจพบข้อบกพร่องที่แท้จริง ปัญหาที่ยังไม่ชัดเจน และข้อเสนอแนะการปรับโครงสร้างโค้ด (refactoring) ที่ไม่จำเป็นได้พร้อมกัน การนำข้อเสนอแนะทุกข้อไปใช้ อาจทำให้การเปลี่ยนแปลงขยายตัวออกไปโดยไม่ปรับปรุงพฤติกรรมที่ต้องการ

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

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

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

กด Shift+Tab จนกว่าโหมด Plan จะปรากฏขึ้น หรือเปิด Claude Code ด้วยคำสั่ง claude --permission-mode plan ในโหมดนี้ Claude สามารถตรวจสอบไฟล์และรันคำสั่งแบบอ่านอย่างเดียวได้โดยไม่แก้ไขโค้ดต้นฉบับของคุณ ตรวจสอบไฟล์ที่เสนอมา ความพึ่งพา และการทดสอบก่อนที่จะอนุมัติการดำเนินการ กด Ctrl+G เพื่อเปิดแผนที่เสนอมาในตัวแก้ไขของคุณ

ให้ Claude ข้อมูลที่จำเป็นเพื่อเข้าใจงาน: การอ้างอิงไฟล์, บันทึกข้อผิดพลาดที่ได้รับการกรอง, ภาพหน้าจอ หรือเอกสารข้อกำหนด ใช้ @ ตามด้วยเส้นทางไฟล์เพื่อรวมเนื้อหาของไฟล์นั้น

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

ตัวอย่างเช่น, cat error.log | claude -p "Explain this error" จะส่งบันทึกด้วยคำขอแบบไม่โต้ตอบ ใช้คำสั่งนี้เพียงหลังจากตรวจสอบเนื้อหาของไฟล์แล้วเท่านั้น นี่คือประโยชน์ทางปฏิบัติของAI ที่อิงบริบท: การให้ข้อมูลที่เกี่ยวข้องกับงานแก่โมเดล

เมื่อเพิ่มฟีเจอร์ใหม่ ให้ระบุส่วนประกอบหรือฟังก์ชันที่คล้ายกันในรีโพสิตอรี แจ้งให้ Claude ทราบว่าควรปฏิบัติตามกฎเกณฑ์ใด เช่น API client, ตรรกะการตรวจสอบความถูกต้อง, การจัดการข้อผิดพลาด หรือโครงสร้างการทดสอบ

“ติดตามวิธีที่ @src/widgets/Weather.tsx ดึงข้อมูลและเก็บไว้ในแคช” ให้ Claude มีข้อมูลอ้างอิงที่ชัดเจน นอกจากนี้ ให้ระบุความแตกต่างใดๆ ที่ฟีเจอร์ใหม่ต้องการ เพื่อไม่ให้คัดลอกพฤติกรรมที่ไม่เหมาะสมอีกต่อไป ข้อกำหนดเหล่านี้ควรสะท้อนถึงกระบวนการพัฒนาซอฟต์แวร์ของทีมคุณ

สำหรับการเปลี่ยนแปลงโค้ด ให้ระบุคำสั่ง test, build หรือ lint ที่เกี่ยวข้อง และพฤติกรรมที่คำสั่งนั้นควรตรวจสอบ สำหรับการวิจัย ให้ขอข้อมูลอ้างอิงไฟล์หรือ ID commit สำหรับงาน UI ให้จัดเตรียมภาพอ้างอิงและวิธีการที่ตั้งค่าไว้เพื่อบันทึกการนำไปใช้ในวิวพอร์ตเดียวกัน

ขอให้ Claude รายงานสิ่งที่มันตรวจสอบจริง ๆ รวมถึงการตรวจสอบที่ล้มเหลวและถูกข้ามไป ตรวจสอบว่าหลักฐานดังกล่าวครอบคลุมข้อกำหนดหรือไม่; การสร้างโค้ดที่ผ่านไม่ได้เป็นการยืนยันว่าทุกพฤติกรรมที่ร้องขอทำงานได้

สำหรับงานที่ใช้เวลานาน Claude Code ยังเสนอเงื่อนไข /goalและ Stop hooks ด้วย ตัวประเมินเป้าหมายจะวิเคราะห์หลักฐานที่ปรากฏในบทสนทนา แทนที่จะตรวจสอบไฟล์หรือรันการทดสอบอย่างอิสระ Stop hook ที่ตั้งค่าไว้สามารถบล็อกการเสร็จสิ้นได้ แต่มีข้อจำกัดในการบล็อกซ้ำๆ ทั้งสองอย่างนี้ไม่สามารถแทนที่การทดสอบที่เหมาะสมและการตรวจสอบโดยมนุษย์ได้

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

คู่มือแนวทางปฏิบัติที่ดีที่สุดของ Anthropic แนะนำให้เริ่มต้นใหม่หลังจากแก้ไขปัญหาเดียวกันไม่สำเร็จสองครั้ง ใช้คำสั่ง /clear แล้วให้คำสั่งใหม่ที่ปรับปรุงโดยนำสิ่งที่คุณได้เรียนรู้มาปรับใช้ การล้างการสนทนาจะไม่ยกเลิกการเปลี่ยนแปลงไฟล์

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

บันทึกแนวทางสำหรับทั้งโครงการในไฟล์ CLAUDE.md ขั้นตอนที่สามารถทำซ้ำได้ในส่วน skills และคำสั่งสำหรับไฟล์เฉพาะในกฎที่มีขอบเขตตามเส้นทาง ใช้ hooks สำหรับการดำเนินการที่เชื่อมโยงกับเหตุการณ์เฉพาะ เช่น การเรียกใช้ตัวจัดรูปแบบหลังจากแก้ไข

เลือกตามช่วงเวลาที่คำสั่งควรถูกนำไปใช้:

ข้อกำหนดสำหรับฟีเจอร์หนึ่งมักควรอยู่ในคำสั่งงานหรือเอกสารข้อกำหนดของฟีเจอร์นั้นเอง ไม่ใช่ในไฟล์ CLAUDE.md การเพิ่มคำสั่งชั่วคราวลงในไฟล์ที่ใช้ทั่วทั้งโครงการจะทำให้ยากต่อการแยกแยะจากกฎเกณฑ์ที่ควรใช้ทั่วทั้งรีโพสิตอรี

ตัวอย่างเช่น เก็บคำสั่งทดสอบของโครงการไว้ในไฟล์ CLAUDE.md กำหนดกฎเกณฑ์เฉพาะส่วนประกอบในกฎที่มีขอบเขตตามเส้นทาง (path-scoped rule) และบันทึกขั้นตอนการตรวจสอบที่ซ้ำๆ เป็นทักษะ (skill) ตรวจสอบไฟล์เหล่านี้เมื่อคำสั่งหรือกฎเกณฑ์มีการเปลี่ยนแปลง เช่นเดียวกับที่คุณทำกับเอกสารโครงการอื่นๆ

คำสั่ง Prompts, CLAUDE.md และคู่มือทักษะ (skills guide) เป็นตัวกำหนดพฤติกรรมของ Claude; แต่ไม่รับประกันว่าคำสั่งดังกล่าวจะได้รับการปฏิบัติตาม ฮุก (hooks) สามารถดำเนินการตรวจสอบเมื่อเกิดเหตุการณ์ที่กำหนดไว้ แต่ความน่าเชื่อถือของมันขึ้นอยู่กับประเภทของฮุกและวิธีการนำไปใช้

Command hook ใช้เพื่อเรียกใช้สคริปต์ ส่วน prompt หรือ agent hook ขึ้นอยู่กับความตัดสินใจของโมเดลตามที่คู่มือแนวทางปฏิบัติที่ดีที่สุดของAnthropic อธิบายไว้ว่า: “prompt หรือ agent hook ขอให้โมเดลอื่นตัดสินใจ ดังนั้นมันจึงไม่ใช่แบบกำหนดผลลัพธ์แน่นอนเช่นกัน” สำหรับกฎที่ต้องบังคับใช้ ให้ใช้การควบคุมสิทธิ์ที่เหมาะสม และทดสอบ command hook หรือ HTTP hook ที่เกี่ยวข้อง รวมถึงวิธีที่มันจัดการกับความผิดพลาด

subagent ที่กำหนดเองเป็นอีกวิธีหนึ่งในการจัดระเบียบงานที่เกิดขึ้นซ้ำๆ ให้กำหนดผู้เชี่ยวชาญใน claude/agents/ เมื่อต้องการบทบาทการตรวจสอบหรือขอบเขตเครื่องมือที่เฉพาะเจาะจง แทนที่จะเพิ่มคำสั่งผู้เชี่ยวชาญทุกข้อลงในเซสชันหลัก คู่มือเหล่านี้เกี่ยวกับโมเดล Claude ที่เหมาะสมที่สุดสำหรับงานและ ประเภทของเอเยนต์ AIจะให้บริบทเพิ่มเติม

หากทีมของคุณกำลังดูแลพรอมต์ในหลายผลิตภัณฑ์ AI โปรดดูเครื่องมือวิศวกรรมพรอมต์เหล่านี้เพื่อจัดการไลบรารีนอกเหนือจาก Claude Code

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

คำสั่ง “Investigate the repository” ให้ Claude ทิศทางน้อยมากเกี่ยวกับไฟล์ใดที่สำคัญหรือเมื่อใดควรหยุด คุณอาจได้รับสรุปทั่วไปโดยไม่มีคำตอบสำหรับปัญหาที่เป็นสาเหตุของการส่งคำขอ

ระบุพฤติกรรมหรือการตัดสินใจที่คุณต้องการเข้าใจ กำหนดจุดเริ่มต้น และกำหนดผลลัพธ์ที่คาดหวัง ตัวอย่างเช่น: “ติดตามวิธีที่จุดปลายนี้ตรวจสอบสิทธิ์การเข้าถึง และระบุฟังก์ชันที่เกี่ยวข้อง” หากใช้ subagents ให้กำหนดคำถามที่มีขอบเขตชัดเจนสำหรับแต่ละ subagent แทนที่จะมอบหมายการค้นหาแบบไม่มีข้อจำกัดเดียวกัน

การเปลี่ยนไปมาระหว่างฟีเจอร์ ข้อบกพร่องที่ไม่เกี่ยวข้อง และคำขอเอกสาร ทำให้การสนทนายังคงมีบริบทที่อาจไม่เกี่ยวข้องกับงานปัจจุบัน การอ้างอิงเช่น “ไฟล์นั้น” หรือ “วิธีการก่อนหน้านี้” จึงกลายเป็นไม่ชัดเจน

ใช้เซสชันแยกกันสำหรับงานที่ไม่เกี่ยวข้องกัน หากมีหลายเซสชันที่จะแก้ไขรีโพสิตอรี ให้ใช้ Git worktrees แยกกัน เพื่อไม่ให้มีการแก้ไขไดเรกทอรีทำงานเดียวกัน สำหรับคำถามสั้นๆ ที่ไม่เกี่ยวข้อง คำสั่ง /btw ของ Claude Code จะช่วยไม่ให้การแลกเปลี่ยนข้อความนั้นปรากฏในประวัติการสนทนาหลัก

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

กำหนดเกณฑ์การยอมรับให้สอดคล้องกับการตรวจสอบเฉพาะ สำหรับการแก้ไขข้อผิดพลาด ให้ขอหลักฐานว่า การทดสอบเพื่อจำลองข้อผิดพลาดล้มเหลวก่อนการเปลี่ยนแปลง และผ่านหลังการเปลี่ยนแปลง ให้เกณฑ์ที่ยังไม่ได้รับการทดสอบยังคงปรากฏอยู่ แทนที่จะถือว่าการสั่งคำสั่งที่สำเร็จเพียงครั้งเดียวเป็นการยืนยันการเปลี่ยนแปลงทั้งหมด

ไฟล์ CLAUDE.md ที่กำลังขยายตัวอาจมีคำสั่งที่ล้าสมัย กฎที่ซ้ำกัน และคำแนะนำที่ขัดแย้งกับข้อกำหนดเฉพาะของงาน การเพิ่มคำที่ชัดเจนขึ้นจะไม่ช่วยแก้ไขความขัดแย้งเหล่านั้น

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

การตรวจสอบสามารถระบุข้อบกพร่องที่แท้จริง ปัญหาที่ยังไม่ชัดเจน และข้อเสนอแนะการปรับโครงสร้างโค้ด (refactoring) ที่ไม่จำเป็นได้พร้อมกัน การนำข้อเสนอแนะทุกข้อไปใช้ อาจทำให้การเปลี่ยนแปลงขยายตัวโดยไม่ปรับปรุงพฤติกรรมที่ร้องขอ

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

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

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

กด Shift+Tab จนกว่าโหมด Plan จะปรากฏขึ้น หรือเปิด Claude Code ด้วยคำสั่ง claude --permission-mode plan ในโหมดนี้ Claude สามารถตรวจสอบไฟล์และรันคำสั่งแบบอ่านอย่างเดียวได้โดยไม่แก้ไขโค้ดต้นฉบับของคุณ ตรวจสอบไฟล์ที่เสนอมา ความพึ่งพา และการทดสอบก่อนที่จะอนุมัติการดำเนินการ กด Ctrl+G เพื่อเปิดแผนที่เสนอมาในตัวแก้ไขของคุณ

ให้ Claude ข้อมูลที่จำเป็นเพื่อเข้าใจงาน: การอ้างอิงไฟล์, บันทึกข้อผิดพลาดที่ได้รับการกรอง, ภาพหน้าจอ หรือเอกสารข้อกำหนด ใช้ @ ตามด้วยเส้นทางไฟล์เพื่อรวมเนื้อหาของไฟล์นั้น

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

ตัวอย่างเช่น, cat error.log | claude -p "Explain this error" จะส่งไฟล์บันทึกมาพร้อมคำขอแบบไม่โต้ตอบ (non-interactive). ใช้คำสั่งนี้เพียงหลังจากตรวจสอบเนื้อหาของไฟล์แล้วเท่านั้น นี่คือประโยชน์ทางปฏิบัติของAI ที่อิงบริบท: การให้ข้อมูลที่เกี่ยวข้องกับงานแก่โมเดล

เมื่อเพิ่มฟีเจอร์ใหม่ ให้ระบุคอมโพเนนต์หรือฟังก์ชันที่คล้ายกันในรีโพสิตอรี แจ้งให้ Claude ทราบว่าควรปฏิบัติตามกฎเกณฑ์ใด เช่น API client, ตรรกะการตรวจสอบความถูกต้อง, การจัดการข้อผิดพลาด หรือโครงสร้างการทดสอบ

“ติดตามวิธีที่ @src/widgets/Weather.tsx ดึงข้อมูลและเก็บไว้ในแคช” ให้ Claude มีข้อมูลอ้างอิงที่ชัดเจน นอกจากนี้ ให้ระบุความแตกต่างที่ฟีเจอร์ใหม่ต้องการ เพื่อไม่ให้คัดลอกพฤติกรรมที่ไม่เหมาะสมอีกต่อไป ข้อกำหนดเหล่านี้ควรสะท้อนถึงกระบวนการพัฒนาซอฟต์แวร์ของทีมคุณ

สำหรับการเปลี่ยนแปลงโค้ด ให้ระบุคำสั่ง test, build หรือ lint ที่เกี่ยวข้อง และพฤติกรรมที่คำสั่งนั้นควรตรวจสอบ สำหรับการวิจัย ให้ขอข้อมูลอ้างอิงไฟล์หรือ ID commit สำหรับงาน UI ให้จัดเตรียมภาพอ้างอิงและวิธีการที่ตั้งค่าไว้เพื่อบันทึกการนำไปใช้ในวิวพอร์ตเดียวกัน

ขอให้ Claude รายงานสิ่งที่มันตรวจสอบจริง ๆ รวมถึงการตรวจสอบที่ล้มเหลวและถูกข้ามไป ตรวจสอบว่าหลักฐานดังกล่าวครอบคลุมข้อกำหนดหรือไม่; การสร้างโค้ดที่ผ่านไม่ได้เป็นการยืนยันว่าทุกพฤติกรรมที่ร้องขอทำงานได้

สำหรับงานที่ใช้เวลานาน Claude Code ยังเสนอเงื่อนไข /goalและ Stop hooks ด้วย ตัวประเมินเป้าหมายจะวิเคราะห์หลักฐานที่ปรากฏในบทสนทนา แทนที่จะตรวจสอบไฟล์หรือรันการทดสอบอย่างอิสระ Stop hook ที่ตั้งค่าไว้สามารถบล็อกการเสร็จสิ้นได้ แต่มีข้อจำกัดในการบล็อกซ้ำๆ ทั้งสองอย่างนี้ไม่สามารถแทนที่การทดสอบที่เหมาะสมและการตรวจสอบโดยมนุษย์ได้

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

คู่มือแนวทางปฏิบัติที่ดีที่สุดของ Anthropic แนะนำให้เริ่มต้นใหม่หลังจากแก้ไขปัญหาเดียวกันไม่สำเร็จสองครั้ง ใช้คำสั่ง /clear แล้วให้คำสั่งใหม่ที่ปรับปรุงโดยนำสิ่งที่คุณได้เรียนรู้มาปรับใช้ การล้างการสนทนาจะไม่ยกเลิกการเปลี่ยนแปลงไฟล์

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

บันทึกแนวทางสำหรับทั้งโครงการในไฟล์ CLAUDE.md ขั้นตอนที่สามารถทำซ้ำได้ในส่วน skills และคำสั่งสำหรับไฟล์เฉพาะในกฎที่กำหนดขอบเขตตามเส้นทาง (path-scoped rules) ใช้ hooks สำหรับการดำเนินการที่เชื่อมโยงกับเหตุการณ์เฉพาะ เช่น การเรียกใช้ตัวจัดรูปแบบ (formatter) หลังจากแก้ไข

เลือกตามช่วงเวลาที่คำสั่งควรถูกนำไปใช้:

ข้อกำหนดสำหรับฟีเจอร์หนึ่งมักควรอยู่ในคำสั่งงานหรือเอกสารข้อกำหนดของฟีเจอร์นั้นเอง มากกว่าที่จะอยู่ในไฟล์ CLAUDE.md การเพิ่มคำสั่งชั่วคราวลงในไฟล์ที่ใช้สำหรับทั้งโครงการจะทำให้ยากต่อการแยกแยะจากกฎเกณฑ์ที่ควรใช้ทั่วทั้งรีโพสิตอรี

ตัวอย่างเช่น เก็บคำสั่งทดสอบของโครงการไว้ในไฟล์ CLAUDE.md กำหนดกฎเกณฑ์เฉพาะส่วนประกอบในกฎที่มีขอบเขตตามเส้นทาง (path-scoped rule) และบันทึกขั้นตอนการตรวจสอบที่ซ้ำๆ เป็นทักษะ (skill) ตรวจสอบไฟล์เหล่านี้เมื่อคำสั่งหรือกฎเกณฑ์มีการเปลี่ยนแปลง เช่นเดียวกับที่คุณทำกับเอกสารโครงการอื่นๆ

คำสั่ง Prompts, CLAUDE.md และคู่มือทักษะ (skills guide) เป็นตัวกำหนดพฤติกรรมของ Claude; แต่ไม่รับประกันว่าคำสั่งดังกล่าวจะถูกปฏิบัติตาม ฮุค (hooks) สามารถดำเนินการตรวจสอบเมื่อเกิดเหตุการณ์ที่กำหนดไว้ แต่ความน่าเชื่อถือของมันขึ้นอยู่กับประเภทของฮุคและวิธีการนำไปใช้

Command hook ใช้เพื่อเรียกใช้สคริปต์ ส่วน prompt หรือ agent hook ขึ้นอยู่กับความตัดสินใจของโมเดลตามที่คู่มือแนวทางปฏิบัติที่ดีที่สุดของ Anthropic อธิบายไว้ว่า: “prompt หรือ agent hook ขอให้โมเดลอื่นตัดสินใจ ดังนั้นมันจึงไม่ใช่แบบกำหนดแน่นอนเช่นกัน” สำหรับกฎที่ต้องบังคับใช้ ให้ใช้การควบคุมสิทธิ์ที่เหมาะสม และทดสอบ command hook หรือ HTTP hook ที่เกี่ยวข้อง รวมถึงวิธีที่มันจัดการกับความล้มเหลว

subagent ที่กำหนดเองเป็นอีกวิธีหนึ่งในการจัดระเบียบงานที่เกิดขึ้นซ้ำๆ ให้กำหนดผู้เชี่ยวชาญใน claude/agents/ เมื่อต้องการบทบาทการตรวจสอบหรือขอบเขตเครื่องมือที่เฉพาะเจาะจง แทนที่จะเพิ่มคำสั่งผู้เชี่ยวชาญทุกข้อลงในเซสชันหลัก คู่มือเหล่านี้เกี่ยวกับโมเดล Claude ที่เหมาะสมที่สุดสำหรับงานและ ประเภทของเอเยนต์ AIจะให้บริบทเพิ่มเติม

หากทีมของคุณกำลังดูแลพรอมต์ในหลายผลิตภัณฑ์ AI โปรดดูเครื่องมือวิศวกรรมพรอมต์เหล่านี้เพื่อจัดการไลบรารีนอกเหนือจาก Claude Code

เมื่อเซสชันให้ผลลัพธ์ที่ไม่สมบูรณ์หรือไม่เหมาะสม ให้ตรวจสอบว่าคำขอได้ทิ้งการตัดสินใจสำคัญไว้โดยไม่ได้รับการแก้ไขหรือไม่ ความผิดพลาดทั้งห้าข้อนี้อาจทำให้การวินิจฉัยและตรวจสอบงานกลายเป็นเรื่องที่ยากขึ้น

คำสั่ง “Investigate the repository” ให้ Claude ทิศทางน้อยมากเกี่ยวกับไฟล์ใดที่สำคัญหรือเมื่อใดควรหยุด คุณอาจได้รับสรุปทั่วไปโดยไม่มีคำตอบสำหรับปัญหาที่เป็นสาเหตุของคำขอ

ระบุพฤติกรรมหรือการตัดสินใจที่คุณต้องการเข้าใจ กำหนดจุดเริ่มต้น และกำหนดผลลัพธ์ที่คาดหวัง ตัวอย่างเช่น: “ติดตามวิธีที่จุดปลายนี้ตรวจสอบสิทธิ์ และระบุฟังก์ชันที่เกี่ยวข้อง” หากคุณใช้ subagents ให้กำหนดคำถามที่มีขอบเขตชัดเจนสำหรับแต่ละ subagent แทนที่จะมอบหมายการค้นหาแบบไม่จำกัดเดียวกัน

การเปลี่ยนไปมาระหว่างฟีเจอร์ ข้อบกพร่องที่ไม่เกี่ยวข้อง และคำขอเอกสาร ทำให้การสนทนายังคงมีบริบทที่อาจไม่เกี่ยวข้องกับงานปัจจุบัน การอ้างอิงเช่น “ไฟล์นั้น” หรือ “วิธีการก่อนหน้านี้” จึงกลายเป็นไม่ชัดเจน

ใช้เซสชันแยกกันสำหรับงานที่ไม่เกี่ยวข้องกัน หากมีหลายเซสชันที่จะแก้ไขรีโพสิตอรี ให้ใช้ Git worktrees แยกกัน เพื่อไม่ให้มีการแก้ไขไดเรกทอรีทำงานเดียวกัน สำหรับคำถามสั้นๆ ที่ไม่เกี่ยวข้อง คำสั่ง /btw ของ Claude Code จะช่วยไม่ให้การแลกเปลี่ยนข้อความนั้นปรากฏในประวัติการสนทนาหลัก

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

กำหนดเกณฑ์การยอมรับให้สอดคล้องกับการตรวจสอบเฉพาะ สำหรับการแก้ไขข้อผิดพลาด ให้ขอหลักฐานว่าการทดสอบการจำลองข้อผิดพลาดล้มเหลวก่อนการเปลี่ยนแปลงและผ่านหลังการเปลี่ยนแปลง ให้เกณฑ์ที่ยังไม่ได้รับการทดสอบยังคงปรากฏอยู่ แทนที่จะถือว่าการสั่งการหนึ่งครั้งผ่านแล้วเป็นการยืนยันการเปลี่ยนแปลงทั้งหมด

ไฟล์ CLAUDE.md ที่กำลังขยายตัวอาจมีคำสั่งที่ล้าสมัย กฎที่ซ้ำกัน และคำแนะนำที่ขัดแย้งกับข้อกำหนดเฉพาะของงาน การเพิ่มคำที่ชัดเจนขึ้นจะไม่ช่วยแก้ไขความขัดแย้งเหล่านั้น

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

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

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

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

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

กด Shift+Tab จนกว่าโหมด Plan จะปรากฏขึ้น หรือเปิด Claude Code ด้วยคำสั่ง claude --permission-mode plan ในโหมดนี้ Claude สามารถตรวจสอบไฟล์และรันคำสั่งแบบอ่านอย่างเดียวได้โดยไม่แก้ไขโค้ดต้นฉบับของคุณ ตรวจสอบไฟล์ที่เสนอมา ความพึ่งพา และการทดสอบก่อนที่จะอนุมัติการดำเนินการ กด Ctrl+G เพื่อเปิดแผนที่เสนอมาในตัวแก้ไขของคุณ

ให้ Claude ข้อมูลที่จำเป็นเพื่อเข้าใจงาน: การอ้างอิงไฟล์, บันทึกข้อผิดพลาดที่ได้รับการกรอง, ภาพหน้าจอ หรือเอกสารข้อกำหนด ใช้ @ ตามด้วยเส้นทางไฟล์เพื่อรวมเนื้อหาของไฟล์นั้น

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

ตัวอย่างเช่น, cat error.log | claude -p "Explain this error" จะส่งไฟล์บันทึกพร้อมคำขอแบบไม่โต้ตอบ ใช้คำสั่งนี้เฉพาะหลังจากตรวจสอบเนื้อหาของไฟล์แล้วเท่านั้น นี่คือประโยชน์ทางปฏิบัติของAI ที่อิงบริบท: การให้ข้อมูลที่เกี่ยวข้องกับงานแก่โมเดล

เมื่อเพิ่มฟีเจอร์ใหม่ ให้ระบุส่วนประกอบหรือฟังก์ชันที่คล้ายกันในรีโพสิตอรี แจ้งให้ Claude ทราบว่าควรปฏิบัติตามกฎเกณฑ์ใด เช่น API client, ตรรกะการตรวจสอบความถูกต้อง, การจัดการข้อผิดพลาด หรือโครงสร้างการทดสอบ

“ติดตามวิธีที่ @src/widgets/Weather.tsx ดึงข้อมูลและเก็บไว้ในแคช” ให้ Claude มีข้อมูลอ้างอิงที่ชัดเจน นอกจากนี้ ให้ระบุความแตกต่างที่ฟีเจอร์ใหม่ต้องการ เพื่อไม่ให้คัดลอกพฤติกรรมที่ไม่เหมาะสมอีกต่อไป กฎเกณฑ์เหล่านี้ควรสะท้อนถึงกระบวนการพัฒนาซอฟต์แวร์ของทีมคุณ

สำหรับการเปลี่ยนแปลงโค้ด ให้ระบุคำสั่ง test, build หรือ lint ที่เกี่ยวข้อง และพฤติกรรมที่คำสั่งนั้นควรตรวจสอบ สำหรับการวิจัย ให้ขอข้อมูลอ้างอิงไฟล์หรือ ID commit สำหรับงาน UI ให้จัดเตรียมภาพอ้างอิงและวิธีการที่ตั้งค่าไว้เพื่อบันทึกการนำไปใช้ในวิวพอร์ตเดียวกัน

ขอให้ Claude รายงานสิ่งที่มันตรวจสอบจริง ๆ รวมถึงข้อผิดพลาดและการตรวจสอบที่ถูกข้ามไป ตรวจสอบว่าหลักฐานดังกล่าวครอบคลุมข้อกำหนดหรือไม่; การสร้างที่ผ่านไม่ได้เป็นการยืนยันว่าทุกพฤติกรรมที่ร้องขอทำงานได้

สำหรับงานที่ใช้เวลานาน Claude Code ยังเสนอเงื่อนไข /goalและ Stop hooks ด้วย ตัวประเมินเป้าหมายจะประเมินหลักฐานที่ปรากฏในบทสนทนา แทนที่จะตรวจสอบไฟล์หรือรันการทดสอบอย่างอิสระ Stop hook ที่กำหนดค่าไว้สามารถบล็อกการเสร็จสิ้นได้ แต่มีข้อจำกัดในการบล็อกซ้ำๆ ทั้งสองอย่างนี้ไม่สามารถแทนที่การทดสอบที่เหมาะสมและการตรวจสอบโดยมนุษย์ได้

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

คู่มือแนวทางปฏิบัติที่ดีที่สุดของ Anthropic แนะนำให้เริ่มต้นใหม่หลังจากแก้ไขปัญหาเดียวกันไม่สำเร็จสองครั้ง ใช้คำสั่ง /clear แล้วให้คำสั่งใหม่ที่รวมสิ่งที่คุณได้เรียนรู้ไว้ การล้างการสนทนาจะไม่ยกเลิกการเปลี่ยนแปลงไฟล์

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

บันทึกแนวทางสำหรับทั้งโครงการในไฟล์ CLAUDE.md ขั้นตอนที่สามารถทำซ้ำได้ในส่วน skills และคำสั่งสำหรับไฟล์เฉพาะในกฎที่กำหนดขอบเขตตามเส้นทาง ใช้ hooks สำหรับการดำเนินการที่เชื่อมโยงกับเหตุการณ์เฉพาะ เช่น การเรียกใช้ตัวจัดรูปแบบหลังจากแก้ไข

เลือกตามช่วงเวลาที่คำสั่งควรถูกนำไปใช้:

ข้อกำหนดสำหรับฟีเจอร์หนึ่งมักควรอยู่ในคำสั่งงานหรือเอกสารข้อกำหนดของฟีเจอร์นั้นเอง ไม่ใช่ในไฟล์ CLAUDE.md การเพิ่มคำสั่งชั่วคราวลงในไฟล์ที่ใช้สำหรับทั้งโครงการจะทำให้ยากต่อการแยกแยะจากกฎเกณฑ์ที่ควรใช้ทั่วทั้งรีโพสิตอรี

ตัวอย่างเช่น เก็บคำสั่งทดสอบของโครงการไว้ในไฟล์ CLAUDE.md กำหนดกฎเกณฑ์เฉพาะส่วนประกอบในกฎที่มีขอบเขตตามเส้นทาง (path-scoped rule) และบันทึกขั้นตอนการตรวจสอบที่เกิดขึ้นซ้ำๆ เป็นทักษะ (skill) ตรวจสอบไฟล์เหล่านี้เมื่อคำสั่งหรือกฎเกณฑ์มีการเปลี่ยนแปลง เช่นเดียวกับที่คุณทำกับเอกสารโครงการอื่นๆ

คำสั่ง Prompts, CLAUDE.md และคู่มือทักษะ (skills guide) เป็นตัวกำหนดพฤติกรรมของ Claude; แต่ไม่รับประกันว่าคำสั่งใด ๆ จะถูกปฏิบัติตาม ฮุก (hooks) สามารถดำเนินการตรวจสอบเมื่อเกิดเหตุการณ์ที่กำหนดไว้ แต่ความน่าเชื่อถือของมันขึ้นอยู่กับประเภทของฮุกและวิธีการนำไปใช้

Command hook ใช้เพื่อเรียกใช้สคริปต์ ส่วน prompt หรือ agent hook ขึ้นอยู่กับความตัดสินใจของโมเดลตามที่คู่มือแนวทางปฏิบัติที่ดีที่สุดของAnthropic อธิบายว่า: “prompt หรือ agent hook ขอให้โมเดลอื่นตัดสินใจ ดังนั้นมันจึงไม่ใช่แบบกำหนดแน่นอนเช่นกัน” สำหรับกฎที่ต้องบังคับใช้ ให้ใช้การควบคุมสิทธิ์ที่เหมาะสม และทดสอบ command hook หรือ HTTP hook ที่เกี่ยวข้อง รวมถึงวิธีที่มันจัดการกับความล้มเหลว

subagent ที่กำหนดเองเป็นอีกวิธีหนึ่งในการจัดระเบียบงานที่เกิดขึ้นซ้ำๆ ให้กำหนดผู้เชี่ยวชาญใน claude/agents/ เมื่อต้องการบทบาทการตรวจสอบหรือขอบเขตเครื่องมือที่เฉพาะเจาะจง แทนที่จะเพิ่มคำสั่งผู้เชี่ยวชาญทุกข้อลงในเซสชันหลัก คู่มือเหล่านี้เกี่ยวกับโมเดล Claude ที่เหมาะสมที่สุดสำหรับงานและ ประเภทของเอเยนต์ AIจะให้บริบทเพิ่มเติม

หากทีมของคุณกำลังดูแลพรอมต์ในหลายผลิตภัณฑ์ AI โปรดดูเครื่องมือวิศวกรรมพรอมต์เหล่านี้เพื่อจัดการไลบรารีนอกเหนือจาก Claude Code

เมื่อเซสชันให้ผลลัพธ์ที่ไม่สมบูรณ์หรือไม่เหมาะสม ให้ตรวจสอบว่าคำขอได้ทิ้งการตัดสินใจสำคัญไว้โดยไม่ได้รับการแก้ไขหรือไม่ ความผิดพลาดทั้งห้าข้อนี้อาจทำให้การวินิจฉัยและตรวจสอบงานกลายเป็นเรื่องที่ยากขึ้น

คำสั่ง “Investigate the repository” ให้ Claude ทิศทางน้อยมากเกี่ยวกับไฟล์ใดที่สำคัญหรือเมื่อใดควรหยุด คุณอาจได้รับสรุปทั่วไปโดยไม่มีคำตอบสำหรับปัญหาที่เป็นสาเหตุของการส่งคำขอ

ระบุพฤติกรรมหรือการตัดสินใจที่คุณต้องการเข้าใจ ระบุจุดเริ่มต้น และกำหนดผลลัพธ์ที่คาดหวัง ตัวอย่างเช่น: “ติดตามวิธีที่จุดปลายนี้ตรวจสอบสิทธิ์การเข้าถึง และระบุฟังก์ชันที่เกี่ยวข้อง” หากคุณใช้ subagents ให้ตั้งคำถามที่มีขอบเขตชัดเจนสำหรับแต่ละ subagent แทนที่จะมอบหมายการค้นหาแบบไม่จำกัดเดียวกัน

การเปลี่ยนไปมาระหว่างฟีเจอร์ ข้อบกพร่องที่ไม่เกี่ยวข้อง และคำขอเอกสาร ทำให้การสนทนายังคงมีบริบทที่อาจไม่เกี่ยวข้องกับงานปัจจุบัน การอ้างอิงเช่น “ไฟล์นั้น” หรือ “วิธีการก่อนหน้านี้” จึงกลายเป็นไม่ชัดเจน

ใช้เซสชันแยกกันสำหรับงานที่ไม่เกี่ยวข้องกัน หากมีหลายเซสชันที่จะแก้ไขรีโพสิตอรี ให้ใช้ Git worktrees แยกกัน เพื่อไม่ให้มีการแก้ไขไดเรกทอรีทำงานเดียวกัน สำหรับคำถามสั้นๆ ที่ไม่เกี่ยวข้อง คำสั่ง /btw ของ Claude Code จะช่วยไม่ให้การแลกเปลี่ยนข้อความนั้นปรากฏในประวัติการสนทนาหลัก

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

กำหนดเกณฑ์การยอมรับให้สอดคล้องกับการตรวจสอบเฉพาะ สำหรับการแก้ไขข้อผิดพลาด ให้ขอหลักฐานว่า การทดสอบเพื่อจำลองข้อผิดพลาดไม่ผ่านก่อนการเปลี่ยนแปลง และผ่านหลังการเปลี่ยนแปลง ให้เกณฑ์ที่ยังไม่ได้รับการทดสอบยังคงปรากฏอยู่ แทนที่จะถือว่าการสั่งคำสั่งที่สำเร็จเพียงครั้งเดียวเป็นการยืนยันการเปลี่ยนแปลงทั้งหมด

ไฟล์ CLAUDE.md ที่ขยายตัวอาจมีคำสั่งที่ล้าสมัย กฎที่ซ้ำกัน และคำแนะนำที่ขัดแย้งกับข้อกำหนดเฉพาะของงาน การเพิ่มคำที่ชัดเจนขึ้นจะไม่ช่วยแก้ไขความขัดแย้งเหล่านั้น

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

การตรวจสอบสามารถระบุข้อบกพร่องที่แท้จริง ปัญหาที่ยังไม่ชัดเจน และข้อเสนอแนะการปรับโครงสร้างโค้ด (refactoring) ที่ไม่จำเป็นได้พร้อมกัน การนำข้อเสนอแนะทุกข้อไปใช้ อาจทำให้การเปลี่ยนแปลงขยายตัวโดยไม่ปรับปรุงพฤติกรรมที่ร้องขอ

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

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

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

กด Shift+Tab จนกว่าโหมด Plan จะปรากฏขึ้น หรือเปิด Claude Code ด้วยคำสั่ง claude --permission-mode plan ในโหมดนี้ Claude สามารถตรวจสอบไฟล์และรันคำสั่งแบบอ่านอย่างเดียวได้โดยไม่แก้ไขโค้ดต้นฉบับของคุณ ตรวจสอบไฟล์ที่เสนอมา ความพึ่งพา และการทดสอบก่อนที่จะอนุมัติการดำเนินการ กด Ctrl+G เพื่อเปิดแผนที่เสนอมาในตัวแก้ไขของคุณ

ให้ Claude ข้อมูลที่จำเป็นเพื่อเข้าใจงาน: การอ้างอิงไฟล์, บันทึกข้อผิดพลาดที่ได้รับการกรองแล้ว, ภาพหน้าจอ หรือเอกสารข้อกำหนด ใช้ @ ตามด้วยเส้นทางไฟล์เพื่อรวมเนื้อหาของไฟล์นั้น

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

ตัวอย่างเช่น, cat error.log | claude -p "Explain this error" จะส่งไฟล์บันทึกด้วยคำขอแบบไม่โต้ตอบ (non-interactive). ใช้คำสั่งนี้เพียงหลังจากตรวจสอบเนื้อหาของไฟล์แล้วเท่านั้น นี่คือประโยชน์ทางปฏิบัติของAI ที่อิงบริบท: การให้ข้อมูลที่เกี่ยวข้องกับงานแก่โมเดล

เมื่อเพิ่มฟีเจอร์ใหม่ ให้ระบุส่วนประกอบหรือฟังก์ชันที่คล้ายกันในรีโพสิตอรี แจ้งให้ Claude ทราบว่าควรปฏิบัติตามกฎเกณฑ์ใด เช่น API client, ตรรกะการตรวจสอบความถูกต้อง, การจัดการข้อผิดพลาด หรือโครงสร้างการทดสอบ

“ติดตามวิธีที่ @src/widgets/Weather.tsx ดึงข้อมูลและเก็บไว้ในแคช” ให้ Claude มีข้อมูลอ้างอิงที่ชัดเจน นอกจากนี้ ให้ระบุความแตกต่างที่ฟีเจอร์ใหม่ต้องการ เพื่อไม่ให้คัดลอกพฤติกรรมที่ไม่เหมาะสมอีกต่อไป ข้อกำหนดเหล่านี้ควรสะท้อนถึงกระบวนการพัฒนาซอฟต์แวร์ของทีมคุณ

สำหรับการเปลี่ยนแปลงโค้ด ให้ระบุคำสั่ง test, build หรือ lint ที่เกี่ยวข้อง และพฤติกรรมที่คำสั่งนั้นควรตรวจสอบ สำหรับการวิจัย ให้ขอข้อมูลอ้างอิงไฟล์หรือ ID commit สำหรับงาน UI ให้จัดเตรียมภาพอ้างอิงและวิธีการที่ตั้งค่าไว้เพื่อบันทึกการนำไปใช้ในวิวพอร์ตเดียวกัน

ขอให้ Claude รายงานสิ่งที่มันตรวจสอบจริง ๆ รวมถึงข้อผิดพลาดและการตรวจสอบที่ถูกข้ามไป ตรวจสอบว่าหลักฐานดังกล่าวครอบคลุมข้อกำหนดหรือไม่; การสร้างโค้ดที่ผ่านไม่ได้เป็นการยืนยันว่าทุกพฤติกรรมที่ร้องขอทำงานได้

สำหรับงานที่ใช้เวลานาน Claude Code ยังเสนอเงื่อนไข /goalและ Stop hooks ด้วย ตัวประเมินเป้าหมายจะประเมินหลักฐานที่ปรากฏในบทสนทนา แทนที่จะตรวจสอบไฟล์หรือรันการทดสอบอย่างอิสระ Stop hook ที่กำหนดค่าไว้สามารถบล็อกการเสร็จสิ้นได้ แต่มีข้อจำกัดในการบล็อกซ้ำๆ ทั้งสองอย่างนี้ไม่สามารถแทนที่การทดสอบที่เหมาะสมและการตรวจสอบโดยมนุษย์ได้

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

คู่มือแนวทางปฏิบัติที่ดีที่สุดของ Anthropic แนะนำให้เริ่มต้นใหม่หลังจากแก้ไขปัญหาเดียวกันไม่สำเร็จสองครั้ง ใช้คำสั่ง /clear แล้วให้คำสั่งใหม่ที่รวมสิ่งที่คุณได้เรียนรู้ไว้ การล้างการสนทนาจะไม่ยกเลิกการเปลี่ยนแปลงไฟล์

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

บันทึกแนวทางสำหรับทั้งโครงการในไฟล์ CLAUDE.md ขั้นตอนที่สามารถทำซ้ำได้ในส่วน skills และคำสั่งสำหรับไฟล์เฉพาะในกฎที่กำหนดขอบเขตตามเส้นทาง (path-scoped rules) ใช้ hooks สำหรับการดำเนินการที่เชื่อมโยงกับเหตุการณ์เฉพาะ เช่น การเรียกใช้ตัวจัดรูปแบบ (formatter) หลังจากแก้ไข

เลือกตามช่วงเวลาที่คำสั่งควรถูกนำไปใช้:

ข้อกำหนดสำหรับฟีเจอร์หนึ่งมักควรอยู่ในคำสั่งงานหรือเอกสารข้อกำหนดของฟีเจอร์นั้นเอง ไม่ใช่ในไฟล์ CLAUDE.md การเพิ่มคำสั่งชั่วคราวลงในไฟล์ที่ใช้สำหรับทั้งโครงการจะทำให้ยากต่อการแยกแยะจากกฎเกณฑ์ที่ควรใช้ทั่วทั้งรีโพสิตอรี

ตัวอย่างเช่น เก็บคำสั่งทดสอบของโครงการไว้ในไฟล์ CLAUDE.md กำหนดกฎเกณฑ์เฉพาะส่วนประกอบในกฎที่มีขอบเขตตามเส้นทาง (path-scoped rule) และบันทึกขั้นตอนการตรวจสอบที่ซ้ำๆ เป็นทักษะ (skill) ตรวจสอบไฟล์เหล่านี้เมื่อคำสั่งหรือกฎเกณฑ์มีการเปลี่ยนแปลง เช่นเดียวกับที่คุณทำกับเอกสารโครงการอื่นๆ

คำสั่ง Prompts, CLAUDE.md และคู่มือทักษะ (skills guide) เป็นตัวกำหนดพฤติกรรมของ Claude; แต่ไม่รับประกันว่าคำสั่งใด ๆ จะถูกปฏิบัติตาม ฮุก (hooks) สามารถดำเนินการตรวจสอบเมื่อเกิดเหตุการณ์ที่กำหนดไว้ แต่ความน่าเชื่อถือของมันขึ้นอยู่กับประเภทของฮุกและวิธีการนำไปใช้

Command hook ใช้เพื่อเรียกใช้สคริปต์ ส่วน prompt หรือ agent hook ขึ้นอยู่กับความตัดสินใจของโมเดลตามที่คู่มือแนวทางปฏิบัติที่ดีที่สุดของ Anthropic อธิบายไว้ว่า: “prompt หรือ agent hook ขอให้โมเดลอื่นตัดสินใจ ดังนั้นมันจึงไม่ใช่แบบกำหนดแน่นอนเช่นกัน” สำหรับกฎที่ต้องบังคับใช้ ให้ใช้การควบคุมสิทธิ์ที่เหมาะสม และทดสอบ command hook หรือ HTTP hook ที่เกี่ยวข้อง รวมถึงวิธีที่มันจัดการกับความล้มเหลว

subagent ที่กำหนดเองเป็นอีกวิธีหนึ่งในการจัดระเบียบงานที่เกิดขึ้นซ้ำๆ ให้กำหนดผู้เชี่ยวชาญใน claude/agents/ เมื่อต้องการบทบาทการตรวจสอบหรือขอบเขตเครื่องมือที่เฉพาะเจาะจง แทนที่จะเพิ่มคำสั่งผู้เชี่ยวชาญทุกข้อลงในเซสชันหลัก คู่มือเหล่านี้เกี่ยวกับโมเดล Claude ที่เหมาะสมที่สุดสำหรับงานและ ประเภทของเอเยนต์ AIจะให้บริบทเพิ่มเติม

หากทีมของคุณกำลังดูแลพรอมต์ในหลายผลิตภัณฑ์ AI โปรดดูเครื่องมือวิศวกรรมพรอมต์เหล่านี้เพื่อจัดการไลบรารีนอกเหนือจาก Claude Code

เมื่อเซสชันให้ผลลัพธ์ที่ไม่สมบูรณ์หรือไม่เหมาะสม ให้ตรวจสอบว่าคำขอได้ทิ้งการตัดสินใจสำคัญไว้โดยไม่ได้รับการแก้ไขหรือไม่ ความผิดพลาดทั้งห้าข้อนี้อาจทำให้การวินิจฉัยและตรวจสอบงานกลายเป็นเรื่องที่ยากขึ้น

คำสั่ง “Investigate the repository” ให้ Claude ทิศทางน้อยมากเกี่ยวกับไฟล์ใดที่สำคัญหรือเมื่อใดควรหยุด คุณอาจได้รับสรุปทั่วไปโดยไม่มีคำตอบสำหรับปัญหาที่เป็นสาเหตุของการส่งคำขอ

ระบุพฤติกรรมหรือการตัดสินใจที่คุณต้องการเข้าใจ กำหนดจุดเริ่มต้น และกำหนดผลลัพธ์ที่คาดหวัง ตัวอย่างเช่น: “ติดตามวิธีที่จุดปลายนี้ตรวจสอบสิทธิ์การเข้าถึง และระบุฟังก์ชันที่เกี่ยวข้อง” หากคุณใช้ subagents ให้กำหนดคำถามที่มีขอบเขตชัดเจนสำหรับแต่ละ subagent แทนที่จะมอบหมายการค้นหาแบบไม่มีข้อจำกัดเดียวกัน

การเปลี่ยนไปมาระหว่างฟีเจอร์ ข้อบกพร่องที่ไม่เกี่ยวข้อง และคำขอเอกสาร ทำให้การสนทนายังคงมีบริบทที่อาจไม่เกี่ยวข้องกับงานปัจจุบัน การอ้างอิงเช่น “ไฟล์นั้น” หรือ “วิธีการก่อนหน้านี้” จึงกลายเป็นไม่ชัดเจน

ใช้เซสชันแยกกันสำหรับงานที่ไม่เกี่ยวข้องกัน หากมีหลายเซสชันที่จะแก้ไขรีโพสิตอรี ให้ใช้ Git worktrees แยกกัน เพื่อไม่ให้มีการแก้ไขไดเรกทอรีทำงานเดียวกัน สำหรับคำถามสั้นๆ ที่ไม่เกี่ยวข้อง คำสั่ง /btw ของ Claude Code จะช่วยไม่ให้การแลกเปลี่ยนข้อความนั้นปรากฏในประวัติการสนทนาหลัก

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

กำหนดเกณฑ์การยอมรับให้สอดคล้องกับการตรวจสอบเฉพาะ สำหรับการแก้ไขข้อผิดพลาด ให้ขอหลักฐานว่า การทดสอบเพื่อจำลองข้อผิดพลาดล้มเหลวก่อนการเปลี่ยนแปลง และผ่านหลังการเปลี่ยนแปลง ให้เกณฑ์ที่ยังไม่ได้รับการทดสอบยังคงปรากฏอยู่ แทนที่จะถือว่าการสั่งคำสั่งที่สำเร็จเพียงครั้งเดียวเป็นการยืนยันการเปลี่ยนแปลงทั้งหมด

ไฟล์ CLAUDE.md ที่กำลังขยายตัวอาจมีคำสั่งที่ล้าสมัย กฎที่ซ้ำกัน และคำแนะนำที่ขัดแย้งกับข้อกำหนดเฉพาะของงาน การเพิ่มคำที่ชัดเจนขึ้นจะไม่ช่วยแก้ไขความขัดแย้งเหล่านั้น

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

การตรวจสอบสามารถระบุข้อบกพร่องที่แท้จริง ปัญหาที่ยังไม่ชัดเจน และข้อเสนอแนะการปรับโครงสร้างโค้ด (refactoring) ที่ไม่จำเป็นได้พร้อมกัน การนำข้อเสนอแนะทุกข้อไปใช้ อาจทำให้การเปลี่ยนแปลงขยายตัวโดยไม่ปรับปรุงพฤติกรรมที่ร้องขอ

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