npx @agent-native/skills add)한 문장으로 이 프로젝트가 뭘 하는지부터.
BuilderIO/skills = "코딩 에이전트에게 끼워 넣는, 잘 쓰인 지시문 카드 10장." 우리가 흔히 떠올리는 라이브러리는 함수·클래스 같은 '실행 코드'를 담는다. 그런데 이 레포가 담는 건 코드가 아니라 마크다운으로 쓴 '행동 지침'이다. 예를 들어 "응답 끝에 🟢/🟡/🔴 상태 줄을 붙여라", "외부 API를 다룰 땐 기억으로 추측하지 말고 공식 문서를 먼저 검색해 읽어라" 같은 규율을 SKILL.md라는 한 장짜리 파일에 적어 두고, 그걸 Claude Code·Codex·Cursor 같은 코딩 에이전트에 설치한다.
유능한 신입에게 회사의 모든 규정을 외우라고 하면 오히려 굳어서 판단을 못 한다. 대신 "코드 리뷰할 땐 이 카드, 계획 세울 땐 저 카드"처럼 꼭 필요한 순간에 꺼내 보는 짧은 카드를 주면, 신입은 핵심에서 실수하지 않으면서도 자기 머리로 생각할 여유를 남긴다.
BuilderIO/skills가 바로 그 '카드 묶음'이다. 카드 한 장 = SKILL.md 하나. 거대한 규정집(프레임워크)을 강요하지 않고, 원하는 카드만 골라 에이전트 주머니에 넣는다.
SKILL.md라는 마크다운 파일 한 장이다. 맨 위에 이름·설명을 적은 머리표(frontmatter)가 있고, 그 아래에 "언제 발동하고 무엇을 하라"는 지침을 적는다. Anthropic이 정립한 형식을 따른다.한 가지 짚을 것 — 이 레포는 Builder.io라는 알려진 회사의 공식 저장소다(라이선스에 "Copyright Builder.io" 명시). 2026년에 막 만들어진 신생 레포지만, "비주얼 개발 도구"를 만들던 회사가 이번엔 "AI 에이전트를 위한 비주얼 계획·리뷰 도구"를 들고 나온 것이라는 맥락 때문에 빠르게 주목받고 있다.
TrendShift 일간 12위 — 별 43개의 신생 레포가 트렌딩에 오른 이유.
2025~2026년은 "모든 개발자가 코딩 에이전트를 쓰는" 시대로 넘어가는 중이다. 그러자 곧바로 다음 질문이 따라왔다 — "에이전트를 어떻게 길들여 일관되게, 똑똑하게 일하게 만들까?" 그 답으로 'Agent Skills(에이전트 스킬)' 생태계가 폭발했고, GitHub 트렌딩에 'skills'라는 이름의 레포가 쏟아졌다. BuilderIO/skills는 그 흐름 위에서, 다음 다섯 가지로 눈길을 끈다.
Builder.io는 비주얼 CMS, Figma-to-code, 그리고 오픈소스 프레임워크 Qwik·Mitosis로 개발자 사이에서 이름값이 있는 회사다. 그런 회사가 직접 "에이전트 스킬"을 공개했다는 사실 자체가 신호다. 개인이 모은 잡다한 모음집과 달리, 회사가 자기 제품 라인의 일부로 관리하는 스킬이라는 점이 신뢰를 준다.
대부분의 스킬이 "이렇게 행동하라"는 텍스트 규율에 머무는데, 이 레포의 간판인 visual-plan·visual-recap은 한 걸음 더 간다. 평범한 텍스트 계획이나 코드 diff를 다이어그램·와이어프레임·API 명세·주석 코드가 들어간 인터랙티브 시각 문서(MDX)로 바꿔, 사람이 한눈에 검토·승인하게 만든다. "비주얼"이 정체성인 Builder.io다운 차별점이다.
Claude Code 전용이 아니다. 저장소에 .claude-plugin(Claude Code용)·.codex-plugin(OpenAI Codex용) 매니페스트가 함께 있고, 공유 .agents 경로로 Cursor·OpenCode·GitHub Copilot 등에도 설치된다. "내가 쓰는 에이전트가 무엇이든 같은 스킬을 쓴다"는 이식성이 강점이다.
README가 분명히 선을 긋는다: "거대한 프로세스 프레임워크가 아니다(They are not a giant process framework)." 규칙을 잔뜩 씌워 에이전트를 옭아매는 대신, 판단이 중요한 지점에만 얇게 개입한다. 도구가 비대해질수록 모델이 멍청해진다는 점을 정면으로 의식한 설계다.
npx @agent-native/skills add 한 줄이면 대화형 설치 마법사가 뜬다. 어떤 스킬을, 어떤 에이전트에, 사용자 단위인지 프로젝트 단위인지까지 물어보고 알아서 깔아 준다. 진입 장벽이 거의 없다.
| 스킬 모음집 | 성격 | 이 레포와의 차이 |
|---|---|---|
| anthropics/skills | Anthropic 공식 예제 | 문서·산출물(docx/pptx) 생성 중심. 이 레포는 '행동 규율 + 시각 계획'에 집중. |
| obra/superpowers | 방법론까지 포함한 큰 프레임워크 | '프로세스 체계'를 지향. 이 레포는 정반대로 '작게 조합'을 표방. |
| mattpocock/skills | 개인(맷 포콕)의 실전 스킬 | 한 사람의 .claude 디렉토리. 이 레포는 회사 공식 + 멀티에이전트. |
| BuilderIO/skills | 회사 공식 · 작고 조합 가능 | 판단 지점에만 얇게 개입 + visual-plan/recap이라는 시각 도구 차별화. |
이 레포의 진짜 가치는 스킬 개수가 아니라 각 스킬이 노리는 지점의 정확함이다. 토큰 비싼 모델은 판단에만 쓰고(efficient-frontier), 다른 에이전트 작업은 감사하고(agent-watchdog), 끝맺음은 상태 신호로 명확히 하고(quick-recap) — 에이전트 협업에서 실제로 자주 깨지는 곳만 골라 카드를 만들었다.
별이 43개에 불과하고, 릴리스도 아직 없으며(0.0.0), 커밋도 12개 안팎인 매우 초기 단계 레포다. 트렌딩에 오른 건 "막 떠오르는 것을 잡아낸다"는 TrendShift 특성과 Builder.io 브랜드 효과가 크다. 내용물 상당수(visual-plan/recap)는 자매 레포 BuilderIO/agent-native에서 자동 동기화되는 사본이라, 이 저장소 단독으로 모든 게 돌아가는 건 아니다. 성숙도를 기대하기보단 "방향과 설계 패턴을 배우는" 자료로 보는 게 맞다.
README · package.json · plugin.json · .github/workflows · scripts에서 직접 확인한 실제 구성.
먼저 마음의 준비 — 이 레포에는 백엔드·프론트엔드·데이터베이스 같은 전통적 '기술 스택'이 거의 없다. package.json엔 의존성이 한 줄도 없고, pnpm-workspace.yaml은 빈 파일이며, 실제 소스코드라곤 동기화 스크립트(.mjs) 하나뿐이다. 파일의 대부분이 마크다운(.md) 27개다. 그래서 여기서 말하는 '스택'은 "스킬을 어떻게 적고·묶고·배포하는가"의 도구들이다.
| 구성요소 | 무엇 | 역할 |
|---|---|---|
| Markdown | 스킬 본문 형식 | SKILL.md·README.md·references/*.md. 모든 지침이 사람이 읽는 마크다운. |
| YAML frontmatter | 스킬 머리표 | 파일 맨 위 --- name / description --- 블록. 에이전트가 "이 스킬 언제 쓰지?"를 판단하는 근거. |
| MDX (산출물) | visual-plan/recap 결과물 | 마크다운 + 컴포넌트. 다이어그램·와이어프레임을 품은 인터랙티브 문서로 렌더링. |
| 구성요소 | 역할 |
|---|---|
.claude-plugin/plugin.json | Claude Code 플러그인 매니페스트(이름·작성자·키워드). |
.codex-plugin/plugin.json | OpenAI Codex용 같은 역할의 매니페스트. |
agents/openai.yaml | 스킬별 Codex 어댑터 — 표시 이름·기본 프롬프트 같은 메타데이터. |
references/*.md | 긴 세부 규칙을 본문에서 분리(점진 공개). 예: wireframe.md(와이어프레임 품질 기준). |
| 구성요소 | 역할 |
|---|---|
GitHub Actions ci.yml | PR마다 npm run check 실행 — visual 스킬이 원본과 어긋났는지 검증. |
GitHub Actions update-...yml | 봇이 원본 레포 변경을 감지 → 동기화 → PR 생성 → 자동 머지(squash)까지. |
scripts/sync-...mjs | 유일한 실제 코드(Node ESM). BuilderIO/agent-native에서 visual-plan/recap을 복사 동기화. |
| 구성요소 | 역할 |
|---|---|
@agent-native/skills (npm CLI) | 권장 설치 도구. BuilderIO/skills를 읽어 내 에이전트에 설치. |
Vercel skills CLI | 대안 설치 — 스킬 폴더를 단순 복사(npx skills add BuilderIO/skills). |
| Plan MCP · agent-native.com | visual-plan/recap의 MDX 결과를 보는 호스티드 앱 + 연결용 MCP 서버. |
---로 감싸 적는 메타데이터 블록. 이 레포에선 name(스킬 이름)과 description(언제 쓰는지) 두 줄이 핵심이다. 에이전트는 이 description을 읽고 "지금 이 스킬을 꺼낼까?"를 판단한다 — 그래서 설명을 잘 쓰는 게 스킬 품질의 절반이다.스킬 한 장이 에이전트 행동을 바꾸기까지 — 그리고 두 레포가 자동으로 맞물리는 구조.
이 레포의 '아키텍처'는 서버·DB 다이어그램이 아니라 두 가지 흐름이다. (1) 스킬이 어떻게 내 에이전트에 들어가 행동을 바꾸는가, (2) 이 카탈로그 레포가 자매 레포와 어떻게 자동으로 동기화되는가. 먼저 전체 그림을 보고, 설치 흐름 한 줄기를 따라가자.
npx @agent-native/skills add 한 줄의 안쪽설치 명령 하나가 내부에서 어떤 순서로 도는지, 핵심만 따라간다.
① 카탈로그 읽기. 설치 CLI(@agent-native/skills)가 BuilderIO/skills 레포의 skills/ 폴더를 읽어 어떤 스킬이 있는지 목록을 만든다. 기본값으로 visual-plan·visual-recap을 맨 위에 추천한다.
② 대화형 선택. 어떤 스킬을, 어떤 에이전트(Claude Code/Codex/둘 다)에, 사용자 단위인지 프로젝트 단위인지 묻는다. 선택한 조각만 설치된다.
③ 복사. 고른 스킬의 SKILL.md와 딸린 references/·assets/를 내 컴퓨터의 .claude/skills(Claude 네이티브 경로)나 공유 .agents 경로로 복사한다.
④ 상시 지침 주입(선택). "항상 켜져 있어야 하는" 규율(예: quick-recap의 상태 블록 컨벤션)은 단순 복사로는 발동되지 않는다. 그래서 설치기가 관리형 AGENTS.md / CLAUDE.md 블록을 프로젝트에 넣어, 에이전트가 매번 그 지침을 읽도록 만든다.
⑤ 발동. 이제 에이전트는 작업 중 frontmatter의 description("이럴 때 쓰라")과 상황을 맞춰 보고 스스로 스킬을 꺼내 그 지침대로 행동한다. visual-plan을 골랐다면, 위험한 계획을 MDX 시각 문서로 써서 Plan 앱(MCP 연결)에서 사람이 검토하게 한다.
가장 중요한 통찰. 스킬은 코드가 아니다. SKILL.md 한 장의 frontmatter(name/description) + 본문 지침이 전부다. 긴 세부 규칙은 본문에 다 욱여넣지 않고 references/로 분리해, 에이전트가 필요할 때만 불러 읽게 한다(점진 공개, progressive disclosure). 실제 frontmatter는 이렇게 생겼다:
# 가장 단순한 스킬: quick-recap
---
name: quick-recap
description: Use when adding or following the red/yellow/green
final status block convention for agent responses.
---
# 긴 설명은 YAML 블록 스칼라(>-)로
---
name: read-the-damn-docs
description: >-
Use when implementing, integrating, upgrading, or debugging
third-party APIs, libraries, frameworks, CLIs, cloud services...
---
그리고 본문은 "무엇을 하라"를 명령형으로 짧게 적는다. quick-recap의 핵심부는 이렇다:
# Quick Recap — 모든 응답 끝에 상태 한 줄
🟢 요청한 작업을 끝냈을 때
🟡 비정상적 후속 작업이 남았을 때 (남은 항목 명시)
🔴 사용자 입력에 막혔을 때
# 규칙: 100자 이내, 맨 끝 줄에, 뒤에 아무것도 붙이지 말 것
같은 스킬을 Claude·Codex·Cursor 어디서든 쓰게 하려고 매니페스트를 에이전트별로 두고 본문은 공유한다. .claude-plugin/plugin.json과 .codex-plugin/plugin.json이 각 에이전트에 "이 묶음은 이런 스킬이다"를 알리고, 5개 스킬은 agents/openai.yaml이라는 얇은 어댑터로 Codex용 표시 이름·기본 프롬프트를 덧댄다. 본문(SKILL.md)은 하나로 공유하니 중복이 없다.
가장 흥미로운 운영 패턴. 간판 스킬 visual-plan/recap의 '원본'은 이 레포가 아니라 자매 레포 BuilderIO/agent-native에 있다. 이 레포는 그 단일 진실원(single source of truth)의 사본을 둘 뿐이다. 원본이 바뀌면 GitHub Actions 봇이 자동으로 ⑴ 변경 감지 → ⑵ 이 레포에 복사 → ⑶ PR 생성 → ⑷ squash로 자동 머지까지 한다. 실제로 클론해 보면 유일한 커밋의 작성자가 사람 아닌 builder-io-integration[bot]이다. 사람 손이 거의 닿지 않고 굴러가는 콘텐츠 파이프라인이다.
SKILL.md를 짧게 두고 긴 규칙(예: 와이어프레임 작성법)은 references/로 빼서, 에이전트가 토큰을 아끼며 필요한 만큼만 읽게 한다.agent-native 레포 한 곳이고, 이 레포의 것은 봇이 자동으로 맞춰 주는 사본이다. 원본만 고치면 사본이 따라온다.저장소를 열었을 때 어디부터 봐야 하는가 — 거의 전부가 마크다운이다.
구조는 단순하다. skills/가 본체(공개 스킬 10개)이고, 점(.)으로 시작하는 폴더들은 각 에이전트에 붙이기 위한 매니페스트, scripts/·.github/는 자동화 장치다. 공부 순서는 README.md → skills/quick-recap/SKILL.md(가장 짧음) → skills/visual-plan/(가장 김) 추천.
| 위치 | 역할 |
|---|---|
README.md | 전체 카탈로그와 설치법. 이 레포의 '얼굴' — 여기부터 읽는다. |
skills/*/SKILL.md | 스킬의 본체. frontmatter(이름·설명) + 본문 지침. 각 스킬당 한 장. |
skills/visual-plan/references/ | 긴 세부 규칙을 분리 보관(점진 공개). wireframe.md는 품질 기준 단일 진실원. |
.claude-plugin/ · .codex-plugin/ | 각 에이전트에 스킬 묶음을 등록하는 매니페스트. |
.github/workflows/ · scripts/ | 봇이 자매 레포에서 visual-* 스킬을 동기화·검증하는 자동화. |
이 레포에서 실제로 무엇을 배울 수 있는가 — 기술별 + 실습 아이디어.
가장 큰 배움. 에이전트의 능력을 늘리는 데 꼭 코드가 필요한 게 아니다. 명확하게 쓴 마크다운 한 장이 에이전트 행동을 바꾼다. 특히 frontmatter의 description을 어떻게 쓰느냐(언제 발동할지)가 스킬 품질의 절반이라는 점을 10개 예시로 배울 수 있다.
실습 아이디어: quick-recap과 read-the-damn-docs의 description을 나란히 놓고, "어떤 단어가 에이전트의 발동 판단을 돕는지" 분석해 본다.
visual-plan은 SKILL.md(489줄) + references/ 4개로 나뉘어 있다. 모든 규칙을 한 파일에 욱여넣지 않고 "먼저 요약, 필요할 때 세부"로 쪼갠 이유를 보면, 긴 지침을 어떻게 토큰 효율적으로 구조화하는지 배운다. 이건 사람용 문서 작성에도 그대로 통한다.
실습 아이디어: 내가 쓴 긴 가이드 문서 하나를 "핵심 1장 + 부록 N장"으로 분해해, 무엇을 본문에 남기고 무엇을 부록으로 뺄지 결정해 본다.
같은 콘텐츠를 여러 에이전트에 붙이는 법. .claude-plugin·.codex-plugin·공유 .agents 경로·agents/openai.yaml 어댑터를 비교하면, "본문은 공유, 껍데기만 에이전트별로"라는 이식성 설계를 익힌다. 플러그인·확장을 만들 때 두루 쓰이는 패턴이다.
실습 아이디어: 두 plugin.json을 diff로 비교해 어떤 필드가 같고 어떤 필드가 에이전트마다 다른지 표로 정리한다.
운영 자동화의 좋은 교본. .github/workflows/update-...yml은 repository_dispatch 신호를 받아 원본을 동기화하고, diff가 있으면 봇 계정으로 PR을 만들어 자동 머지까지 한다. "사람 없이 굴러가는 콘텐츠 파이프라인"을 한 파일로 본다.
실습 아이디어: 이 워크플로 yml을 한 줄씩 읽으며 "트리거 → 체크아웃 → 동기화 → PR → 머지" 단계가 어디인지 주석을 달아 본다.
efficient-fable·efficient-frontier가 담은 생각: 고비용 프런티어 모델은 계획·통합·최종 판정에만 쓰고, 토큰을 많이 먹는 탐색·코딩·테스트는 값싼 서브에이전트에 위임한다. agent-watchdog(감사)·quick-recap(상태 보고)과 합치면 여러 에이전트가 협업할 때 비용과 품질을 동시에 잡는 패턴이 보인다.
실습 아이디어: 내 작업 하나를 "판단 단계"와 "노가다 단계"로 나눠, 어디를 비싼 모델에, 어디를 싼 모델/도구에 맡길지 설계해 본다.
무엇이 있어야 쓸 수 있나 — 빌드도, GPU도, 서버도 없다.
좋은 소식 — 깔 게 거의 없다. 이 레포 자체는 빌드가 필요 없는 마크다운 묶음이라, 설치기를 돌릴 Node.js와 스킬을 쓸 코딩 에이전트 하나만 있으면 된다. 무거운 건 전부 그 에이전트(와, 선택적으로 visual 앱)가 담당한다.
| 항목 | 요구사항 / 비고 |
|---|---|
| Node.js | 설치 CLI(npx @agent-native/skills)와 동기화 스크립트 실행용. (CI는 Node 22 사용) |
| 코딩 에이전트 | Claude Code · OpenAI Codex · Cursor · OpenCode · GitHub Copilot 등 1개 이상. |
| git | 레포를 직접 클론해 살펴보거나 Vercel skills CLI로 폴더 복사 시. |
| GPU / 서버 / DB | 전부 불필요. 스킬은 텍스트 지침이라 그 자체로는 연산이 없다. |
| Plan MCP + 호스티드/로컬 Plan 앱 | visual-plan/recap을 쓸 때만 필요. MDX 결과를 보는 앱과 연결용 MCP 커넥터. 호스티드 모드는 무료·오픈소스. |
처음이라면 quick-recap·read-the-damn-docs처럼 의존성 없는 텍스트 스킬부터 깔아 보라 — 에이전트와 Node만 있으면 1분이면 된다. visual-plan/recap은 Plan 앱·MCP 연결이 추가로 필요하니, 텍스트 스킬로 감을 잡은 뒤 시각 기능은 한 단계 더 들어갈 때 붙이는 게 매끄럽다.
난이도별로 — 직접 설치해 에이전트 행동이 바뀌는 걸 봐야 감이 온다.
먼저 설치 명령부터. 이게 사용의 전부다 — 빌드도 설정 파일도 없다.
# 텍스트 스킬 하나만 콕 집어 설치(대화형 마법사 건너뛰기)
npx @agent-native/skills add --skill quick-recap
# visual-recap + PR 비주얼 리캡 깃허브 액션까지 함께
npx @agent-native/skills add --skill visual-recap --with-github-action
# 대안: Vercel 'skills' CLI로 스킬 폴더만 단순 복사
npx skills add BuilderIO/skills --skill quick-recap
quick-recap을 설치하고(필요하면 관리형 CLAUDE.md 블록 포함), 에이전트에게 아무 작업이나 시켜 본다. 응답 끝에 🟢/🟡/🔴 상태 줄이 붙는지, 막혔을 때 🔴이 뜨는지 관찰한다. "스킬 한 장이 출력 형식을 바꾼다"를 체감하는 가장 빠른 길.
read-the-damn-docs를 설치한 뒤, 잘 모르는 외부 라이브러리 사용법을 물어본다. 에이전트가 기억으로 지어내는 대신 공식 문서를 먼저 검색해 읽는지 지켜본다. 설치 전후의 답변 품질을 비교하면 효과가 또렷하다.
이 레포의 형식을 흉내 내 직접 스킬을 만든다. frontmatter(name/description) + 본문 지침을 적어 .claude/skills에 넣고 발동시켜 본다. description을 어떻게 써야 원하는 순간에 발동하는지 직접 실험한다.
---
name: my-commit-style
description: Use when writing git commit messages for this repo.
---
# My Commit Style
- 제목은 50자 이내, 명령형(動詞로 시작)
- 본문은 "왜"를 설명, "무엇"은 diff가 말하게
visual-recap을 --with-github-action으로 설치해, 내 저장소의 PR에 자동 비주얼 리캡(주석 diff·다이어그램·파일맵)이 붙게 한다. 평범한 코드 diff가 사람이 한눈에 검토할 수 있는 시각 문서로 바뀌는 걸 본다. (Plan 앱 연결이 필요하다.)
efficient-frontier 스킬을 읽고, 내 멀티스텝 작업 하나를 "판단(비싼 모델)"과 "노가다(싼 서브에이전트)"로 분리해 실제로 돌려 본다. 비싼 모델을 계획·통합·최종 리뷰에만 쓰면 비용이 얼마나 줄고 품질은 유지되는지 측정한다.
이 레포를 발판으로 'Agent Skills 잘 만들기'까지 — 6주 계획.
| 주차 | 주제 | 학습 자료 / 할 일 |
|---|---|---|
| 1주차 | Agent Skills 기초 | SKILL.md·frontmatter 형식 이해. Anthropic Agent Skills 문서 + 이 레포 quick-recap 설치. |
| 2주차 | 10개 스킬 정독 | 이 레포 스킬을 전부 읽고 description 작성 패턴 분석. "언제 발동"을 어떻게 적는가. |
| 3주차 | 점진 공개 설계 | visual-plan의 SKILL.md + references/ 분리 구조 분석. 긴 지침 쪼개기 연습. |
| 4주차 | 멀티에이전트 패키징 | .claude-plugin·.codex-plugin·.agents·openai.yaml 비교. 내 스킬을 두 에이전트에 붙이기. |
| 5주차 | CI 자동화 | GitHub Actions(repository_dispatch·자동 PR·머지) + Node ESM 스크립트 읽기. |
| 6주차 | 오케스트레이션 & MCP | efficient-fable/frontier 패턴 + MCP·MDX visual-plan 생태계. 비용-품질 분리 실험. |
문서·코드에 자주 나오는 용어 — 한 줄 정의.
| 용어 | 의미 |
|---|---|
| Coding Agent | 스스로 코드를 읽고·쓰고·실행하는 AI 도구(Claude Code·Codex·Cursor 등). |
| Agent Skill | 에이전트 행동을 바꾸는 설치형 능력 묶음. 핵심은 SKILL.md 한 장. |
| SKILL.md | 스킬 본체. frontmatter(이름·설명) + 본문 지침을 담은 마크다운. |
| frontmatter | 파일 맨 위 --- 메타데이터. name·description 두 줄이 핵심. |
| description (트리거) | "이럴 때 쓰라"는 한 줄. 에이전트가 스킬 발동을 판단하는 근거. |
| Composable | 레고처럼 작은 조각만 골라 끼우는 성질. 묶음 강요 없음. |
| Progressive Disclosure | 요약 먼저, 세부는 필요할 때. SKILL.md + references/ 분리. |
| Plugin Manifest | .claude-plugin/.codex-plugin의 plugin.json. 에이전트에 스킬 묶음을 등록. |
| .agents 경로 | 여러 에이전트가 공유하는 스킬 설치 폴더(Cursor·OpenCode·Copilot 등). |
| MCP | 에이전트와 외부 도구를 잇는 표준 단자. visual-plan을 Plan 앱에 연결. |
| MDX | 마크다운 + 컴포넌트. visual-plan/recap의 인터랙티브 결과물 형식. |
| GitHub Actions | 저장소 이벤트에 반응해 자동 실행되는 워크플로. 여기선 동기화 봇. |
| repository_dispatch | 외부 신호로 워크플로를 깨우는 트리거. 원본 변경 알림에 쓰임. |
| Single Source of Truth | 원본 한 곳만 진짜로 삼는 원칙. visual-* 원본은 agent-native 레포. |
| Orchestration | 비싼 모델은 판단에, 싼 에이전트는 노가다에 — 역할 분담(efficient-*). |
| Builder.io | 비주얼 CMS·Qwik·Mitosis를 만든 회사. 이 레포의 공식 소유자. |
원문으로 더 깊이 — 공식 소스 위주.
npx @agent-native/skills add · npm @agent-native/skills