การขุดค้น Skill: จาก 3,500 ผู้สมัครสู่ 466 ความสามารถ

ตัวเลขในบทความนี้สะท้อนระบบ ณ วันที่เผยแพร่ (มกราคม 2026) ดูหน้าทีมของเราสำหรับตัวเลขปัจจุบัน

ปัญหา Skill 3,500 รายการ

เมื่อเราเริ่มสร้างระบบประสาน agent เราเจอความท้าทายที่น่าสนใจ: มี skill ที่เป็นไปได้หลายพันรายการกระจายอยู่ทั่วระบบนิเวศ AI GitHub repository, เอกสาร vendor, โปรเจกต์ชุมชน, รูปแบบภายใน — skill มีอยู่ทุกที่ แต่อันไหนสำคัญ? อันไหนทำงานได้จริง? และคุณจะดูแลคลัง skill ที่สอดคล้องกันซึ่ง agent ใช้งานได้จริงได้อย่างไร?

คำตอบของเรา: ลูปการขุดค้นและนำเข้าอย่างเป็นระบบ

ตัวเลขวันนี้

เพียงสามเดือนเศษหลังจาก Anthropic เปิดตัว Agent Skills เมื่อวันที่ 16 ตุลาคม 2025 นี่คือจุดที่เรายืนอยู่เมื่อบทความนี้เผยแพร่ เมื่อวันที่ 27 มกราคม 2026:

เมตริก	จำนวน
ผู้สมัครที่ระบุแล้ว	3,500+
Skill ที่รับเข้าใช้งาน	466
Skill จาก Vendor	373
Skill ภายใน	93
Vendor ที่ใช้งานอยู่	25+
Token เฉลี่ยต่อ Skill	2,834
เครื่องมือที่ถูกอ้างอิง	89
แท็กที่ไม่ซ้ำกัน	635

เราได้รีวิว skill ผู้สมัครไปแล้วกว่า 3,500 รายการ เรารับเข้าใช้งาน 466 รายการ นั่นคืออัตราการรับเข้า 13% — และความเลือกสรรนั้นตั้งใจ

ระบบชั้นความรู้

ไม่ใช่ทุก skill ที่ถูกสร้างมาเท่าเทียมกัน เราจัดระเบียบพวกมันเป็นห้าชั้นความรู้ (K0-K4) แต่ละชั้นแทนขอบเขตการใช้งานที่ต่างกัน:

K0: รากฐาน (สากล)

Skill ที่ agent ทุกตัวควรมี สิ่งเหล่านี้แทนความสามารถ “นักคิดที่ดี” ที่ทำงานได้ทุกที่

foundations/
├── test-first-discipline       # TDD: Red-Green-Refactor
├── evidence-based-completion   # Verify before claiming done
├── systematic-debugging        # Root cause methodology
├── structured-planning         # Break work into tasks
└── context-budget-awareness    # Manage token consumption

Skill ระดับ K0 พกพาได้ไปยังโปรเจกต์ใดก็ตาม โดเมนใดก็ตาม สแตกใดก็ตาม พวกมันเข้ารหัสรูปแบบทางปัญญาสากล

K1: อัตลักษณ์ (วินัย)

Skill แบบ “วิศวกรที่ดี” หรือ “นักวิจัยที่ดี” ที่ใช้ได้ข้ามโปรเจกต์ภายในสาขาวิชาชีพหนึ่ง

identities/
├── research-workflows          # Multi-source research
├── web-extraction-playbook     # Content extraction
├── code-review                 # PR review patterns
└── cli-interface-standards     # CLI design patterns

K2: โดเมน (ความเชี่ยวชาญเฉพาะเรื่อง)

Skill แบบ “ผู้เชี่ยวชาญฐานข้อมูลที่ดี” หรือ “วิศวกรความปลอดภัยที่ดี” ที่พกพาได้ภายในสาขาหนึ่ง

domains/
├── schema-migration-workflow   # Safe migration patterns
├── rpc-validation-checklist    # RPC health checks
├── auth-validation-checklist   # JWT/OAuth patterns
└── secrets-audit-checklist     # Credential scanning

K3: Stacks (เทคโนโลยี)

Skill แบบ “ผู้ใช้ Supabase ที่ดี” หรือ “นักพัฒนา Cloudflare ที่ดี” สำหรับเทคโนโลยีสแตกเฉพาะ

stacks/
├── maguyva-quickstart          # Our semantic search patterns
├── cloudflare-deployment       # Workers/Pages deployment
└── mcp-tool-best-practices     # MCP tool selection

K4: โปรเจกต์ (องค์กร)

