thaddeus 1.0.18 → 1.0.27

package/src/commands/init-verifiers.js

@@ -0,0 +1,258 @@
+const command = {
+    type: 'prompt',
+    name: 'init-verifiers',
+    description: 'Create verifier skill(s) for automated verification of code changes',
+    contentLength: 0, // Dynamic content
+    progressMessage: 'analyzing your project and creating verifier skills',
+    source: 'builtin',
+    async getPromptForCommand() {
+        return [
+            {
+                type: 'text',
+                text: `Use the TodoWrite tool to track your progress through this multi-step task.
+
+## Goal
+
+Create one or more verifier skills that can be used by the Verify agent to automatically verify code changes in this project or folder. You may create multiple verifiers if the project has different verification needs (e.g., both web UI and API endpoints).
+
+**Do NOT create verifiers for unit tests or typechecking.** Those are already handled by the standard build/test workflow and don't need dedicated verifier skills. Focus on functional verification: web UI (Playwright), CLI (Tmux), and API (HTTP) verifiers.
+
+## Phase 1: Auto-Detection
+
+Analyze the project to detect what's in different subdirectories. The project may contain multiple sub-projects or areas that need different verification approaches (e.g., a web frontend, an API backend, and shared libraries all in one repo).
+
+1. **Scan top-level directories** to identify distinct project areas:
+   - Look for separate package.json, Cargo.toml, pyproject.toml, go.mod in subdirectories
+   - Identify distinct application types in different folders
+
+2. **For each area, detect:**
+
+   a. **Project type and stack**
+      - Primary language(s) and frameworks
+      - Package managers (npm, yarn, pnpm, pip, cargo, etc.)
+
+   b. **Application type**
+      - Web app (React, Next.js, Vue, etc.) → suggest Playwright-based verifier
+      - CLI tool → suggest Tmux-based verifier
+      - API service (Express, FastAPI, etc.) → suggest HTTP-based verifier
+
+   c. **Existing verification tools**
+      - Test frameworks (Jest, Vitest, pytest, etc.)
+      - E2E tools (Playwright, Cypress, etc.)
+      - Dev server scripts in package.json
+
+   d. **Dev server configuration**
+      - How to start the dev server
+      - What URL it runs on
+      - What text indicates it's ready
+
+3. **Installed verification packages** (for web apps)
+   - Check if Playwright is installed (look in package.json dependencies/devDependencies)
+   - Check MCP configuration (.mcp.json) for browser automation tools:
+     - Playwright MCP server
+     - Chrome DevTools MCP server
+     - Thaddeus Chrome Extension MCP (browser-use via Thaddeus's Chrome extension)
+   - For Python projects, check for playwright, pytest-playwright
+
+## Phase 2: Verification Tool Setup
+
+Based on what was detected in Phase 1, help the user set up appropriate verification tools.
+
+### For Web Applications
+
+1. **If browser automation tools are already installed/configured**, ask the user which one they want to use:
+   - Use AskUserQuestion to present the detected options
+   - Example: "I found Playwright and Chrome DevTools MCP configured. Which would you like to use for verification?"
+
+2. **If NO browser automation tools are detected**, ask if they want to install/configure one:
+   - Use AskUserQuestion: "No browser automation tools detected. Would you like to set one up for UI verification?"
+   - Options to offer:
+     - **Playwright** (Recommended) - Full browser automation library, works headless, great for CI
+     - **Chrome DevTools MCP** - Uses Chrome DevTools Protocol via MCP
+     - **Thaddeus Chrome Extension** - Uses the Thaddeus Chrome extension for browser interaction (requires the extension installed in Chrome)
+     - **None** - Skip browser automation (will use basic HTTP checks only)
+
+3. **If user chooses to install Playwright**, run the appropriate command based on package manager:
+   - For npm: \`npm install -D @playwright/test && npx playwright install\`
+   - For yarn: \`yarn add -D @playwright/test && yarn playwright install\`
+   - For pnpm: \`pnpm add -D @playwright/test && pnpm exec playwright install\`
+   - For bun: \`bun add -D @playwright/test && bun playwright install\`
+
+4. **If user chooses Chrome DevTools MCP or Thaddeus Chrome Extension**:
+   - These require MCP server configuration rather than package installation
+   - Ask if they want you to add the MCP server configuration to .mcp.json
+   - For Thaddeus Chrome Extension, inform them they need the extension installed from the Chrome Web Store
+
+5. **MCP Server Setup** (if applicable):
+   - If user selected an MCP-based option, configure the appropriate entry in .mcp.json
+   - Update the verifier skill's allowed-tools to use the appropriate mcp__* tools
+
+### For CLI Tools
+
+1. Check if asciinema is available (run \`which asciinema\`)
+2. If not available, inform the user that asciinema can help record verification sessions but is optional
+3. Tmux is typically system-installed, just verify it's available
+
+### For API Services
+
+1. Check if HTTP testing tools are available:
+   - curl (usually system-installed)
+   - httpie (\`http\` command)
+2. No installation typically needed
+
+## Phase 3: Interactive Q&A
+
+Based on the areas detected in Phase 1, you may need to create multiple verifiers. For each distinct area, use the AskUserQuestion tool to confirm:
+
+1. **Verifier name** - Based on detection, suggest a name but let user choose:
+
+   If there is only ONE project area, use the simple format:
+   - "verifier-playwright" for web UI testing
+   - "verifier-cli" for CLI/terminal testing
+   - "verifier-api" for HTTP API testing
+
+   If there are MULTIPLE project areas, use the format \`verifier-<project>-<type>\`:
+   - "verifier-frontend-playwright" for the frontend web UI
+   - "verifier-backend-api" for the backend API
+   - "verifier-admin-playwright" for an admin dashboard
+
+   The \`<project>\` portion should be a short identifier for the subdirectory or project area (e.g., the folder name or package name).
+
+   Custom names are allowed but MUST include "verifier" in the name — the Verify agent discovers skills by looking for "verifier" in the folder name.
+
+2. **Project-specific questions** based on type:
+
+   For web apps (playwright):
+   - Dev server command (e.g., "npm run dev")
+   - Dev server URL (e.g., "http://localhost:3000")
+   - Ready signal (text that appears when server is ready)
+
+   For CLI tools:
+   - Entry point command (e.g., "node ./cli.js" or "./target/debug/myapp")
+   - Whether to record with asciinema
+
+   For APIs:
+   - API server command
+   - Base URL
+
+3. **Authentication & Login** (for web apps and APIs):
+
+   Use AskUserQuestion to ask: "Does your app require authentication/login to access the pages or endpoints being verified?"
+   - **No authentication needed** - App is publicly accessible, no login required
+   - **Yes, login required** - App requires authentication before verification can proceed
+   - **Some pages require auth** - Mix of public and authenticated routes
+
+   If the user selects login required (or partial), ask follow-up questions:
+   - **Login method**: How does a user log in?
+     - Form-based login (username/password on a login page)
+     - API token/key (passed as header or query param)
+     - OAuth/SSO (redirect-based flow)
+     - Other (let user describe)
+   - **Test credentials**: What credentials should the verifier use?
+     - Ask for the login URL (e.g., "/login", "http://localhost:3000/auth")
+     - Ask for test username/email and password, or API key
+     - Note: Suggest the user use environment variables for secrets (e.g., \`TEST_USER\`, \`TEST_PASSWORD\`) rather than hardcoding
+   - **Post-login indicator**: How to confirm login succeeded?
+     - URL redirect (e.g., redirects to "/dashboard")
+     - Element appears (e.g., "Welcome" text, user avatar)
+     - Cookie/token is set
+
+## Phase 4: Generate Verifier Skill
+
+**All verifier skills are created in the project root's \`.claude/skills/\` directory.** This ensures they are automatically loaded when Thaddeus runs in the project.
+
+Write the skill file to \`.claude/skills/<verifier-name>/SKILL.md\`.
+
+### Skill Template Structure
+
+\`\`\`markdown
+---
+name: <verifier-name>
+description: <description based on type>
+allowed-tools:
+  # Tools appropriate for the verifier type
+---
+
+# <Verifier Title>
+
+You are a verification executor. You receive a verification plan and execute it EXACTLY as written.
+
+## Project Context
+<Project-specific details from detection>
+
+## Setup Instructions
+<How to start any required services>
+
+## Authentication
+<If auth is required, include step-by-step login instructions here>
+<Include login URL, credential env vars, and post-login verification>
+<If no auth needed, omit this section>
+
+## Reporting
+
+Report PASS or FAIL for each step using the format specified in the verification plan.
+
+## Cleanup
+
+After verification:
+1. Stop any dev servers started
+2. Close any browser sessions
+3. Report final summary
+
+## Self-Update
+
+If verification fails because this skill's instructions are outdated (dev server command/port/ready-signal changed, etc.) — not because the feature under test is broken — or if the user corrects you mid-run, use AskUserQuestion to confirm and then Edit this SKILL.md with a minimal targeted fix.
+\`\`\`
+
+### Allowed Tools by Type
+
+**verifier-playwright**:
+\`\`\`yaml
+allowed-tools:
+  - Bash(npm:*)
+  - Bash(yarn:*)
+  - Bash(pnpm:*)
+  - Bash(bun:*)
+  - mcp__playwright__*
+  - Read
+  - Glob
+  - Grep
+\`\`\`
+
+**verifier-cli**:
+\`\`\`yaml
+allowed-tools:
+  - Tmux
+  - Bash(asciinema:*)
+  - Read
+  - Glob
+  - Grep
+\`\`\`
+
+**verifier-api**:
+\`\`\`yaml
+allowed-tools:
+  - Bash(curl:*)
+  - Bash(http:*)
+  - Bash(npm:*)
+  - Bash(yarn:*)
+  - Read
+  - Glob
+  - Grep
+\`\`\`
+
+
+## Phase 5: Confirm Creation
+
+After writing the skill file(s), inform the user:
+1. Where each skill was created (always in \`.claude/skills/\`)
+2. How the Verify agent will discover them — the folder name must contain "verifier" (case-insensitive) for automatic discovery
+3. That they can edit the skills to customize them
+4. That they can run /init-verifiers again to add more verifiers for other areas
+5. That the verifier will offer to self-update if it detects its own instructions are outdated (wrong dev server command, changed ready signal, etc.)
+`,
+            },
+        ];
+    },
+};
+export default command;

