slash-do 2.5.0 → 2.7.0

package/commands/do/depfree.md

@@ -1,13 +1,13 @@
 ---
 description: Audit third-party dependencies and remove unnecessary ones by writing replacement code
-argument-hint: "[--interactive] [--scan-only] [--no-merge] [specific packages to evaluate]"
+argument-hint: "[--interactive] [--scan-only] [--no-merge] [--heavy] [specific packages to evaluate]"
 ---
 
 # Depfree — Dependency Freedom Audit
 
 Audit all third-party dependencies, classify them as acceptable (large, widely-audited) or suspect (small, replaceable), analyze actual usage of suspect dependencies, and replace them with owned code where feasible.
 
-Every small library is an attack surface. Supply chain compromises are real and common. Large, widely-audited libraries (express, react, d3, three.js, next, vue, fastify, lodash-es, etc.) are acceptable. But for smaller libraries or libraries where only one helper function is used, we should write the code ourselves.
+Every small library is an attack surface. Supply chain compromises are real and common. In default mode, large, widely-audited libraries (express, react, d3, three.js, next, vue, fastify, lodash-es, etc.) are acceptable. But for smaller libraries or libraries where only one helper function is used, we should write the code ourselves. In heavy mode, the acceptability bar is much higher — see the Heavy Mode section below.
 
 **Default mode: fully autonomous.** Uses Balanced model profile, proceeds through all phases without prompting.
 
@@ -17,8 +17,11 @@ Parse `$ARGUMENTS` for:
 - **`--interactive`**: pause at each decision point for user approval
 - **`--scan-only`**: run Phase 0 + 1 + 2 only (audit and plan), skip remediation
 - **`--no-merge`**: run through PR creation, skip merge
+- **`--heavy`**: aggressive mode — only keep foundational frameworks and language runtimes; replace everything else that is feasibly replaceable (see Heavy Mode below)
 - **Specific packages**: limit audit scope to named packages (e.g., "chalk dotenv")
 
+Set `HEAVY_MODE` to `true` if `--heavy` was passed, `false` otherwise.
+
 ## Configuration
 
 ### Default Mode (autonomous)
@@ -48,6 +51,18 @@ Record the selection as `MODEL_PROFILE` and derive:
 
 When the resolved model is `opus`, **omit** the `model` parameter on the Agent call so the agent inherits the session's Opus version.
 
+## Heavy Mode (`--heavy`)
+
+Heavy mode shifts the philosophy from "remove obvious attack surface" to "own everything we feasibly can." The only dependencies that survive are foundational frameworks, core platform tooling, and language-level runtimes — the kind maintained by large teams with dedicated security processes. Everything else is a candidate for replacement.
+
+Key behavioral changes when `HEAVY_MODE` is `true`:
+
+1. **Tier 1 is narrowed** to only foundational frameworks and language runtimes (see Phase 1b overrides below). Libraries like lodash, chalk, dotenv, commander, yargs, uuid, axios, etc. are NOT Tier 1 in heavy mode — they move to Tier 2 or 3.
+2. **EVALUATE recommendations become REMOVE** — the bias flips from "when in doubt, keep" to "when in doubt, replace."
+3. **Complexity ceiling rises** — replacements up to 300 lines are acceptable (vs the default where agents bail at ~2x estimate). Only truly infeasible replacements (deep domain expertise, crypto primitives, protocol parsers) are skipped.
+4. **Maintenance status is irrelevant** — even well-maintained small libraries are candidates. The question is "can we own this code?" not "is this library risky?"
+5. **DevDependencies get equal priority** — build tools and test utilities are audited with the same aggression as production dependencies (overriding the default Phase 1a deprioritization of devDependencies).
+
 ## Compaction Guidance
 
 When compacting during this workflow, always preserve:
@@ -57,6 +72,7 @@ When compacting during this workflow, always preserve:
 - All PR numbers and URLs created so far
 - `BUILD_CMD`, `TEST_CMD`, `PROJECT_TYPE`, `WORKTREE_DIR`, `REPO_DIR` values
 - `VCS_HOST`, `CLI_TOOL`, `DEFAULT_BRANCH`, `CURRENT_BRANCH`
