メニュー
สร้างแผน refactor แบบละเอียดที่ซอยเป็น commit เล็ก ๆ ผ่านการสัมภาษณ์ user แล้วเปิดเป็น GitHub issue ใช้เมื่อ user อยากวางแผน refactor สร้าง refactoring RFC หรือแตก refactor ออกเป็นขั้นเล็ก ๆ ที่ปลอดภัย
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
วางแผนงานก้อนใหญ่ — ใหญ่เกินกว่าหนึ่ง agent session จะรับไหว — เป็นแผนที่ร่วมของ ticket สำหรับการ investigate บน issue tracker ของคุณ แล้วไล่ resolve ทีละใบจนกว่าเส้นทางไปยังจุดหมายจะชัด
สร้าง interface design หลายแบบที่ต่างกันสุดขั้วสำหรับ module หนึ่ง โดยใช้ sub-agent แบบ parallel ใช้เมื่อ user อยากออกแบบ API, สำรวจตัวเลือกของ interface, เปรียบเทียบรูปทรงของ module หรือพูดถึง "design it twice"
QA session แบบ interactive ที่ผู้ใช้เล่าบั๊กหรือปัญหาแบบคุยกันธรรมดา แล้ว agent เปิด GitHub issue ให้ พร้อมสำรวจ codebase เบื้องหลังเพื่อเก็บ context และภาษา domain ใช้เมื่อผู้ใช้อยากรายงานบั๊ก ทำ QA เปิด issue แบบคุยกัน หรือพูดถึง "QA session"
สกัด glossary ภาษากลางสไตล์ DDD จากบทสนทนาปัจจุบัน พร้อมชี้จุดกำกวมและเสนอ term มาตรฐาน เซฟลง UBIQUITOUS_LANGUAGE.md ใช้เมื่อผู้ใช้อยากนิยามศัพท์ domain สร้าง glossary ทำ terminology ให้แน่น สร้าง ubiquitous language หรือพูดถึง "domain model" หรือ "DDD"
ถามว่า skill หรือ flow ไหนเหมาะกับสถานการณ์ของคุณ เป็น router ที่ครอบ skill ทั้งหมดใน repo นี้
รีวิวการเปลี่ยนแปลงตั้งแต่จุดอ้างอิงคงที่ (commit, branch, tag หรือ merge-base) ตามสองแกน — Standards (code ทำตาม coding standards ที่ repo นี้บันทึกไว้ไหม?) และ Spec (code ตรงกับสิ่งที่ issue/PRD ต้นทางขอไหม?) รันรีวิวทั้งสองแกนใน sub-agent ที่ทำงานขนานกันแล้วรายงานเทียบเคียงกัน ใช้เมื่อ user อยากรีวิว branch, PR, งานที่ยังทำค้างอยู่ หรือพูดว่า "review since X"
| name | request-refactor-plan |
| description | สร้างแผน refactor แบบละเอียดที่ซอยเป็น commit เล็ก ๆ ผ่านการสัมภาษณ์ user แล้วเปิดเป็น GitHub issue ใช้เมื่อ user อยากวางแผน refactor สร้าง refactoring RFC หรือแตก refactor ออกเป็นขั้นเล็ก ๆ ที่ปลอดภัย |
skill นี้จะถูกเรียกเมื่อ user อยากสร้างคำขอ refactor ให้ทำตามขั้นตอนด้านล่าง จะข้ามขั้นตอนที่เห็นว่าไม่จำเป็นก็ได้
ขอให้ user อธิบายปัญหาที่อยากแก้แบบยาวและละเอียด รวมถึงไอเดียแนวทางแก้ที่อาจเป็นไปได้
สำรวจ repo เพื่อยืนยันสิ่งที่ user เล่ามา และทำความเข้าใจสถานะปัจจุบันของ codebase
ถามว่าเขาเคยพิจารณาทางเลือกอื่นหรือยัง และนำเสนอทางเลือกอื่น ๆ ให้เขาดู
สัมภาษณ์ user เรื่อง implementation ให้ละเอียดและถี่ถ้วนสุด ๆ
เคาะขอบเขตที่แน่นอนของ implementation ตกลงให้ชัดว่าตั้งใจจะเปลี่ยนอะไรและตั้งใจจะไม่เปลี่ยนอะไร
เข้าไปดูใน codebase ว่าบริเวณนี้มี test coverage แค่ไหน ถ้า coverage ไม่พอ ให้ถาม user ว่ามีแผนเรื่องการ test ยังไง
แตก implementation ออกเป็นแผนของ commit เล็กจิ๋ว ๆ จำคำแนะนำของ Martin Fowler ที่ว่า "ทำแต่ละขั้นของการ refactor ให้เล็กที่สุดเท่าที่จะเล็กได้ เพื่อให้เห็นโปรแกรมยังทำงานได้อยู่เสมอ"
สร้าง GitHub issue พร้อมแผน refactor ใช้ template ต่อไปนี้สำหรับ description ของ issue:
ปัญหาที่ developer กำลังเจอ เล่าจากมุมมองของ developer
วิธีแก้ปัญหา จากมุมมองของ developer
แผน implementation แบบยาวและละเอียด เขียนแผนเป็นร้อยแก้วธรรมดา โดยแตก implementation ออกเป็น commit ที่เล็กที่สุดเท่าที่จะทำได้ แต่ละ commit ต้องทิ้ง codebase ไว้ในสถานะที่ยังทำงานได้
รายการการตัดสินใจด้าน implementation ที่เกิดขึ้น ซึ่งอาจรวมถึง:
ห้ามใส่ file path หรือ code snippet แบบเจาะจง เพราะพวกมันอาจล้าสมัยเร็วมาก
รายการการตัดสินใจด้านการ test ที่เกิดขึ้น ให้ใส่:
คำอธิบายสิ่งที่อยู่นอกขอบเขตของการ refactor นี้
โน้ตอื่น ๆ เกี่ยวกับการ refactor นี้
