Skill Mining: Mula sa 3,500 Kandidato Papunta sa 466 Kakayahan

Ang mga numero sa post na ito ay sumasalamin sa system noong publication (Enero 2026). Tingnan ang aming team page para sa kasalukuyang mga figure.

Ang Problema ng 3,500 Skill

Nang magsimula kaming bumuo ng agent orchestration system, hinarap namin ang isang interesting na hamon: may libo-libong potensyal na skill na nakakalat sa buong AI ecosystem. GitHub repositories, vendor documentation, community projects, internal patterns - saan-saan meron mga skill. Pero alin ang mahalaga? Alin ang gumagana? At paano ka magpapanatili ng coherent na skill library na talagang magagamit ng mga agent?

Ang sagot namin: isang sistematikong mining at ingestion loop.

Ang mga Numero Ngayon

Tatlong buwan lamang matapos ilunsad ng Anthropic ang Agent Skills noong Oktubre 16, 2025, ganito ang aming kalagayan nang ma-publish ang post na ito noong Enero 27, 2026:

Metric	Bilang
Nakilalang candidates	3,500+
Inampong skills	466
Mga skill mula sa vendor	373
Panloob na mga skill	93
Aktibong vendors	25+
Average na tokens bawat skill	2,834
Na-reference na tools	89
Natatanging tags	635

Sinuri namin ang mahigit 3,500 skill candidate. Inampon namin ang 466. Iyon ay 13% na adoption rate - at sinadya ang selectivity na iyon.

Ang Knowledge Tier System

Hindi magkapareho ang lahat ng skill. Ino-organisa namin sila sa limang knowledge layer (K0-K4), bawat isa kumakatawan sa ibang scope ng applicability:

K0: Mga pundasyon (universal)

Mga skill na dapat meron ang bawat agent. Kumakatawan ang mga ito sa “good thinker” na capabilities na gumagana kahit saan.

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

Portable ang mga K0 skill sa anumang project, anumang domain, anumang stack. In-encode nila ang universal cognitive patterns.

K1: Mga identity (disiplina)

Mga “good engineer” o “good researcher” na skill na umaapply sa mga project sa loob ng isang discipline.

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

K2: Mga domain (dalubhasang paksa)

Mga “good database expert” o “good security engineer” na skill na portable sa loob ng isang field.

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: Mga stack (teknolohiya)

Mga “good Supabase user” o “good Cloudflare developer” na skill para sa specific na technology stacks.

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

K4: Proyekto (organisasyon)

Mga skill na specific sa organisasyon at workflows namin.

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

Ang Mining Loop

Yugto 1: Pagtuklas

Galing kahit saan ang mga skill:

Vendor Repositories: Naglalathala ng skill collections ang AWS, Anthropic, Cloudflare, Supabase, at mga community contributor. Sinusubaybayan namin ang 25+ vendor root.

Mga community project: Puno ang GitHub ng mga Claude Code template, agent pattern, at workflow definition.

Internal Patterns: Habang nireresolba ng team namin ang mga problema, lumalabas ang mga pattern. Nagiging formalized ang mga ito papunta sa mga skill.

Documentation Mining: Madalas may implicit na skills ang technical documentation - mga procedure, checklist, decision tree.

Tuloy-tuloy ang pagtuklas. Gumagamit kami ng skill backlog para subaybayan ang mga candidate bago ang formal evaluation.

Yugto 2: Pagsusuri

Dumadaan ang bawat candidate sa parehong rubric:

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

Dapat pumasa ang lahat ng limang product criteria. Kaya naman 87% ng mga candidate ang tinatanggihan.

Tapos dumadaan ang bawat candidate sa hiwalay na trust review. Hindi namin tinuturing na katumbas na source of truth ang isang official vendor repository, isang kilalang community maintainer, at isang random na 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

Nakakakuha ng mas magaan na provenance review ang mga trusted vendor, pero hindi ito free pass. Nakakakuha ng mas malalim na manual audit ang mga untrusted o unknown na source, at hindi namin pinapatakbo ang mga bundled script hangga’t hindi ito nababasa, na-scope, at na-classify na safe.

Pagsusuri ng gap: Bago mag-adopt, sini-search namin ang registry:

uv run orkestra skills search "<capability>"

