Google이 직접 만든 안드로이드 에이전트 스킬 33개, R8부터 Compose까지

에이전트가 아는 안드로이드는 학습이 끝난 날의 안드로이드이고, android/skills가 담은 안드로이드는 10월 22일까지 고쳐진 안드로이드입니다. 스킬 33개의 머리말에 적힌 갱신일 가운데 가장 늦은 날이 10월 22일이고, 22개가 10월에 고쳐졌습니다. Google이 Apache-2.0 라이선스로 GitHub에 공개한 이 저장소는 10월 27일(UTC) 기준 별이 약 9,800개, 포크가 635개이고, 최신 릴리스는 10월 23일 14:35 UTC에 나온 v1.0.17입니다. README가 밝힌 선정 기준은 평가에서 LLM이 부진한 사용 사례와 워크플로를 먼저 다룬다는 것이고, 기본적인 Compose 모범 사례처럼 모델이 이미 잘하는 곳은 일부러 뒤로 미뤘다고 합니다.

33개를 순서대로 소개하면 목록이 될 뿐이라서, 이 글은 먼저 폴더를 열어 모양으로 나누고, 영역으로 한 번 더 묶은 다음, 성격이 극단인 스킬 몇 개만 골라 안을 들여다봅니다. 폴더 구성과 줄 수는 v1.0.17 저장소를 10월 27일에 직접 받아 센 값입니다.

폴더 세 개를 열어 보면 같은 이름 아래 모양이 이렇게 다르다

모든 스킬은 SKILL.md가 있는 폴더 하나입니다. 그런데 SKILL.md 하나만 있는 폴더, 참고 문서가 줄줄이 딸린 폴더, 파이썬 코드까지 든 폴더가 섞여 있습니다. 아래 그림의 가운데 열 노란 scripts/는 SKILL.md가 부르지만 저장소에는 없는 폴더이고, 나머지는 실제 폴더 구성입니다.

그림 1. 스킬 폴더의 세 가지 모양. 가운데 열의 scripts/는 SKILL.md가 부르지만 저장소 트리에는 없는 폴더

왼쪽 edge-to-edge는 426줄짜리 SKILL.md 한 장이 전부입니다. 계획, 적용, 키보드, 목록, 대화상자, 체크리스트가 모두 그 안에 있어서 스킬이 켜지면 한 번에 통째로 읽힙니다. 가운데 r8-analyzer는 본문이 69줄로 짧고, 세부는 references/의 문서 8개로 보냅니다. 에이전트는 본문이 가리키는 문서만 그때그때 엽니다.

오른쪽 play-policy-insights는 사정이 다릅니다. 본문 169줄이 에이전트에게 시키는 일은 “scripts/orchestrator.py를 먼저 돌려라”입니다. 이 스크립트가 코드를 정적 분석해 감사 목표를 정하고, 목표마다 하위 에이전트용 프롬프트를 만듭니다. 하위 에이전트를 쓸 수 있는 환경이면 동시에 3개까지 나눠 맡기고, 못 쓰면 에이전트가 프롬프트 파일을 순서대로 직접 읽고 수행합니다. 스크립트가 실패하면 수동 감사로 대신하지 않고 이유를 설명하며 멈추라고 못 박아 두었고, 끝에는 compliance_report.md가 나옵니다. 같은 “스킬”이어도 이쪽은 설명서라기보다 작은 실행 도구에 가깝습니다.

본문 줄 수와 딸린 파일 수로 33개를 펼치면

모양을 숫자로 바꾸면 33개가 한 장에 올라갑니다. 가로축은 SKILL.md의 줄 수, 세로축은 같은 폴더에 있는 다른 파일 수입니다. 점선은 편집부가 임의로 그은 기준(300줄, 파일 15개)이며 공식 구분이 아닙니다.

그림 2. 33개 스킬의 본문 길이와 딸린 파일 수. 점선 기준은 편집부가 정함(300줄, 15개). 빨간 점은 본문에서 따로 다루는 스킬