Skill เฉพาะสำหรับองค์กรและเวิร์กโฟลว์ของเรา

project/
├── agent-creation-workflow     # How we build agents
├── skill-authoring-workflow    # How we write skills
├── mining-session-workflow     # This very process
└── vendor-skill-evaluation     # Evaluation rubrics

ลูปการขุดค้น

เฟส 1: การค้นพบ

Skill มาจากทุกที่:

คลัง Vendor: AWS, Anthropic, Cloudflare, Supabase และผู้ร่วมสมทบชุมชนเผยแพร่ชุด skill เราติดตามแหล่งต้นทาง vendor มากกว่า 25 แหล่ง

โปรเจกต์ชุมชน: GitHub เต็มไปด้วยเทมเพลตของ Claude Code, รูปแบบ agent และคำนิยามเวิร์กโฟลว์

รูปแบบภายใน: เมื่อทีมของเราแก้ปัญหา รูปแบบก็ปรากฏขึ้น สิ่งเหล่านี้ถูกทำให้เป็นทางการเป็น skill

การขุดเอกสาร: เอกสารทางเทคนิคมักมี skill โดยนัยอยู่ — ขั้นตอน, รายการตรวจสอบ, ต้นไม้การตัดสินใจ

การค้นพบเป็นไปอย่างต่อเนื่อง เราใช้ skill แบ็กล็อกเพื่อติดตามผู้สมัครก่อนการประเมินอย่างเป็นทางการ

เฟส 2: การประเมิน

ผู้สมัครทุกคนผ่านเกณฑ์การประเมินเดียวกัน:

adoption_criteria:
  - fills_real_gap: true      # We lack this capability
  - well_structured: true     # Progressive disclosure
  - actively_maintained: true # Commits in last 6 months
  - portable: true            # Not hyper-specific
  - tested: true              # Evidence of usage

เกณฑ์ผลิตภัณฑ์ทั้งห้าต้องผ่านทั้งหมด นี่คือเหตุผลที่ผู้สมัคร 87% ถูกปฏิเสธ

จากนั้นผู้สมัครทุกคนจะผ่านการรีวิวความน่าเชื่อถือแยกต่างหาก เราไม่ถือว่า vendor repository ที่เป็นทางการ ผู้ดูแลชุมชนที่มีชื่อเสียง และ GitHub repo สุ่มๆ เป็นแหล่งความจริงที่เท่าเทียมกัน

trust_review:
  vendor_credibility:
    - ownership_verified       # Official vendor, known maintainer, or internal source
    - maintenance_signal       # Recent commits, issue response, release history
    - adoption_signal          # Evidence of real use, stars alone are not enough
    - provenance_clear         # We can trace where the skill came from
  prompt_injection_scan:
    - hidden_instruction_check # Buried "ignore previous instructions" patterns
    - exfiltration_check       # Prompts that try to leak files, secrets, or context
    - authority_check          # Claims of priority over system or developer rules
  script_audit:
    - inspect_scripts          # Read shell/python/js helpers before adoption
    - network_and_exec_review  # curl|bash, remote downloads, subprocess execution
    - file_and_secret_review   # Env vars, credential access, broad file writes
    - destructive_action_check # rm, reset, overwrite, or unsafe automation

vendor ที่เชื่อถือได้ได้รับการรีวิวที่มาที่ไปที่เบากว่า แต่ไม่ใช่ผ่านฟรี แหล่งที่มาที่ไม่น่าเชื่อถือหรือไม่รู้จักจะได้รับการตรวจสอบด้วยมือที่ลึกกว่า และเราจะไม่รันสคริปต์ที่ถูกรวมมาจนกว่ามันจะถูกอ่าน กำหนดขอบเขต และจำแนกว่าปลอดภัยแล้ว

การวิเคราะห์ช่องว่าง: ก่อนรับเข้าใช้งาน เราค้นหาในรีจิสทรีของเรา:

uv run orkestra skills search "<capability>"

ถ้าเรามีมันอยู่แล้ว เราก็ไม่ต้องการมันอีก ถ้าเรามีอะไรที่ใกล้เคียง เราอาจรวมมันเข้าด้วยกันแทนที่จะรับเข้าใช้งาน

การให้คะแนนความลึกและมาตรฐาน: เรายังให้คะแนนว่าผู้สมัครใช้โมเดล agent-skill อย่างเต็มที่แค่ไหน SKILL.md เดี่ยวๆ ยังคงมีประโยชน์ได้ แต่ skill ที่ลึกกว่าจะมีคุณค่ามากกว่าเมื่อมันแยกคำสั่งออกจากการอ้างอิง, สคริปต์ และทรัพยากร ในแบบที่ agentskills.io สนับสนุน