Kung meron na kami niyan, hindi na namin kailangan. Kung may malapit kaming meron, baka mag-merge kami sa halip na mag-adopt.

Depth at Standards Scoring: Sini-score rin namin kung gaano kalubos ginagamit ng isang candidate ang agent-skill model. Puwede pa ring maging kapaki-pakinabang ang nag-iisang SKILL.md, pero mas mahalaga ang mas malalim na mga skill kapag hinihiwalay nila ang instructions mula sa references, scripts, at assets sa paraang hinihikayat ng 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

Puwedeng kaunting umangat ang credibility score dahil sa GitHub stars, pero hindi nila kailanman naililigtas ang isang mababaw o hindi ligtas na skill. Ang isang repo na maraming star na may isang malabo na SKILL.md at opaque na scripts, mas mababa ang score kaysa sa isang mas maliit na repo na may precise na deskripsyon, curated na references/, at atomic na mga helper na talagang lumelevereyds sa buong skill capability.

Structural Analysis: Chine-check namin ang kalidad ng skill:

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

Kung may kasamang scripts ang isang candidate, mas mahigpit ang review na iyon. Ang isang magandang skill, hindi lang kapaki-pakinabang; kailangan din itong legible, bounded, at ligtas na maiabot sa isang agent. Ang safety filter na iyon lang, nagdi-disqualify na ng makabuluhang bahagi ng kung hindi man ay interesting na candidates.

Yugto 3: Pag-ingest

Kapag pumasa sa evaluation ang isang skill, papasok ito sa registry. Pero hindi kailanman inaampon ang mga skill nang hindi binabago. Binabago sila para umangkop sa system namin.

Mga Pagbabago sa Adoption:

1. Metadata Normalization: Nakukuha ng bawat skill ang frontmatter schema namin
2. Pagtatalaga ng K-tier: Inilalagay ang mga skill sa naaangkop na knowledge layer
3. Pagpapayaman ng tag: Nagdaragdag ng tags para sa discovery
4. Deklarasyon ng tool: Explicit na na-declare ang mga allowed tool
5. Pag-align ng seksyon: Muling in-a-istruktura ang content para tumugma sa template namin

Isang karaniwang skill YAML pagkatapos ng ingestion:

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

Yugto 4: Pagtatalaga ng saklaw

Ini-assign ang mga skill sa mga scope - mga kategorya na tumutukoy kung aling agent ang naglo-load ng aling 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

Idine-declare ng mga agent ang scope nila, at automatic na ina-assign ang mga skill:

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

Yugto 5: Pag-materialize

Hindi nakatira bilang YAML ang mga skill sa production. Ini-render sila papunta sa mga SKILL.md file na puwedeng i-load ng Claude Code:

uv run orkestra sync

Ang command na ito:

1. Binabasa ang lahat ng skill YAML definition
2. Ini-render ang mga ito sa pamamagitan ng Jinja templates
3. Isinusulat ang mga SKILL.md file papunta sa .claude/skills/
4. Ino-organisa ayon sa K-tier (foundations/, identities/, domains/, stacks/, project/)

Ang huling output structure:

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

Ang Dormant Scope Pattern

Isa sa pinakamalakas naming pattern, ang “adopted-but-not-loaded” na mga skill. Tinatawag namin itong dormant scopes.

Isipin ang mga scientific computing skill mula sa k-dense-scientific repository. Nag-adopt kami ng 120+ na skill na sumasaklaw sa bioinformatics, chemistry, quantum computing, at clinical informatics. Pero karamihan sa mga agent namin, hindi kailangan ng molecular docking o gene expression analysis.

Sa halip na i-load ang lahat ng 120 skill sa bawat agent (na nagpapalaki sa context windows), kami ay:

1. Nag-a-adopt ng mga skill na may specific na scope (halimbawa, bioinformatics)
2. Pinapanatili silang dormant - registered pero hindi naka-load
3. Ina-enable lang sila kapag nag-declare ang isang agent ng scope na iyon

# 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

Dahil sa pattern na ito, kaya naming magkaroon ng 466 skill sa registry habang karaniwang 40-60 relevant na skill lang ang naglo-load ang mga typical na agent.

Mga Uri ng Skill

Dumarating ang mga skill sa tatlong cognitive pattern:

Workflow (daloy ng trabaho)

