# Sg Prune Build Bloat

> Python 및 JavaScript/TypeScript 빌드 프로젝트에서 기존 정적 검사를 우선 활용해 불필요한 의존성과 코드를 찾아 보수적으로 정리하고 로컬 빌드 관문에 연결한다. 빌드 지연, 의존성 비대화, 미사용 패키지·import·변수·파일·export·dead code 정리, 빌드 전 정적 검사 배치를 요청할 때 사용한다.

- Skill: `innnteraction/sg-prune-build-bloat` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add innnteraction/sg-prune-build-bloat`
- Raw SKILL.md: https://api.skillmd.com/api/skills/innnteraction/sg-prune-build-bloat/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Innnteraction (https://skillmd.com/u/innnteraction)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/innnteraction/sg-prune-build-bloat

---


# Prune Build Bloat

새 분석기를 도입하는 것부터 시작하지 말고, 저장소가 이미 신뢰하는 검사와 빌드 흐름을 찾아 부족한 부분만 보완한다. 정적 분석 결과를 사용 사실로 단정하지 말고 공개 계약과 동적 경계를 확인한 뒤 작은 단위로 정리한다.

## 프로젝트 판별

1. 대상 root, revision, dirty 상태와 사용자 변경을 확인한다. 기존 변경을 덮어쓰거나 정리 범위에 섞지 않는다.
2. `pyproject.toml`, Python lockfile, `requirements*.txt`, `package.json`, JavaScript lockfile, `tsconfig*.json`과 실제 소스 분포를 함께 조사한다. manifest가 있는 각 workspace를 독립적인 분석 단위로 기록한다.
3. Git이 무시하는 경로와 생성물, vendor, cache, virtual environment, dependency 설치 디렉터리, build 출력을 언어 판별과 후보 집계에서 제외한다.
4. Python이 있으면 [Python 연결 지침](references/python.md)을 읽고, JavaScript 또는 TypeScript가 있으면 [JavaScript/TypeScript 연결 지침](references/javascript-typescript.md)을 읽는다. 혼합 저장소에서는 둘 다 읽되 workspace 경계를 유지한다.

## 기존 관문 조사와 브리핑

1. package script, task runner, lint, typecheck, dependency 검사, dead-code 검사, pre-commit과 로컬 build 진입점을 조사한다. 이름만 보고 충분하다고 판단하지 말고 실제 명령, 설정, 대상 경로와 workspace coverage를 확인한다.
2. manifest, lockfile, 설정과 프로젝트 환경에서 사용 가능한 실행 파일을 대조해 설치된 도구만 식별한다. 도구 탐색을 위해 프로젝트의 install 또는 build script를 실행하지 않는다.
3. 변경 전에 다음을 브리핑한다.
   - 감지한 언어, framework, workspace, package manager와 build 진입점
   - 기존 검사, 실행 위치, 대상 범위와 빠진 범위
   - 실행할 진단 명령, 중복 검사와 미설치 도구
   - 동적 import, plugin, reflection, code generation, framework entrypoint와 공개 API 등 오탐 위험
4. 일반적인 보수적 정리는 브리핑 뒤 계속한다. 도구 설치, 공개 계약 제거, 동적 사용 여부가 불명확한 변경은 근거와 선택지를 제시하고 승인을 기다린다.

## 진단과 분류

1. 저장소가 이미 제공하는 명령과 설정을 먼저 사용한다. 같은 범위를 검사하는 새 도구나 병렬 관문을 추가하지 않는다.
2. 모든 검사를 수정 없는 진단 모드로 먼저 실행하고 명령, 도구 버전, 작업 디렉터리, 종료 코드와 검사 범위를 기록한다.
3. 로컬 프로젝트 환경에 없는 도구를 자동 설치하거나 다운로드하지 않는다. 자동 다운로드할 수 있는 `npx`와 전역 설치 도구에 의존하지 않는다. 필요한 경우 감지한 package manager에 맞는 dev 의존성, 이유와 설치 명령을 제안하고 승인 전에는 실행하지 않는다.
4. 각 후보를 코드 검색, 설정, manifest entrypoint, package script, 테스트와 공개 계약에 대조해 다음으로 분류한다.
   - `제거 가능`: 직접 근거가 있고 알려진 소비자가 없음
   - `보존`: 정적 분석 밖의 소비자 또는 계약 근거가 있음
   - `확인 필요`: 동적 경계나 외부 소비자를 반증할 수 없음
5. transitive, peer, optional, development와 runtime dependency를 구분한다. 선언 위치가 잘못된 문제를 미사용 문제로 바꾸지 않는다.

## 단계별 정리

1. `제거 가능` 항목만 import와 local symbol, 내부 dead code, 내부 file/export, dependency 순서의 작은 묶음으로 정리한다. 뒤 항목의 근거가 앞 변경으로 달라지면 다시 진단한다.
2. 자동 수정은 진단을 검토한 뒤 안전하다고 확인한 규칙과 경로에만 제한한다. 적용 직후 diff를 읽고 예상 밖 변경은 자신이 만든 정확한 변경만 되돌린다.
3. dependency는 감지한 package manager의 제거 명령을 사용해 manifest와 lockfile을 함께 갱신한다. lockfile을 직접 부분 편집하거나 다른 package manager로 재생성하지 않는다.
4. 코드·dependency·export를 줄인 묶음에서 module header, API 문서, manifest metadata와 사용 예시가 새 표면을 정확히 설명하도록 함께 갱신한다.
5. 각 묶음 뒤에 해당 정적 검사와 관련 테스트를 실행한다. 실패하면 후보 분류를 되돌아가며, 검증을 약화하거나 넓은 ignore로 통과시키지 않는다.
6. 공개 export, CLI, plugin hook, decorator 등록, reflection, 문자열 기반 조회, side-effect import, code generation 입력과 framework 규약 경로는 명시적 승인 없이 제거하지 않는다.
7. 오탐은 보존 근거를 남기고 최소 symbol 또는 경로만 ignore한다. 도구나 workspace 전체를 끄지 않는다.

## 로컬 빌드 관문 연결

1. 정리가 안정화된 뒤 기존 task runner와 품질 관문에 검사를 합친다. 이미 동등한 검사가 build 전에 실행되면 변경하지 않는다.
2. 기존 관문이 부족하면 저장소 명명과 package manager 관례를 따르는 최소 로컬 명령을 만들고, 비싼 compile, bundle 또는 package 단계보다 앞에 배치한다. 기존 prebuild 동작을 보존해 합성한다.
3. 공급자별 CI workflow는 수정하지 않는다. CI가 저장소의 같은 로컬 명령을 호출할 수 있게 단일 진입점을 유지한다.
4. 최종 정적 검사, 관련 테스트와 canonical build를 실행한다. build 실패를 피하려고 검사를 우회하지 말고 실패 원인과 마지막으로 성공한 단계부터 좁힌다.

## 완료 보고

- 제거한 dependency, import, symbol, file과 export를 범주별로 요약한다.
- 보존하거나 확인이 필요한 항목, 오탐 근거와 승인되지 않은 제안을 구분한다.
- 재사용하거나 변경한 로컬 관문과 CI가 호출할 단일 명령을 밝힌다.
- 실행한 진단, 테스트와 build의 결과 및 검사하지 못한 workspace를 보고한다.
- 동일 환경의 재현 가능한 전후 측정이 있을 때만 build 시간 개선을 수치로 주장한다.

