# การขุดค้น Skill: จาก 3,500 รายการที่เข้าข่ายสู่ 466 ความสามารถ

Canonical source: https://maguyva.ai/th/blog/skill-mining-3500-and-counting

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-01-27 · Author: Maguyva Team

> เราคัดกรอง skill ที่เข้าข่าย 3,500 รายการ และรับเข้าใช้งาน 466 รายการ ลูปการขุดค้นและนำเข้าอย่างเป็นระบบ เพื่อสร้างคลัง skill ของ AI agent ที่สอดคล้องกันในระดับใหญ่

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

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

เมื่อเราเริ่มสร้างระบบประสาน agent เราเจอความท้าทายที่น่าสนใจ: มี skill ที่เป็นไปได้หลายพันรายการกระจายอยู่ทั่วระบบนิเวศ AI GitHub รีโพซิทอรี, เอกสาร 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: การประเมิน

skill ทุกตัวที่เข้าข่ายได้รับการประเมินด้วยเกณฑ์เดียวกัน:

```yaml
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% ถูกปฏิเสธ

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

```yaml
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 ที่เชื่อถือได้ได้รับการรีวิวที่มาที่ไปที่เบากว่า แต่ก็ไม่ได้ผ่านโดยอัตโนมัติ แหล่งที่มาที่ไม่น่าเชื่อถือหรือไม่รู้จักจะได้รับการตรวจสอบด้วยมือที่ลึกกว่า และเราจะไม่รันสคริปต์ที่ถูกรวมมาจนกว่ามันจะถูกอ่าน กำหนดขอบเขต และจำแนกว่าปลอดภัยแล้ว

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

```bash
uv run orkestra skills search "<capability>"
```

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

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

```yaml
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 ที่ตื้นหรือไม่ปลอดภัยได้ รีโพที่มีดาวสูงพร้อม `SKILL.md` ที่คลุมเครือหนึ่งอันและสคริปต์ที่ตรวจสอบการทำงานได้ยาก จะได้คะแนนต่ำกว่ารีโพที่เล็กกว่าซึ่งมีคำอธิบายที่แม่นยำ `references/` ที่คัดสรรมาอย่างดี และสคริปต์ช่วยงานขนาดเล็กที่รับผิดชอบงานเดียวที่ใช้ประโยชน์จากความสามารถของ skill เต็มรูปแบบจริงๆ

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

```bash
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 ทั่วไปหลังการนำเข้า:

```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 ตัวไหน:

```yaml
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 จะถูกกำหนดโดยอัตโนมัติ:

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

### เฟส 5: การสร้างไฟล์ที่ใช้งานได้จริง

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

```bash
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 รีโพซิทอรี เรารับเข้าใช้งาน skill มากกว่า 120 รายการครอบคลุมชีวสารสนเทศศาสตร์, เคมี, การประมวลผลควอนตัม และสารสนเทศศาสตร์คลินิก แต่ agent ส่วนใหญ่ของเราไม่ต้องการการจำลองการเข้าจับกันของโมเลกุล หรือการวิเคราะห์การแสดงออกของยีน

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

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

```yaml
# 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"

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

### วินัย

ข้อจำกัดเชิงพฤติกรรม: "ทำ X เสมอ", "ห้ามทำ Y", "ควรเลือก Z"

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

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

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

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

## เกณฑ์คุณภาพ

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

```yaml
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 รู้ว่าจะแนะนำมันเมื่อไหร่

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

```bash
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:

```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 รีโพใหม่ปรากฏขึ้น รูปแบบชุมชนเกิดขึ้น เวิร์กโฟลว์ภายในตกผลึก ลูปไม่เคยหยุด

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

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

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` เพื่อสำรวจรีจิสทรีปัจจุบันของเรา*