Ordered na procedural na mga hakbang: “1. Gawin ang X, 2. Tapos ang Y, 3. Sa wakas ang Z”

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

Discipline (disiplina)

Behavioral na mga guardrail: “Palaging X”, “Huwag kailanman Y”, “Mas piliin ang Z”

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

Checklist (listahan ng pagsusuri)

Mga verification criteria: “Kumpirmahin ang X”, “I-verify ang Y”, “I-check ang Z”

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

Mga gate ng kalidad

Kailangang pumasa ang bawat skill sa validation bago ito magship:

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

Kailangang 50-400 characters ang mga deskripsyon na may trigger phrases (“Gamitin kapag…”, “Kapag kailangan mo ng…”) para malaman ng Claude Code kung kailan sila imumungkahi.

Tuloy-tuloy naming vina-validate ito:

uv run orkestra validate --show-warnings

Ang Vendor Ecosystem

Ang 373 vendor skills namin, galing sa:

Provider	Skills	Domain
AWS Agent	19	Mga serbisyo sa cloud
Anthropic	12	Pagbuo ng dokumento
Cloudflare	8	Edge computing
Supabase	5	Base ng Datos
k-dense	100+	Siyentipikong computing
silvainfm	4	Agham ng datos
Java Developer Kit	45+	Spring/Java
Vercel	1	Automation ng browser

Idine-declare ang bawat vendor root sa 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

Kapag pumapatakbo ang orkestra sync, sini-symlink ang mga vendor skill papunta sa .claude/skills/vendor/ kasama ang provider namespace nila.

Ano ang Natutunan Namin

May bunga ang selectivity. Nakakatukso na i-adopt ang lahat ng mukhang kapaki-pakinabang. Pero may halaga sa tokens ang bawat skill. Sa 2,834 average na token kada skill, mabilis na nasasaktan ang bloat. Pinapanatili ng 13% na adoption rate namin ang mga agent na lean.

Nagbibigay-daan ang structure sa discovery. Hindi lang organisasyon ang K-tier system - tungkol ito sa portability. Puwedeng magamit muli ang mga K0 skill kahit saan. Sinadyang project-specific ang mga K4 skill. Tinutulungan ng kalinawang ito ang parehong tao at agent na mahanap ang kailangan nila.

Nag-sscale ang dormant scopes. Puwede kang mag-adopt ng daan-daang skill nang hindi ini-load ang lahat ng ito. Hinahayaan ka ng scopes na bumuo ng comprehensive na registry habang pinapanatiling manageable ang context windows ng indibidwal na agent.

Mahalaga ang modification on adoption. Bihirang umangkop ang raw na vendor skills sa system mo. Ang ingestion process - pagdagdag ng metadata, pag-assign ng tiers, pagpapayaman ng tags - ang gumagawa sa external na skills na gumana internally.

Tuloy-tuloy ang mining. Patuloy na lumalaki ang numerong 3,500. May lumalabas na bagong vendor repos. Umuusbong ang community patterns. Lumalakas ang internal workflows. Hindi kailanman huminto ang loop.

Ano ang Susunod

Nagtatrabaho kami sa ilang improvement:

1. Awtomatikong pagtuklas ng gap: Mag-alerto kapag puwedeng masolusyunan ng isang hindi pa inampong skill ang mga karaniwang agent failure
2. Workflow para sa pag-deprecate ng skill: Formal na proseso para sa pagretiro ng mga skill na na-supersede o hindi na ginagamit
3. Dependency sa pagitan ng skill: Explicit na declaration ng mga skill prerequisite
4. Analytics ng paggamit: Subaybayan kung aling mga skill ang talagang tinatawag ng mga agent kumpara sa i-load lang

Infrastructure ang skill mining loop. Hindi ito kaakit-akit. Pero ito ang gumagawa sa 41 agent na gumana nang coherent kasama ang 466 capabilities habang nananatili sa loob ng context limits.

Iyon ang kwento kung paano naging 466 ang 3,500. Hindi sa pamamagitan ng pagbalewala sa 3,000 - sa pamamagitan ng sistematikong pagsuri sa kanila at pag-a-adopt lang ng gumagana.

---

Gustong makita ang skill system sa aksyon? Tingnan ang uv run orkestra skills list para i-explore ang kasalukuyang registry namin.