slash-do 1.9.0 → 2.1.0

package/commands/do/depfree.md

@@ -0,0 +1,525 @@
+---
+description: Audit third-party dependencies and remove unnecessary ones by writing replacement code
+argument-hint: "[--interactive] [--scan-only] [--no-merge] [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.
+
+**Default mode: fully autonomous.** Uses Balanced model profile, proceeds through all phases without prompting.
+
+**`--interactive` mode:** Pauses for classification approval, replacement review, and merge confirmation.
+
+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
+- **Specific packages**: limit audit scope to named packages (e.g., "chalk dotenv")
+
+## Configuration
+
+### Default Mode (autonomous)
+
+Use the **Balanced** model profile automatically (`AUDIT_MODEL=sonnet`, `REMEDIATION_MODEL=sonnet`).
+
+### Interactive Mode (`--interactive`)
+
+Present the user with configuration options using `AskUserQuestion`:
+
+```
+AskUserQuestion([{
+  question: "Which model profile for audit and remediation agents?",
+  header: "Model",
+  multiSelect: false,
+  options: [
+    { label: "Quality", description: "Opus for all agents — fewest false positives, best replacements (highest cost)" },
+    { label: "Balanced (Recommended)", description: "Sonnet for audit and remediation — good quality at moderate cost" },
+    { label: "Budget", description: "Haiku for audit, Sonnet for remediation — fastest and cheapest" }
+  ]
+}])
+```
+
+Record the selection as `MODEL_PROFILE` and derive:
+- `AUDIT_MODEL`: `opus` / `sonnet` / `haiku` based on profile
+- `REMEDIATION_MODEL`: `opus` / `sonnet` / `sonnet` based on profile
+
+When the resolved model is `opus`, **omit** the `model` parameter on the Agent call so the agent inherits the session's Opus version.
+
+## Compaction Guidance
+
+When compacting during this workflow, always preserve:
+- The `DEPENDENCY_MAP` (complete classification of all dependencies)
+- All REMOVABLE findings with package names and usage details
+- The current phase number and what phases remain
+- 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`
+
+
+## Phase 0: Discovery & Setup
+
+### 0a: VCS Host Detection
+Run `gh auth status` to check GitHub CLI. If it fails, run `glab auth status` for GitLab.
+- Set `VCS_HOST` to `github` or `gitlab`
+- Set `CLI_TOOL` to `gh` or `glab`
+- If neither is authenticated, warn the user and halt
+
+### 0b: Project Type Detection
+Check for project manifests to determine the tech stack:
+- `package.json` → Node.js (check for `next`, `react`, `vue`, `express`, etc.)
+- `Cargo.toml` → Rust
+- `pyproject.toml` / `requirements.txt` / `setup.py` → Python
+- `go.mod` → Go
+- `pom.xml` / `build.gradle` → Java/Kotlin
+- `Gemfile` → Ruby
+- `*.csproj` / `*.sln` → .NET
+
+Record the detected stack as `PROJECT_TYPE`.
+
+### 0c: Build & Test Command Detection
+Derive build and test commands from the project type:
+- Node.js: check `package.json` scripts for `build`, `test`, `typecheck`, `lint`
+- Rust: `cargo build`, `cargo test`
+- Python: `pytest`, `python -m pytest`
+- Go: `go build ./...`, `go test ./...`
+- If ambiguous, check project conventions already in context
+
+Record as `BUILD_CMD` and `TEST_CMD`.
+
+### 0d: State Snapshot
+- Record `REPO_DIR` via `git rev-parse --show-toplevel`
+- Record `CURRENT_BRANCH` via `git rev-parse --abbrev-ref HEAD`
+- Record `DEFAULT_BRANCH` via `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` (or `glab` equivalent)
+- Record `IS_DIRTY` via `git status --porcelain`
+
+
+## Phase 1: Dependency Inventory
+
+### 1a: Extract All Dependencies
+
+Based on `PROJECT_TYPE`, extract the full dependency list:
+
+**Node.js:**
+- Read `package.json` → `dependencies` and `devDependencies`
+- Note: `devDependencies` used only in build/test are lower priority but still worth auditing
+- Check for workspace packages (monorepo) in `workspaces` field
+
+**Rust:**
+- Read `Cargo.toml` → `[dependencies]`, `[dev-dependencies]`, `[build-dependencies]`
+
+**Python:**
+- Read `pyproject.toml` → `[project.dependencies]`, `[project.optional-dependencies]`
+- Or `requirements.txt`, `setup.py`
+
+**Go:**
+- Read `go.mod` → `require` block
+
+**Ruby:**
+- Read `Gemfile`
+
+### 1b: Classify Dependencies
+
+For each dependency, classify it into one of three tiers:
+
+**Tier 1 — ACCEPTABLE (keep without question):**
+Large, widely-audited, foundational libraries. Examples by ecosystem:
+- **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
+- **Go**: standard library (no third-party needed for most things)
+- **Ruby**: rails, rspec, sidekiq, puma, devise
+- Any dependency with >10M weekly downloads (npm) or equivalent popularity metric for the ecosystem
+
+**Tier 2 — SUSPECT (audit usage):**
+Smaller libraries that may be doing something we can write ourselves. Indicators:
+- <1M weekly downloads (npm) or equivalent
+- Single-purpose utility (does one thing)
+- We only use 1-2 functions from it
+- Wrapper libraries that add thin abstractions over built-in APIs
+- Libraries that replicate functionality available in newer language/runtime versions
+- Abandoned or unmaintained (no commits in 12+ months, open security issues)
+
+**Tier 3 — REMOVABLE (strong candidate for replacement):**
+Libraries where the cost of owning the code is clearly lower than the supply chain risk:
+- 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
+- The library's functionality is now available natively (e.g., `node:fs/promises` replacing `fs-extra` for most use cases, `structuredClone` replacing `lodash.cloneDeep`, `Array.prototype.flat` replacing `array-flatten`)
+- Color/string utilities where we use 1-2 functions (e.g., using `chalk` just for `chalk.red()` when a 10-line ANSI wrapper suffices)
+- UUID generation when `crypto.randomUUID()` is available
+- Deep merge/clone when `structuredClone` suffices
+- `dotenv` when the runtime supports `--env-file` natively
+- `is-odd`, `is-number`, `left-pad` tier micro-packages
+
+Record the full classification as `DEPENDENCY_MAP`.
+
+### 1c: Usage Analysis (Tier 2 & 3 only)
+
+For each Tier 2 and Tier 3 dependency, launch parallel Explore agents (using `AUDIT_MODEL`) to determine actual usage:
+
+Each agent should:
+1. Search all source files for imports/requires of the package
+2. List every function, class, constant, or type imported from it
+3. Count call sites per imported symbol
+4. Assess complexity of replacement:
+   - **Trivial** (<20 lines): simple wrapper, single utility function, type alias
+   - **Moderate** (20-100 lines): multi-function utility, needs tests, edge cases to handle
+   - **Complex** (100-300 lines): significant logic, crypto, parsing, protocol implementation
+   - **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
+
+Report format:
+```
+- **{package-name}** — Tier {2|3}
+  - Imports: {list of imported symbols}
+  - Call sites: {count} across {N} files
+  - Functions used: {list with brief description of each}
+  - Replacement complexity: {Trivial|Moderate|Complex|Infeasible}
+  - Maintenance: {last publish date, open issues, known CVEs}
+  - Recommendation: **REMOVE** / **KEEP** / **EVALUATE**
+  - Replacement sketch: {brief description of how to replace, if REMOVE}
+```
+
+Wait for all agents to complete before proceeding.
+
+
+## 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
+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)
+   - **Consolidation**: multiple small deps replaced by one owned utility module
+5. Estimate total lines of replacement code needed
+6. Add a new section to PLAN.md:
+
+```markdown
+## Depfree Audit - {YYYY-MM-DD}
+
+Summary: {N} total dependencies. {A} acceptable (Tier 1), {B} audited and kept (Tier 2), {C} to remove (Tier 3).
+Estimated replacement code: ~{lines} lines across {files} new/modified files.
+
+### Dependencies to Remove
+| Package | Tier | Used Functions | Call Sites | Replacement | Complexity | Risk |
+|---------|------|---------------|------------|-------------|------------|------|
+| ...     | ...  | ...           | ...        | ...         | ...        | ...  |
+
+### Dependencies Kept (with rationale)
+| Package | Tier | Reason Kept |
+|---------|------|-------------|
+| ...     | ...  | ...         |
+
+### Replacement Tasks
+For each dependency to remove:
+- [ ] **{package}** — {strategy}. Replace {N} call sites in {M} files. Write {utility name} ({est. lines} lines). Complexity: {level}.
+```
+
+7. Print summary table:
+```
+| Status     | Count | Examples                          |
+|------------|-------|-----------------------------------|
+| Acceptable | ...   | react, express, typescript, ...   |
+| Kept       | ...   | {packages kept with reasons}      |
+| Removable  | ...   | {packages to remove}              |
+| Total      | ...   |                                   |
+```
+
+**GATE: If `--scan-only` was passed, STOP HERE.** Print the summary and exit.
+
+**GATE: If no removable dependencies were found, print "All dependencies are justified" and exit.**
+
+**Interactive mode**: Present the removal plan via `AskUserQuestion`:
+```
+AskUserQuestion([{
+  question: "Dependency removal plan:\n{summary of packages to remove}\n\nProceed with replacement?",
+  options: [
+    { label: "Proceed", description: "Remove all listed dependencies and write replacement code" },
+    { label: "Review individually", description: "Let me approve/reject each removal" },
+    { label: "Abort", description: "Stop here — I'll review the plan manually" }
+  ]
+}])
+```
+
+If "Review individually": present each dependency with REMOVE/KEEP options, then proceed with only approved removals.
+
+
+## Phase 3: Worktree Remediation
+
+### 3a: Setup
+
+1. If `IS_DIRTY` is true: `git stash --include-untracked -m "depfree: pre-audit stash"`
+2. Set `DATE` to today's date in YYYY-MM-DD format
+3. Create the worktree:
+   ```bash
+   git worktree add ../depfree-{DATE} -b depfree/{DATE}
+   ```
+4. Set `WORKTREE_DIR` to `../depfree-{DATE}`
+
+### 3b: Write Replacement Code
+
+For each dependency to remove, spawn a general-purpose agent (using `REMEDIATION_MODEL`) with these instructions:
+
+```
+<context>
+Project type: {PROJECT_TYPE}
+Build command: {BUILD_CMD}
+Test command: {TEST_CMD}
+Working directory: {WORKTREE_DIR} (this is a git worktree — all work happens here)
+</context>
+
+<task>
+Remove the dependency on `{PACKAGE_NAME}` and replace with owned code.
+
+Current usage:
+{USAGE_DETAILS from Phase 1c — imported symbols, call sites, files}
+
+Replacement strategy: {STRATEGY from Phase 2}
+
+Steps:
+1. Write the replacement code (utility function, inline replacement, or native API call)
+2. Update ALL import/require statements across the codebase to use the new code
+3. Remove the package from the manifest ({package.json, Cargo.toml, etc.})
+4. Run `{BUILD_CMD}` to verify compilation
+5. Run `{TEST_CMD}` to verify tests pass
+6. If tests reference the removed package directly (mocking it, importing test helpers from it), update those tests too
+</task>
+
+<guardrails>
+- The replacement must preserve behavior for all currently-used call sites and documented invariants
+- You may omit handling for input shapes or edge cases that are provably unreachable based on {USAGE_DETAILS}, but do not narrow behavior for any actual call site
+- 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
+- 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>
+```
+
+**Parallelization**: Launch up to 5 agents in parallel. If >5 dependencies to remove, batch them. Assign each agent a non-overlapping set of dependencies (no two agents should modify the same files — if overlap exists, group those dependencies into one agent).
+
+### 3c: Lock File Update
+
+After all replacement agents complete:
+1. Remove all replaced packages from the lock file:
+   ```bash
+   cd {WORKTREE_DIR}
+   # Node.js: refresh lockfile only, without running lifecycle scripts
+   npm install --package-lock-only --ignore-scripts
+   # Or: yarn install --mode=update-lockfile --ignore-scripts
+   # Or: pnpm install --lockfile-only --ignore-scripts
+   # Rust: let a check refresh Cargo.lock to reflect manifest changes only
+   cargo check
+   # Python: use the project's lock tool to refresh
+   # poetry lock --no-update
+   # pip-compile requirements.in
+   ```
+2. Commit the lock file update:
+   ```bash
+   git -C {WORKTREE_DIR} add {lock file}
+   git -C {WORKTREE_DIR} commit -m "chore: update lock file after dependency removal"
+   ```
+
+
+## Phase 4: Verification
+
+### 4a: Build & Test
+
+1. Run the full build:
+   ```bash
+   cd {WORKTREE_DIR} && {BUILD_CMD}
+   ```
+2. Run all tests:
+   ```bash
+   cd {WORKTREE_DIR} && {TEST_CMD}
+   ```
+3. If build or tests fail:
+   - Identify which replacement caused the failure
+   - Attempt to fix in a new commit
+   - If unfixable, revert the replacement commit AND re-add the dependency:
+     ```bash
+     git -C {WORKTREE_DIR} revert <sha>
+     ```
+     Note the reverted package as "kept — replacement failed"
+
+### 4b: Internal Code Review
+
+1. Generate the diff:
+   ```bash
+   cd {WORKTREE_DIR} && git diff {DEFAULT_BRANCH}...HEAD
+   ```
+2. Review all replacement code for:
+   - Functional equivalence (does the replacement handle the same inputs/outputs?)
+   - Missing edge cases that the original library handled
+   - Security regressions (e.g., replacing a sanitization library with a naive regex)
+   - Performance regressions (e.g., replacing an optimized parser with O(n^2) code)
+   - Correct error handling at system boundaries
+3. Fix any issues found, commit each fix separately
+
+### 4c: Verify No Phantom Dependencies
+
+Confirm no source file still references a removed package:
+```bash
+cd {WORKTREE_DIR}
+for pkg in {REMOVED_PACKAGES}; do
+  grep -r "$pkg" \
+    --include='*.ts' \
+    --include='*.js' \
+    --include='*.tsx' \
+    --include='*.jsx' \
+    --include='*.py' \
+    --include='*.rs' \
+    --include='*.go' \
+    --include='*.rb' \
+    . && echo "WARN: $pkg still referenced"
+done
+```
+Fix any remaining references.
+
+
+## Phase 5: PR Creation
+
+### 5a: Push & Create PR
+
+```bash
+cd {WORKTREE_DIR}
+git push -u origin depfree/{DATE}
+```
+
+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
+
+### Summary
+Removed {N} unnecessary third-party dependencies and replaced with owned code.
+Estimated supply chain attack surface reduction: {N} packages ({transitive count} including transitive deps).
+
+### Dependencies Removed
+| Package | Replacement | Lines of Owned Code |
+|---------|-------------|-------------------|
+{table of removed packages}
+
+### Dependencies Kept (audited)
+{count} dependencies audited and kept with rationale. See PLAN.md for details.
+
+### Replacement Code
+{bulleted list of new utility files or inline changes}
+
+### Verification
+- [ ] Build passes
+- [ ] All tests pass
+- [ ] No phantom references to removed packages
+- [ ] Lock file updated
+EOF
+)"
+```
+
+**GitLab:**
+```bash
+glab mr create --source-branch depfree/{DATE} --target-branch {DEFAULT_BRANCH} \
+  --title "refactor: remove {N} unnecessary dependencies" --description "..."
+```
+
+Record `PR_NUMBER` and `PR_URL`.
+
+**GATE: If `--no-merge` was passed, STOP HERE.** Print the PR URL and summary.
+
+### 5b: CI Verification
+
+1. Wait 30 seconds for CI to start
+2. Poll CI status:
+   ```bash
+   gh pr checks {PR_NUMBER}
+   ```
+   Poll every 30 seconds, max 10 minutes.
+3. If CI fails:
+   - Fetch failure logs, diagnose, fix, commit, push
+   - Max 3 fix attempts before informing the user
+
+### 5c: Copilot Review Loop (GitHub only)
+
+If `VCS_HOST` is `github`, run the Copilot review loop using the shared template:
+
+!`cat ~/.claude/lib/copilot-review-loop.md`
+
+Pass: `{PR_NUMBER}`, `{OWNER}/{REPO}`, `depfree/{DATE}`, and `{BUILD_CMD}`.
+
+### 5d: Merge
+
+**Default mode**: Auto-merge if review is clean.
+**Interactive mode**: Ask user for merge approval.
+
+```bash
+gh pr merge {PR_NUMBER} --merge
+```
+
+
+## Phase 6: Cleanup
+
+1. Remove the worktree:
+   ```bash
+   git worktree remove {WORKTREE_DIR}
+   ```
+2. Delete the local branch:
+   ```bash
+   git checkout {DEFAULT_BRANCH}
+   git branch -D depfree/{DATE}
+   git push origin --delete depfree/{DATE}
+   ```
+3. Restore stashed changes if applicable:
+   ```bash
+   git stash pop
+   ```
+4. Update PLAN.md:
+   - Mark completed removals with `[x]`
+   - Add PR link
+   - Note any packages that were reverted
+5. Print the final summary:
+
+```
+| Package          | Status   | Replacement              | Lines |
+|------------------|----------|--------------------------|-------|
+| {package}        | Removed  | {utility/native API}     | {N}   |
+| {package}        | Kept     | {reason}                 | —     |
+| {package}        | Reverted | {reason for failure}     | —     |
+
+Total dependencies before: {before}
+Total dependencies after:  {after}
+Packages removed: {count}
+Owned replacement code: ~{lines} lines
+Transitive deps eliminated: ~{count} (estimated)
+```
+
+
+## Error Recovery
+
+- **Agent failure**: continue with remaining agents, note gaps in the summary
+- **Build failure in worktree**: attempt fix; if unfixable, revert the problematic replacement and re-add the dependency
+- **Push failure**: `git pull --rebase --autostash` then retry push
+- **CI failure on PR**: investigate logs, fix, push (max 3 attempts)
+- **Replacement too complex**: if an agent reports that replacement exceeds 2x estimated complexity, skip that dependency and keep it with a note
+- **Test failure from replacement**: if tests fail and the fix isn't obvious, revert the replacement — a working dependency is better than broken owned code
+- **Existing worktree found at startup**: ask user — resume or clean up
+
+!`cat ~/.claude/lib/graphql-escaping.md`
+
+## Notes
+
+- 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
+- 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
+- For monorepos, audit the root manifest and each workspace package manifest

