GitHub เผยแพร่คู่มือ agent skills แบบ portable เมื่อ 12 พ.ย. อธิบายหลักการแยก skill ออกจาก config ของโปรเจกต์ การแบ่งหน้าที่ของแต่ละ skill และการเขียน skill ให้ผ่านการตรวจสอบของ agent อีกตัว
เดือนก่อน ๆ ผมเขียนบทความเรื่อง Teardown ซึ่งเป็น Agent Skill ที่ทำงานได้จริง ตอนนั้นผมยังมองว่า Agent Skill เป็นแค่รูปแบบไฟล์ที่ Anthropic ทำไว้ให้ Claude Code ใช้
ตอนนี้สถานะเปลี่ยนไปแล้ว: Anthropic บริจาค Agent Skills ให้ Linux Foundation เมื่อ 22 ต.ค. และมีมากกว่า 70 platform รองรับแล้ว รวมถึง GitHub Copilot, Cursor และ VS Code
และเมื่อวานนี้ (12 พ.ย.) GitHub เผยแพร่คู่มือ Build once, run on any agent ที่อธิบายวิธีออกแบบ skill ให้ portable จริง ๆ ผมอ่านจบแล้วคิดว่ามันน่าจะเป็นบทความที่มีประโยชน์กับคนที่ทำงานกับ agent ทุกวัน
โครงสร้างของ skill คือ directory ที่มีไฟล์ SKILL.md เป็นศูนย์กลาง บรรยายว่าเมื่อไรและอย่างไรที่เราจะทำงานที่ทำซ้ำ ๆ กันได้
แต่ประเด็นที่ GitHub ย้ำคือ คุณแชร์คำสั่งได้ แต่สภาพแวดล้อมยังเป็นของ host:
Agent skills capture repeatable engineering work in files teams can review and reuse, while tools, project context, and permissions remain specific to the host that runs them.
พูดง่าย ๆ คือ skill อาจบอกว่า "วิธี query ฐานข้อมูล" ได้ แต่ มันไม่ได้ให้สิทธิ์เข้าถึงฐานข้อมูลนั้น
ขอบเขตนี้สำคัญมาก เพราะมันตอบคำถามที่คนมักสับสน: "ถ้าผมแชร์ skill ที่ใช้คีย์ API ของผมไปกับทีม ทีมจะรันได้ไหม" — คำตอบคือ คำสั่งได้ แต่ credential ไม่ได้ติดไปด้วย
skill ที่ดีต้องระบุ job, input และ output ให้ชัด ในตัวอย่างของ GitHub คือ Proof Agent ที่ใช้ตรวจงานที่ AI สร้าง โดยให้ verifier อีกตัวหนึ่งตรวจแทน
เหตุผลที่แยก verifier ออกมาอีกตัว เพราะ: ถ้า agent เดียวกันตรวจงานของตัวเอง คำอธิบายของมันเองจะมีอิทธิพลต่อผลการตรวจ กฎข้อเดียวที่เขาใส่ไว้คือ:
self-verification is not verification.
frontmatter ของ skill ดูง่าย ๆ แบบนี้:
---
name: proof-agent
description: Adversarial verification of AI-generated work. Spawns an independent verifier to check for false claims, broken code, and security issues.
---ส่วนเนื้อใน SKILL.md มีหัวข้อ When to Verify บอกว่าเมื่อไรควรเรียก skill นี้ แล้วส่วนที่เหลืออธิบายว่า verifier ตรวจอะไรและต้องให้หลักฐานอะไรมาด้วย
ตัวอย่าง Data Forge ในบทความเป็น pipeline ที่มีหลาย skill ทำงานต่อกัน แต่ละ skill มีหน้าที่แน่นอน และ อ่าน manifest ชุดเดียวกัน แทนที่จะเดาเองทีละอัน
แนวคิดตรงนี้สำคัญมาก: ถ้า knowledge ที่ทำให้ pipeline ถูกต้องอยู่ในหัวสี่คน คนทั้งสี่ก็คือ roadmap — ทุกการเปลี่ยนแปลงของ pipeline ขึ้นอยู่กับว่าคนพวกนั้นว่างไหม
คำสั่งใน GitHub: "We don’t want to hardcode every project’s names, database, or conventions into the skills."
ทางแก้คือ manifest แยกไฟล์:
project:
name: 'support-desk'
store_name: 'support_metric_store'
platform:
engine: 'duckdb'
pipeline_framework: 'spark_python'
duckdb_dir: 'warehouse'skill อ่านไฟล์นี้แทนที่จะ hardcode ชื่อตาราง ชื่อ database
และมีจุดที่ละเอียดมาก ๆ: "A pattern found in a repository isn’t automatically a rule to preserve" — สิ่งที่ค้นพบในโค้ดไม่ใช่กฎที่ต้องรักษาไว้ ต้องให้คนตัดสินใจยืนยัน
คำถามสำหรับเช็ค portability ที่ GitHub เสนอไว้ดีมาก:
could another team use these skills with its own manifest without rewriting them?
skill ควรบอกว่าต้องทำอะไรและเมื่อไรควรขออนุมัติ แต่การตรวจสอบควรเป็น test และ CI check
ในตัวอย่าง Proof Agent มี GitHub Actions workflow ที่ส่ง request เดิมกับ diff ให้ verifier แต่ ไม่ส่งการประเมินของ agent ตัวเขียนโค้ดไปด้วย verifier คืนค่า PASS, FAIL หรือ PARTIAL และต้องอ้างอิงหลักฐานในไฟล์ที่เปลี่ยน
ข้อควรระวังคือ workflow นั้นทำ static review ของ diff — ไม่ execute code และไม่รันเทสต์ ซึ่งถูกต้อง เพราะผลของเทสต์ควรอยู่ใน CI check ของ repo ไม่ใช่ใน skill
ถ้าใช้หลาย client ต้อง sync หลายชุด ในตัวอย่าง Data Forge เก็บ skills/*/SKILL.md เป็น source แล้วใช้ script generate ไฟล์เฉพาะ client:
.claude-plugin/plugin.json สำหรับ Claude Code.cursor-plugin/plugin.json สำหรับ Cursor.github/agents/*.agent.md สำหรับ GitHub Copilotscript มี check mode สำหรับ CI:
node scripts/package.mjs --checkและหลังติดตั้ง skill เสร็จต้องเช็คว่า client มันรู้จัก skill จริง โหลด reference ที่ถูกต้อง ใช้ tool ที่ต้องใช้ได้ และคืนหลักฐานตามที่ skill ระบุ
GitHub มีเกณฑ์ที่ชัดมาก และผมว่ามันสำคัญกว่าที่คู่มืออื่น ๆ มักพูด:
Skills fit bounded, repeatable work that benefits from reusable judgment, such as a checklist, release, migration, or metric pipeline. If a workflow needs a stable interface, shared state, an audit trail, long-running control, or permissions enforced outside the model, an application is a better fit.
สรุปเป็นสองกลุ่ม:
ควรใช้ skill เมื่อ
ควรเขียนเป็นแอปเมื่อ
ถ้าต้องการ permission ที่บังคับนอกโมเดล ก็แปลว่าต้องมีแอปจริง ๆ เพราะ skill ไม่ได้ให้สิทธิ์ใด ๆ นอกจากที่ host มี
Put business context in one file — ชื่อ schema convention ของโปรเจกต์อยู่ใน manifest ที่เห็นได้จุดเดียว skill อ่านจากที่นี่ ไม่ต้อง copy ไปทั่ว
Give related skills one consistent way to use the platform — skill ที่เกี่ยวข้องกันควรใช้ path เดียวกันในการรัน query, job, schema change จะได้ตรวจสอบง่ายและพฤติกรรมเหมือนกันในทุก client
Use instructions to guide the work, and checks to verify it — skill บอกว่าต้องทำอะไรและเมื่อไรต้องขออนุมัติ ส่วน test กับ CI check คือตัวจับปัญหา ถ้าจะให้ check block merge ก็ตั้งค่า requirement ใน rules ของ repo
เพราะสถานะของ Agent Skills เปลี่ยนจาก "ฟีเจอร์ของ Claude Code" เป็น "มาตรฐานของวงการ" ในเวลาไม่กี่สัปดาห์:
แต่ก็ต้องระวังความหมายของ "portable" — portable format ไม่ได้แปลว่าทุก skill รันได้ทุกที่ skill อาจพึ่ง tool, path หรือ runtime เฉพาะของ platform และ skill ฝั่ง filesystem ของ Claude Code ไม่ได้ sync ไปที่ Claude.ai หรือ API อัตโนมัติ
ในทางปฏิบัติสำหรับคนทำงานประจำวัน เรื่องที่ได้ประโยชน์เลยคือ:
เกณฑ์ที่ GitHub ให้ (bounded, repeatable) ดูดี แต่มีความเสี่ยงที่คู่มือไม่ได้พูดตรง ๆ: skill คือ prompt ที่ถูก commit เข้า repo ถ้าเราใส่ข้อมูลบริษัทลงไป ก็ต้องระวังว่า:
SKILL.md ใน repo ก็เท่ากับแก้พฤติกรรมของ agent ทุกคนโดยสรุปคือ portability ของ skill ทำให้เราต้องระวังเรื่อง version control ของ prompt มากขึ้น ไม่ใช่น้อยลง
A2UI 1.0: โปรโตคอลเปิดที่ทำให้ AI Agent ส่ง UI มาให้แอปเรนเดอร์เองได้
13 Nov 2026 · 3 min read
สรุป 4 เครื่องมือ AI Agents & Dev Tools ที่มาแรงวันนี้: จาก Modern Web Guidance ถึง Gemini Decisions API
12 Nov 2026 · 4 min read
รู้จัก Teardown: เปลี่ยนเครื่องจักรซับซ้อนให้เป็น 3D Simulator ในหน้าเดียวด้วย Claude Code
12 Nov 2026 · 3 min read