สิ่งที่ได้เรียนรู้จากการสร้าง Claude Code: วิธีที่เราใช้ Skills

 (x.com/trq212)
102 คะแนน โดย GN⁺ 2026-03-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ใน Claude Code Skills เป็นหนึ่งในจุดขยายความสามารถที่ถูกใช้งานมากที่สุด และบทความนี้ได้เปิดเผยแนวปฏิบัติจากการใช้งานจริงที่ Anthropic สั่งสมมาจากการดูแลสกิลหลายร้อยรายการภายในองค์กร
  • สกิลไม่ใช่แค่ไฟล์ Markdown ธรรมดา แต่เป็น โครงสร้างโฟลเดอร์ที่รวมสคริปต์ แอสเซ็ต ข้อมูล และอื่น ๆ ในรูปแบบที่เอเจนต์สามารถสำรวจและนำไปใช้ได้
  • สกิลถูกจัดเป็น 9 หมวดหมู่ เช่น library reference, product verification, data analysis, code scaffolding, CI/CD และสกิลที่ดีควรอยู่ในหมวดเดียวอย่างชัดเจน
  • เคล็ดลับสำคัญในการเขียนสกิลคือ ส่วน Gotchas, การใช้ระบบไฟล์, การเปิดเผยแบบค่อยเป็นค่อยไป (Progressive Disclosure) และการจัดเก็บข้อมูล
  • เมื่อขยายการใช้งานระดับองค์กร แนะนำให้เผยแพร่สกิลผ่าน ปลั๊กอินมาร์เก็ตเพลสภายใน และติดตามผลด้วยฮุกสำหรับวัดการใช้งาน

Skills คืออะไร

  • ความเข้าใจผิดที่พบบ่อยเกี่ยวกับ Skills คือคิดว่า “เป็นแค่ไฟล์ Markdown” แต่ในความเป็นจริงมันคือ โฟลเดอร์ที่รวมสคริปต์ แอสเซ็ต ข้อมูล และอื่น ๆ
  • เอเจนต์สามารถสำรวจโฟลเดอร์นี้ ค้นพบเนื้อหา และจัดการกับมันได้
  • ใน Claude Code นั้น Skills มี ตัวเลือกการตั้งค่าหลากหลาย และยังสามารถลงทะเบียน dynamic hooks ได้
  • สกิลที่น่าสนใจที่สุดมักเป็นสกิลที่ ใช้ตัวเลือกการตั้งค่าและโครงสร้างโฟลเดอร์เหล่านี้อย่างสร้างสรรค์