점이 몰린 곳은 아래쪽입니다. 본문이 짧고 파일도 적은 스킬이 16개, 본문이 길고 파일은 거의 없는 스킬이 11개로 합쳐 27개입니다. 파일이 15개를 넘는 것은 6개뿐이고, 그중 glance-canonical-layouts가 245줄 본문에 다른 파일 87개로 가장 많이 거느립니다. 홈 화면 위젯 레이아웃 예제가 파일마다 들어 있는 구조입니다. 폴더가 가장 풍성한 스킬이 본문은 중간 길이라는 점이 눈에 띕니다.

왼쪽 위 navigation-3(119줄, 파일 27개)과 android-profiler(57줄, 파일 25개)는 본문이 안내판 노릇을 합니다. navigation-3의 본문은 이관 가이드, 문서, 레시피 24개를 한 줄 설명과 함께 줄 세운 목차이고, android-profiler는 요청이 모호하면 사용자에게 먼저 묻고, 기록이면 recording_orchestrator로, 분석이면 analysis_orchestrator로 보냅니다. 이런 스킬은 읽히는 양이 작아서 스킬을 많이 설치해 둘 때 부담이 적습니다.

오른쪽 아래 끝에는 android-cli(755줄)가 있고, 그 왼쪽에 leanback-to-compose-tv-migration(740줄), android-permissions-security(602줄), display-glasses-with-jetpack-compose-glimmer(598줄), android-intent-security(550줄)가 있습니다. Agent Skills 표준 문서가 SKILL.md를 500줄 안쪽으로 두라고 권하는데, 이 선을 넘는 스킬이 정확히 5개입니다. 안드로이드 문서가 권하는 본문 분량도 1만~2만 자인데, 가장 긴 android-cli의 SKILL.md는 3만 7천 바이트가 넘습니다. 다만 edge-to-edge와 android-intent-security처럼 본문 대부분이 올바른 예와 잘못된 예의 코드인 스킬도 있어서, 줄 수만으로 좋고 나쁨을 가를 수는 없습니다.

영역으로 묶으면 화면 쪽이 4분의 1을 차지한다

폴더를 영역으로 묶어도 지도가 하나 나옵니다. 저장소의 18개 폴더를 편집부가 일곱 영역으로 묶어 세어 본 것입니다.

그림 3. 영역별 스킬 수(편집부 묶음, 33개 기준). 가장 큰 조각이 화면 쪽 8개(24%)

가장 큰 조각은 화면 쪽 8개(24%)입니다. Compose 폴더의 반응형 UI·성능·XML 이관·스타일, 내비게이션 폴더의 navigation-3과 navigation-event, 시스템 폴더의 edge-to-edge와 위젯 레이아웃이 여기에 듭니다. 다음은 빌드·성능·테스트·도구가 6개(AGP 이관, R8, ANR, 프로파일러, 테스트 구성, CLI)이고, 기기 형태 쪽(Wear OS, XR 안경, TV, 자동차)도 6개입니다. 기기 안 AI(appfunctions, litert-lm, litert-runtime, ML Kit 프롬프트 API)는 4개, 보안은 2개입니다. 기본기보다 단계가 길고 버전에 민감한 일이 많은 영역에 스킬이 모여 있고, “버튼 색 바꾸기” 같은 일상 작업을 다루는 스킬은 보이지 않습니다. 선정 기준이 지도에 그대로 찍힌 셈입니다.

설치 길 셋과 스킬이 떨어지는 폴더

하나를 골라 내 프로젝트에 넣는 가장 짧은 순서는 이렇습니다.

1. android update로 Android CLI를 최신으로 맞춘다
2. android skills list로 이름을 확인한다
3. android skills add r8-analyzer --project=.처럼 스킬 이름과 프로젝트 경로를 준다
4. 에이전트에게 평소 말투로 요청한다. 예를 들어 "앱 UI를 edge-to-edge로 만들어 줘"

