메뉴
สร้างและลับ domain model ของ project ให้คม ใช้เมื่อ user อยาก pin down ศัพท์ของ domain หรือ ubiquitous language, บันทึกการตัดสินใจเชิงสถาปัตยกรรม หรือเมื่อ skill อื่นต้องดูแล domain model
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"
สร้างแผน refactor แบบละเอียดที่ซอยเป็น commit เล็ก ๆ ผ่านการสัมภาษณ์ user แล้วเปิดเป็น GitHub issue ใช้เมื่อ user อยากวางแผน refactor สร้าง refactoring RFC หรือแตก refactor ออกเป็นขั้นเล็ก ๆ ที่ปลอดภัย
สกัด glossary ภาษากลางสไตล์ DDD จากบทสนทนาปัจจุบัน พร้อมชี้จุดกำกวมและเสนอ term มาตรฐาน เซฟลง UBIQUITOUS_LANGUAGE.md ใช้เมื่อผู้ใช้อยากนิยามศัพท์ domain สร้าง glossary ทำ terminology ให้แน่น สร้าง ubiquitous language หรือพูดถึง "domain model" หรือ "DDD"
ถามว่า skill หรือ flow ไหนเหมาะกับสถานการณ์ของคุณ เป็น router ที่ครอบ skill ทั้งหมดใน repo นี้
| name | domain-modeling |
| description | สร้างและลับ domain model ของ project ให้คม ใช้เมื่อ user อยาก pin down ศัพท์ของ domain หรือ ubiquitous language, บันทึกการตัดสินใจเชิงสถาปัตยกรรม หรือเมื่อ skill อื่นต้องดูแล domain model |
สร้างและลับ domain model (โมเดลความเข้าใจในโดเมนธุรกิจ) ของ project ให้คมอย่างจริงจังระหว่างที่ออกแบบ นี่คือวินัยแบบ active — ท้าทายคำศัพท์ คิด scenario แบบ edge case ขึ้นมาทดสอบ และเขียน glossary กับการตัดสินใจลงไฟล์ทันทีที่มันตกผลึก (แค่ อ่าน CONTEXT.md เพื่อเอาคำศัพท์มาใช้ไม่นับเป็น skill นี้ — นั่นเป็นนิสัยบรรทัดเดียวที่ skill ไหนก็ทำได้ skill นี้มีไว้ตอนที่คุณกำลังเปลี่ยนตัว model ไม่ใช่แค่ใช้งานมัน)
repo ส่วนใหญ่มี context เดียว:
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
ถ้ามี CONTEXT-MAP.md อยู่ที่ root แปลว่า repo มีหลาย context ตัว map จะชี้ว่าแต่ละ context อยู่ตรงไหน:
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← system-wide decisions
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← context-specific decisions
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr/
สร้างไฟล์แบบ lazy — สร้างต่อเมื่อมีอะไรจะเขียนจริง ๆ ถ้ายังไม่มี CONTEXT.md ให้สร้างตอนที่คำแรกถูกเคาะข้อสรุป ถ้ายังไม่มี docs/adr/ ให้สร้างตอนที่ต้องเขียน ADR อันแรก
เมื่อ user ใช้คำที่ขัดกับภาษาที่มีอยู่แล้วใน CONTEXT.md ให้ท้วงทันที "glossary ของคุณนิยาม 'cancellation' ว่า X แต่ดูเหมือนคุณหมายถึง Y — ตกลงอันไหนกันแน่?"
เมื่อ user ใช้คำที่กำกวมหรือความหมายซ้อนทับกัน ให้เสนอคำ canonical ที่แม่นยำ "คุณพูดว่า 'account' — หมายถึง Customer หรือ User? สองอย่างนี้เป็นคนละเรื่องกัน"
เมื่อกำลังคุยเรื่องความสัมพันธ์ใน domain ให้ stress-test ด้วย scenario เฉพาะเจาะจง คิด scenario ที่จิ้มไปที่ edge case และบังคับให้ user ต้องแม่นยำกับเส้นแบ่งระหว่าง concept
เมื่อ user บอกว่าอะไรทำงานยังไง ให้เช็คว่า code เห็นตรงกันไหม ถ้าเจอความขัดแย้ง ให้ยกขึ้นมา: "code ของคุณ cancel ทั้ง Order แต่คุณเพิ่งบอกว่า cancel บางส่วนได้ — อันไหนถูก?"
เมื่อคำหนึ่งได้ข้อสรุปแล้ว ให้อัปเดต CONTEXT.md ตรงนั้นเลย อย่าสะสมไว้ทำทีเดียว — เก็บมันตอนที่มันเกิดขึ้น ใช้ format ใน CONTEXT-FORMAT.md
CONTEXT.md ต้องปลอดรายละเอียด implementation โดยสิ้นเชิง อย่าใช้ CONTEXT.md เป็น spec, เป็นกระดาษทด หรือเป็นที่เก็บการตัดสินใจด้าน implementation มันคือ glossary และเป็นแค่นั้น
เสนอสร้าง ADR ก็ต่อเมื่อครบทั้งสามข้อนี้เท่านั้น:
ถ้าขาดข้อใดข้อหนึ่งในสามข้อ ให้ข้าม ADR ไป ใช้ format ใน ADR-FORMAT.md