slash-do 1.0.0 → 1.2.0

package/bin/cli.js

@@ -208,7 +208,11 @@ async function main() {
   }
 }
 
-main().catch(err => {
-  console.error('Error:', err.message);
-  process.exit(1);
-});
+if (require.main === module) {
+  main().catch(err => {
+    console.error('Error:', err.message);
+    process.exit(1);
+  });
+}
+
+module.exports = { parseArgs };

package/commands/do/better.md

@@ -13,6 +13,42 @@ Parse `$ARGUMENTS` for:
 - **Path filter**: limit scanning scope to specific directories or files
 - **Focus areas**: e.g., "security only", "DRY and bugs"
 
+## Configuration
+
+Before starting the pipeline, 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 fixes (highest cost, 7+ Opus agents)" },
+      { 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 agent models from this table:
+
+| Agent Role | Quality | Balanced | Budget |
+|------------|---------|----------|--------|
+| Audit agents (7 Explore agents, Phase 1) | opus | sonnet | haiku |
+| Remediation agents (general-purpose, Phase 3) | opus | sonnet | sonnet |
+
+Derive two variables:
+- `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/Task call so the agent inherits the session's Opus version. This avoids version conflicts when organizations pin specific Opus versions.
+
+### Model Profile Rationale
+
+Opus reduces false positives in audit (judgment-heavy). Sonnet is the floor for code-writing agents (remediation). Haiku works for fast first-pass pattern scanning but may produce more false positives — remediation agents (Sonnet+) validate before fixing.
+
 ## Phase 0: Discovery & Setup
 
 Detect the project environment before any scanning or remediation.
@@ -41,7 +77,7 @@ Derive build and test commands from the project type:
 - Rust: `cargo build`, `cargo test`
 - Python: `pytest`, `python -m pytest`
 - Go: `go build ./...`, `go test ./...`
-- If ambiguous, check CLAUDE.md for documented commands
+- If ambiguous, check project conventions already in context for documented commands
 
 Record as `BUILD_CMD` and `TEST_CMD`.
 
@@ -64,7 +100,7 @@ This ensures the browser is ready before we need it in Phase 6, avoiding interru
 
 ## Phase 1: Unified Audit
 
-Read the project's CLAUDE.md files first to understand conventions. Pass relevant conventions to each agent.
+Project conventions are already in your context. Pass relevant conventions to each agent.
 
 Launch 7 Explore agents in two batches. Each agent must report findings in this format:
 ```
@@ -81,6 +117,8 @@ If the surrounding context shows the code is correct, do NOT flag it.
 
 ### Batch 1 (5 parallel Explore agents via Task tool):
 
+**Model**: Pass `AUDIT_MODEL` as the `model` parameter on each agent. If `AUDIT_MODEL` is `opus`, omit the parameter to inherit from session.
+
 1. **Security & Secrets**
    Sources: authentication checks, credential exposure, infrastructure security, input validation, dependency health
    Focus: hardcoded credentials, API keys, exposed secrets, authentication bypasses, disabled security checks, PII exposure, injection vulnerabilities (SQL/command/path traversal), insecure CORS configurations, missing auth checks, unsanitized user input in file paths or queries, known CVEs in dependencies (check `npm audit` / `cargo audit` / `pip-audit` / `go vuln` output), abandoned or unmaintained dependencies, overly permissive dependency version ranges
@@ -103,6 +141,8 @@ If the surrounding context shows the code is correct, do NOT flag it.
 
 ### Batch 2 (2 agents after Batch 1 completes):
 
+**Model**: Same `AUDIT_MODEL` as Batch 1.
+
 6. **Stack-Specific**
    Dynamically focus based on `PROJECT_TYPE` detected in Phase 0:
    - **Node/React**: missing cleanup in useEffect, stale closures, unstable deps arrays, duplicate hooks across components, re-created functions inside render, missing AbortController, bundle size concerns (large imports that could be tree-shaken or lazy-loaded)
@@ -223,7 +263,7 @@ If no shared utilities were identified, skip this step.
    - Bugs, Performance & Error Handling
    - Stack-Specific
 3. Only create tasks for categories that have actionable findings
-4. Spawn up to 5 general-purpose agents as teammates
+4. Spawn up to 5 general-purpose agents as teammates. **Pass `REMEDIATION_MODEL` as the `model` parameter on each agent.** If `REMEDIATION_MODEL` is `opus`, omit the parameter to inherit from session.
 
 ### Agent instructions template:
 ```
@@ -431,7 +471,6 @@ If `BROWSER_AUTHENTICATED` is not true (e.g., Phase 0e was skipped or failed):
 1. Navigate to the first PR URL using `browser_navigate`
 2. Check for user avatar/menu
 3. If not logged in: navigate to `https://github.com/login`, inform the user **"Please log in to GitHub in the browser. I'll wait for you to confirm."**, and use `AskUserQuestion` to wait
-4. Do NOT close the browser at any point during this phase
 
 ### 6.1: Request Copilot reviews on all PRs
 
@@ -450,17 +489,16 @@ If this returns 422 ("not a collaborator"), **fall back to Playwright** for each
 
 ### 6.2: Poll for review completion
 
-For each PR, poll every 15 seconds, max 3 minutes (12 polls):
-```bash
-gh api repos/{OWNER}/{REPO}/pulls/{PR_NUMBER}/reviews --jq '.[] | "\(.user.login): \(.state)"'
-```
+**Dynamic poll timing**: Before your first poll, check how long the most recent Copilot review on this PR took by comparing consecutive Copilot review `submittedAt` timestamps (or PR creation time for the first review). Use that duration as your expected wait. If no prior review exists, default to 5 minutes. Set poll interval to 60 seconds and max wait to **2x the expected duration** (minimum 5 minutes, maximum 20 minutes). Copilot reviews can take **10-15 minutes** for large diffs — do NOT give up early.
 
-Also check for inline comments:
+For each PR, poll using GraphQL to check for a new Copilot review:
 ```bash
-gh api repos/{OWNER}/{REPO}/pulls/{PR_NUMBER}/comments --jq '.[] | "\(.user.login) [\(.path):\(.line)]: \(.body[:120])"'
+echo '{"query":"{ repository(owner: \"OWNER\", name: \"REPO\") { pullRequest(number: PR_NUM) { reviews(last: 5) { nodes { state body author { login } submittedAt } } reviewThreads(first: 100) { nodes { id isResolved comments(first: 3) { nodes { body path line author { login } } } } } } } }"}' | gh api graphql --input -
 ```
 
-The review is complete when a `copilot[bot]` or `copilot-pull-request-reviewer[bot]` review appears.
+The review is complete when a new `copilot-pull-request-reviewer[bot]` review appears with a `submittedAt` after your request. If no review appears after max wait, **ask the user** whether to continue waiting, re-request, or skip.
+
+**Error detection**: After a review appears, check its `body` for error text such as "Copilot encountered an error" or "unable to review this pull request". If found, this is NOT a successful review — log a warning, re-request the review (step 6.1), and resume polling from 6.2. Allow up to 3 error retries per PR before asking the user whether to continue or skip.
 
 ### 6.3: Check for unresolved threads
 
@@ -564,7 +602,6 @@ If merge fails (e.g., branch protection, merge conflicts from a prior PR):
 - **Copilot timeout** (review not received within 3 min): inform user, offer to merge without review approval or wait longer
 - **Copilot review loop exceeds 5 iterations per PR**: stop iterating on that PR, inform user, proceed to merge
 - **Existing worktree found at startup**: ask user — resume (reuse worktree) or cleanup (remove and start fresh)
-- **`gh auth status` / `glab auth status` failure**: halt and tell user to authenticate first
 - **No findings above LOW**: skip Phases 3-7, print "No actionable findings" with the LOW summary
 - **Browser not authenticated**: use `AskUserQuestion` to ask the user to log in — never skip this or close the browser
 - **Merge conflict after prior PR merged**: rebase the branch onto the updated default branch, push with `--force-with-lease`, re-run CI
@@ -580,8 +617,5 @@ If merge fails (e.g., branch protection, merge conflicts from a prior PR):
 - When extracting modules, always add backward-compatible re-exports in the original module to prevent cross-PR breakage
 - Version bump happens exactly once on the first category branch based on aggregate commit analysis
 - Only CRITICAL, HIGH, and MEDIUM findings are auto-remediated; LOW and Test Coverage remain tracked in PLAN.md
-- Do not include co-author or generated-by info in any commits, PRs, or output
 - GitLab projects skip the Copilot review loop entirely (Phase 6) and stop after MR creation
-- Always run `gh auth status` (or `glab auth status`) before any authenticated operation
-- The Playwright browser should be opened early (Phase 0e) and kept open throughout — never close it prematurely
 - CI must pass on each PR before requesting Copilot review or merging

package/commands/do/fpr.md

@@ -94,14 +94,10 @@ gh pr create \
 
 - Write a clear title and rich description
 - If a PR template was found, follow its structure
-- Do NOT include co-author or "generated with" messages
 - Print the resulting PR URL so the user can review it
 
 ## Important
 
-- Never stage files you didn't edit
-- Never use `git add -A` or `git add .`
-- Do NOT bump versions or update changelogs — upstream maintainers control those
 - Do NOT merge the PR — upstream maintainers handle that
 - Do NOT run Copilot review loops — you don't control the upstream repo's review settings
 - If the fork is significantly behind upstream, warn the user about potential merge conflicts

package/commands/do/pr.md

@@ -32,7 +32,7 @@ Before creating the PR, perform a thorough self-review. Read each changed file
 ## Open the PR
 
 - Create a PR from `{current_branch}` to `{default_branch}`
-- Create a rich PR description — no co-author or "generated with" messages
+- Create a rich PR description
 
 **IMPORTANT**: During each fix cycle in the Copilot review loop below, after fixing all review comments and before pushing, also bump the patch version (`npm version patch --no-git-tag-version` or equivalent) and commit the version bump.
 

package/commands/do/push.md

@@ -10,6 +10,7 @@ Commit and push all work from this session, updating documentation as needed.
 
 1. **Identify changes to commit**:
    - Run `git status` and `git diff --stat` to see what changed
+   - If there are no changes to commit, inform the user and stop
    - If you edited files in this session, commit only those files
    - If invoked without prior edit context, review all uncommitted changes
    - if there are files that should be added to the .gitignore that are not yet there, ensure we have proper .gitignore coverage
@@ -47,11 +48,3 @@ Commit and push all work from this session, updating documentation as needed.
 
 5. **Push the changes**:
    - Use `git pull --rebase --autostash && git push` to push safely
-
-## Important
-
-- Never stage files you didn't edit
-- Never use `git add -A` or `git add .`
-- Keep commit messages focused on the "why" not just the "what"
-- If there are no changes to commit, inform the user
-- Do NOT bump the version in package.json — `/release` handles versioning

package/commands/do/release.md

@@ -6,22 +6,30 @@ description: Create a release PR using the project's documented release workflow
 
 Before doing anything, determine the project's source and target branches for releases. Do NOT hardcode branch names. Instead, discover them:
 
-1. **Source branch** — run `gh repo view --json defaultBranchRef -q '.defaultBranchRef.name'` to get the repo's default branch
+1. **Source branch** — run `gh repo view --json defaultBranchRef -q '.defaultBranchRef.name'` to get the repo's default branch (typically `main`)
 2. **Target branch** — determine by reading (in priority order):
    - **GitHub Actions workflows** — check `.github/workflows/release.yml` (or similar) for `on: push: branches:` to find the branch that triggers the release pipeline
-   - **Project CLAUDE.md** — look for git workflow sections, branch descriptions, or release instructions
+   - **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
+3. **Ensure the target branch exists** — if not, create it from the last release tag:
+   ```bash
+   git branch release $(git describe --tags --abbrev=0)
+   git push -u origin release
+   ```
+   This ensures the PR diff shows ALL changes since the last release, not just the version bump.
 
 Print the detected workflow: `Detected release flow: {source} → {target}`
 
 If ambiguous, 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.
+
 ## Pre-Release Checks
 
 1. **Ensure you're on the source branch** — checkout if needed
 2. **Pull latest** — `git pull --rebase --autostash`
-3. **Run tests** — execute the project's test suite (check CLAUDE.md or package.json for the command)
+3. **Run tests** — execute the project's test suite (per project conventions already in context, or check package.json)
 4. **Run build** — execute the project's build command if one exists
 
 ## Determine Version and Finalize Changelog
@@ -63,8 +71,11 @@ Perform a thorough self-review. Read each changed file — not just the diff —
 
 ## Open the Release PR
 
-- Push the source branch to remote
-- Create a PR from `{source}` to `{target}`
+- Push the source branch to remote (it should already be up to date with the release commit)
+- Create a PR from `{source}` → `{target}` (e.g., `main` → `release`)
+  ```bash
+  gh pr create --title "Release v{version}" --base {target} --head {source} --body "..."
+  ```
 - Title: `Release v{version}` (read version from package.json or equivalent)
 - Body: include the changelog content for this version if available, otherwise summarize commits since last release
 - Keep the description clean — no co-author or "generated with" messages
@@ -91,6 +102,12 @@ Perform a thorough self-review. Read each changed file — not just the diff —
 
 ## Post-Merge
 
-- Report the final status including version, PR URL, and merge state
-- Remind the user to check for the GitHub release once CI completes (if the project uses automated releases)
-- Switch back to the source branch locally: `git checkout {source} && git pull --rebase --autostash`
+1. **Tag the release** on the target branch to trigger the publish workflow:
+   ```bash
+   git fetch origin {target}
+   git tag v{version} origin/{target}
+   git push origin v{version}
+   ```
+2. **Switch back to the source branch** locally: `git checkout {source} && git pull --rebase --autostash`
+3. **Report the final status** including version, PR URL, tag, and merge state
+4. Remind the user to check for the GitHub release once CI completes (if the project uses automated releases)

package/commands/do/review.md

@@ -13,19 +13,54 @@ argument-hint: "[base-branch]"
 
 If there are no changes, inform the user and stop.
 
-## Read Project Conventions
+## Apply Project Conventions
 
-Read the project's CLAUDE.md (if it exists) to understand:
-- Code style rules, error handling patterns, logging conventions
-- Custom error classes, validation patterns, framework-specific rules
-- Any explicit security model or scope exclusions
-
-These conventions override generic best practices. For example, if CLAUDE.md says "no auth needed — internal tool", do not flag missing authentication.
+CLAUDE.md is already loaded into your context. Use its rules (code style, error handling, logging, security model, scope exclusions) as overrides to generic best practices throughout this review. For example, if CLAUDE.md says "no auth needed — internal tool", do not flag missing authentication.
 
 ## Deep File Review
 
 For **each changed file** in the diff, read the **entire file** (not just diff hunks). Reviewing only the diff misses context bugs where new code interacts incorrectly with existing code.
 
+### Understand the Code Flow
+
+Before checking individual files against the checklist, **map the flow of changed code across all files**. This means:
+
+1. **Trace call chains** — for each new or modified function/method, identify every caller and callee across the changed files. Read those files too if needed. You cannot evaluate whether code is duplicated or well-structured without knowing how it connects.
+2. **Identify shared data paths** — trace data from entry point (route handler, event listener, CLI arg) through transforms, storage, and output. Understand what each layer is responsible for.
+3. **Map responsibilities** — for each changed module/file, state its single responsibility in one sentence. If you can't, it may be doing too much.
+
+### Evaluate Software Engineering Principles
+
+With the flow understood, evaluate the changed code against these principles:
+
+**DRY (Don't Repeat Yourself)**
+- Look for logic duplicated across changed files or between changed and existing code. Grep for similar function signatures, repeated conditional blocks, or copy-pasted patterns with minor variations.
+- If two functions do nearly the same thing with small differences, they should likely share a common implementation with the differences parameterized.
+- Duplicated validation, error formatting, or data transformation are common violations.
+
+**YAGNI (You Ain't Gonna Need It)**
+- Flag abstractions, config options, parameters, or extension points that serve no current use case. Code should solve the problem at hand, not hypothetical future problems.
+- Unnecessary wrapper functions, premature generalization (e.g., a factory that produces one type), and unused feature flags are common violations.
+
+**SOLID Principles**
+- **Single Responsibility** — each module/function should have one reason to change. If a function handles both business logic and I/O formatting, flag it.
+- **Open/Closed** — new behavior should be addable without modifying existing working code where practical (e.g., strategy patterns, plugin hooks).
+- **Liskov Substitution** — if subclasses or interface implementations exist, verify they are fully substitutable without breaking callers.
+- **Interface Segregation** — callers should not depend on methods they don't use. Large config objects or option bags passed through many layers are a smell.
+- **Dependency Inversion** — high-level modules should not import low-level implementation details directly when an abstraction boundary would be cleaner.
+
+**Separation of Concerns**
+- Business logic should not be tangled with transport (HTTP, WebSocket), storage (SQL, file I/O), or presentation (HTML, JSON formatting).
+- If a route handler contains business rules beyond simple delegation, flag it.
+
+**Naming & Readability**
+- Function and variable names should communicate intent. If you need to read the implementation to understand what a name means, it's poorly named.
+- Boolean variables/params should read as predicates (`isReady`, `hasAccess`), not ambiguous nouns.
+
+Only flag principle violations that are **concrete and actionable** in the changed code. Do not flag pre-existing design issues in untouched code unless the changes make them worse.
+
+### Per-File Checklist
+
 Check every file against this checklist:
 
 !`cat ~/.claude/lib/code-review-checklist.md`
@@ -50,7 +85,7 @@ For each issue found:
 1. Classify severity: **CRITICAL** (runtime crash, data leak, security) vs **IMPROVEMENT** (consistency, robustness, conventions)
 2. Fix all CRITICAL issues immediately
 3. For IMPROVEMENT issues, fix them too — the goal is to eliminate Copilot review round-trips
-4. After fixes, run the project's test suite and build command (check CLAUDE.md for commands)
+4. After fixes, run the project's test suite and build command (per project conventions already in context)
 5. Commit fixes: `refactor: address code review findings`
 
 ## Report

package/commands/do/rpr.md

@@ -4,7 +4,7 @@ description: Resolve PR review feedback with parallel agents
 
 # Resolve PR Review Feedback
 
-Address the latest code review feedback on the current branch's pull request using a team-based approach.
+Address the latest code review feedback on the current branch's pull request using parallel sub-agents.
 
 ## Steps
 
@@ -18,23 +18,21 @@ Address the latest code review feedback on the current branch's pull request usi
    ```
    Save results to `/tmp/pr_threads.json` for parsing.
 
-4. **Spawn a team to address feedback in parallel**:
-   - Create a team with `TeamCreate`
-   - Create a task for each unresolved review thread using `TaskCreate`
-   - Create an additional task for an **independent code quality review** of all files changed in the PR (`gh pr diff --name-only`)
-   - Spawn sub-agents (general-purpose type) as teammates to handle each task in parallel:
-     - One agent per review thread (or group closely related threads on the same file)
-     - One dedicated agent for the code quality review
-   - Each agent should:
+4. **Spawn parallel sub-agents to address feedback**:
+   - For small PRs (1-3 unresolved threads), handle fixes inline instead of spawning agents
+   - For larger PRs, spawn one `Agent` call (general-purpose type) per review thread (or group closely related threads on the same file into one agent)
+   - Spawn one additional `Agent` call for an **independent code quality review** of all files changed in the PR (`gh pr diff --name-only`)
+   - Launch all Agent calls **in parallel** (multiple tool calls in a single response) and wait for all to return
+   - Each thread-fixing agent should:
      - Read the file and understand the context of the feedback
      - Make the requested code changes if they are accurate and warranted
      - Look for further opportunities to DRY up affected code
-     - Report back what was changed and the thread ID that was addressed
+     - Return what was changed and the thread ID that was addressed
    - The code quality reviewer should:
      - Read all changed files in the PR
      - Check for: style violations, missing error handling, dead code, DRY violations, security issues
-     - Apply fixes directly and report what was changed
-   - Wait for all agents to complete, then review their changes
+     - Apply fixes directly and return what was changed
+   - After all agents return, review their changes for conflicts or overlapping edits
 
 5. **Run tests**: Run the project's test suite to verify all changes pass. Do not proceed if tests fail — fix issues first.
 
@@ -68,18 +66,19 @@ Verify the request was accepted by checking that `Copilot` appears in the respon
 
 ### Poll for review completion
 
-Poll every 30 seconds using GraphQL to check for a new review with a `submittedAt` timestamp after the request:
+Poll using GraphQL to check for a new review with a `submittedAt` timestamp after the request:
 ```bash
 gh api graphql -f query='{ repository(owner: "OWNER", name: "REPO") { pullRequest(number: PR_NUM) { reviews(last: 3) { nodes { state body author { login } submittedAt } } reviewThreads(first: 100) { nodes { id isResolved comments(first: 3) { nodes { body path line author { login } } } } } } } }'
 ```
 
-Copilot reviews typically take 60-120 seconds. The review is complete when a new `copilot-pull-request-reviewer` review node appears.
+**Dynamic poll timing**: Before your first poll, check how long the most recent Copilot review on this PR took by comparing consecutive Copilot review `submittedAt` timestamps (or PR creation time for the first review). Use that duration as your expected wait. If no prior review exists, default to 5 minutes. Set poll interval to 60 seconds and max wait to **2x the expected duration** (minimum 5 minutes, maximum 20 minutes). Copilot reviews can take **10-15 minutes** for large diffs — do NOT give up early.
+
+The review is complete when a new `copilot-pull-request-reviewer` review node appears. If no review appears after max wait, **ask the user** whether to continue waiting, re-request, or skip.
+
+**Error detection**: After a review appears, check its `body` for error text such as "Copilot encountered an error" or "unable to review this pull request". If found, this is NOT a successful review — log a warning, re-request the review (same API call above), and resume polling. Allow up to 3 error retries before asking the user whether to continue or skip.
 
 ## Notes
 
 - Only resolve threads where you've actually addressed the feedback
 - If feedback is unclear or incorrect, leave a reply comment instead of resolving
-- Do not include co-author info in commits
-- For small PRs (1-3 threads), sub-agents may be overkill — use judgment on whether to spawn a team or handle inline
 - Always run tests before committing — never push code with known failures
-- Shut down the team after all work is complete

package/hooks/slashdo-check-update.js

@@ -0,0 +1,73 @@
+#!/usr/bin/env node
+// Check for slashdo updates in background, write result to cache
+// Called by SessionStart hook - runs once per session
+
+const fs = require('fs');
+const path = require('path');
+const os = require('os');
+const { spawn } = require('child_process');
+
+const homeDir = os.homedir();
+const cacheDir = path.join(homeDir, '.claude', 'cache');
+const cacheFile = path.join(cacheDir, 'slashdo-update-check.json');
+const versionFile = path.join(homeDir, '.claude', '.slashdo-version');
+
+// Best-effort: silently exit on any setup failure (permissions, read-only FS, etc.)
+try {
+  if (!fs.existsSync(cacheDir)) {
+    fs.mkdirSync(cacheDir, { recursive: true });
+  }
+
+  // Spawn background process so we don't block session start
+  const child = spawn(process.execPath, ['-e', `
+    const fs = require('fs');
+    const { execSync } = require('child_process');
+
+    const cacheFile = ${JSON.stringify(cacheFile)};
+    const versionFile = ${JSON.stringify(versionFile)};
+
+    let installed = '0.0.0';
+    try {
+      if (fs.existsSync(versionFile)) {
+        installed = fs.readFileSync(versionFile, 'utf8').trim();
+      }
+    } catch (e) {}
+
+    // No version file means slashdo isn't installed — skip silently
+    if (installed === '0.0.0') {
+      process.exit(0);
+    }
+
+    let latest = null;
+    try {
+      latest = execSync('npm view slash-do version', { encoding: 'utf8', timeout: 5000, windowsHide: true }).trim();
+    } catch (e) {}
+
+    // Simple semver comparison: only flag update when latest > installed
+    let updateAvailable = false;
+    if (latest && latest !== installed) {
+      const parse = v => (v || '').replace(/^v/, '').replace(/-.+$/, '').split('.').map(Number);
+      const [iM, im, ip] = parse(installed);
+      const [lM, lm, lp] = parse(latest);
+      if ([iM, im, ip, lM, lm, lp].some(isNaN)) { updateAvailable = installed !== latest; }
+      else { updateAvailable = lM > iM || (lM === iM && (lm > im || (lm === im && lp > ip))); }
+    }
+
+    const result = {
+      update_available: updateAvailable,
+      installed,
+      latest: latest || 'unknown',
+      checked: Math.floor(Date.now() / 1000)
+    };
+
+    fs.writeFileSync(cacheFile, JSON.stringify(result));
+  `], {
+    stdio: 'ignore',
+    windowsHide: true,
+    detached: true
+  });
+
+  child.unref();
+} catch (e) {
+  // Hook is best-effort — never break SessionStart
+}

package/hooks/slashdo-statusline.js

@@ -0,0 +1,123 @@
+#!/usr/bin/env node
+// slashdo statusline for Claude Code
+// Shows: model | current task | directory | context usage | update notifications
+
+const fs = require('fs');
+const path = require('path');
+const os = require('os');
+
+// Read JSON from stdin
+let input = '';
+process.stdin.setEncoding('utf8');
+process.stdin.on('data', chunk => input += chunk);
+process.stdin.on('end', () => {
+  try {
+    const data = JSON.parse(input);
+    const model = data.model?.display_name || 'Claude';
+    const dir = data.workspace?.current_dir || process.cwd();
+    const session = data.session_id || '';
+    const remaining = data.context_window?.remaining_percentage;
+
+    // Context window display (shows USED percentage scaled to 80% limit)
+    // Claude Code enforces an 80% context limit, so we scale to show 100% at that point
+    let ctx = '';
+    if (remaining != null) {
+      const rem = Math.round(remaining);
+      const rawUsed = Math.max(0, Math.min(100, 100 - rem));
+      // Scale: 80% real usage = 100% displayed
+      const used = Math.min(100, Math.round((rawUsed / 80) * 100));
+
+      // Write context metrics to bridge file for context-monitor hooks
+      if (session) {
+        try {
+          const safeSession = session.replace(/[^a-zA-Z0-9_-]/g, '');
+          const bridgePath = path.join(os.tmpdir(), `claude-ctx-${safeSession}.json`);
+          const bridgeData = JSON.stringify({
+            session_id: session,
+            remaining_percentage: remaining,
+            used_pct: used,
+            timestamp: Math.floor(Date.now() / 1000)
+          });
+          fs.writeFileSync(bridgePath, bridgeData);
+        } catch (e) {
+          // Silent fail -- bridge is best-effort, don't break statusline
+        }
+      }
+
+      // Build progress bar (10 segments)
+      const filled = Math.floor(used / 10);
+      const bar = '█'.repeat(filled) + '░'.repeat(10 - filled);
+
+      // Color based on scaled usage
+      if (used < 63) {
+        ctx = ` \x1b[32m${bar} ${used}%\x1b[0m`;
+      } else if (used < 81) {
+        ctx = ` \x1b[33m${bar} ${used}%\x1b[0m`;
+      } else if (used < 95) {
+        ctx = ` \x1b[38;5;208m${bar} ${used}%\x1b[0m`;
+      } else {
+        ctx = ` \x1b[5;31m💀 ${bar} ${used}%\x1b[0m`;
+      }
+    }
+
+    // Current task from todos
+    let task = '';
+    const homeDir = os.homedir();
+    const todosDir = path.join(homeDir, '.claude', 'todos');
+    if (session && fs.existsSync(todosDir)) {
+      try {
+        const entries = fs.readdirSync(todosDir);
+        let latestFile = null;
+        let latestMtime = 0;
+        for (const f of entries) {
+          if (!f.startsWith(session) || !f.includes('-agent-') || !f.endsWith('.json')) continue;
+          try {
+            const mt = fs.statSync(path.join(todosDir, f)).mtimeMs;
+            if (mt > latestMtime) { latestMtime = mt; latestFile = f; }
+          } catch (e) {}
+        }
+
+        if (latestFile) {
+          try {
+            const todos = JSON.parse(fs.readFileSync(path.join(todosDir, latestFile), 'utf8'));
+            const inProgress = todos.find(t => t.status === 'in_progress');
+            if (inProgress) task = inProgress.activeForm || '';
+          } catch (e) {}
+        }
+      } catch (e) {
+        // Silently fail on file system errors - don't break statusline
+      }
+    }
+
+    // Update notifications (GSD + slashdo)
+    let updates = '';
+    const gsdCacheFile = path.join(homeDir, '.claude', 'cache', 'gsd-update-check.json');
+    if (fs.existsSync(gsdCacheFile)) {
+      try {
+        const cache = JSON.parse(fs.readFileSync(gsdCacheFile, 'utf8'));
+        if (cache.update_available) {
+          updates += '\x1b[33m⬆ /gsd:update\x1b[0m │ ';
+        }
+      } catch (e) {}
+    }
+    const slashdoCacheFile = path.join(homeDir, '.claude', 'cache', 'slashdo-update-check.json');
+    if (fs.existsSync(slashdoCacheFile)) {
+      try {
+        const cache = JSON.parse(fs.readFileSync(slashdoCacheFile, 'utf8'));
+        if (cache.update_available) {
+          updates += '\x1b[33m⬆ /do:update\x1b[0m │ ';
+        }
+      } catch (e) {}
+    }
+
+    // Output
+    const dirname = path.basename(dir);
+    if (task) {
+      process.stdout.write(`${updates}\x1b[2m${model}\x1b[0m │ \x1b[1m${task}\x1b[0m │ \x1b[2m${dirname}\x1b[0m${ctx}`);
+    } else {
+      process.stdout.write(`${updates}\x1b[2m${model}\x1b[0m │ \x1b[2m${dirname}\x1b[0m${ctx}`);
+    }
+  } catch (e) {
+    // Silent fail - don't break statusline on parse errors
+  }
+});