9 หมวดหมู่ของสกิล

  • เมื่อนำสกิลที่ใช้งานภายในทั้งหมดมาจำแนก พบว่ามันจับกลุ่มเป็น หมวดหมู่ที่เกิดซ้ำอยู่ไม่กี่แบบ
  • สกิลที่ดีควรเข้ากับหมวดหมู่ใดหมวดหมู่หนึ่งอย่างชัดเจน ส่วนสกิลที่ชวนสับสนมักคร่อมหลายหมวด

  • 1. Library & API Reference

    • สกิลที่อธิบายวิธีใช้ไลบรารี, CLI และ SDK ให้ถูกต้อง
    • ไม่ได้จำกัดแค่ไลบรารีภายในองค์กร แต่รวมถึง ไลบรารีทั่วไป ที่ Claude Code มักใช้พลาดด้วย
    • มักมีโฟลเดอร์สำหรับ reference code snippets และ รายการข้อควรระวัง (gotchas)
    • ตัวอย่าง: billing-lib(กรณีขอบของไลบรารีชำระเงินภายใน), internal-platform-cli(ทุก subcommand และตัวอย่างการใช้ของ CLI wrapper ภายใน), frontend-design(ปรับปรุงการใช้ design system)

  • 2. Product Verification

    • สกิลที่อธิบายวิธี ทดสอบและตรวจสอบ ว่าโค้ดทำงานได้ถูกต้อง
    • มักใช้งานร่วมกับเครื่องมือภายนอกอย่าง Playwright, tmux เป็นต้น
    • มีประโยชน์มากต่อการรับประกันความถูกต้องของผลลัพธ์จาก Claude และคุ้มค่าที่วิศวกรจะ ลงทุนเวลาถึงหนึ่งสัปดาห์ เพื่อทำ verification skill ให้ยอดเยี่ยม
    • แนะนำเทคนิคอย่างให้ Claude บันทึกวิดีโอ ของผลลัพธ์ หรือบังคับใช้ programmatic assertions เกี่ยวกับสถานะในแต่ละขั้นตอน
    • ตัวอย่าง: signup-flow-driver(ทำขั้นตอนสมัคร→ยืนยันอีเมล→onboarding ด้วย headless browser), checkout-verifier(ขับ UI การชำระเงินด้วยบัตรทดสอบ Stripe แล้วตรวจสอบสถานะ invoice), tmux-cli-driver(สำหรับทดสอบ interactive CLI ที่ต้องใช้ TTY)

  • 3. Data Fetching & Analysis

    • สกิลที่เชื่อมต่อกับสแตกข้อมูลและมอนิเตอร์ริง
    • อาจรวมไลบรารีดึงข้อมูลที่มี credential, dashboard ID เฉพาะ และคำแนะนำเวิร์กโฟลว์ทั่วไป
    • ตัวอย่าง: funnel-query(ตารางที่มี event และ canonical user_id สำหรับฟันเนลสมัคร→เปิดใช้งาน→ชำระเงิน), cohort-compare(เปรียบเทียบ retention/อัตรา conversion ของสอง cohort พร้อมติดธงความมีนัยสำคัญทางสถิติ), grafana(data source UID, ชื่อคลัสเตอร์, ตาราง lookup ระหว่างปัญหากับ dashboard)

  • 4. Business Process & Team Automation

    • สกิลที่ทำเวิร์กโฟลว์ที่ทำซ้ำบ่อย ๆ ให้เป็น คำสั่งเดียวแบบอัตโนมัติ
    • คำสั่งอาจค่อนข้างเรียบง่าย แต่มี dependency ที่ซับซ้อนกับสกิลอื่นหรือ MCP ได้
    • หากเก็บผลลัพธ์จากการรันครั้งก่อนลงใน ไฟล์ล็อก จะช่วยให้โมเดลรักษาความสม่ำเสมอและสะท้อนผลการรันก่อนหน้าได้ดีขึ้น
    • ตัวอย่าง: standup-post(สแตนด์อัปในรูปแบบที่สรุปจาก ticket tracker, กิจกรรม GitHub และ Slack), create-ticket(บังคับตามสคีมาและมีเวิร์กโฟลว์หลังการสร้าง), weekly-recap(เขียนโพสต์สรุปจาก PR ที่ merge แล้ว + ticket ที่ปิดแล้ว + การ deploy)

  • 5. Code Scaffolding & Templates

    • สกิลที่ สร้าง framework boilerplate สำหรับความสามารถเฉพาะในโค้ดเบส
    • สามารถใช้ร่วมกับสคริปต์ที่ประกอบกันได้ และมีประโยชน์เป็นพิเศษเมื่อมี ข้อกำหนดภาษาธรรมชาติ ที่โค้ดอย่างเดียวครอบคลุมไม่หมด
    • ตัวอย่าง: new-framework-workflow(สร้าง scaffold สำหรับ service/workflow/handler ใหม่พร้อม annotation), new-migration(เทมเพลตไฟล์ migration และข้อควรระวัง), create-app(สร้างแอปภายในใหม่ที่เชื่อม authentication, logging และ deployment settings ไว้ล่วงหน้า)

  • 6. Code Quality & Review

    • สกิลที่ช่วย บังคับใช้คุณภาพโค้ด ในองค์กรและช่วยงาน code review
    • อาจมี สคริปต์หรือเครื่องมือแบบ deterministic เพื่อเพิ่มความแข็งแรงให้มากที่สุด
    • สามารถให้รันอัตโนมัติเป็นส่วนหนึ่งของ hook หรือ GitHub Action ได้
    • ตัวอย่าง: adversarial-review(subagent ที่มองจากมุมใหม่จะวิจารณ์→แก้ไข→วนซ้ำจนข้อทักท้วงเหลือแค่ระดับ nitpick), code-style(บังคับใช้ code style ที่ Claude ทำได้ไม่ดีโดยปริยาย), testing-practices(แนวทางการเขียนเทสต์และสิ่งที่ควรทดสอบ)

  • 7. CI/CD & Deployment

    • สกิลที่ ดึง, push และ deploy โค้ดภายในโค้ดเบส
    • อาจอ้างอิงสกิลอื่นเพื่อรวบรวมข้อมูลได้
    • ตัวอย่าง: babysit-pr(มอนิเตอร์ PR→retry flaky CI→แก้ merge conflict→เปิด auto-merge), deploy-service(build→smoke test→ทยอยปล่อยทราฟฟิก→เปรียบเทียบอัตรา error→rollback อัตโนมัติเมื่อเกิด regression), cherry-pick-prod(worktree แยก→cherry-pick→แก้ conflict→สร้าง PR จากเทมเพลต)

  • 8. Runbooks

    • สกิลที่รับอาการปัญหาเข้าไป (เช่น Slack thread, การแจ้งเตือน, error signature) แล้ว ทำการสืบสวนด้วยหลายเครื่องมือ พร้อมสร้างรายงานแบบมีโครงสร้าง
    • ตัวอย่าง: service-debugging(แมปอาการ→เครื่องมือ→แพตเทิร์นคำสั่ง query), oncall-runner(ดึงการแจ้งเตือน→ตรวจสาเหตุที่พบบ่อย→จัดรูปแบบผลลัพธ์), log-correlator(รวบรวมล็อกของทุกระบบที่เกี่ยวข้องด้วย request ID)

  • 9. Infrastructure Operations

    • สกิลที่ทำงานบำรุงรักษาและขั้นตอนปฏิบัติการประจำวัน พร้อม guardrails สำหรับงานที่มีความเสี่ยงทำลายข้อมูลหรือระบบ
    • ช่วยให้วิศวกรทำตาม best practices ได้ง่ายขึ้นในการปฏิบัติการสำคัญ
    • ตัวอย่าง: resource-orphans(ค้นหา Pod/volume ที่เป็น orphan→แจ้งเตือนทาง Slack→รอช่วงเวลาหนึ่ง→ยืนยันจากผู้ใช้→เก็บกวาดต่อเนื่อง), dependency-management(เวิร์กโฟลว์อนุมัติ dependency ขององค์กร), cost-investigation(bucket และแพตเทิร์น query สำหรับสืบหาสาเหตุที่ค่า storage/egress พุ่งสูง)

