Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/heegyeong/composesample/impact-analyzenpx skills add HeeGyeong/ComposeSample --skill impact-analyzegit clone --depth 1 https://github.com/HeeGyeong/ComposeSampleWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/heegyeong/composesample/impact-analyze)<a href="https://agentmods.dev/skills/heegyeong/composesample/impact-analyze"><img src="https://agentmods.dev/badge/skills/heegyeong/composesample/impact-analyze.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00088 | $0.03046 |
| Opus 5 | $0.00044 | $0.01523 |
| Sonnet 5 | $0.00018 | $0.00609 |
| Haiku 4.5 | $0.00009 | $0.00305 |
Grade A, and why
impact-analyze scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 183 lines — stays where its author put it; the contents beside it link to each section on GitHub.
impact-analyze — 영향 분석 검증형 하네스
변경의 크래시 가능성·사이드 이펙트를 WORKFLOW.md 템플릿의 차원별로 병렬 탐지하고, 각 리스크 후보를 적대적으로 반증(adversarial verify) 해 살아남은 것만 분석 섹션으로 합성하는 read-only 하네스입니다. explore-codebase(탐색형)와 달리 검증형 — 리스크 후보를 그대로 믿지 않고 회의론자가 반증을 시도합니다.
호출: /impact-analyze [변경 대상/설명]
- 인자가 비면 현재 작업트리
git diff를 변경면으로 사용. - 예:
/impact-analyze(현재 diff) - 예:
/impact-analyze ExampleRouter 라우팅 분기 변경의 영향
오케스트레이터 절차 (메인 루프가 따른다)
1. 입력 파싱
$ARGUMENTS 에서 변경 대상/설명을 추출한다. 비어 있으면 git diff(+ 필요시 git diff --staged)를 읽어 변경면으로 삼는다.
2. 변경면 정찰 (인라인, read-only)
바뀌는 파일 · 함수/심볼 · 리소스 목록을 만들고, 핵심 심볼의 1차 호출부를 grep 해둔다.
changeSurface = { summary, files:[...], symbols:[...] }summary= 변경이 무엇을 바꾸는지 1~2문장. finder 들이 공유할 컨텍스트.
3. Workflow 실행
아래 §임베드 Workflow 스크립트를 args: { change: changeSurface } 로 호출한다(실제 JSON 값으로 전달).
4. 결과 제시
반환된 section(분석 섹션 markdown)을 보여준다. 진행 중인 spec 의 step 이 있으면, 그 step 의 "크래시 가능성 / 사이드 이펙트 분석" 에 반영할지 사용자에게 묻는다.
- 합성 섹션은 초안임을 명시하고, 폐기된 후보(
dropped)도 간단히 알려 사용자가 재검토할 수 있게 한다.
임베드 Workflow 스크립트
Workflow도구의script인자로 전달.args={ change }를 실제 JSON 값으로 넘긴다. 안전 규칙:Date.now()/Math.random()/new Date()미사용, schema 강제 출력,.filter(Boolean)로 null 방어.
export const meta = {
name: 'impact-analyze',
description: '차원별 리스크 finder fan-out → adversarial verify → WORKFLOW.md 분석 섹션 합성',
phases: [
{ title: 'Find', detail: '영향 차원별 리스크 후보 탐지' },
{ title: 'Verify', detail: '리스크마다 회의론자 3명이 반증 시도' },
{ title: 'Synthesize', detail: 'WORKFLOW.md 형식 분석 섹션 합성' },
],
}
const change = (args && args.change) || {}
const changeText = JSON.stringify(change, null, 2)
if (!change.summary && !(change.files && change.files.length)) {
log('변경면(change.summary/files)이 비어 있습니다. 메인 루프에서 changeSurface 를 채워 다시 호출하세요.')
return { section: '', survived: [], dropped: [] }
}
// 영향 차원 (Compose + Koin + Clean Architecture 기준)
const DIMENSIONS = [
{ key: 'call-sites', desc: '변경한 함수·프로퍼티·리소스의 호출부/참조부 — 깨지거나 시그니처 불일치가 생기는 곳 (ExampleRouter 분기, 다른 ExampleUI 등)' },
{ key: 'lifecycle', desc: 'Composable 생명주기·재구성과 사이드 이펙트 시점 불일치 — remember/rememberSaveable 키 누락, LaunchedEffect/DisposableEffect 의존성·정리, ViewModel 스코프, 콜백 시점' },
{ key: 'state-restore', desc: '상태 보존/복원 — rememberSaveable/Saver, process death 후 복원, Navigation 인자(Coordinator/Core) 직렬화 호환' },
{ key: 'concurrency', desc: 'Flow/coroutine 취소·재구독, 메인 스레드 밖 UI 접근, race, StateFlow 수집 시점' },
{ key: 'data-compat', desc: '서버 응답(Retrofit/Ktor)/로컬 캐시(Room)의 기존 데이터가 변경된 파싱·분기 로직을 통과하는지' },
{ key: 'shared-component', desc: '공통 Composable/extension/테마/공유 ViewModel 변경 시 이를 쓰는 다른 화면 영향' },
{ key: 'linked-flow', desc: '네비게이션 콜백(onBackEvent), ExampleRouter 라우팅, 공유 상태 등 간접 경로로 영향받는 플로우' },
]
const RISK_SCHEMA = {
type: 'object',
required: ['dimension', 'risks'],
properties: {
dimension: { type: 'string' },
risks: {
type: 'array',
items: {
type: 'object',
required: ['scenario', 'cause', 'evidenceFiles', 'likelihood', 'defense'],
properties: {
scenario: { type: 'string', description: '문제가 터지는 상황' },
cause: { type: 'string', description: '예상 예외/원인' },
evidenceFiles: { type: 'array', items: { type: 'string' }, description: '근거 파일:라인' },
likelihood: { type: 'string', enum: ['상', '중', '하'] },
defense: { type: 'string', description: '대응/방어책' },
},
},
},
},
}
const VERDICT_SCHEMA = {
type: 'object',
required: ['refuted', 'reasoning', 'adjustedLikelihood'],
properties: {
refuted: { type: 'boolean', description: '이 리스크가 실제로는 성립하지 않으면 true' },
reasoning: { type: 'string' },
adjustedLikelihood: { type: 'string', enum: ['상', '중', '하', '해당없음'] },
},
}
// Find → Verify 를 차원별 독립 파이프라인(차원 간 배리어 없음)
const perDim = await pipeline(
DIMENSIONS,
(dim) => agent(
`변경면(JSON):\n${changeText}\n\n` +
`위 변경에 대해 **"${dim.key}"** 차원의 영향만 분석하라: ${dim.desc}\n` +
`해당 차원에서 발생 가능한 리스크 후보를 코드 근거(파일:라인)와 함께 반환하라. ` +
`근거 없이 추측만으로 올리지 말 것. 없으면 빈 배열. read-only — 코드 수정 금지.`,
{ label: `find:${dim.key}`, phase: 'Find', agentType: 'code-explorer', schema: RISK_SCHEMA, model: 'sonnet' },
),
(found, dim) => {
if (!found || !found.risks || !found.risks.length) return []
// 각 리스크를 회의론자 3명이 독립 반증 → 다수(≥2) 반증이면 폐기
return parallel(found.risks.map(risk => () =>
parallel([1, 2, 3].map(n => () =>
agent(
`변경면(JSON):\n${changeText}\n\n` +
`다음 리스크 주장을 **반증**하라(회의론자 #${n}). 코드를 직접 확인해 실제로 성립하지 않으면 refuted=true. ` +
`불확실하면 refuted=true 를 기본으로 한다.\n\n` +
`- 차원: ${dim.key}\n- 시나리오: ${risk.scenario}\n- 원인: ${risk.cause}\n- 근거: ${(risk.evidenceFiles || []).join(', ')}`,
{ label: `verify:${dim.key}#${n}`, phase: 'Verify', agentType: 'code-reviewer', schema: VERDICT_SCHEMA, model: 'sonnet' },
)
)).then(votes => {
const valid = votes.filter(Boolean)
const refutes = valid.filter(v => v.refuted).length
const survived = refutes < 2
// 검증 통과 시 가장 보수적(높은) 가능성으로 보정
const order = { '상': 3, '중': 2, '하': 1, '해당없음': 0 }
const adj = valid.filter(v => !v.refuted).map(v => v.adjustedLikelihood)
const adjusted = adj.length ? adj.reduce((a, b) => (order[b] > order[a] ? b : a)) : risk.likelihood
return { ...risk, dimension: dim.key, survived, adjustedLikelihood: adjusted, refutes, reasoning: valid.map(v => v.reasoning) }
})
))
},
)
const all = perDim.flat().filter(Boolean)
const survived = all.filter(r => r.survived)
const dropped = all.filter(r => !r.survived)
if (!survived.length) {
log(`탐지된 리스크 후보 ${all.length}개가 모두 검증에서 반증되었습니다.`)
return {
section: '## 크래시 가능성 / 사이드 이펙트 분석\n\n검증 결과 성립하는 리스크가 발견되지 않았습니다. (탐지 후보 전부 반증됨 — 폐기 목록 참고)',
survived: [],
dropped,
}
}
// 합성 — 생존 리스크 전체가 모여야 하므로 배리어 1회
phase('Synthesize')
const section = await agent(
`변경면(JSON):\n${changeText}\n\n` +
`아래는 adversarial 검증을 통과한 영향 리스크(JSON)다. 이를 **WORKFLOW.md 형식의 분석 섹션(markdown)** 으로 합성하라. 정확히 이 구조로:\n\n` +
`### 크래시 가능성\n` +
`| 시나리오 | 원인 (예상 예외) | 가능성 | 대응/방어 |\n|---|---|---|---|\n` +
`(생명주기/재구성/상태복원/동시성/데이터호환 등 크래시성 리스크를 adjustedLikelihood 기준으로)\n\n` +
`### 사이드 이펙트\n` +
`- **호출부/참조부 영향**: (call-sites 차원 요약 — "다른 곳 없음"도 확인 결과로 명시)\n` +
`- **공유 컴포넌트 영향**: (shared-component 차원 — 공통 Composable/extension/테마/공유 ViewModel)\n` +
`- **기존 동작 변화**: (의도 외 달라지는 동작)\n` +
`- **연계 플로우**: (linked-flow 차원 — 네비게이션 콜백/ExampleRouter/공유 상태)\n\n` +
`### 분석 근거\n` +
`- (검증 통과 근거 + 확인한 파일:라인 — 분석이 코드 확인에 기반했음을 남김)\n\n` +
`중복 리스크는 합치고, 근거 파일을 반드시 인용하라. 추측은 "추정"으로 표시.\n\n` +
`리스크 데이터:\n\`\`\`json\n${JSON.stringify(survived, null, 2)}\n\`\`\``,
{ label: 'synthesize:section', phase: 'Synthesize', agentType: 'code-explorer', model: 'opus' },
)
return { section, survived, dropped }
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 183 lines · 88 tokens per session scan A 9b9cc2459c31
impact-analyze is a skill published in the GitHub repository HeeGyeong/ComposeSample (11 stars, last pushed 4d ago), licensed MIT. It adds 88 tokens to every session and 3,046 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…