package/commands/do/goals.md

@@ -1,13 +1,18 @@
 ---
-description: Scan codebase to infer project goals, clarify with user, and generate GOALS.md
-argument-hint: "[--refresh] [focus hint, e.g. 'just the CLI']"
+description: Scan codebase to infer project goals and generate GOALS.md (default: fully autonomous; use --interactive to review with user)
+argument-hint: "[--interactive] [--refresh] [focus hint, e.g. 'just the CLI']"
 ---
 
 # Goals — Generate a GOALS.md from Codebase Analysis
 
-Scan the codebase to infer the project's goals, purpose, and direction, then collaborate with the user to produce a comprehensive `GOALS.md` at the repo root.
+Scan the codebase to infer the project's goals, purpose, and direction, then generate a comprehensive `GOALS.md` at the repo root.
+
+**Default mode: fully autonomous.** Scans the codebase, synthesizes goals, and writes GOALS.md without prompting. HIGH and MEDIUM confidence goals are included; LOW confidence goals are included but marked as inferred.
+
+**`--interactive` mode:** Pauses after synthesis to validate purpose, prioritize goals, confirm non-goals, and refine wording with the user.
 
 Parse `$ARGUMENTS` for:
+- **`--interactive`**: pause after synthesis for user validation and refinement
 - **`--refresh`**: re-scan and update an existing GOALS.md rather than creating from scratch
 - **Focus hints**: e.g., "focus on API goals", "just the CLI"
 