3번의 --project를 빼면 전역에 설치되고, --agent=claude처럼 쉼표로 에이전트를 지정할 수 있으며, 지정하지 않으면 감지된 모든 에이전트가 대상입니다. 감지된 에이전트 폴더가 하나도 없고 지정도 안 하면 Gemini와 Antigravity용 경로(~/.gemini/antigravity/skills)에 깔립니다. README는 --all을 빼면 android-cli 스킬만 설치된다고 적고, 전부 받으려면 --all을 붙입니다. 이미 설치한 스킬에 add를 다시 하면 최신으로 덮어쓰이므로 고쳐 쓰려면 폴더 이름부터 바꿔야 합니다.

Claude Code와 Codex를 쓰면 플러그인으로 저장소째 받는 길도 있습니다.

/plugin marketplace add android/skills
/plugin install android-skills@android-skills

Codex는 codex plugin marketplace add android/skills와 codex plugin add android-skills@android-skills입니다. 세 번째 길은 Android Studio입니다. 저장소에서 스킬을 내려받아 프로젝트 루트나 홈 폴더의 .agents/skills 또는 .android-studio/skills에 두고, 에이전트 모드 입력창에서 @를 쳐 직접 부를 수도 있습니다. 예전 Studio가 쓰던 .skills, agent/skills는 Quail 1 이후 새 위치로 옮기라고 문서(9월 25일 갱신)가 안내합니다. 한편 직접 쓰는 방법을 다룬 안드로이드 스킬 문서는 프로젝트 루트의 .skills/ 또는 .agent/skills/를 적고 있어서, 문서마다 폴더 이름이 다릅니다. 쓰는 도구의 버전에 맞는 문서를 따르면 됩니다.

agp-9-upgrade: 일을 시작하기 전에 멈추는 스킬

폴더 모양이 평범한 스킬 중에는 지침의 성격이 독특한 것이 있습니다. agp-9-upgrade는 103줄 본문의 첫 규칙이 “프로젝트의 AGP 버전을 먼저 보고, 9 미만이면 멈춰라”입니다. 멈춘 에이전트는 Android Studio의 AGP 업그레이드 도우미를 먼저 실행하고 끝나면 알려 달라고 사용자에게 요청합니다. 사용자가 이 단계를 건너뛰자고 하면 그때서야 AGP를 최신 안정 버전으로 올리는 일까지 맡습니다. 한 번에 두 단계를 건너뛰는 에이전트의 사고를 문장 하나로 막는 설계입니다.

AGP가 이미 9 이상일 때의 본 절차는 여섯 단계입니다. KSP는 2.3.6 이상, Hilt는 2.59.2 이상인지 확인하고, 내장 Kotlin으로 옮기고, 새 DSL로 옮기고, kapt는 KSP나 legacy-kapt로 바꾸고, 사용자 정의 BuildConfig 필드가 있으면 전용 문서대로 처리한 뒤, gradle.properties의 임시 플래그 네 개(android.builtInKotlin, android.newDsl, android.uniquePackageNames, android.enableAppCompileTimeRClass)와 에이전트가 만든 임시 파일을 지웁니다. 검증은 Studio 동기화, ./gradlew help, ./gradlew build --dry-run 세 가지입니다.

이 스킬에서 읽을 만한 것은 “하지 말 것” 네 줄입니다. 파이썬 스크립트를 쓰거나 돌리지 않는다, 의존성 캐시는 외부 라이브러리 확인에만 최후 수단으로 본다, android.disallowKotlinSourceSets=false를 넣지 않는다, 검증 중 clean을 돌리지 않는다(시간 낭비라는 이유가 적혀 있음). 에이전트가 길을 헤맬 때 흔히 택하는 우회로를 미리 막아 둔 목록입니다. Kotlin Multiplatform 프로젝트에는 쓰지 말라고 스스로 제외하고, 스크린샷 테스트 도구 Paparazzi가 v2.0.0-alpha04 이하에서 AGP 9와 충돌한다는 참고 문서가 따로 달려 있습니다.