เคล็ดลับการเขียนสกิล

  • อย่าเขียนสิ่งที่ชัดเจนอยู่แล้ว

    • Claude Code รู้เรื่องโค้ดเบสมากอยู่แล้ว และมีมุมมองพื้นฐานเกี่ยวกับการเขียนโค้ดด้วย
    • หากจะสร้างสกิลเชิงความรู้ ควรโฟกัสที่ ข้อมูลที่ทำให้ Claude เบี่ยงออกจากวิธีคิดทั่วไปของมัน
    • frontend-design เป็นตัวอย่างที่ดี โดยเป็นสกิลที่วิศวกรของ Anthropic สร้างขึ้นจากการทำซ้ำร่วมกับลูกค้า เพื่อ ปรับปรุงเซนส์ด้านดีไซน์ ของ Claude และหลีกเลี่ยงแพตเทิร์นซ้ำ ๆ อย่างฟอนต์ Inter กับไล่สีม่วง

  • สร้างส่วน Gotchas

    • ในทุกสกิล ส่วนที่มี คุณค่าสัญญาณสูงที่สุด คือส่วน Gotchas
    • ควรสะสมจาก จุดที่มักล้มเหลว เมื่อ Claude ใช้งานสกิล
    • อุดมคติคือคอยอัปเดต gotchas เหล่านี้อย่างต่อเนื่องเมื่อเวลาผ่านไป

  • ใช้ระบบไฟล์และการเปิดเผยแบบค่อยเป็นค่อยไป

    • เพราะสกิลเป็นโฟลเดอร์ จึงควรใช้ ระบบไฟล์ทั้งหมดเป็นเครื่องมือสำหรับ context engineering และการเปิดเผยแบบค่อยเป็นค่อยไป
    • หากบอก Claude ว่าในสกิลมีไฟล์อะไรบ้าง มันจะอ่านในจังหวะที่เหมาะสม
    • รูปแบบที่ง่ายที่สุด: แยก signature ของฟังก์ชันโดยละเอียดและตัวอย่างการใช้ไปไว้ใน Markdown แยกต่างหาก เช่น references/api.md
    • หากผลลัพธ์สุดท้ายเป็น Markdown ก็สามารถใส่ ไฟล์เทมเพลตในโฟลเดอร์ assets/ ได้
    • โฟลเดอร์สำหรับ reference, สคริปต์, ตัวอย่าง และอื่น ๆ จะช่วยเพิ่มประสิทธิภาพการทำงานของ Claude

  • อย่าจำกัด Claude มากเกินไป

    • Claude พยายามทำตามคำสั่ง แต่สกิลมีการนำกลับมาใช้ซ้ำสูง จึงควรระวัง คำสั่งที่เฉพาะเจาะจงเกินไป
    • ให้ข้อมูลที่จำเป็น แต่เปิดพื้นที่ให้มัน ปรับตัวตามสถานการณ์ได้อย่างยืดหยุ่น

  • ออกแบบกระบวนการ Setup

    • บางสกิลต้องมีขั้นตอนตั้งค่าเพื่อ เก็บบริบทจากผู้ใช้
    • เช่น ถ้าเป็นสกิลที่โพสต์สแตนด์อัปลง Slack ก็ต้องถามว่าจะโพสต์ไปที่ช่องไหน
    • แพตเทิร์นที่ดีคือเก็บข้อมูลการตั้งค่าไว้ใน ไฟล์ config.json ในไดเรกทอรีของสกิล และถ้ายังไม่ได้ตั้งค่า เอเจนต์จะถามผู้ใช้
    • หากต้องการถามแบบหลายตัวเลือกที่มีโครงสร้าง สามารถสั่งให้ใช้ AskUserQuestion tool ได้

  • ฟิลด์ Description มีไว้เพื่อโมเดล

    • เมื่อ Claude Code เริ่มเซสชัน มันจะ สร้างรายการ description ของสกิลทั้งหมดที่ใช้งานได้
    • Claude จะสแกนรายการนี้เพื่อพิจารณาว่า “มีสกิลที่เหมาะกับคำขอนี้หรือไม่?”
    • ดังนั้นฟิลด์ description ไม่ใช่สรุปเนื้อหา แต่คือ คำอธิบายว่าควรทริกเกอร์สกิลนี้เมื่อใด

  • หน่วยความจำและการจัดเก็บข้อมูล

    • สกิลสามารถมี หน่วยความจำในรูปแบบของการเก็บข้อมูล ได้
    • ตั้งแต่ไฟล์ล็อกข้อความธรรมดาหรือไฟล์ JSON ไปจนถึง ฐานข้อมูล SQLite
    • เช่น หากสกิล standup-post เก็บประวัติการเขียนทั้งหมดไว้ใน standups.log เมื่อรันครั้งถัดไป Claude ก็จะอ่านประวัติของตัวเองและดูได้ว่ามีอะไรเปลี่ยนไปตั้งแต่เมื่อวาน
    • ข้อมูลที่เก็บในไดเรกทอรีของสกิลอาจถูกลบเมื่ออัปเกรดสกิล จึงควรเก็บไว้ใน โฟลเดอร์ถาวร ${CLAUDE_PLUGIN_DATA}

  • การเก็บสคริปต์และการสร้างโค้ด

    • หนึ่งในเครื่องมือที่ทรงพลังที่สุดที่ให้ Claude ได้คือ ตัวโค้ดเอง
    • หากให้สคริปต์และไลบรารีไว้ Claude จะโฟกัสกับ การประกอบ (composition) แทนที่จะเสียเวลาเขียน boilerplate ใหม่
    • เช่น ในสกิลด้าน data science อาจใส่ ไลบรารี helper functions สำหรับดึงข้อมูลจากแหล่ง event
    • Claude สามารถนำความสามารถเหล่านี้มาผสมกันเพื่อ สร้างสคริปต์เฉพาะกิจได้ทันที และใช้กับการวิเคราะห์ที่ซับซ้อนอย่าง “วันอังคารเกิดอะไรขึ้นบ้าง?”

  • On Demand Hooks

    • สกิลสามารถมีฮุกที่เปิดใช้งานเฉพาะเมื่อถูกเรียกใช้ และ คงอยู่เฉพาะระหว่างเซสชันเท่านั้น
    • เหมาะกับ ฮุกที่มีความเห็นชัดเจนมาก ซึ่งหนักเกินกว่าจะให้รันตลอดเวลา แต่มีประโยชน์มากในบางสถานการณ์
    • ตัวอย่าง:
      • /careful — บล็อก rm -rf, DROP TABLE, force-push, kubectl delete ด้วย PreToolUse matcher และเปิดใช้เฉพาะเวลาทำงานกับโปรดักชัน
      • /freeze — บล็อก Edit/Write ทั้งหมดนอกไดเรกทอรีที่กำหนด มีประโยชน์ในการดีบักเพื่อป้องกันการแก้ไขโดยไม่ตั้งใจ