@@ -94,29 +99,35 @@ For each goal, assign a confidence level:
 - **MEDIUM** — strongly implied by patterns, architecture, or recent work
 - **LOW** — inferred/speculative, needs user confirmation
 
-## Phase 3: User Clarification
+## Phase 3: Validation
+
+### Default Mode (autonomous)
+
+Skip user clarification. Include all HIGH and MEDIUM confidence goals directly. Include LOW confidence goals but mark them with `(inferred)` so the user can review after generation. Proceed directly to Phase 4.
+
+### Interactive Mode (`--interactive`)
 
 Present the draft to the user and ask targeted questions to resolve uncertainty. Use `AskUserQuestion` for each area that needs input.
 
-### 3a: Purpose Validation
+#### 3a: Purpose Validation
 Show the inferred one-paragraph purpose statement. Ask if it's accurate or needs refinement.
 
-### 3b: Goal Prioritization
+#### 3b: Goal Prioritization
 Present the inferred goals list. For each LOW or MEDIUM confidence goal, ask the user:
 - Is this actually a goal?
 - How would you rephrase it?
 - What priority is it (primary, secondary, stretch)?
 
-### 3c: Missing Goals
+#### 3c: Missing Goals
 Ask: "Are there any goals I missed that aren't yet reflected in the codebase?" Present 2-3 suggested possibilities based on common patterns for this type of project, to prompt the user's thinking.
 
