사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/ckorhonen/hone-skills --skill hone:broken-windows-hunt시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Broken Windows Hunt
What This Skill Does
Scans the codebase for signs of accumulated technical neglect -- the "broken windows" that signal declining quality and invite further shortcuts. Each finding is a small fix that prevents larger decay.
Detected signal categories:
- Stale TODOs: TODO/FIXME/HACK/XXX comments with no linked issue
or with dates older than 90 days.
- Disabled tests: tests marked skip, pending, xfail, or
commented out.
- Lint suppressions: inline ignores, nolint, eslint-disable,
type: ignore, and similar markers.
- Commented-out code: blocks of commented code longer than 3
lines that are clearly executable code, not documentation.
- Dead imports: imported symbols that are not referenced in the
file.
- Empty catch/except blocks: error handlers that silently
swallow exceptions.
- Deprecated API usage: calls to functions or methods marked
deprecated via language-standard annotations or doc comments.
When To Use
- Daily scheduled sweep to catch new entropy before it compounds.
- After a sprint or release to assess accumulated shortcuts.
- When joining a new codebase to gauge maintenance health.
Do Not Use
- For feature development or refactoring planning (use other skills).
- For security vulnerability scanning (use a security tool).
- For style or formatting issues (use a linter).
- For deep architectural analysis (use intent-clarity-audit or
naming-specificity-audit).
Inputs To Confirm
- Scope -- which directories or file patterns to scan
(default: entire repo, excluding vendored/generated code).
- TODO age threshold -- how old a TODO must be to count as stale
(default: 90 days, inferred from git blame).
- Categories to include -- which signal categories to check
(default: all).
Instructions
- Identify the repository root and enumerate source files, excluding
vendored directories (vendor/, node_modules/, .git/, third_party/), generated files, lock files, and binary assets.
- Stale TODOs: search for TODO, FIXME, HACK, and XXX comments.
For each, check:
- Is there a linked issue number or URL? If yes, note it but
still flag if the issue is closed or the comment is very old.
- Use
git blameon the line to determine age. Flag if older
than the configured threshold.
- Record the comment text, file path, line number, and age.
- Disabled tests: search for test-disabling patterns across
languages:
- JavaScript/TypeScript:
it.skip,describe.skip,xit,
xdescribe, test.skip.
- Python:
@pytest.mark.skip,@unittest.skip,@pytest.mark.xfail. - Ruby:
skip,pending,xit. - Go:
t.Skip(). - Java:
@Disabled,@Ignore. - Also detect fully commented-out test functions.
- Lint suppressions: search for inline suppression markers:
eslint-disable,@ts-ignore,@ts-expect-error,nolint,
noqa, type: ignore, rubocop:disable, // noinspection, @SuppressWarnings, #pragma, NOLINT.
- Record the rule being suppressed if specified.
- Commented-out code: identify blocks of 3+ consecutive
commented lines that parse as valid code in the file's language. Exclude license headers, documentation blocks, and ASCII art.
- Dead imports: for each file, extract import/require/use
statements and check whether the imported symbol appears elsewhere in the file. Flag unused imports.
- Empty catch blocks: find try/catch, try/except, rescue, or
equivalent blocks where the error handler body is empty or contains only a comment.
- Deprecated API usage: search for deprecation annotations
(@deprecated, @Deprecated, DeprecationWarning, [[deprecated]]) in the codebase, then find call sites of those deprecated symbols.
- For each finding, record:
- Category (one of the seven above).
- File path and line number.
- The offending code snippet (1-3 lines).
- Severity:
high(disabled tests, empty catches),
medium (stale TODOs, lint suppressions, deprecated usage), low (dead imports, short commented-out code).
- Suggested fix (e.g., "remove dead import", "add error logging
to catch block", "convert TODO to issue #N or delete").
- Produce the output report.
Output Requirements
Produce a Markdown report with:
- Health summary: a one-paragraph assessment of the codebase's
entropy level with total finding count and breakdown by category.
- Findings by category: one section per category with a table of
findings (file, line, snippet, severity, suggested fix).
- Trend indicators: if this is not the first run, note whether
entropy is increasing, stable, or decreasing (based on finding count vs. previous run if available; otherwise note this is a baseline).
- Quick wins: the top 5 findings that can be fixed in under 5
minutes each.
Quality Bar
- Every finding must include a file path, line number, and code
snippet.
- Stale TODO age must be derived from git blame, not guessed.
- Disabled tests must be distinguished from conditionally skipped
tests (e.g., platform-specific skips with a reason are lower severity than bare skip calls).
- Commented-out code detection must not flag license headers or
documentation blocks.
- The report must be actionable as a daily cleanup checklist.



