เลิกสั่งซ้ำ: codify workflow ที่ทำบ่อย ให้เป็น command เดียวของ AI agent

เลิกสั่งซ้ำ: codify workflow ที่ทำบ่อย ให้เป็น command เดียวของ AI agent

TL;DR — ถ้าคุณสั่ง AI agent ทำ “งานหลายขั้นแบบเดิม” ซ้ำๆ (เช่น ลงบทความ, ขึ้น release, scaffold โมดูล) — อย่าพิมพ์ใหม่ทุกครั้ง. codify มันเป็น reusable command/skill ครั้งเดียว: ขั้นตอน + guardrails + self-contained. เรียกคำสั่งเดียวจบ, ทำเหมือนกันทุกครั้ง, ทั้งทีมใช้ได้

🌐 หมายเหตุความ neutral — บทความนี้เอียงไป Claude Code (skill เป็นฟีเจอร์ของมัน) แต่ หลักการ “codify workflow ซ้ำ = reusable command” ใช้ได้ทุกเครื่องมือ. 🔷 = ทำใน Claude Code, 🌐 = ทำในเครื่องมืออื่น (Copilot / Cursor / Codex / Antigravity)

ปัญหา: งานซ้ำที่ต้องสั่งเหมือนเดิมทุกครั้ง

มีงานประเภทหนึ่งที่ agent ทำได้ดี แต่ หลายขั้น และคุณทำมัน บ่อย — เช่น:

  • ลงบทความบล็อก: เลือกหมวด → แตก branch → เขียน frontmatter SEO → สร้างรูป hero → build เช็ค → ขอ merge
  • ขึ้น release: bump version → changelog → tag → build → publish
  • scaffold ฟีเจอร์ใหม่ตาม convention ของทีม

ถ้าทุกครั้งคุณต้อง พิมพ์อธิบายขั้นตอนใหม่ = เสียเวลา + อธิบายไม่ครบ + agent ทำไม่เหมือนเดิม + เพื่อนร่วมทีมทำคนละแบบ

หลักการ: codify workflow ซ้ำ → reusable artifact

ทางแก้เป็นหลักการเดียว ใช้ได้ทุกเครื่องมือ:

เขียน workflow ที่ทำซ้ำ ให้เป็น artifact ที่ reusable + self-contained ครั้งเดียว — มีขั้นตอนครบ, มี guardrails (จุดที่ต้องหยุดถาม / ห้ามทำ), เรียกด้วย trigger เดียว

ผลลัพธ์: จาก “อธิบาย 10 บรรทัดทุกครั้ง” → เหลือ “เรียกคำสั่งเดียว” และได้ผล สม่ำเสมอ

ตัวอย่างจริง: skill ลงบทความบล็อกอัตโนมัติ

บทความที่คุณกำลังอ่านนี้ก็ลงด้วย skill ตัวหนึ่งที่ codify ขั้นตอนทั้งหมดไว้ ชื่อ /publish-article. เรียกครั้งเดียว มันจะ:

  1. เลือก/สร้างหมวดให้เหมาะ → แตก branch
  2. เขียน frontmatter ที่ tune SEO + เนื้อหา (โครงถูกตาม theme ของบล็อก)
  3. สร้างรูป OG hero ให้อัตโนมัติ
  4. build เช็คว่า frontmatter/รูป/หน้าเว็บ valid (เช็ค SEO จาก HTML จริง)
  5. หยุดขออนุมัติก่อน merge (guardrail) — และไม่ push เอง

จาก “เล่าขั้นตอนใหม่ทุกบทความ” เหลือพิมพ์ /publish-article คำเดียว

องค์ประกอบของ command/skill ที่ดี

ไม่ว่าเครื่องมือไหน artifact ที่ดีมี 4 อย่าง:

  1. Trigger ชัด — รู้ว่าเมื่อไรควรใช้ (คำอธิบาย/ชื่อคำสั่งดีๆ)
  2. Self-contained — ขั้นตอนครบในตัว ไม่พึ่ง context ที่อาจหาย (เช่น path, convention, ตัวอย่าง)
  3. Guardrails — จุดหยุดถาม (ก่อน merge/deploy) และข้อห้าม (อย่า push, อย่าแตะ main)
  4. Verify ในตัว — มี step ตรวจงานตัวเอง (build/test) ก่อนบอกว่าเสร็จ

🔷 ทำใน Claude Code (skill)

Claude Code มี skills = โฟลเดอร์ ~/.claude/skills/<ชื่อ>/SKILL.md (มี frontmatter name + description) + แนบสคริปต์ได้. description คือสิ่งที่ทำให้มัน auto-trigger เมื่อคุณพูดตรงเรื่อง (เช่น “ลงบทความให้หน่อย”) หรือพิมพ์ /<ชื่อ> ตรงๆ

  • เก็บที่ user level (~/.claude/skills/) → ใช้ได้ทุกโปรเจกต์ทุก session
  • แนบไฟล์ประกอบได้ (สคริปต์, template) → skill เรียกใช้เองได้
  • เขียนขั้นตอน + guardrails ลง SKILL.md ให้ครบ (self-contained) เพราะ skill อาจถูกใช้ตอนที่ memory ไม่ได้โหลด (ผูกกับ path)