-### 3d: Non-Goals Validation
+#### 3d: Non-Goals Validation
 Present the inferred non-goals. Ask: "Are these accurate? Anything to add or remove?"
 
-### 3e: Target Users
+#### 3e: Target Users
 Present the inferred target user description. Ask if it's accurate.
 
-### 3f: Success Criteria (optional)
+#### 3f: Success Criteria (optional)
 Ask: "Would you like to define measurable success criteria for any of these goals?" Offer examples relevant to the project type (e.g., "support N concurrent users", "< Xms response time", "100% test coverage on core module").
 
 ## Phase 4: Document Generation
@@ -190,9 +201,9 @@ If `--refresh` was passed and `GOALS.md` already exists:
 1. Read the existing `GOALS.md`
 2. Compare existing goals against current codebase state
 3. Identify goals whose status has changed (new progress, completed, abandoned)
-4. Present changes to the user for confirmation
-5. Update the document in-place, preserving user-written content where possible
-6. If any checkbox task lists are found in the existing GOALS.md, flag them and offer to move them to PLAN.md
+4. **Default mode**: Update the document in-place automatically, preserving user-written content where possible. Print a summary of what changed.
+   **Interactive mode (`--interactive`)**: Present changes to the user for confirmation before updating.
+5. If any checkbox task lists are found in the existing GOALS.md, move them to PLAN.md automatically (default) or offer to move them (interactive)
 
 ## Phase 5: Finalize
 