การเผยแพร่สกิล

  • ข้อดีสำคัญอย่างหนึ่งของสกิลคือ สามารถแชร์ให้ทั้งทีมใช้ร่วมกันได้
  • มีสองวิธีในการแชร์:
    • เช็กอินสกิลเข้าไปใน repo (ใต้ ./.claude/skills)
    • ทำเป็นปลั๊กอินแล้วอัปโหลดไปยัง Claude Code Plugin marketplace เพื่อให้ผู้ใช้ติดตั้ง

  • การดูแลมาร์เก็ตเพลส

    • หากเป็นทีมเล็กที่ทำงานบนไม่กี่ repo วิธีเช็กอินลง repo จะเหมาะกว่า
    • สกิลที่เช็กอินไว้จะ เพิ่มเข้าไปในบริบทของโมเดลทีละน้อย ดังนั้นเมื่อระบบใหญ่ขึ้น การมีปลั๊กอินมาร์เก็ตเพลสภายในจะได้เปรียบกว่า
    • ไม่มี ทีมกลางที่คอยตัดสิน ว่าสกิลใดควรอยู่ในมาร์เก็ตเพลส แต่ปล่อยให้สกิลที่มีประโยชน์จริงถูกค้นพบตามธรรมชาติ
    • หากมีสกิลที่อยากลองใช้ ให้ลองอัปโหลดไปยัง โฟลเดอร์ sandbox ใน GitHub และประกาศผ่าน Slack หรือช่องทางอื่น
    • เมื่อได้แรงดึงดูดมากพอ เจ้าของสกิลจึงค่อยเปิด PR เพื่อย้ายเข้ามาร์เก็ตเพลส
    • เพราะสกิลที่แย่หรือซ้ำซ้อนสามารถถูกสร้างได้ง่าย จึงควรมีกลไก คัดเลือกก่อนปล่อยใช้งานจริง

  • การประกอบสกิล (Composing Skills)

    • อาจต้องมี dependency ระหว่างสกิล (เช่น สกิลอัปโหลดไฟล์ + สกิลสร้างและอัปโหลด CSV)
    • แม้ว่ามาร์เก็ตเพลสหรือระบบสกิลจะยัง ไม่มี dependency management แบบเนทีฟ แต่ถ้าอ้างถึงสกิลอื่นด้วยชื่อ โมเดลก็จะเรียกใช้ได้หากติดตั้งอยู่

  • การวัดผลสกิล

    • เพื่อดูว่าสกิลได้ผลแค่ไหน มีการใช้ PreToolUse hook สำหรับล็อกการใช้งานสกิลภายในบริษัท
    • ใช้ค้นหาทั้งสกิลยอดนิยมและ สกิลที่ถูกทริกเกอร์น้อยกว่าที่คาด