package/src/commands/init.js

@@ -0,0 +1,248 @@
+import { feature } from 'bun:bundle';
+import { maybeMarkProjectOnboardingComplete } from '../projectOnboardingState.js';
+import { isEnvTruthy } from '../utils/envUtils.js';
+const OLD_INIT_PROMPT = `Please analyze this codebase and create a THADDEUS.md file, which will be given to future instances of Thaddeus to operate in this repository.
+
+What to add:
+1. Commands that will be commonly used, such as how to build, lint, and run tests. Include the necessary commands to develop in this codebase, such as how to run a single test.
+2. High-level code architecture and structure so that future instances can be productive more quickly. Focus on the "big picture" architecture that requires reading multiple files to understand.
+
+Usage notes:
+- If there's already a THADDEUS.md, suggest improvements to it.
+- When you make the initial THADDEUS.md, do not repeat yourself and do not include obvious instructions like "Provide helpful error messages to users", "Write unit tests for all new utilities", "Never include sensitive information (API keys, tokens) in code or commits".
+- Avoid listing every component or file structure that can be easily discovered.
+- Don't include generic development practices.
+- If there are Cursor rules (in .cursor/rules/ or .cursorrules) or Copilot rules (in .github/copilot-instructions.md), make sure to include the important parts.
+- If there is a README.md, make sure to include the important parts.
+- Do not make up information such as "Common Development Tasks", "Tips for Development", "Support and Documentation" unless this is expressly included in other files that you read.
+- Be sure to prefix the file with the following text:
+
+\`\`\`
+# THADDEUS.md
+
+This file provides guidance to Thaddeus when working with code in this repository.
+\`\`\``;
+const NEW_INIT_PROMPT = `Set up a minimal THADDEUS.md (and optionally skills and hooks) for this repo. THADDEUS.md is loaded into every Thaddeus session, so it must be concise — only include what Thaddeus would get wrong without it.
+
+## Phase 1: Ask what to set up
+
+Use AskUserQuestion to find out what the user wants:
+
+- "Which THADDEUS.md files should /init set up?"
+  Options: "Project THADDEUS.md" | "Personal THADDEUS.local.md" | "Both project + personal"
+  Description for project: "Team-shared instructions checked into source control — architecture, coding standards, common workflows."
+  Description for personal: "Your private preferences for this project (gitignored, not shared) — your role, sandbox URLs, preferred test data, workflow quirks."
+
+- "Also set up skills and hooks?"
+  Options: "Skills + hooks" | "Skills only" | "Hooks only" | "Neither, just THADDEUS.md"
+  Description for skills: "On-demand capabilities you or Thaddeus invoke with \`/skill-name\` — good for repeatable workflows and reference knowledge."
+  Description for hooks: "Deterministic shell commands that run on tool events (e.g., format after every edit). Thaddeus can't skip them."
+
+## Phase 2: Explore the codebase
+
+Launch a subagent to survey the codebase, and ask it to read key files to understand the project: manifest files (package.json, Cargo.toml, pyproject.toml, go.mod, pom.xml, etc.), README, Makefile/build configs, CI config, existing THADDEUS.md, .claude/rules/, AGENTS.md, .cursor/rules or .cursorrules, .github/copilot-instructions.md, .windsurfrules, .clinerules, .mcp.json.
+
+Detect:
+- Build, test, and lint commands (especially non-standard ones)
+- Languages, frameworks, and package manager
+- Project structure (monorepo with workspaces, multi-module, or single project)
+- Code style rules that differ from language defaults
+- Non-obvious gotchas, required env vars, or workflow quirks
+- Existing .claude/skills/ and .claude/rules/ directories
+- Formatter configuration (prettier, biome, ruff, black, gofmt, rustfmt, or a unified format script like \`npm run format\` / \`make fmt\`)
+- Git worktree usage: run \`git worktree list\` to check if this repo has multiple worktrees (only relevant if the user wants a personal THADDEUS.local.md)
+
+Note what you could NOT figure out from code alone — these become interview questions.
+
+## Phase 3: Fill in the gaps
+
+Use AskUserQuestion to gather what you still need to write good THADDEUS.md files and skills. Ask only things the code can't answer.
+
+If the user chose project THADDEUS.md or both: ask about codebase practices — non-obvious commands, gotchas, branch/PR conventions, required env setup, testing quirks. Skip things already in README or obvious from manifest files. Do not mark any options as "recommended" — this is about how their team works, not best practices.
+
+If the user chose personal THADDEUS.local.md or both: ask about them, not the codebase. Do not mark any options as "recommended" — this is about their personal preferences, not best practices. Examples of questions:
+  - What's their role on the team? (e.g., "backend engineer", "data scientist", "new hire onboarding")
+  - How familiar are they with this codebase and its languages/frameworks? (so Thaddeus can calibrate explanation depth)
+  - Do they have personal sandbox URLs, test accounts, API key paths, or local setup details Thaddeus should know?
+  - Only if Phase 2 found multiple git worktrees: ask whether their worktrees are nested inside the main repo (e.g., \`.claude/worktrees/<name>/\`) or siblings/external (e.g., \`../myrepo-feature/\`). If nested, the upward file walk finds the main repo's THADDEUS.local.md automatically — no special handling needed. If sibling/external, the personal content should live in a home-directory file (e.g., \`~/.claude/<project-name>-instructions.md\`) and each worktree gets a one-line THADDEUS.local.md stub that imports it: \`@~/.claude/<project-name>-instructions.md\`. Never put this import in the project THADDEUS.md — that would check a personal reference into the team-shared file.
+  - Any communication preferences? (e.g., "be terse", "always explain tradeoffs", "don't summarize at the end")
+
+**Synthesize a proposal from Phase 2 findings** — e.g., format-on-edit if a formatter exists, a \`/verify\` skill if tests exist, a THADDEUS.md note for anything from the gap-fill answers that's a guideline rather than a workflow. For each, pick the artifact type that fits, **constrained by the Phase 1 skills+hooks choice**:
+
+  - **Hook** (stricter) — deterministic shell command on a tool event; Thaddeus can't skip it. Fits mechanical, fast, per-edit steps: formatting, linting, running a quick test on the changed file.
+  - **Skill** (on-demand) — you or Thaddeus invoke \`/skill-name\` when you want it. Fits workflows that don't belong on every edit: deep verification, session reports, deploys.
+  - **THADDEUS.md note** (looser) — influences Thaddeus's behavior but not enforced. Fits communication/thinking preferences: "plan before coding", "be terse", "explain tradeoffs".
+
+  **Respect Phase 1's skills+hooks choice as a hard filter**: if the user picked "Skills only", downgrade any hook you'd suggest to a skill or a THADDEUS.md note. If "Hooks only", downgrade skills to hooks (where mechanically possible) or notes. If "Neither", everything becomes a THADDEUS.md note. Never propose an artifact type the user didn't opt into.
+
+**Show the proposal via AskUserQuestion's \`preview\` field, not as a separate text message** — the dialog overlays your output, so preceding text is hidden. The \`preview\` field renders markdown in a side-panel (like plan mode); the \`question\` field is plain-text-only. Structure it as:
+
+  - \`question\`: short and plain, e.g. "Does this proposal look right?"
+  - Each option gets a \`preview\` with the full proposal as markdown. The "Looks good — proceed" option's preview shows everything; per-item-drop options' previews show what remains after that drop.
+  - **Keep previews compact — the preview box truncates with no scrolling.** One line per item, no blank lines between items, no header. Example preview content:
+
+    • **Format-on-edit hook** (automatic) — \`ruff format <file>\` via PostToolUse
+    • **/verify skill** (on-demand) — \`make lint && make typecheck && make test\`
+    • **THADDEUS.md note** (guideline) — "run lint/typecheck/test before marking done"
+
+  - Option labels stay short ("Looks good", "Drop the hook", "Drop the skill") — the tool auto-adds an "Other" free-text option, so don't add your own catch-all.
+
+**Build the preference queue** from the accepted proposal. Each entry: {type: hook|skill|note, description, target file, any Phase-2-sourced details like the actual test/format command}. Phases 4-7 consume this queue.
+
+## Phase 4: Write THADDEUS.md (if user chose project or both)
+
+Write a minimal THADDEUS.md at the project root. Every line must pass this test: "Would removing this cause Thaddeus to make mistakes?" If no, cut it.
+
+**Consume \`note\` entries from the Phase 3 preference queue whose target is THADDEUS.md** (team-level notes) — add each as a concise line in the most relevant section. These are the behaviors the user wants Thaddeus to follow but didn't need guaranteed (e.g., "propose a plan before implementing", "explain the tradeoffs when refactoring"). Leave personal-targeted notes for Phase 5.
+
+Include:
+- Build/test/lint commands Thaddeus can't guess (non-standard scripts, flags, or sequences)
+- Code style rules that DIFFER from language defaults (e.g., "prefer type over interface")
+- Testing instructions and quirks (e.g., "run single test with: pytest -k 'test_name'")
+- Repo etiquette (branch naming, PR conventions, commit style)
+- Required env vars or setup steps
+- Non-obvious gotchas or architectural decisions
+- Important parts from existing AI coding tool configs if they exist (AGENTS.md, .cursor/rules, .cursorrules, .github/copilot-instructions.md, .windsurfrules, .clinerules)
+
+Exclude:
+- File-by-file structure or component lists (Thaddeus can discover these by reading the codebase)
+- Standard language conventions Thaddeus already knows
+- Generic advice ("write clean code", "handle errors")
+- Detailed API docs or long references — use \`@path/to/import\` syntax instead (e.g., \`@docs/api-reference.md\`) to inline content on demand without bloating THADDEUS.md
+- Information that changes frequently — reference the source with \`@path/to/import\` so Thaddeus always reads the current version
+- Long tutorials or walkthroughs (move to a separate file and reference with \`@path/to/import\`, or put in a skill)
+- Commands obvious from manifest files (e.g., standard "npm test", "cargo test", "pytest")
+
+Be specific: "Use 2-space indentation in TypeScript" is better than "Format code properly."
+
+Do not repeat yourself and do not make up sections like "Common Development Tasks" or "Tips for Development" — only include information expressly found in files you read.
+
+Prefix the file with:
+
+\`\`\`
+# THADDEUS.md
+
+This file provides guidance to Thaddeus when working with code in this repository.
+\`\`\`
+
+If THADDEUS.md already exists: read it, propose specific changes as diffs, and explain why each change improves it. Do not silently overwrite.
+
+For projects with multiple concerns, suggest organizing instructions into \`.claude/rules/\` as separate focused files (e.g., \`code-style.md\`, \`testing.md\`, \`security.md\`). These are loaded automatically alongside THADDEUS.md and can be scoped to specific file paths using \`paths\` frontmatter.
+
+For projects with distinct subdirectories (monorepos, multi-module projects, etc.): mention that subdirectory THADDEUS.md files can be added for module-specific instructions (they're loaded automatically when Thaddeus works in those directories). Offer to create them if the user wants.
+
+## Phase 5: Write THADDEUS.local.md (if user chose personal or both)
+
+Write a minimal THADDEUS.local.md at the project root. This file is automatically loaded alongside THADDEUS.md. After creating it, add \`THADDEUS.local.md\` to the project's .gitignore so it stays private.
+
+**Consume \`note\` entries from the Phase 3 preference queue whose target is THADDEUS.local.md** (personal-level notes) — add each as a concise line. If the user chose personal-only in Phase 1, this is the sole consumer of note entries.
+
+Include:
+- The user's role and familiarity with the codebase (so Thaddeus can calibrate explanations)
+- Personal sandbox URLs, test accounts, or local setup details
+- Personal workflow or communication preferences
+
+Keep it short — only include what would make Thaddeus's responses noticeably better for this user.
+
+If Phase 2 found multiple git worktrees and the user confirmed they use sibling/external worktrees (not nested inside the main repo): the upward file walk won't find a single THADDEUS.local.md from all worktrees. Write the actual personal content to \`~/.claude/<project-name>-instructions.md\` and make THADDEUS.local.md a one-line stub that imports it: \`@~/.claude/<project-name>-instructions.md\`. The user can copy this one-line stub to each sibling worktree. Never put this import in the project THADDEUS.md. If worktrees are nested inside the main repo (e.g., \`.claude/worktrees/\`), no special handling is needed — the main repo's THADDEUS.local.md is found automatically.
+
+If THADDEUS.local.md already exists: read it, propose specific additions, and do not silently overwrite.
+
+## Phase 6: Suggest and create skills (if user chose "Skills + hooks" or "Skills only")
+
+Skills add capabilities Thaddeus can use on demand without bloating every session.
+
+**First, consume \`skill\` entries from the Phase 3 preference queue.** Each queued skill preference becomes a SKILL.md tailored to what the user described. For each:
+- Name it from the preference (e.g., "verify-deep", "session-report", "deploy-sandbox")
+- Write the body using the user's own words from the interview plus whatever Phase 2 found (test commands, report format, deploy target). If the preference maps to an existing bundled skill (e.g., \`/verify\`), write a project skill that adds the user's specific constraints on top — tell the user the bundled one still exists and theirs is additive.
+- Ask a quick follow-up if the preference is underspecified (e.g., "which test command should verify-deep run?")
+
+**Then suggest additional skills** beyond the queue when you find:
+- Reference knowledge for specific tasks (conventions, patterns, style guides for a subsystem)
+- Repeatable workflows the user would want to trigger directly (deploy, fix an issue, release process, verify changes)
+
+For each suggested skill, provide: name, one-line purpose, and why it fits this repo.
+
+If \`.claude/skills/\` already exists with skills, review them first. Do not overwrite existing skills — only propose new ones that complement what is already there.
+
+Create each skill at \`.claude/skills/<skill-name>/SKILL.md\`:
+
+\`\`\`yaml
+---
+name: <skill-name>
+description: <what the skill does and when to use it>
+---
+
+<Instructions for Thaddeus>
+\`\`\`
+
+Both the user (\`/<skill-name>\`) and Thaddeus can invoke skills by default. For workflows with side effects (e.g., \`/deploy\`, \`/fix-issue 123\`), add \`disable-model-invocation: true\` so only the user can trigger it, and use \`$ARGUMENTS\` to accept input.
+
+## Phase 7: Suggest additional optimizations
+
+Tell the user you're going to suggest a few additional optimizations now that THADDEUS.md and skills (if chosen) are in place.
+
+Check the environment and ask about each gap you find (use AskUserQuestion):
+
+- **GitHub CLI**: Run \`which gh\` (or \`where gh\` on Windows). If it's missing AND the project uses GitHub (check \`git remote -v\` for github.com), ask the user if they want to install it. Explain that the GitHub CLI lets Thaddeus help with commits, pull requests, issues, and code review directly.
+
+- **Linting**: If Phase 2 found no lint config (no .eslintrc, ruff.toml, .golangci.yml, etc. for the project's language), ask the user if they want Thaddeus to set up linting for this codebase. Explain that linting catches issues early and gives Thaddeus fast feedback on its own edits.
+
+- **Proposal-sourced hooks** (if user chose "Skills + hooks" or "Hooks only"): Consume \`hook\` entries from the Phase 3 preference queue. If Phase 2 found a formatter and the queue has no formatting hook, offer format-on-edit as a fallback. If the user chose "Neither" or "Skills only" in Phase 1, skip this bullet entirely.
+
+  For each hook preference (from the queue or the formatter fallback):
+
+  1. Target file: default based on the Phase 1 THADDEUS.md choice — project → \`.claude/settings.json\` (team-shared, committed); personal → \`.claude/settings.local.json\`. Only ask if the user chose "both" in Phase 1 or the preference is ambiguous. Ask once for all hooks, not per-hook.
+
+  2. Pick the event and matcher from the preference:
+     - "after every edit" → \`PostToolUse\` with matcher \`Write|Edit\`
+     - "when Thaddeus finishes" / "before I review" → \`Stop\` event (fires at the end of every turn — including read-only ones)
+     - "before running bash" → \`PreToolUse\` with matcher \`Bash\`
+     - "before committing" (literal git-commit gate) → **not a hooks.json hook.** Matchers can't filter Bash by command content, so there's no way to target only \`git commit\`. Route this to a git pre-commit hook (\`.git/hooks/pre-commit\`, husky, pre-commit framework) instead — offer to write one. If the user actually means "before I review and commit Thaddeus's output", that's \`Stop\` — probe to disambiguate.
+     Probe if the preference is ambiguous.
+
+  3. **Load the hook reference** (once per \`/init\` run, before the first hook): invoke the Skill tool with \`skill: 'update-config'\` and args starting with \`[hooks-only]\` followed by a one-line summary of what you're building — e.g., \`[hooks-only] Constructing a PostToolUse/Write|Edit format hook for .claude/settings.json using ruff\`. This loads the hooks schema and verification flow into context. Subsequent hooks reuse it — don't re-invoke.
+
+  4. Follow the skill's **"Constructing a Hook"** flow: dedup check → construct for THIS project → pipe-test raw → wrap → write JSON → \`jq -e\` validate → live-proof (for \`Pre|PostToolUse\` on triggerable matchers) → cleanup → handoff. Target file and event/matcher come from steps 1–2 above.
+
+Act on each "yes" before moving on.
+
+## Phase 8: Summary and next steps
+
+Recap what was set up — which files were written and the key points included in each. Remind the user these files are a starting point: they should review and tweak them, and can run \`/init\` again anytime to re-scan.
+
+Then tell the user that you'll be introducing a few more suggestions for optimizing their codebase and Thaddeus setup based on what you found. Present these as a single, well-formatted to-do list where every item is relevant to this repo. Put the most impactful items first.
+
+When building the list, work through these checks and include only what applies:
+- If frontend code was detected (React, Vue, Svelte, etc.): suggest looking for community plugins that provide design principles, component patterns, or browser testing capabilities.
+- If you found gaps in Phase 7 (missing GitHub CLI, missing linting) and the user said no: list them here with a one-line reason why each helps.
+- If tests are missing or sparse: suggest setting up a test framework so Thaddeus can verify its own changes.
+- Browse plugins with \`/plugin\` — you can add custom marketplace sources and install plugins that bundle skills, agents, hooks, and MCP servers. You can also create your own custom plugins to share them with others. (Always include this one.)`;
+const command = {
+    type: 'prompt',
+    name: 'init',
+    get description() {
+        return feature('NEW_INIT') &&
+            (process.env.USER_TYPE === 'ant' ||
+                isEnvTruthy(process.env.THADDEUS_NEW_INIT))
+            ? 'Initialize project instruction file(s) and optional skills/hooks with codebase documentation'
+            : 'Initialize a project instruction file with codebase documentation';
+    },
+    contentLength: 0, // Dynamic content
+    progressMessage: 'analyzing your codebase',
+    source: 'builtin',
+    async getPromptForCommand() {
+        maybeMarkProjectOnboardingComplete();
+        return [
+            {
+                type: 'text',
+                text: feature('NEW_INIT') &&
+                    (process.env.USER_TYPE === 'ant' ||
+                        isEnvTruthy(process.env.THADDEUS_NEW_INIT))
+                    ? NEW_INIT_PROMPT
+                    : OLD_INIT_PROMPT,
+            },
+        ];
+    },
+};
+export default command;