r8-analyzer: 환경을 읽고 세 갈래 중 길을 고른다

R8(코드를 줄이고 난독화하는 도구)의 유지 규칙을 손볼 때 어려운 점은 어떤 규칙이 실제로 얼마나 큰 영향을 주는지 모른다는 것입니다. r8-analyzer는 build.gradle, gradle.properties, libs.versions.toml에서 AGP와 R8 버전을 읽고, 쓸 수 있는 가장 정량적인 길을 스스로 고릅니다.

그림 4. R8 분석기의 경로 선택. 위쪽 두 길은 R8 데이터로 점수를 만들고, 아래쪽 길은 규칙 파일을 읽어 제안한다

경로 A는 AGP가 9.3.0 이상일 때입니다. ./gradlew :app:analyzeReleaseR8Config가 만든 .pb 보고서를 JSON으로 바꿔 분석합니다. 경로 B는 AGP가 그보다 낮아도 R8이 9.3.7-dev 이상일 때이고, assembleRelease에 -Dcom.android.tools.r8.dumpkeepradiustodirectory=...를 줘서 같은 데이터를 뽑습니다. 둘 다 tmp/ 아래에 analysis_result.txt를 쓰고, 그 안에는 최적화·난독화·축소 점수가 들어 있습니다. 참고 문서의 분석 코드를 보면 점수는 100에서 “해당 제한을 거는 규칙이 붙들고 있는 항목의 비율”을 뺀 값이고, 전역 규칙 -dontoptimize가 있으면 최적화 점수가, -dontobfuscate면 난독화 점수가, -dontshrink면 축소 점수가 곧바로 0이 됩니다. 두 길이 모두 안 되는 낮은 버전이면 경로 C로, proguard-rules.pro를 눈으로 읽어 라이브러리가 이미 가진 규칙은 제거(Remove), 패키지 전체를 건드리는 넓은 규칙은 다듬기(Refine)를 제안합니다. -keep class com.example.**{ *; } 같은 패키지 통째 규칙이 가장 먼저 의심받는 대상이고, 느낌표(!) 연산자를 쓴 유지 규칙은 그 클래스를 뺀 앱 전체를 붙드는 규칙이라 좁은 규칙으로 바꾸라고 합니다.

세 경로의 끝은 같습니다. 코드를 고치지 않고 정해진 형식의 마크다운 보고서만 채팅에 내놓으며, 군더더기 인사말도 금지입니다. 규칙을 바꾼 뒤에는 Macrobenchmark와 UI Automator로 검증하라고 권합니다.

이 스킬의 폴더에서 눈여겨볼 곳이 한 군데 있습니다. 경로 A는 .agents/skills/r8-analyzer/scripts/convert_pb_to_json.py와 .../scripts/analyze.py를 실행하라고 하는데, v1.0.17 저장소 트리의 r8-analyzer에는 scripts/ 폴더가 없습니다. 같은 변환·분석 파이썬 코드는 경로 B의 참고 문서 CONFIGURATION-ANALYZER.md에 본문으로 실려 있습니다. 그림 1 가운데 열의 노란 폴더가 이것입니다. 스킬을 설치한 뒤 경로 A가 실행에 실패하면 이 문서의 코드가 같은 일을 한다는 것을 알아 두면 됩니다.

edge-to-edge: 한 요소에 한 방법만

앱 화면이 상태 바와 내비게이션 바 뒤까지 그려지면 버튼이 바에 가리거나 키보드가 입력창을 덮습니다. edge-to-edge는 Compose 프로젝트가 대상이고, targetSdk가 35보다 낮으면 35로 올리라고 합니다. 절차는 계획, 적용, 인셋 처리의 세 단계입니다. 모든 Activity에서 지원이 없는 곳과 가려지는 요소를 찾아 계획을 세우고, onCreate의 setContent 앞에서 enableEdgeToEdge를 부르고, 키보드를 쓰는 Activity에는 매니페스트에 android:windowSoftInputMode="adjustResize"를 둡니다.