skill_depth:
  - level_1: SKILL.md only                     # Single instruction file
  - level_2: SKILL.md + strong description     # Clear triggers and scope
  - level_3: adds references/                  # Load docs only when needed
  - level_4: adds atomic scripts/              # Small, reviewable helpers
  - level_5: adds assets/examples/templates    # Full progressive disclosure
depth_signals:
  - standards_adherence        # Structure aligns with agentskills.io conventions
  - reference_quality          # Curated references, not giant context dumps
  - script_atomicity           # Focused helpers, not opaque monoliths
  - tool_boundary_clarity      # Clear limits on what the skill can execute
  - community_signal           # Stars/forks/users help, but only as a weak boost

ดาว GitHub สามารถยกระดับคะแนนความน่าเชื่อถือได้เล็กน้อย แต่มันไม่เคยช่วยกู้ skill ที่ตื้นหรือไม่ปลอดภัยได้ repo ที่มีดาวสูงพร้อม SKILL.md ที่คลุมเครือหนึ่งอันและสคริปต์ที่ทึบแสง จะได้คะแนนต่ำกว่า repo ที่เล็กกว่าซึ่งมีคำอธิบายที่แม่นยำ references/ ที่คัดสรรมาอย่างดี และตัวช่วยแบบอะตอมมิกที่ใช้ประโยชน์จากความสามารถของ skill เต็มรูปแบบจริงๆ

การวิเคราะห์เชิงโครงสร้าง: เราตรวจสอบคุณภาพ skill:

wc -l vendor/<repo>/<skill>/SKILL.md  # Size check
ls vendor/<repo>/<skill>/scripts/     # Supporting files
ls vendor/<repo>/<skill>/references/  # Bundled docs

หากผู้สมัครมีสคริปต์ การรีวิวนั้นจะเข้มงวดขึ้น skill ที่ดีไม่ใช่แค่มีประโยชน์ มันต้องอ่านเข้าใจได้ มีขอบเขต และปลอดภัยที่จะมอบให้ agent ตัวกรองความปลอดภัยนั้นเพียงอย่างเดียวก็ตัดผู้สมัครที่น่าสนใจในด้านอื่นๆ ออกไปจำนวนมาก

เฟส 3: การนำเข้า

เมื่อ skill ผ่านการประเมิน มันเข้าสู่รีจิสทรี แต่ skill ไม่เคยถูกรับเข้าใช้งานโดยไม่มีการเปลี่ยนแปลง พวกมันถูกปรับให้เข้ากับระบบของเรา

การปรับเปลี่ยนตอนรับเข้าใช้งาน:

1. การนอร์มัลไลซ์ Metadata: ทุก skill ได้รับ frontmatter schema ของเรา
2. การกำหนดชั้น K: skill ถูกวางในชั้นความรู้ที่เหมาะสม
3. การเสริมแท็ก: มีการเพิ่มแท็กเพื่อการค้นพบ
4. การประกาศเครื่องมือ: เครื่องมือที่อนุญาตถูกประกาศอย่างชัดเจน
5. การจัดวางส่วน: เนื้อหาถูกจัดโครงสร้างใหม่ให้ตรงกับเทมเพลตของเรา

skill YAML ทั่วไปหลังการนำเข้า:

metadata:
  identifier: vendor-skill-evaluation
  name: vendor-skill-evaluation
  description: Systematic evaluation of vendor skills for adoption.
  type: workflow
  layer: K4
  semantic_folder: project
  source: core
  last_updated: '2026-01-17'

frontmatter:
  tags:
    - agents
    - meta
    - skill-adoption
    - vendor
  allowed_tools:
    - Bash
    - Read
    - Write
    - Edit
    - Grep
    - Glob
    - Task

เฟส 4: การกำหนดขอบเขต

Skill ถูกกำหนดให้กับขอบเขต — หมวดหมู่ที่ตัดสินว่า agent ตัวไหนโหลด skill ตัวไหน:

scopes:
  database:
    primary_skills:
      - domains/schema-migration-workflow
      - domains/rpc-validation-checklist
      - vendor/supabase/supabase-database
      - vendor/supabase/supabase-auth

  research:
    primary_skills:
      - identities/research-workflows
      - identities/web-extraction-playbook
      - identities/dataset-discovery-quickstart

agent ประกาศขอบเขตของตัวเอง และ skill จะถูกกำหนดโดยอัตโนมัติ:

# Agent definition
scopes: [database, research]
# Gets: all database skills + all research skills + universal skills