บทสรุป

  • Skills เป็นเครื่องมือที่ทรงพลังและยืดหยุ่นมากสำหรับเอเจนต์ แต่ยังอยู่ในช่วงเริ่มต้น และ ทุกคนยังอยู่ระหว่างค้นหาวิธีใช้งานที่ดีที่สุด
  • บทความนี้ไม่ใช่คู่มือฉบับตายตัว แต่เป็น ชุดเคล็ดลับที่พิสูจน์แล้วว่าใช้ได้ผลจริง
  • สกิลส่วนใหญ่เริ่มจากไม่กี่บรรทัดกับ gotcha เพียงข้อเดียว และผู้คนก็ ค่อย ๆ เติมและปรับปรุงต่อไป ทุกครั้งที่ Claude เจอกรณีขอบใหม่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
xguru 2026-03-19

ช่วงนี้สิ่งที่รู้สึกเมื่อมอง Anthropic คือ ฝ่ายพัฒนากำลังแชร์ประสบการณ์ที่ได้เจอมาให้มากที่สุด พร้อมทั้งชักชวนให้ผู้ใช้ใช้ผลิตภัณฑ์ของตัวเองได้ดีขึ้น

มันดูเหมือนเป็นตัวอย่างที่แสดงให้เห็นด้วยตัวเองว่า “ระบบนิเวศการพัฒนาในยุค AI สร้างกันแบบนี้”