핵심은 한 요소에 한 방법만 쓰라는 규칙입니다. 같은 영역에 방법을 겹치면 여백이 두 번 들어가는 이중 패딩이 생기기 때문입니다. 선호 순서는 다음과 같습니다.

1. Scaffold가 내려주는 PaddingValues를 내용 영역이 그대로 쓴다
2. Material 3 부품(앱 바, 내비게이션 바·레일, 모달 시트)의 내장 처리를 믿는다
3. Scaffold 밖에서는 safeDrawingPadding() 같은 패딩 modifier를 쓴다
4. 깊이 중첩된 내용에서는 WindowInsetsRulers와 fitInside를 쓴다
5. 시스템 바와 같은 높이여야 하는 장식 요소에는 인셋 크기 modifier를 쓴다

키보드는 별도 절이 있습니다. 선호하는 방식은 내용 컨테이너에 fitInside(WindowInsetsRulers.Ime.current)를 거는 것이고, 대안은 imePadding()을 verticalScroll() 앞에 두는 것입니다. contentWindowInsets를 safeDrawing으로 둔 Scaffold처럼 키보드 인셋을 이미 처리하는 부모 안에서 imePadding()을 또 쓰면 이중 패딩이 되니 피하라고 하고, 올바른 예와 잘못된 예를 코드로 나란히 실어 둡니다. SOFT_INPUT_ADJUST_RESIZE 상수는 쓰지 말고 매니페스트 속성을 쓰라는 주의도 있습니다. 적응형 Scaffold(NavigationSuiteScaffold, ListDetailPaneScaffold)는 안쪽 내용에 PaddingValues를 전달하지 않으므로 화면이나 부품마다 인셋을 따로 처리해야 하고, 부모에 safeDrawingPadding 같은 modifier를 씌우면 화면이 잘려 edge-to-edge가 깨진다고 경고합니다. 한계도 숨기지 않습니다. 패턴을 찾아 소스를 훑는 방식이라 특이하게 감싼 부품은 놓칠 수 있고, 검증이 빌드 성공까지라서 제스처 내비게이션, 3버튼 내비게이션, 키보드가 열린 상태는 기기에서 사람이 눈으로 확인해야 합니다.

점검 스킬 다섯은 점검하는 방식이 다 다르다

고치는 스킬 말고 점검과 진단을 맡는 스킬이 다섯 있고, 같은 “점검”인데 방식이 제각각입니다.

점검의 방식이 곧 신뢰 방식이라는 점이 눈에 띕니다. ANR 스킬은 에이전트의 추측을 막으려고 증명을 요구하고, 권한 스킬은 점검표로 패턴을 모아 주고, Play 정책 스킬은 한 에이전트의 판단을 믿지 않고 다른 에이전트가 다시 검토하게 합니다. 어느 쪽이든 결과는 사람이 다시 봐야 한다는 README의 면책 문구가 전제입니다.

android-cli: 755줄 사용 설명서가 에이전트에게 가르치는 것

가장 긴 스킬은 기능 스킬이 아니라 도구 사용 설명서입니다. android-cli 스킬은 android 명령으로 SDK 설치, 프로젝트 생성, 에뮬레이터, 문서 검색, 스킬 관리를 하는 법을 가르치고, 본문의 3분의 1 가까이를 기기 화면을 다루는 법과 저니 테스트에 씁니다. 에이전트가 먼저 android layout으로 화면 구조를 JSON으로 읽고, 부족하면 android screen capture --annotate로 요소마다 번호를 붙인 스크린샷을 찍고, android screen resolve로 번호를 좌표로 바꿔 adb shell input으로 누르는 순서입니다. 글자 입력 전에 입력칸의 상태에 FOCUSED가 있는지 확인하고, 스크롤은 천천히 하고, 동작 뒤에 화면이 안 바뀌면 몇 초 기다렸다가 layout을 다시 읽으라는 규칙이 번호로 적혀 있습니다.