+- `HEAVY_MODE` flag
 
 
 ## Phase 0: Discovery & Setup
@@ -126,6 +142,8 @@ For each dependency, classify it into one of three tiers:
 
 **Tier 1 — ACCEPTABLE (keep without question):**
 Large, widely-audited, foundational libraries. Examples by ecosystem:
+
+**Default mode:**
 - **Node.js**: react, next, vue, express, fastify, hono, typescript, eslint, prettier, webpack, vite, jest, vitest, mocha, d3, three, prisma, drizzle, @types/*, tailwindcss, postcss
 - **Rust**: tokio, serde, clap, reqwest, hyper, tracing, sqlx, axum, actix-web
 - **Python**: django, flask, fastapi, sqlalchemy, pandas, numpy, scipy, pytest, requests, httpx, pydantic
@@ -133,8 +151,21 @@ Large, widely-audited, foundational libraries. Examples by ecosystem:
 - **Ruby**: rails, rspec, sidekiq, puma, devise
 - Any dependency with >10M weekly downloads (npm) or equivalent popularity metric for the ecosystem
 
+**Heavy mode (`HEAVY_MODE=true`) — Tier 1 is restricted to foundational frameworks, core platform tooling, and runtimes:**
+- **Node.js**: react, next, vue, express, fastify, typescript, webpack, vite, tailwindcss, postcss, prisma, drizzle
+- **Rust**: tokio, serde, hyper, sqlx, axum, actix-web
+- **Python**: django, flask, fastapi, sqlalchemy, pandas, numpy, scipy, pydantic
+- **Go**: standard library only
+- **Ruby**: rails, puma
+- Download count is NOT a factor — popularity does not exempt a library from replacement
+- Libraries that are wrappers, utilities, CLIs, or single-purpose tools are Tier 2 or 3 regardless of popularity
+- Linting/formatting tools (eslint, prettier) in heavy mode: remain Tier 1 when required by CI or organization-wide standards (do not attempt replacement); otherwise treat as Tier 2 (audit usage, but do not rewrite their behavior)
+- Examples of libraries that DROP from Tier 1 in heavy mode: lodash, chalk, commander, yargs, dotenv, uuid, axios, node-fetch, glob, minimatch, semver, debug, winston, morgan, cors, helmet, body-parser, cookie-parser, compression, color, ora, inquirer, boxen, marked, highlight.js, moment, dayjs, date-fns, underscore, ramda, rxjs (if only basic operators used), jest (if vitest is also present — deduplicate), mocha, d3 (unless the visualization requires it), three (unless 3D rendering is core), rspec, sidekiq, devise, requests, httpx, pytest, clap, reqwest, tracing
+
 **Tier 2 — SUSPECT (audit usage):**
-Smaller libraries that may be doing something we can write ourselves. Indicators:
+Smaller libraries that may be doing something we can write ourselves.
+
+**Default mode indicators:**
 - <1M weekly downloads (npm) or equivalent
 - Single-purpose utility (does one thing)
 - We only use 1-2 functions from it
@@ -142,8 +173,19 @@ Smaller libraries that may be doing something we can write ourselves. Indicators
 - Libraries that replicate functionality available in newer language/runtime versions
 - Abandoned or unmaintained (no commits in 12+ months, open security issues)
 
+**Heavy mode additional indicators** (these move libraries INTO Tier 2 that would otherwise be Tier 1):
+- Any library maintained by an individual or small team (not a major org/foundation)
+- Any library where we use <50% of its API surface
+- Utility collections where we use a handful of functions (lodash, ramda, underscore)
+- HTTP clients when the runtime has built-in fetch (axios, node-fetch, got, superagent)
+- Logging libraries (winston, pino, morgan, debug) — evaluate if a thin wrapper over console suffices
+- CLI argument parsers (commander, yargs, minimist) — evaluate if process.argv parsing is feasible
+- Test runners if multiple are present — deduplicate to one
+
 **Tier 3 — REMOVABLE (strong candidate for replacement):**
 Libraries where the cost of owning the code is clearly lower than the supply chain risk:
+
+**Default mode:**
 - We use a single function that's <50 lines to implement
 - The library wraps a built-in API with minimal added value
 - The library is unmaintained with known vulnerabilities
@@ -154,6 +196,23 @@ Libraries where the cost of owning the code is clearly lower than the supply cha
 - `dotenv` when the runtime supports `--env-file` natively
 - `is-odd`, `is-number`, `left-pad` tier micro-packages
 
+**Heavy mode — Tier 3 expands significantly:**
+All of the above, PLUS:
+- Any library where the replacement is <=300 lines of owned code (up from ~50 in default)
+- Utility libraries where we use any subset of functions, even if heavily used (write an owned utils module)
+- HTTP client wrappers — replace with native `fetch` + a thin owned wrapper
+- Color/terminal libraries regardless of how many functions we use (chalk, colors, kleur, ansi-colors) — write an ANSI utility
+- Argument parsers for CLIs with <20 flags — write a simple parser
+- Environment loaders (dotenv, envalid, env-var) — use runtime flags or write a loader
+- Date libraries if we use <10 functions (moment, dayjs, date-fns) — write owned date helpers
+- Glob/path matching (glob, minimatch, micromatch) if usage is simple — use native `fs.glob` (Node 22+) or write a matcher
+- String utilities (camelcase, slugify, pluralize, humanize) — write the specific transformations used
+- Validation libraries where we use <30% of their schemas (joi, yup, zod) — write focused validators
+- Retry/backoff libraries (p-retry, async-retry) — write a retry function
+- Deep equality/diff (deep-equal, fast-deep-equal, deep-diff) — write what's needed for actual use cases
+- Event emitter libraries (eventemitter3, mitt) — use native EventEmitter or EventTarget
+- Markdown parsers if only rendering basic markdown — consider native or minimal owned parser
+
 Record the full classification as `DEPENDENCY_MAP`.
 
 ### 1c: Usage Analysis (Tier 2 & 3 only)
@@ -171,6 +230,7 @@ Each agent should:
    - **Infeasible** (300+ lines or requires deep domain expertise): keep the dependency
 5. Check if the package has known vulnerabilities: `npm audit`, `cargo audit`, `pip-audit`, etc.
 6. Check last publish date and maintenance status
+7. Check for **consolidation opportunities**: does this package overlap in purpose with another dependency in the project? (e.g., two state managers, two HTTP clients, two date libraries, two test runners). If so, flag which kept dependency could absorb this one's usage
 
 Report format:
 ```
@@ -181,17 +241,40 @@ Report format:
   - Replacement complexity: {Trivial|Moderate|Complex|Infeasible}
   - Maintenance: {last publish date, open issues, known CVEs}
   - Recommendation: **REMOVE** / **KEEP** / **EVALUATE**
+  - Consolidation target: {kept dependency that covers the same purpose, if any — e.g., "redux" for zustand, "dayjs" for moment}
   - Replacement sketch: {brief description of how to replace, if REMOVE}
 ```
 
 Wait for all agents to complete before proceeding.
 
+### 1d: Transitive Dependency Check
+
+Before planning replacements, check whether any REMOVE candidate is also a transitive dependency of a package we are keeping. Removing a direct dependency that remains in the lock file as a transitive dep of a kept package provides zero supply chain benefit — the code is still downloaded, installed, and executable.
+
+For each REMOVE candidate:
+
+1. Check if it appears as a transitive dependency of any Tier 1 or kept Tier 2 package:
+   - **Node.js (npm)**: `npm ls {package}` — check the output for dependents *other than the project root*. Since REMOVE candidates are direct dependencies, they always appear at the top level; the signal is whether a kept dependency *also* depends on them (shown as a nested entry under that kept package's tree)
+   - **Node.js (yarn)**: `yarn why {package}` — check if any kept dependency requires it
+   - **Node.js (pnpm)**: `pnpm why {package}` — same check
+   - **Rust**: `cargo tree -i {package}` — check if a kept crate depends on it
+   - **Python**: use a reverse dependency tree, e.g. `pipdeptree -r -p {package}` or `uv pip tree --invert | grep {package}`, and check whether any kept package depends on it (record the full chain)
+   - **Go**: `go mod graph | grep {package}` — check if a kept module requires it
+   - **Ruby**: `bundle why {gem}` — shows the dependency chain explaining why the gem is in the bundle; check if any kept gem appears in the chain
+2. If the package IS a transitive dependency of a kept package, determine the **removal motivation**:
+   - **Supply chain only** — the package was flagged purely for attack surface reduction (e.g., small/unmaintained utility). Downgrade to **KEEP (transitive)** because removing the direct entry doesn't remove the code from the lock file or the runtime.
+   - **Consolidation** — the package overlaps in purpose with another kept dependency and removal unifies the codebase around one solution (e.g., zustand→redux, moment→dayjs, lodash→native utils). Keep the **REMOVE** recommendation — the value is in eliminating redundant usage from *our* code, not in shrinking the lock file. Record the consolidation target (e.g., "consolidate state management into redux").
+   - Record the dependency chain in either case, root-to-leaf (e.g., `@react-three/fiber → tunnel-rat → zustand`)
+3. Exception: if the direct dependency pulls a **different major version** than the transitive one, removal still eliminates that version from the dependency tree. In this case, keep the REMOVE recommendation but note the version difference.
+
+Update `DEPENDENCY_MAP` with transitive check results before proceeding to Phase 2.
+
 
 ## Phase 2: Replacement Plan
 
 1. Read the existing `PLAN.md` (create if it doesn't exist)
-2. Filter to only REMOVE recommendations from Phase 1c
-3. For EVALUATE recommendations: **Default mode** — treat as KEEP (conservative). **Interactive mode** — present to user via `AskUserQuestion` for each
+2. Filter to only REMOVE recommendations from Phase 1c/1d (exclude any downgraded to KEEP (transitive) in Phase 1d)
+3. For EVALUATE recommendations: **Default mode** — treat as KEEP (conservative). **Heavy mode** — treat as REMOVE (aggressive). **Interactive mode** — present to user via `AskUserQuestion` for each. If both `--interactive` and `--heavy` are set, still prompt for each EVALUATE item (interactive takes precedence), but present REMOVE as the default suggestion
 4. Group removable dependencies by replacement strategy:
    - **Native replacement**: built-in API replaces the library (e.g., `crypto.randomUUID()`)
    - **Inline replacement**: write a small utility function (e.g., ANSI color wrapper)
@@ -210,6 +293,16 @@ Estimated replacement code: ~{lines} lines across {files} new/modified files.
 |---------|------|---------------|------------|-------------|------------|------|
 | ...     | ...  | ...           | ...        | ...         | ...        | ...  |
 
+### Dependencies to Remove — Consolidation (transitive dep of kept package, but redundant with another kept dep)
+| Package | Tier | Consolidation Target | Transitive Via |
+|---------|------|---------------------|----------------|
+| ...     | ...  | ...                 | ...            |
+
+### Dependencies Kept — Transitive (would remain in lock file, no consolidation value)
+| Package | Tier | Kept Via (dependency chain) |
+|---------|------|-----------------------------|
+| ...     | ...  | ...                         |
+
 ### Dependencies Kept (with rationale)
 | Package | Tier | Reason Kept |
 |---------|------|-------------|
@@ -296,7 +389,7 @@ Steps:
 - Do NOT introduce new dependencies to replace old ones
 - Do NOT use `git add -A` or `git add .` — stage specific files only
 - Keep replacement code minimal
-- If replacement is more complex than estimated (>2x the estimated lines), report back and skip — do not force a bad replacement
+- If replacement is more complex than estimated (>2x the estimated lines), report back and skip — do not force a bad replacement. In `HEAVY_MODE`, the ceiling is 300 lines per replacement — only skip if replacement requires deep domain expertise (crypto primitives, binary protocol parsers, codec implementations) or exceeds 300 lines
 - Place shared utility replacements in a sensible location (e.g., `src/utils/`, `lib/`, `internal/`) following existing project conventions
 - Commit each replacement independently: `refactor: replace {package} with owned {utility/code}`
 </guardrails>
@@ -396,10 +489,15 @@ Create the PR:
 
 **GitHub:**
 ```bash
-gh pr create --head depfree/{DATE} --base {DEFAULT_BRANCH} \
-  --title "refactor: remove {N} unnecessary dependencies" \
-  --body "$(cat <<'EOF'
-## Depfree Audit — Dependency Removal
+HEAVY_SUFFIX=""
+HEAVY_HEADING=""
+if [ "$HEAVY_MODE" = "true" ]; then
+  HEAVY_SUFFIX=" (heavy mode)"
+  HEAVY_HEADING=" (Heavy Mode)"
+fi
+
+PR_TITLE="refactor: remove {N} unnecessary dependencies${HEAVY_SUFFIX}"
+PR_BODY="## Depfree Audit — Dependency Removal${HEAVY_HEADING}
 
 ### Summary
 Removed {N} unnecessary third-party dependencies and replaced with owned code.
@@ -420,9 +518,11 @@ Estimated supply chain attack surface reduction: {N} packages ({transitive count
 - [ ] Build passes
 - [ ] All tests pass
 - [ ] No phantom references to removed packages
-- [ ] Lock file updated
-EOF
-)"
+- [ ] Lock file updated"
+
+gh pr create --head depfree/{DATE} --base {DEFAULT_BRANCH} \
+  --title "$PR_TITLE" \
+  --body "$PR_BODY"
 ```
 
 **GitLab:**
@@ -522,8 +622,10 @@ Transitive deps eliminated: ~{count} (estimated)
 
 - This command complements `/do:better` — run `depfree` for dependency hygiene, `better` for code quality
 - All remediation happens in an isolated worktree — the user's working directory is never modified
-- The threshold for "acceptable" libraries is deliberately generous — the goal is to remove obvious attack surface, not to rewrite everything
+- **Default mode**: the threshold for "acceptable" libraries is deliberately generous — the goal is to remove obvious attack surface, not to rewrite everything
+- **Heavy mode**: the threshold narrows to foundational frameworks only — the goal is to own as much code as feasibly possible, eliminating supply chain risk from individual maintainers and small projects
 - Replacement code should be minimal and focused — don't over-engineer utilities that replace single-purpose packages
-- When in doubt, keep the dependency. A maintained library is better than a buggy reimplementation
-- devDependencies are lower priority since they don't ship to production, but unmaintained build tools still pose supply chain risk
+- **Default mode**: when in doubt, keep the dependency. A maintained library is better than a buggy reimplementation
+- **Heavy mode**: when in doubt, replace it. Write owned code unless the replacement requires crypto primitives, binary protocol parsing, or deep domain expertise that would be unsafe to reimplement
+- **Default mode**: devDependencies are lower priority since they don't ship to production. **Heavy mode**: devDependencies are audited on par with production deps — unmaintained build tools still pose supply chain risk
 - For monorepos, audit the root manifest and each workspace package manifest

package/commands/do/help.md

@@ -14,7 +14,7 @@ List all available `/do:*` commands with their descriptions.
 |---|---|
 | `/do:better` | Unified DevSecOps audit, remediation, per-category PRs, CI verification, and Copilot review loop |
 | `/do:better-swift` | SwiftUI-optimized DevSecOps audit with multi-platform coverage (iOS, macOS, watchOS, tvOS, visionOS) |
-| `/do:depfree` | Audit third-party dependencies and remove unnecessary ones by writing replacement code |
+| `/do:depfree` | Audit third-party dependencies and remove unnecessary ones by writing replacement code. Use `--heavy` for aggressive mode that targets all non-foundational libraries for replacement where feasible |
 | `/do:fpr` | Commit, push to fork, and open a PR against the upstream repo |
 | `/do:goals` | Scan codebase to infer project goals, clarify with user, and generate GOALS.md |
 | `/do:help` | List all available slashdo commands |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "slash-do",
-  "version": "2.5.0",
+  "version": "2.7.0",
   "description": "Curated slash commands for AI coding assistants — Claude Code, OpenCode, Gemini CLI, and Codex",
   "author": "Adam Eivy <adam@eivy.com>",
   "license": "MIT",