@@ -211,8 +222,8 @@ If `--refresh` was passed and `GOALS.md` already exists:
 ## Notes
 
 - This command is project-agnostic — it reads whatever project signals exist
-- The goal is collaboration: scan first, then refine with the user — never assume
-- LOW confidence inferences should always be validated with the user before inclusion
+- In default mode, scan and generate autonomously; in interactive mode, collaborate with the user
+- LOW confidence inferences are included as `(inferred)` in default mode; validated with the user in interactive mode
 - Preserve the user's voice — if they provide rephrased goals, use their wording verbatim
 - If the project is brand new with minimal code, lean more heavily on user input and less on codebase inference
 - If `gh` CLI is not authenticated, skip issue/PR scanning gracefully — don't halt

package/commands/do/help.md

@@ -14,6 +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: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/commands/do/release.md

@@ -1,7 +1,12 @@
 ---
 description: Create a release PR using the project's documented release workflow
+argument-hint: "[--interactive]"
 ---
 
+**Default mode: fully autonomous.** Auto-detects branches, determines version bump from commits, runs review, creates and merges the release PR without prompting.
+
+**`--interactive` mode:** Pauses for branch confirmation, version approval, and merge confirmation.
+
 ## Detect Release Workflow
 
 Before doing anything, determine the project's source and target branches for releases. Do NOT hardcode branch names. Instead, discover them:
@@ -11,7 +16,7 @@ Before doing anything, determine the project's source and target branches for re
    - **GitHub Actions workflows** — check `.github/workflows/release.yml` (or similar) for `on: push: branches:` to find the branch that triggers the release pipeline
    - **Project conventions** (already in context) — look for git workflow sections, branch descriptions, or release instructions
    - **Versioning docs** — check `docs/VERSIONING.md`, `CONTRIBUTING.md`, or `RELEASING.md`
-   - **Branch convention** — if a `release` branch exists, the target is `release`; otherwise ask the user
+   - **Branch convention** — if a `release` branch exists, the target is `release`; otherwise create it from the last release tag (see step 3 below). In `--interactive` mode, ask the user to confirm
 3. **Ensure the target branch exists** — if not, create it from the last release tag:
    ```bash
    git branch release $(git describe --tags --abbrev=0)
@@ -21,7 +26,7 @@ Before doing anything, determine the project's source and target branches for re
 
 Print the detected workflow: `Detected release flow: {source} → {target}`
 
-If ambiguous, ask the user to confirm before proceeding.
+**Default mode**: If ambiguous, use the most likely branch (prefer `release` if it exists). If the target branch does not exist, create it from the last release tag (see step 3 above). If detection still yields `target == source`, abort with an error — a release PR cannot merge a branch into itself. **Interactive mode (`--interactive`)**: Ask the user to confirm before proceeding.
 
 **Important**: The PR direction is `{source}` → `{target}` (e.g., `main` → `release`). This gives Copilot the full diff of all changes since the last release for review. Do NOT create a branch from source and PR back into it — that only shows the version bump commit.
 
@@ -40,7 +45,7 @@ If ambiguous, ask the user to confirm before proceeding.
      - `feat:` → **minor** bump
      - `fix:`, `chore:`, `docs:`, `refactor:`, `perf:`, `style:`, `test:`, `ci:` → **patch** bump
    - Use the **highest applicable level** across all commits
-   - Present the proposed version to the user for confirmation
+   - **Default mode**: Use the determined version automatically. **Interactive mode (`--interactive`)**: Present the proposed version to the user for confirmation
 
 2. **Bump version**: Run `npm version <major|minor|patch> --no-git-tag-version` to update `package.json` and `package-lock.json`
 
@@ -82,7 +87,7 @@ Checklist to apply to each file:
 
 !`cat ~/.claude/lib/code-review-checklist.md`
 
-Verification — confirm before proceeding:
+Verification — self-check before proceeding (no user prompt needed):
 - [ ] Read every changed file in full (not just diffs)
 - [ ] Checked each file against the relevant checklist tiers
 - [ ] Quoted specific code for each finding