dead-code-eliminator
Proves code is unreachable with converging evidence, then removes it and its tests, fixtures, and flags in reversible slices without breaking dynamic callers. Use when deleting suspected dead code, cleaning up after a migration or feature retirement, trimming a bloated module, or before estimating work on unfamiliar code. Do NOT use when you want to survey and rank an area's debt without committing to deletion - use find-tech-debt instead.
- License 许可
- MIT
- 最近更新
- 2026-10-14
- Stars
- ★ 25
- Forks
- 3
01 前言 Front Matter
- name
- dead-code-eliminator
- metadata
- { "title": "Dead Code Eliminator" }
- description
- Proves code is unreachable with converging evidence, then removes it and its tests, fixtures, and flags in reversible slices without breaking dynamic callers. Use when deleting suspected dead code, cleaning up after a migration or feature retirement, trimming a bloated module, or before estimating work on unfamiliar code. Do NOT use when you want to survey and rank an area's debt without committing to deletion - use find-tech-debt instead.
03 SKILL.md 正文
Dead Code Eliminator
Delete code only after converging evidence proves it dead, then remove it in reversible slices that include its tests, fixtures, config, and flags.
Workflow
- Scope one cluster. Pick a single symbol, file, or feature to prove dead. Do not batch unrelated removals - a regression must point to one change.
- Gather static evidence. Run the language's dead-code detector (ts-prune or knip for TS/JS, vulture for Python,
deadcodefor Go) and a dependency grapher (madge) or IDE "find usages". Record what each reports unreachable. - Gather runtime evidence. Check production coverage or profiling data over a representative window - at least 30 days for user-facing paths, 90+ days for code tied to monthly or quarterly jobs - and telemetry: was this endpoint, job, or branch hit this quarter? A symbol is a deletion candidate only when static analysis AND runtime evidence agree. One signal alone produces false positives that take down prod.
- Hunt the dynamic callers static tools miss. Grep the symbol name as a string (reflection, string-keyed dispatch, serialization). Check DI containers, registries, ORM hooks, cron/queue workers, and feature-flag config. Search infra repos and other services. Public API surface and library exports are reachable by definition unless you control every consumer.
- Classify the kind of dead, because each is removed differently. Unreachable (no path calls it) → delete. Unused (callable, never called) → delete. Redundant (duplicates a live path) → repoint callers first. Dormant-behind-a-flag (flag off for a cycle) → retire the flag first, then delete its branch.
- Soft-delete risky removals first. Replace the suspect path with log-and-throw, or gate it behind a kill flag while keeping the code, for one full business cycle - 30 days minimum, 90 for anything touching monthly or quarterly processes. If nothing fires the log, proceed. For low-risk leaf code, skip to step 7.
- Delete in a focused PR. Remove the code AND its tests, fixtures, config, flags, and now-orphaned imports. Keep the diff under roughly 400 changed lines so it is reviewable in one sitting; a bigger cluster gets split into multiple PRs. Let CI and the type-checker catch references the search missed. No formatting or refactors in the same diff.
Deliverable
Produce a deletion PR (one per cluster) containing the removed code plus its entire footprint - tests, fixtures, config, flags, orphaned imports - and a PR description that cites the two converging evidence signals, names which of the four kinds of dead the code is, and, for soft-deleted paths, records the observation window with zero hits.
Quality bar
- Every deletion cites at least two independent converging signals (static + runtime).
- The PR removes the dead symbol's entire footprint, leaving no orphaned test, fixture, or flag.
- The removal names which of the four kinds of dead it is.
- Reverting the PR cleanly restores the prior behavior.
Do NOT
- Treat "I can't find a caller" as proof of death - absence of a static caller is not absence of a dynamic one.
- Delete code you only suspect is dead, public API without consumer proof, or code added in the last few weeks (it may be ahead of its caller).
- Skip the string-grep and DI/flag/registry check for anything invoked indirectly.
- Fold formatting or refactors into a deletion PR.
- Batch many clusters into one PR.
When evidence is ambiguous, mark the symbol deprecated and instrument it rather than guessing.
04 同仓库更多 Skills
有氧运动计划
zone-2-cardio-plan
当有人要求制定稳态有氧训练计划、进行有氧基础训练或达到第二区间、安排轻松或耐力型的每周有氧训练、按心率区间训练，或提高静息心率、最大摄氧量或耐力时，可以使用此方案。该方案构建了一个包含训练计划结构、训练方式选择和进度安排的心率区间有氧训练模块。本方案仅提供一般健身指导，不构成医疗建议。请勿用于设计力量或举重训练计划（请使用力量训练计划）、高强度间歇训练 (HIIT) 或循环训练（请使用体能训练和 HIIT 计划），或灵活性/柔韧性训练（请使用灵活性训练计划）。
youtube-script-writer
Writes retention-engineered long-form YouTube scripts on a hook/body/payoff architecture - a first-30-seconds hook that survives the retention cliff, a beat-sheet body with mini-hooks and bridges, timed pattern interrupts, and a payoff that over-delivers - with B-roll and editing cues marked inline. Use when someone says "script my next video", "my retention graph dies at the start", "tighten this draft", or "outline a video on X". Do NOT use for the 3-second opener of TikTok, Reels, or Shorts - use video-hook-writer instead; do NOT use for spoken voiceover synced to on-screen tutorial actions - use narration-script instead; do NOT use for a sales demo built on a buyer's discovery notes - use demo-script instead; do NOT use to design the thumbnail and title - use thumbnail-concept instead.
win-back-campaign
Designs segmented win-back email sequences for dormant users - dormancy tiers, a three-beat sequence with a single proportional incentive, and a suppression rule - and measures success by re-activation, not opens. Use when someone says "our users went quiet", "design a win-back campaign", "how do I re-engage lapsed customers", "should we email people who haven't logged in for months", or lifecycle messaging has stopped landing with a lapsed segment. Do NOT use for recovering an unfinished checkout - use abandoned-cart-sequence instead. Do NOT use for diagnosing and fixing why active customers cancel - use churn-reduction instead. Do NOT use for building always-on onboarding or nurture flows - use email-drip-builder instead.
wikipedia-style
Writes neutral, verifiable, encyclopedic prose following Wikipedia's core content policies and manual of style - NPOV, inline citations, notability-backed claims, and a strict ban on promotional language. Use when someone asks "write this like a Wikipedia article", "draft a Wikipedia page for this company or person", "make this neutral and encyclopedic", or "why does my article draft keep getting rejected". Do NOT use for persuasive or opinion writing - use op-ed-writer instead; for thesis-driven academic papers, use academic-essay; for verifying claims in existing text, use fact-checker.
whitepapers
Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks "write a whitepaper on this topic", "turn our research into a lead-gen asset", "make this credible enough for executives", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.
white-space-analysis
Finds unmet market gaps by ranking jobs-to-be-done on importance versus satisfaction, overlaying them against current solutions and workarounds, and validating that each gap is real, winnable, and worth winning. Use when someone asks "where are the gaps in this market", "what's underserved here", "where should we play next", or is hunting for product, feature, or market-entry opportunities. Do NOT use for profiling competitors and building battle cards - use competitive-intelligence instead; for putting a dollar figure on an identified opportunity - use market-sizing instead; for extracting jobs-to-be-done from raw customer interviews - use jtbd-extractor instead.