ตัวอย่าง SKILL.md (โครงจริง — เก็บที่ ~/.claude/skills/publish-article/SKILL.md):

---
name: publish-article
description: ลงบทความบล็อก — ใช้เมื่อผู้ใช้บอก "ลงบทความ / ทำเป็นบทความ"
---
1. เลือก/สร้างหมวด → แตก branch `content/<slug>`
2. เขียน frontmatter (SEO) + เนื้อหา + สร้างรูป hero
3. `pnpm build` เช็ค frontmatter/รูป/หน้าเว็บ valid
4. **หยุดขออนุมัติก่อน merge** · ห้าม push (guardrail)

description = trigger (auto-เรียกเมื่อพูดตรงเรื่อง) · body = ขั้นตอน + guardrail ครบในตัว

🌐 ทำในเครื่องมืออื่น

หลักการเดียวกัน แค่รูปแบบ artifact ต่างกัน:

  • GitHub Copilotprompt files .github/prompts/<ชื่อ>.prompt.md (reusable prompt ที่เรียกได้)
    • .github/copilot-instructions.md สำหรับ convention รวม
  • Cursor — เก็บ workflow เป็น rules .cursor/rules/*.mdc หรือ reusable prompt แล้วอ้างถึง
  • Codex / Antigravity — เขียน ritual/ขั้นตอนลง AGENTS.md (หรือ doc ในเรพ) เป็น checklist ที่มี ชื่อ แล้วสั่งว่า “ทำ <ชื่อ workflow>” — agent อ่านจากไฟล์แล้วทำตาม

ตัวอย่างเทียบ — workflow เดียวกันในรูป Copilot prompt file (.github/prompts/publish-article.prompt.md):

---
mode: agent
description: ลงบทความบล็อก
---
1. เลือกหมวด → แตก branch content/<slug>
2. เขียน frontmatter + เนื้อหา + hero
3. build เช็ค → หยุดขออนุมัติก่อน merge (ห้าม push)

จะเห็นว่า เนื้อ workflow เหมือน SKILL.md เป๊ะ ต่างแค่ชื่อไฟล์/frontmatter ของแต่ละเครื่องมือ

จุดร่วม: artifact อยู่ใน เรพ หรือ config ของเครื่องมือ (ไม่ใช่ในหัว agent) → reusable + ทั้งทีม ได้ประโยชน์ + ทำเหมือนกันทุกครั้ง (เช็ค docs รุ่นล่าสุดของเครื่องมือคุณอีกที)

ระวัง: อย่าให้ artifact “ซ้ำ” กันจน drift

ถ้า workflow เดียวไปเขียนไว้หลายที่ (skill + memory + doc) → แก้ที่นึงลืมอีกที่ = ข้อมูลขัดกัน. เลือก source of truth เดียว (เช่น skill) แล้วที่อื่นแค่ทำ pointer ชี้มา

2 pattern ที่พิสูจน์แล้วว่าคุ้ม (อัปเดตจากการใช้จริง):

  1. wrapper ต้องบาง — ตัว command/skill ควรเป็นแค่ “ตัวเรียก” ไม่กี่บรรทัดที่ชี้ไปขั้นตอนเต็ม ในเอกสารกลาง (rule/guide) — เนื้อหาอยู่บ้านเดียว wrapper แปลง/ย้ายค่ายได้ถูก ๆ
  2. wrong-situation guard — บรรทัดแรกของ command เช็คก่อนว่าถูกสถานการณ์ไหม (เช่น /bootstrap-… เจอ tracker เก่า → หยุดแล้วชี้ให้ใช้ /migrate-… แทน) — user จำ command ผิดตัวก็ไม่พังงาน · เขียน guard ครั้งเดียว ประหยัดอุบัติเหตุตลอดไป

สรุป

  1. งานหลายขั้นที่ทำซ้ำ → อย่าสั่งใหม่ทุกครั้ง codify มันครั้งเดียว
  2. artifact ที่ดี = trigger ชัด + self-contained + guardrails + verify ในตัว
  3. 🔷 Claude Code = skill (~/.claude/skills/…/SKILL.md) · 🌐 อื่นๆ = prompt files (Copilot) / rules (Cursor) / AGENTS.md checklist (Codex, Antigravity)
  4. เก็บ artifact ใน เรพ/config ไม่ใช่ในหัว agent → reusable + ทั้งทีมได้ + ไม่ drift

codify ครั้งเดียว ใช้ได้ตลอด — คืนเวลาให้คุณไปโฟกัสงานที่คิดจริงๆ 🚀

Supawut Thomas

Supawut Thomas

Software Developer

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