ให้บริบท repository ที่มีประโยชน์แก่ agent

เริ่มจาก checkout ปัจจุบัน

Agent ต้องรู้ว่ากำลังเปลี่ยน repository และ branch ใด และต้องรู้ว่า working directory มีการเปลี่ยนแปลงที่ไม่เกี่ยวข้องหรือไม่ ข้อเท็จจริงเหล่านี้มีผลต่อสิ่งที่แก้ได้อย่างปลอดภัยและวิธีตีความ diff สุดท้าย

ขอให้ agent ตรวจดูคำสั่งโครงการและ package configuration ก่อนพัฒนา คำสั่งที่จำมาจาก repository อื่นอาจใช้ที่นี่ไม่ได้ ชื่อ framework ที่คุ้นเคยไม่ได้บอกเวอร์ชันที่ติดตั้งหรือธรรมเนียมของโครงการ

สำหรับการเปลี่ยนแปลงเล็ก ให้ module ที่เกี่ยวข้อง ส่วนที่เรียกใช้ test และการตัดสินใจด้านสถาปัตยกรรม เพิ่มข้อมูลเมื่อการสืบค้นแสดงว่าต้องการข้อมูลใดโดยเฉพาะ

ใช้คำสั่ง repository เก็บกฎที่ใช้ต่อเนื่อง

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

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

คำสั่งที่มีประโยชน์คือ “รัน integration test ด้านการตรวจสอบสิทธิ์เมื่อ route เปลี่ยนพฤติกรรมการเข้าถึง” คำสั่งกำกวมคือ “ระวังเรื่องความปลอดภัยเสมอ” แบบแรกระบุเงื่อนไขเริ่มและการดำเนินการที่ผู้ตรวจทานตรวจสอบได้

ตรวจสอบคำสั่งเทียบกับโค้ด

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

บันทึกข้อขัดแย้ง ใช้หลักฐานตรงจากเวอร์ชันปัจจุบันเพื่อเข้าใจพฤติกรรมที่พัฒนาจริง อย่าทิ้ง policy ที่ตั้งใจไว้โดยไม่แจ้งเพียงเพราะโค้ดเก่าละเมิดมัน Policy กับพฤติกรรมปัจจุบันตอบคนละคำถาม

ตัวอย่างเช่น คู่มืออาจห้ามเขียนตรงลง branch ที่ใช้ร่วมกัน แต่สคริปต์เก่ายังทำอยู่ วิธีที่ถูกต้องคือรักษา policy และแก้สคริปต์ โค้ดที่มีอยู่ไม่ได้ให้สิทธิ์ทำสิ่งที่ห้ามซ้ำ

ให้บริบทเกี่ยวข้องกับงานและปลอดภัย

Repository ทั้งชุดอาจมีข้อมูลรับรอง fixture ส่วนตัว ข้อมูลลูกค้าที่ export และ log เก่าจากงานช่วยเหลือ สิทธิ์เข้าถึง repository ไม่ได้ทำให้ทุกไฟล์เหมาะจะส่งให้บริการโมเดลโดยอัตโนมัติ

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

คำสั่ง repository ที่บอกว่า “ห้ามอ่าน secret” เป็นแนวทางที่มีประโยชน์ แต่ใช้แทนการจำกัดสิทธิ์เข้าถึงที่เก็บ secret และ directory ที่มีข้อมูลอ่อนไหวไม่ได้

ทิ้งบันทึกที่มีประโยชน์ให้คนถัดไป

เมื่องานเสร็จ ให้บันทึกพฤติกรรมที่เปลี่ยน การตรวจสอบ และข้อจำกัดที่ยังแก้ไม่ได้ใน pull request อัปเดตเอกสารโครงการที่เก็บไว้ใช้อ้างอิงต่อเนื่องเมื่อ workflow ที่รองรับเปลี่ยน อย่าคัดลอกบทสนทนาของ agent ทั้งหมดเข้า repository

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

บริบทที่ดีลดการสืบค้นซ้ำ และทำให้พบข้อผิดพลาดง่ายขึ้น เพราะพฤติกรรมที่คาดหวังและคำสั่งที่ใช้งานได้ระบุไว้อย่างชัดเจน