이 스킬에는 다른 곳에서 못 본 절도 있습니다. 앱의 동작을 XML로 적은 “저니(Journey)” 테스트를 평가하는 방법입니다. <action> 안에 “Home 아이콘을 누른다”, “홈 화면인지 확인한다” 같은 문장을 순서대로 적어 두면, 에이전트가 각 문장을 서로 독립적으로, 적힌 그대로 수행합니다. 하나라도 실패하거나 앱이 종료·충돌·멈춤에 빠지면 저니는 실패이고, 저니 XML이 정답이라 앱이 저니와 다르면 앱이 틀린 것으로 칩니다. “소다를 검색해 첫 결과를 장바구니에 담는다”처럼 여러 동작이 한 문장에 든 <action>은 쪼개서 따로 평가하라고 합니다.

CLI 자체도 4월 이후 크게 자랐습니다. 릴리스 노트에는 4월의 0.7이 첫 릴리스로 올라 있고, 5월 1.0.x에서 스킬 라이브러리가 들어왔으며, 10월의 1.1.16717390에는 현장 충돌 신호(android signals), 앱 프로파일링(android profiler), 산출물 분석(android analyze), Compose 미리보기(android preview), 기기 화면 미러링 창(android device hub)이 추가됐다고 적혀 있습니다. 문서가 밝힌 알려진 문제로 윈도에서는 android emulator가 꺼져 있고 PowerShell로 CLI를 내려받는 방식은 지원하지 않습니다. 사용 정보는 하위 명령과 옵션 이름, 익명 처리한 오류 정보를 모으고 응답 내용이나 프로젝트 이름·경로 같은 사용자 입력은 모으지 않으며, 끄려면 --no-metrics를 줍니다. 자주 쓰는 옵션은 홈 폴더의 .androidrc에 줄마다 적어 둘 수 있습니다.

10월에만 스킬 22개가 고쳐졌다

4월 16일 Android Developers 블로그가 CLI, 스킬, 지식 베이스를 함께 내놓았을 때 첫 스킬은 Navigation 3, edge-to-edge, AGP 9와 XML→Compose 이관, R8 정도였습니다. 블로그는 CLI로 프로젝트와 환경을 설정할 때 표준 도구만 쓴 에이전트보다 완료 시간이 3배 빠르고 LLM 토큰은 70% 넘게 줄었다고 밝혔는데, 이는 설정 작업에 대한 Google의 내부 실험값입니다. 내 프로젝트에서 같은 폭을 기대하기보다 설정 단계에서 헤매는 시간이 줄 수 있다는 방향으로 읽는 편이 안전합니다.

그림 5. 발표부터 33개까지의 경과(CLI 릴리스 노트와 저장소 태그 기준, 2026년)

반년 사이 속도가 붙었습니다. 33개 스킬의 머리말 last-updated를 세어 보면 7월 1개, 8월 2개, 9월 8개, 10월 22개입니다. 10월 21일의 v1.0.16에서 새 스킬 3개와 갱신 13개가, 23일의 v1.0.17에서 갱신 11개가 나왔습니다. v1.0.14와 v1.0.15 릴리스에는 변경 목록이 적혀 있지 않습니다.

