request-refactor-plan

สัมภาษณ์ผู้ใช้อย่างไม่ลดละเกี่ยวกับแผนหรือการออกแบบจนกว่าจะถึงความเข้าใจร่วมกัน โดยแก้ไขแต่ละกิ่งของแผนผังการตัดสินใจ ใช้เมื่อผู้ใช้ต้องการทดสอบแผนอย่างเข้มข้น ถูกซักถามเกี่ยวกับการออกแบบ หรือพูดถึง "grill me

เซสชันการย่างที่ท้าทายแผนของคุณกับโมเดลโดเมนที่มีอยู่ ปรับแต่งคำศัพท์ให้คมชัด และอัปเดตเอกสาร (CONTEXT.md, ADRs) แบบเรียลไทม์เมื่อการตัดสินใจตกผลึก ใช้เมื่อผู้ใช้ต้องการทดสอบแผนกับภาษาและการตัดสินใจที่บันทึกไว้ในโปรเจกต์ของตน

ค้นหาโอกาสในการปรับปรุงโค้ดเบสให้ลึกซึ้งยิ่งขึ้น โดยอิงจากภาษาของโดเมนใน CONTEXT.md และการตัดสินใจใน docs/adr/ ใช้เมื่อผู้ใช้ต้องการปรับปรุงสถาปัตยกรรม ค้นหาโอกาสในการรีแฟกเตอร์ รวมโมดูลที่เชื่อมโยงกันอย่างแน่นหนา หรือทำให้โค้ดเบสสามารถทดสอบได้และนำทางด้วย AI ได้ง่ายขึ้น

สอนผู้ใช้ทักษะหรือแนวคิดใหม่ภายในพื้นที่ทำงานนี้

การพัฒนาที่ขับเคลื่อนด้วยการทดสอบด้วยวงจรแดง-เขียว-ปรับปรุง ใช้เมื่อผู้ใช้ต้องการสร้างฟีเจอร์หรือแก้ไขบั๊กโดยใช้ TDD กล่าวถึง "แดง-เขียว-ปรับปรุง" ต้องการการทดสอบแบบบูรณาการ หรือขอให้พัฒนาด้วยการทดสอบก่อน

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

ย่อบทสนทนาปัจจุบันให้เป็นเอกสารส่งต่อสำหรับเอเจนต์อื่นเพื่อดำเนินการต่อ

วงจรการวินิจฉัยที่มีระเบียบสำหรับบั๊กที่ยากและการถดถอยของประสิทธิภาพ ทำซ้ำ → ลดขนาด → ตั้งสมมติฐาน → ตรวจวัด → แก้ไข → ทดสอบการถดถอย ใช้เมื่อผู้ใช้พูดว่า "diagnose this" / "debug this" รายงานบั๊ก พูดว่ามีบางอย่างเสีย/เกิดข้อผิดพลาด/ล้มเหลว หรืออธิบายการถดถอยของประสิทธิภาพ