metal
정보
Metal 스킬은 코드베이스를 분석하여 표준화된 스킬, 에이전트, 팀 정의로 개념적 아키텍처를 추출합니다. 이는 구현 세부사항 없이 프로젝트의 목적(WHAT)과 역할(WHO)을 포착하여 조직적 패턴을 추상화합니다. 온보딩, 에이전트 시스템 부트스트랩, 또는 프로젝트의 DNA를 연구하여 영감을 얻는 데 사용하세요.
빠른 설치
Claude Code
추천npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/metalClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Metal
Extract conceptual DNA of repo → roles + procedures + coordination patterns as generalized agentskills.io defs. Like noble metal from ore, separate IS (essence) from DOES (impl) → reusable skill/agent/team defs capturing organizational genome w/o reproducing codebase.
Use When
- Onboard new codebase → map conceptual architecture before code
- Bootstrap agentic system from existing project — implicit workflows → explicit defs
- Study project's organizational DNA for cross-pollination
- Build skill/agent/team library inspired by reference, no copy
- Project structure reveals creators' mental models + domain expertise
In
- Required: Path to repo/project root
- Required: Purpose statement — why extract? (onboard/bootstrap/study/cross-pollinate)
- Optional: Focus domains (default: all)
- Optional: Output depth —
survey(prospect+assay),extract(full),report(extract+written) (default:extract) - Optional: Max extractions cap (default: 15)
Ore Test
Central quality criterion:
Could concept exist in completely different impl?
YES → metal (essence). Extract. NO → gangue (impl detail). Leave.
Ex: weather app's "integrate external data source" = metal (any third-party fetch). "parse OpenWeatherMap v3 JSON res" = gangue (one API).
Skills = CLASS of task not instance. Agents = ROLE not person. Teams = COORDINATION PATTERN not org chart.
Do
Step 1: Prospect — Survey Ore Body
Survey repo structure, no judgment. Map terrain before mining.
- Glob tree for shape:
- Source dirs + org pattern (feature/layer/domain)
- Config:
package.json,DESCRIPTION,setup.py,Cargo.toml,go.mod,Makefile - Docs:
README.md,CLAUDE.md,CONTRIBUTING.md, architecture - CI/CD:
.github/workflows/,Dockerfile, deploy configs - Tests + structure
- Read self-description (README, manifest) → declared purpose
- Count files by type/lang → scope + primary tech
- Boundary — begins/ends, deps vs. provides
- Prospect Report:
Project: [name]
Declared Purpose: [from README/manifest]
Languages: [primary, secondary]
Size: [file count, approx LOC]
Shape: [monorepo/library/app/framework/docs]
External Surface: [CLI/API/UI/library exports/none]
→ Factual survey. No classification yet. Reads like geological survey not review.
If err: no README/manifest → infer from dirs, file content, test descs. >1000 files → narrow to most active dirs (git log freq or README refs).
Step 2: Assay — Composition
Read representative files → conceptual DOES.
- Sample 5-10 representative files diverse, not exhaustive:
- Entry points (main, route handlers, CLI cmds)
- Core logic (most-imported/referenced)
- Tests (intent > impl)
- Config (operational + deploy ctx)
- Per area:
- Domains: subject areas ("auth", "data transformation", "reporting")
- Verbs: actions ("validate", "transform", "deploy", "notify")
- Roles: actors ("data engineer", "end user", "reviewer")
- Flows: sequences ("ingest → validate → transform → store")
- Classify each:
- Essential: any impl solving this would have
- Accidental: this impl's tech choices
- Assay Report: domains/verbs/roles/flows + tags
→ Conceptual map reads like domain glossary not code walkthrough. Tech-stack-naive reader understands.
If err: opaque codebase (heavy metaprogramming, generated, obfuscated) → tests + docs over source. No tests → commit msgs for intent.
Step 3: Meditate — Release Impl Bias
Pause + clear cognitive anchoring from reading code.
- Notice dominating framework/lang/pattern → label
- Release HOW: "uses React" → "has UI layer." "PostgreSQL" → "persistent structured storage."
- Apply Ore Test on Assay findings:
- "integrate external data source" → YES → metal
- "configure Axios interceptors" → NO → gangue
- Rewrite failures at higher abstraction
- Multi-perspective lenses:
- Archaeologist: structure → creators' mental models?
- Biologist: replicable genome vs. specific phenotype?
- Music theorist: form (sonata, rondo) vs. notes?
- Cartographer: which abstraction level → useful topology?
→ Assay free of framework-specific lang. All findings pass Ore Test. Concepts portable to any lang/framework.
If err: bias persists → invert: "If rewritten in completely different stack, which concepts survive?" Only those = metal.
Step 4: Smelt — Separate Metal from Slag
Core extraction. Classify into skill/agent/team.
- Per essential concept, type:
Classification Criteria:
+--------+----------------------------+----------------------------+----------------------------+
| Type | What to Look For | Naming Convention | Test Question |
+--------+----------------------------+----------------------------+----------------------------+
| SKILL | Repeatable procedures, | Verb-first kebab-case: | "Could an agent follow |
| | workflows, transformations | validate-input, | this as a step-by-step |
| | with clear inputs/outputs | deploy-artifact | procedure?" |
+--------+----------------------------+----------------------------+----------------------------+
| AGENT | Persistent roles, domain | Noun/role kebab-case: | "Does this require ongoing |
| | expertise, judgment calls, | data-engineer, | context, expertise, or a |
| | communication styles | quality-reviewer | specific communication |
| | | | style?" |
+--------+----------------------------+----------------------------+----------------------------+
| TEAM | Multi-role coordination, | Group descriptor: | "Does this need more than |
| | handoffs, reviews, | pipeline-ops, | one distinct perspective |
| | parallel workstreams | review-board | to accomplish?" |
+--------+----------------------------+----------------------------+----------------------------+
-
Per extracted:
- Generalized name — not project-specific. "UserAuthService" →
identity-manager(agent). "deployToAWS()" →deploy-artifact(skill). - One-line desc standalone-readable
- Source concept for traceability not reproduction
- Apply Ore Test final time
- Generalized name — not project-specific. "UserAuthService" →
-
Avoid classification errs:
- Not every fn = skill — look for PROCEDURES not single ops
- Not every module = agent — look for ROLES needing judgment
- Not every collab = team — look for COORDINATION w/ distinct specialties
- Most projects yield 3-8 skills, 2-4 agents, 0-2 teams. 20+ → too fine.
→ Classified inventory: type + generalized name + one-line desc. No source-specific tech/API/data refs.
If err: ambiguous (skill or agent?) → "DOING (skill) vs. BEING someone who does (agent)?" Skill = recipe, agent = chef. Unclear → default skill — easier to compose later.
Step 5: Heal — Verify Quality
Honest extraction — neither too much nor too little.
-
Over-extraction: per def:
- Reconstruct original proprietary logic? → too much detail
- Refs specific libs/APIs/schemas/paths? → still gangue
- Full impl proc or concept sketch? → should be sketch
-
Under-extraction: defs only (no source) ask:
- Understand KIND of project that inspired? → yes
- Capture essential nature? → yes
- Major capabilities missing? → no
-
Generalization: per def:
- Name in different stack? → yes
- Desc framework-agnostic? → yes
- Useful in completely different domain? → ideally yes
-
Balance: ratios:
- 3-8 skills, 2-4 agents, 0-2 teams = typical focused
- <3 total → under-extracted
-
15 → over-extracted or insufficient generalization
→ Confidence right abstraction. Each def = seed for different soil, not cutting only surviving original garden.
If err: over-extracted → raise abstraction, merge specifics, collapse similar agents. Under-extracted → Step 2 + sample more. Generalization fails → strip tech refs, rewrite.
Step 6: Cast — Pour Metal into Forms
Produce agentskills.io standard outputs.
- Per skill skeletal:
# Skill: [generalized-name]
name: [generalized-name]
locale: caveman-ultra
source_locale: en
source_commit: 82c77053
translator: "Julius Brussee homage — caveman"
translation_date: "2026-04-19"
description: [one-line, framework-agnostic]
domain: [closest domain from the 52 existing domains, or suggest a new one]
complexity: [basic/intermediate/advanced]
# Concept-level procedure (3-5 steps, NOT full implementation):
# Step 1: [high-level action]
# Step 2: [high-level action]
# Step 3: [high-level action]
# Derived from: [source concept in original project]
- Per agent skeletal:
# Agent: [role-name]
name: [role-name]
locale: caveman-ultra
source_locale: en
source_commit: 82c77053
translator: "Julius Brussee homage — caveman"
translation_date: "2026-04-19"
description: [one-line purpose]
tools: [minimal tool set needed]
skills: [list of extracted skills this agent would carry]
# Derived from: [source role/module in original project]
- Per team skeletal:
# Team: [group-name]
name: [group-name]
locale: caveman-ultra
source_locale: en
source_commit: 82c77053
translator: "Julius Brussee homage — caveman"
translation_date: "2026-04-19"
description: [one-line purpose]
lead: [lead agent from extracted agents]
members: [list of member agents]
coordination: [hub-and-spoke/sequential/parallel/adaptive]
# Derived from: [source workflow/process in original project]
- Compile all → Assay Report w/ Skills/Agents/Teams sections + summary table
→ Structured report w/ all defs in agentskills.io format. Each skeletal (concept not impl) → starting point for create-skill/create-agent/create-team.
If err: >15 items → priority by centrality, keep most unique to project's domain. Generic ("manage-configuration") drop unless unusual twist.
Step 7: Temper — Final Validation
Verify complete extraction + summary.
- Count: N skills, N agents, N teams
- Coverage: span major domains?
- Independence: read each w/o source ctx → stands alone?
- Final Ore Test on complete set:
Temper Assessment:
+-----+---------------------------+----------+------------------------------------+
| # | Name | Type | Ore Test Result |
+-----+---------------------------+----------+------------------------------------+
| 1 | [name] | skill | PASS / FAIL (reason) |
| 2 | [name] | agent | PASS / FAIL (reason) |
| ... | ... | ... | ... |
+-----+---------------------------+----------+------------------------------------+
- Final summary:
- Total (skills/agents/teams)
- Coverage (which domains represented)
- Confidence (high/med/low) + rationale
- Next steps: which defs ready to flesh out first
→ Validated Assay Report w/ table + confidence + actionable next steps. Self-contained — naive reader understands extracted concepts.
If err: >20% fail Ore Test → Step 4, re-extract higher abstraction. Coverage <60% → Step 2, sample more.
Check
- Prospect: structure, langs, size, declared purpose
- Assay: domains, verbs, roles, flows + essential/accidental
- Meditate: bias cleared, no framework-specific lang
- All elements pass Ore Test (essence not impl)
- Skills = verbs, agents = nouns, teams = group descriptors
- All names generalized — no project-specific refs
- Count in typical range (5-15 total, not 1, not 30)
- Outputs follow agentskills.io format (frontmatter + sections)
- Over + under-extraction checks pass
- Temper: count + coverage + confidence + next steps
- Complete report understandable w/o source
Traps
- Mirror dir structure: One skill per file → not cross-cutting concepts. Metal = CONCEPTUAL not filesystem. 20-file project ≠ 20 skills.
- Framework worship: "configure-nextjs-api-routes" instead of "define-api-endpoints". Strip framework, keep pattern. Ore Test catches: "Without Next.js?" No → gangue.
- Role inflation: Agent per module. Most projects = 2-5 genuine roles needing distinct expertise. Look JUDGMENT + COMMUNICATION STYLE differences, not just functional.
- Skip Ore Test: Biggest failure mode. Every output must pass: "Could concept exist in different impl?" Refs specific libs/APIs/schemas → slag.
- Impl guides: Skills = CONCEPT-LEVEL sketches (3-5 steps), not full procs. Seeds for
create-skill, not finished. 50-step extraction = reproduction not essence. - Under-generalize names: "UserAuthService" = class. "identity-manager" = role. "manage-user-identity" = skill. Specific → universal.
- Ignore coordination: Teams hardest because coordination implicit. Look review workflows, deploy pipelines, data handoffs, approval chains.
→
athanor— when metal reveals project needs transformation not just essencechrysopoeia— value extraction at code level; metal = conceptual level above codetransmute— convert extracted concepts between domains/paradigmscreate-skill— flesh out extracted skill sketches → full SKILL.mdcreate-agent— flesh out extracted agent sketches → full agent defscreate-team— flesh out extracted team sketches → full team compositionsobserve— deeper observation when prospect reveals unfamiliar domainanalyze-codebase-for-mcp— complementary: metal extracts concepts, that extracts tool surfacesreview-codebase— complementary: metal extracts essence, that evaluates quality
GitHub 저장소
연관 스킬
content-collections
메타이 스킬은 콘텐츠 콜렉션(Content Collections)을 위한 프로덕션 검증된 설정을 제공합니다. 콘텐츠 콜렉션은 Markdown/MDX 파일을 Zod 검증이 포함된 타입 안전한 데이터 콜렉션으로 변환해주는 TypeScript 최우선 도구입니다. 블로그, 문서 사이트 또는 콘텐츠 중심의 Vite + React 애플리케이션을 구축할 때 타입 안전성과 자동 콘텐츠 검증을 보장하기 위해 사용하세요. Vite 플러그인 구성과 MDX 컴파일부터 배포 최적화 및 스키마 검증에 이르기까지 모든 것을 다룹니다.
polymarket
메타이 스킬은 개발자들이 Polymarket 예측 시장 플랫폼을 활용한 애플리케이션을 구축할 수 있도록 지원하며, 거래 및 시장 데이터를 위한 API 통합 기능을 포함합니다. 또한 WebSocket을 통한 실시간 데이터 스트리밍을 제공하여 실시간 거래와 시장 활동을 모니터링할 수 있습니다. 이를 통해 거래 전략을 구현하거나 실시간 시장 업데이트를 처리하는 도구를 생성하는 데 활용할 수 있습니다.
creating-opencode-plugins
메타이 스킬은 개발자들이 명령어, 파일, LSP 작업 등 25개 이상의 이벤트 유형에 연결되는 OpenCode 플러그인을 만들 수 있도록 돕습니다. JavaScript/TypeScript 모듈을 위한 플러그인 구조, 이벤트 API 명세, 구현 패턴을 제공합니다. OpenCode AI 어시스턴트의 라이프사이클을 사용자 정의 이벤트 기반 로직으로 가로채거나, 모니터링하거나, 확장해야 할 때 사용하세요.
sglang
메타SGLang은 RadixAttention 프리픽스 캐싱을 활용하여 JSON, 정규식, 에이전트 워크플로우를 위한 고속 구조화 생성에 특화된 고성능 LLM 서빙 프레임워크입니다. 특히 반복되는 프리픽스가 있는 작업에서 상당히 빠른 추론 속도를 제공하여 복잡한 구조화 출력 및 다중 턴 대화에 이상적입니다. 제약 디코딩이 필요하거나 광범위한 프리픽스 공유가 있는 애플리케이션을 구축할 때는 vLLM과 같은 대안보다 SGLang을 선택하십시오.