เฟส 5: การทำให้เป็นรูปธรรม

Skill ไม่ได้อาศัยอยู่เป็น YAML ในโปรดักชัน พวกมันถูกเรนเดอร์เป็นไฟล์ SKILL.md ที่ Claude Code โหลดได้:

uv run orkestra sync

คำสั่งนี้:

1. อ่านคำนิยาม skill YAML ทั้งหมด
2. เรนเดอร์พวกมันผ่าน Jinja เทมเพลต
3. เขียนไฟล์ SKILL.md ไปยัง .claude/skills/
4. จัดระเบียบตามชั้น K (foundations/, identities/, domains/, stacks/, project/)

โครงสร้างผลลัพธ์สุดท้าย:

.claude/skills/
├── foundations/     # K0: Universal
├── identities/      # K1: Discipline
├── domains/         # K2: Subject
├── stacks/          # K3: Technology
├── project/         # K4: Organization
└── vendor/          # External skills

รูปแบบขอบเขตแบบแฝง

หนึ่งในรูปแบบที่ทรงพลังที่สุดของเราคือ skill แบบ “รับเข้าแต่ไม่โหลด” เราเรียกสิ่งเหล่านี้ว่าขอบเขตแฝง

พิจารณา skill การคำนวณทางวิทยาศาสตร์จาก k-dense-scientific repository เรารับเข้าใช้งาน skill มากกว่า 120 รายการครอบคลุมชีวสารสนเทศศาสตร์, เคมี, การประมวลผลควอนตัม และสารสนเทศศาสตร์คลินิก แต่ agent ส่วนใหญ่ของเราไม่ต้องการการจับคู่โมเลกุล หรือการวิเคราะห์การแสดงออกของยีน

แทนที่จะโหลด skill ทั้ง 120 รายการเข้าไปในทุก agent (ทำให้หน้าต่างบริบทบวม) เรา:

1. รับเข้าใช้งาน skill พร้อมขอบเขตที่ระบุ (เช่น bioinformatics)
2. ปล่อยให้มันแฝงอยู่ — ลงทะเบียนแต่ไม่โหลด
3. เปิดใช้งาน เฉพาะเมื่อ agent ประกาศขอบเขตนั้น

# In scopes.yaml - dormant scope
bioinformatics:
  description: "Bioinformatics and genomics"
  primary_skills: []  # Empty - skills exist but aren't loaded

# When an agent needs bioinformatics:
# Agent YAML
scopes: [research, bioinformatics]  # Now loads bioinformatics skills

รูปแบบนี้ทำให้เรามี skill 466 รายการในรีจิสทรี ในขณะที่ agent ทั่วไปโหลดเพียง 40-60 รายการที่เกี่ยวข้อง

ประเภท Skill

Skill มาในสามรูปแบบทางปัญญา:

เวิร์กโฟลว์

ขั้นตอนตามลำดับ: “1. ทำ X, 2. จากนั้นทำ Y, 3. สุดท้ายทำ Z”

type: workflow
# Examples: schema-migration-workflow, mining-session-workflow

วินัย

ข้อจำกัดเชิงพฤติกรรม: “เสมอ X”, “ไม่เคย Y”, “ควรเลือก Z”

type: discipline
# Examples: test-first-discipline, evidence-based-completion

รายการตรวจสอบ

เกณฑ์การตรวจสอบ: “ยืนยัน X”, “ตรวจสอบ Y”, “เช็ค Z”

type: checklist
# Examples: auth-validation-checklist, secrets-audit-checklist

เกณฑ์คุณภาพ

ทุก skill ต้องผ่านการตรวจสอบก่อนถูกปล่อยออกมา:

validation:
  file_exists: true           # Skill file at declared path
  frontmatter_valid: true     # Frontmatter parses correctly
  sections_complete: true     # Expected sections present
  tools_registered: true      # Declared tools exist in registry

คำอธิบายต้องมี 50-400 ตัวอักษรพร้อมวลีกระตุ้น (“ใช้เมื่อ…”, “เมื่อคุณต้องการ…”) เพื่อให้ Claude Code รู้ว่าจะแนะนำมันเมื่อไหร่

เราตรวจสอบอย่างต่อเนื่อง:

uv run orkestra validate --show-warnings

ระบบนิเวศ Vendor

skill 373 รายการจาก vendor ของเรามาจาก:

ผู้ให้บริการ	Skill	โดเมน
AWS Agent	19	บริการคลาวด์
Anthropic	12	การสร้างเอกสาร
Cloudflare	8	การประมวลผลแบบเอดจ์
Supabase	5	ฐานข้อมูล
k-dense	100+	การคำนวณทางวิทยาศาสตร์
silvainfm	4	วิทยาการข้อมูล
Java Developer Kit	45+	Spring/Java
Vercel	1	ระบบอัตโนมัติของเบราว์เซอร์

แต่ละแหล่งต้นทาง vendor ถูกประกาศใน metadata.yaml:

vendor_roots:
  - path: vendor/aws-agent-skills
    provider: aws
  - path: vendor/k-dense-scientific/scientific-skills
    provider: k-dense
  - path: vendor/supabase-skills
    provider: supabase

เมื่อ orkestra sync รัน skill ของ vendor จะถูก symlink เข้าไปใน .claude/skills/vendor/ พร้อม namespace ของผู้ให้บริการ

สิ่งที่เราเรียนรู้

ความเลือกสรรคุ้มค่า มันน่าดึงดูดที่จะรับเข้าใช้งานทุกอย่างที่ดูมีประโยชน์ แต่ skill แต่ละอันมีต้นทุนเป็น token ด้วยค่าเฉลี่ย 2,834 token ต่อ skill ความฟุ่มเฟือยทำร้ายเราเร็ว อัตราการรับเข้าใช้งาน 13% ของเราทำให้ agent ยังคงกระชับ

โครงสร้างเปิดให้ค้นพบ ระบบชั้น K ไม่ใช่แค่การจัดระเบียบ — มันคือเรื่องของการพกพาได้ skill ระดับ K0 นำกลับมาใช้ที่ไหนก็ได้ skill ระดับ K4 ตั้งใจให้เจาะจงเฉพาะโปรเจกต์ ความชัดเจนนี้ช่วยทั้งมนุษย์และ agent หาสิ่งที่ต้องการได้

ขอบเขตแฝงขยายสเกลได้ คุณสามารถรับเข้าใช้งาน skill หลายร้อยรายการโดยไม่ต้องโหลดทั้งหมด ขอบเขตให้คุณสร้างรีจิสทรีที่ครอบคลุม ในขณะที่ยังรักษาหน้าต่างบริบทของ agent แต่ละตัวให้จัดการได้

การปรับเปลี่ยนตอนรับเข้าใช้งานเป็นสิ่งจำเป็น skill vendor แบบดิบแทบไม่เคยเข้ากับระบบของคุณเลย กระบวนการนำเข้า — การเพิ่ม metadata, การกำหนดชั้น, การเสริมแท็ก — ทำให้ skill ภายนอกทำงานภายในได้

การขุดค้นเป็นไปอย่างต่อเนื่อง ตัวเลข 3,500 ยังคงเติบโตต่อไป vendor repo ใหม่ปรากฏขึ้น รูปแบบชุมชนเกิดขึ้น เวิร์กโฟลว์ภายในตกผลึก ลูปไม่เคยหยุด

ต่อไปคืออะไร

เรากำลังทำงานเกี่ยวกับการปรับปรุงหลายอย่าง:

1. การตรวจจับช่องว่างอัตโนมัติ: แจ้งเตือนเมื่อความล้มเหลวทั่วไปของ agent สามารถแก้ไขได้ด้วย skill ที่ยังไม่ได้รับเข้าใช้งาน
2. เวิร์กโฟลว์การเลิกใช้ skill: กระบวนการที่เป็นทางการสำหรับการปลดระวาง skill ที่ถูกแทนที่หรือไม่ได้ใช้
3. การพึ่งพาข้าม Skill: การประกาศข้อกำหนดเบื้องต้นของ skill อย่างชัดเจน
4. การวิเคราะห์การใช้งาน: ติดตามว่า skill ไหนที่ agent เรียกใช้จริงเทียบกับแค่โหลด

ลูปการขุดค้น skill คือโครงสร้างพื้นฐาน มันไม่ได้หรูหรา แต่มันคือสิ่งที่ทำให้ agent 41 ตัวทำงานสอดคล้องกันด้วยความสามารถ 466 รายการ ในขณะที่ยังอยู่ในขีดจำกัดของบริบท

นั่นคือเรื่องราวว่า 3,500 กลายเป็น 466 ได้อย่างไร ไม่ใช่ด้วยการเพิกเฉยต่อ 3,000 รายการ — แต่ด้วยการประเมินอย่างเป็นระบบและรับเข้าใช้งาน เฉพาะสิ่งที่ใช้ได้ผล

---

อยากเห็นระบบ skill ทำงานจริงไหม ดูที่ uv run orkestra skills list เพื่อสำรวจรีจิสทรีปัจจุบันของเรา