10월 21일에 들어온 새 스킬 셋은 성격이 서로 멉니다. litert-lm은 Hugging Face의 .litertlm 모델(Gemma, Qwen, Llama, Phi)을 폰 안에서 CPU나 GPU로 돌리는 앱을 만드는 스킬입니다. litertlm-android 0.18.0 AAR의 minSdk 24, 엔진 초기화는 메인 스레드 밖에서, 모델 파일은 assets/나 APK가 아니라 기기 저장소에 두라는 지침이 들어 있고, 이미지·오디오 입력, 도구 호출, NPU는 범위 밖으로 둡니다. anr-audit-and-fix는 앞서 본 증명형 점검이고, projected-hardware는 Android XR의 오디오 안경·디스플레이 안경에서 카메라와 마이크, 안경 전용 런타임 권한, 연결 수명주기를 다루는 43줄짜리 스킬입니다. 기기 형태가 자꾸 늘어나는 안드로이드의 폭이 스킬 목록에 그대로 반영되고 있습니다.

내 팀 스킬을 같은 모양으로 쓰려면

문서는 직접 쓰는 방법도 안내합니다. 스킬마다 폴더를 두고 대소문자를 지킨 SKILL.md를 넣습니다. 가장 작은 모양은 다음과 같습니다.

---
name: team-room-migration
description: 팀 프로젝트에서 Room 스키마를 바꿀 때 마이그레이션 테스트까지 만들어야 하면 사용한다.
metadata:
  author: my-team
  version: "1.0"
---

1. 변경 전 스키마 JSON이 있는지 확인한다.
2. 마이그레이션 클래스를 추가하고 테스트를 작성한다.
3. 끝나면 ./gradlew test 통과를 확인한다.

name은 소문자·숫자·하이픈으로 64자 이내이고 폴더 이름과 같아야 하며, description은 1,024자 이내입니다. 에이전트가 스킬을 부르는 시점은 이 설명문에 달려 있어서 “무엇을 하는지”와 “언제 쓰는지”를 함께 적어야 합니다. 본문은 1만~2만 자 안쪽을 권하고, 길어지면 references/(자세한 문서), scripts/(실행 코드), assets/(템플릿·스키마)로 나눕니다. 앞의 지도에 비춰 보면 어떤 모양을 고를지 감이 옵니다. 지침이 짧고 단계가 분명하면 agp-9-upgrade처럼 본문 한 장에 “하지 말 것”까지 적고, 참고할 문서가 많으면 navigation-3처럼 본문을 목차로 쓰며, 순서와 검증이 기계적이면 play-policy-insights처럼 스크립트에 맡기는 식입니다.

몇 가지 제약도 알아 둘 만합니다. 프로젝트 안에 설치된 스킬만 지원하고, 에이전트가 설명문을 보고 알아서 고르므로 호출이 보장되지는 않습니다. 자동으로 안 불리면 요청에 스킬 이름을 직접 넣어 보세요. 범위를 스스로 긋는 스킬도 많아서, AGP 이관은 Kotlin Multiplatform에, edge-to-edge는 View 기반 화면에, litert-lm은 이미지·오디오 입력에 쓰지 말라고 적혀 있습니다. 저장소는 공개 기여를 받지 않고 피드백과 새 스킬 요청은 이슈로 받습니다.

스킬 말고 같은 일을 맡기는 다른 길

스킬이 절차를 에이전트에게 쥐여 주는 방식이라면, 문서 자체를 최신으로 불러오게 하는 길이 있고(Context7), 폴더 하나가 어떻게 읽히는지 뜯어 보는 글도 있습니다. 먼저 Agent Skills를 재단에 넘긴 소식과 SKILL.md가 세 단계로 읽히는 구조를 보면 이 글의 폴더 그림이 표준의 어디에 해당하는지 이어집니다. 보안 점검형 스킬이 궁금하다면 취약점을 찾은 에이전트를 다른 에이전트가 반박하게 하는 Cloudflare의 보안 감사 스킬이 같은 “다른 에이전트가 다시 검토한다”는 발상을 다른 방식으로 씁니다. 모델이 낡은 API를 쓰는 문제를 문서 검색으로 푸는 쪽은 Context7 설치법과 한계에, 공식 사용법과 명령 전체는 Android CLI 문서(android -h, android skills add -h)에 있습니다.