@prestyj/cli 4.3.210 → 4.3.237

package/dist/core/prompt-commands.js

@@ -6,333 +6,97 @@ export const PROMPT_COMMANDS = [
     {
         name: "goal",
         aliases: ["g"],
-        description: "Create a programmatic goal loop",
-        prompt: `# Goal: Programmatic Goal Loop
-
-You are creating a durable Goal run: a programmatic control loop that should keep the main orchestrator focused on the user's objective while workers/harnesses/diagnostics produce evidence.
-
-## User objective
-
-The user's objective is in the command arguments. If the arguments are absent or too vague to identify an actionable objective, ask exactly one concise clarifying question and do not create a Goal run yet.
-
-## Required behavior
-
-1. Translate the user's objective into:
-   - a short title,
-   - the original goal text,
-   - concrete success criteria that can be verified,
-   - prerequisite checks,
-   - an evidence plan: the simplest proof paths that would demonstrate success end-to-end,
-   - the local/free harness or observability you can build,
-   - a verifier command or verifier description.
-2. Build a capability/evidence plan before implementation: decide what would actually prove the goal works, such as scripts, tests, fixtures, seeded data, app/dev servers, browser automation, screenshots, logs, video/frame inspection, source/docs/code-search comparison, local CLIs, or generated assets. Do not require a script for every task; choose the simplest reliable proof that removes assumptions.
-3. Before doing implementation work or launching workers, identify prerequisites and check the ones you can check locally. Examples:
-   - model/API/OAuth credentials exist for simulated-agent testing,
-   - required local CLIs exist (ffmpeg, expo, adb, xcrun, playwright, etc.),
-   - required app/dev server can start or is already running,
-   - required fixture files, assets, devices, emulators, or test data exist or can be generated locally.
-4. Prefer local/free tools: scripts, shell commands, existing CLIs, test runners, logs, screenshots/images, existing dependencies, source_path, web docs, kencode search, and disposable workers/subagents. Do not require paid services, signups, or new external accounts unless unavoidable.
-5. Only ask the user for true external blockers after checking what you can do yourself. If a missing input cannot be generated or verified locally (credentials, paid services, physical devices, private assets, permissions), record the exact minimal prerequisite and ask once in chat; do not ask for broad lists of things you could inspect or create yourself.
-6. Treat user-provided prerequisites as the first Goal item, named "User prerequisites" in the pane. The user may provide the missing value or instructions in chat. After they do, verify it locally without revealing secrets, then update the matching prerequisite to \`met\` with short evidence before any worker task runs.
-7. Persist the run with the goals tool:
-   - call \`goals({ action: "create", ... })\` once the objective is understood,
-   - include success criteria, prerequisites, evidence_plan items, harness items, and verifier info,
-   - if any prerequisite is missing or unknown and cannot be automatically checked, persist the run as blocked and ask the user for the exact missing thing once.
-8. Add Goal tasks with \`goals({ action: "task", ... })\`. Do not use the normal tasks tool for this workflow. Each Goal task prompt must be standalone, mention the same project cwd, the specific files/scripts/commands to use, evidence to record, and verification expectations. Avoid pure "investigate and report" tasks unless their prompt explicitly requires persisting concrete findings with \`goals({ action: "evidence", ... })\` and creating or updating the next implementation task from those findings.
-9. Persist evidence with \`goals({ action: "evidence", ... })\` whenever you create diagnostics, run harnesses, capture logs/screenshots, record controller decisions, attach verifier artifact paths, or learn a blocker.
-10. Completion means verifier evidence satisfies the original success criteria. Do not call \`goals({ action: "complete" })\` merely because tasks are done; only complete after verification passes.
-11. When the Goal reaches a terminal state, give the user a concise final summary in chat. Use a compact 3–4 column table with columns that fit what happened, such as outcome, evidence/verifier, changed work, blockers, or next action. Do not dump worker logs; point to artifact paths when useful.
-
-## Loop semantics
-
-Think in this order: observe → instrument → automate → run → inspect evidence → fix → rerun until verified or blocked.
-
-After the user starts a Goal from the Goal pane with (R), worker and verifier completions are sent back to you as hidden synthetic events. On each event, call \`goals({ action: "status", run_id })\`, inspect current state, briefly say what the orchestrator is doing so the chat shows progress, and take the next durable control-loop action rather than merely narrating. The UI keeps auto-continuing until the run is passed, blocked, paused, or failed.
-
-If no verifier command exists yet, create a task to define one. If the verifier fails, persist the failure evidence and add the next Goal task that addresses the failure. Cap runaway loops by pausing and recording evidence when repeated attempts stop making progress.
-
-## Final response
-
-When initially creating the Goal, keep the response short: say whether the Goal was created, ready, or blocked; mention the exact missing prerequisite if blocked; and tell the user they can press Ctrl+G to view it. If they ask how to start it, tell them the Goal pane keybind is (R) to run it. When auto-continuation eventually passes, fails, blocks, or pauses the Goal, provide the compact final summary table described above.`,
-    },
-    {
-        name: "scan",
-        aliases: [],
-        description: "Find confirmed dead code only",
-        prompt: `# Scan: Confirmed Dead Code Review
-
-Find dead code in this codebase. Do not look for bugs, security issues, performance issues, style issues, or refactors. This command is report-first: do not edit or delete anything until the user chooses an option at the end.
-
-## Phase 1: Parallel dead-code search
-
-Spawn exactly 3 sub-agents in parallel using the subagent tool (call the subagent tool 3 times in a single response), each with a different validation angle:
-
-**Agent 1 - Static Reachability**: Check exports, imports, call sites, route registration, command registration, component usage, tests, package entrypoints, and public API surfaces. Identify candidates only when references appear absent or unreachable.
-
-**Agent 2 - Runtime & Dynamic Usage**: Check dynamic loading, reflection, string-based references, plugin systems, CLI commands, routes, config keys, generated-code hooks, framework conventions, side-effect imports, and files used outside TypeScript import graphs.
-
-**Agent 3 - Historical & Boundary Safety**: Check git history, package manifests, build configs, docs, examples, scripts, CI, release artifacts, and external-facing filenames/API names that may be consumed by users even if unused internally.
-
-Each sub-agent must return only candidates with file:line ranges, estimated line counts, validation evidence, and reasons removal may be unsafe. Finding nothing is valid.
-
-## Phase 2: Main-agent validation
-
-For every candidate, validate it yourself before reporting it:
-
-1. Search for references with grep/find and language-aware patterns where possible, including exact symbol names, filenames, route names, config keys, CLI command names, test names, and documented examples.
-2. Check exports and package/public entrypoints before marking anything removable.
-3. Check framework conventions and dynamic lookup risks before marking anything removable. Use official docs when a framework/tool convention could imply usage without direct imports.
-4. Check whether removing it would change public API, CLI behavior, routes, config support, migration behavior, generated artifacts, docs examples, tests, or side effects.
-5. For code-level removal tasks, kencode search is secondary: use it only to verify framework/tool conventions or common generated-code patterns that could make code appear unused locally. Do not treat absence from public code search as proof that local code is dead.
-6. If evidence is incomplete, mark safety as Low or drop the finding.
-
-## What counts as dead code
-
-Report only code that is validated as one of:
-
-- **Unused file**: no imports, no entrypoint references, no dynamic/framework usage, no public/exported contract.
-- **Unused export**: exported but not referenced internally or by package entrypoints, and not part of documented/public API.
-- **Unreachable branch**: condition/path cannot execute based on current code and config.
-- **Obsolete artifact**: stale script/config/example/generated artifact no longer referenced by build, docs, package manifests, or CI.
-- **No-op code**: code executes but has no observable effect and no intentional placeholder/documentation purpose.
-
-Do not report:
-- Public APIs, package exports, CLI commands, routes, config keys, migrations, docs examples, tests, generated-code integration points, or plugin hooks unless you can prove they are obsolete.
-- Code only unused in the current test suite.
-- Code that might be used through strings, framework conventions, side effects, or external consumers.
-- Anything you are not confident is safe to remove.
-
-## Safety labels
-
-- **High**: Strong evidence from static references, entrypoints, configs, docs, tests, and dynamic-use checks; removal is likely safe.
-- **Medium**: Probably dead, but one boundary or dynamic-use risk remains; remove only with targeted verification.
-- **Low**: Suspicious but not proven; do not remove without more investigation.
-
-## Final output
-
-Output one concise table, prioritized by safety and impact. No prose before the table.
-
-| Priority | Location | Lines | Dead-code type | Evidence | Safety to remove | Recommended action |
-|---|---|---:|---|---|---|---|
-| P0/P1/P2/P3 | file:line-line | N | unused file/export/branch/artifact/no-op | one sentence | High/Medium/Low | Remove / Investigate / Keep |
-
-Priority guide:
-- **P0**: High-safety removal with meaningful line or complexity reduction.
-- **P1**: High-safety small removal, or Medium-safety meaningful cleanup.
-- **P2**: Medium-safety small cleanup; needs targeted verification.
-- **P3**: Low-safety candidate; keep unless user wants deeper investigation.
-
-Rules:
-- Put High safety rows first, then Medium, then Low.
-- Keep each table cell short.
-- If no confirmed dead code is found, output one row saying none found and set action to \`Keep\`.
-- Do not recommend deletion for Low-safety rows.
-
-After the table, ask exactly:
-
-What should I do?
-A) Create tasks to remove all High-safety dead code
-B) Create tasks to remove only top priorities
-C) Skip
-
-Do not start deleting or editing until the user chooses.
-
-If the user chooses A or B, do not remove code directly. Instead, use the tasks tool to create one task per selected removal or tightly coupled removal group, ordered by dependency and risk. Each task prompt must be standalone and include the exact locations, safety evidence, reference-search requirements, removal instructions, project verification commands, and instructions to prove the removal did not delete used code before marking the task complete. That proof must include fresh local reference searches after editing, relevant project checks/tests, and official-docs or kencode comparison only where framework/tool conventions or generated-code patterns could imply hidden usage. After creating tasks, tell the user exactly: "Tasks created. Press CTRL + T to open the Tasks Pane and press R to run all tasks." Do not begin executing them unless the user explicitly starts a task.`,
-    },
-    {
-        name: "verify",
-        aliases: [],
-        description: "Review this codebase against real-world implementations",
-        prompt: `# Verify: Codebase Real-World Check
-
-Review this codebase's implementation against real-world code, not opinions. Start with changes from this conversation or \`git diff\` / \`git status\`; if there are no relevant changes, choose the most important implemented feature or module in the current project and review that.
-
-## Phase 1: Parallel codebase review
-
-Spawn exactly 3 sub-agents in parallel using the subagent tool (call the subagent tool 3 times in a single response), each with a different focus:
-
-**Agent 1 - Implementation Shape**: Identify the main APIs, components, functions, file structure, state flow, and integration points. Return only concrete search anchors and candidate concerns.
-
-**Agent 2 - Completeness**: Check whether the implementation appears to miss expected pieces: edge cases, cleanup, error states, validation, tests, configuration, accessibility, migrations, docs, or lifecycle handling. Return only concrete candidate gaps.
-
-**Agent 3 - Divergence**: Look for unusual patterns, over-custom code, reinvented utilities, brittle abstractions, or choices that may differ from how mature projects solve the same problem. Return only concrete candidate divergences.
-
-Each sub-agent must include file:line references and suggested literal search anchors for kencode search, such as imports, function names, hooks, props, config keys, or API calls. Do not report subjective style preferences.
-
-## Phase 2: Real-world comparison with kencode search
-
-After the 3 agents return, use \`mcp__kencode-search__searchCode\` yourself to verify or reject their candidates.
-
-Search rules:
-- Use literal code tokens, not conceptual phrases.
-- Prefer imports, framework identifiers, config keys, hook names, component names, and API calls from this codebase.
-- Use \`peek: true\` first when exploring, then fetch narrowed examples with repo/path filters when useful.
-- Compare against multiple real repositories when possible; one repo is weak evidence unless it is an official or canonical implementation.
-- If kencode search is unavailable or returns insufficient evidence, say that in the Evidence column and lower confidence.
-
-## What to classify
-
-Report only findings that fit one of these:
-
-1. **Aligned** - The implementation matches consistent real-world practice. No action needed.
-2. **Missing** - Real-world implementations consistently include something this code lacks.
-3. **Divergent** - This code differs from common implementations in a way that likely matters.
-4. **Better Elsewhere** - Real-world implementations solve the same problem more robustly or simply, with evidence.
-
-Drop anything that is only taste, personal preference, or unsupported by code evidence.
-
-## Final output
-
-Output one concise table, prioritized by impact. No prose before the table.
-
-| Priority | Type | Location | Finding | Evidence | Recommended action |
-|---|---|---|---|---|---|
-| P0/P1/P2/P3 | Missing/Divergent/Better Elsewhere/Aligned | file:line | one sentence | kencode evidence in one sentence | concrete action or \`None\` |
-
-Priority guide:
-- **P0**: likely bug, data loss, security risk, or broken integration.
-- **P1**: important missing behavior or maintainability risk.
-- **P2**: useful improvement backed by real-world evidence.
-- **P3**: aligned/no-action observations.
-
-Rules:
-- Keep each table cell short.
-- Put action-taking findings before aligned findings.
-- If everything is aligned, output only aligned rows and set every action to \`None\`.
-- If there is not enough evidence for any finding, output one row explaining that verification was inconclusive.
-
-After the table, ask exactly:
-
-Which should I do?
-A) Create tasks to refine and adjust all
-B) Create tasks for just top priorities
-C) Skip
-
-Do not start fixing until the user chooses.
-
-If the user chooses A or B, do not fix directly. Instead, use the tasks tool to create one task per selected finding or tightly coupled finding group, ordered by dependency and priority. Each task prompt must be standalone and include the finding, affected local files/anchors, kencode evidence from the report, instructions to compare the approach with kencode search before editing, implementation instructions, project verification commands, and instructions to compare the final implementation with kencode search again before marking the task complete. After creating tasks, tell the user exactly: "Tasks created. Press CTRL + T to open the Tasks Pane and press R to run all tasks." Do not begin executing them unless the user explicitly starts a task.`,
+        description: "Plan as needed, then create a programmatic goal loop",
+        // Contract anchors for the audit verifier: /goal setup is setup-only.
+        // Do not implement; plan/research as needed first, then define success criteria, evidence_plan, verifier, and goals metadata, then stop.
+        prompt: "Create a Goal run for the following objective. First plan/research only if needed; Goal setup will consume that plan and create durable Goal state.",
     },
     {
         name: "expand",
         aliases: [],
-        description: "Find high-value gaps by comparing this project to current alternatives",
-        prompt: `# Expand: Current Competitive Gap Review
+        description: "Find exciting new features to add",
+        prompt: `# Expand: Exciting Feature Discovery
 
-Find high-value gaps by comparing this project to similar, adjacent, and best-in-class repositories/tools/websites/services. This command is project-agnostic: infer what THIS project is before choosing comparisons. This command is report-first: do not edit, install, or implement anything until the user chooses an option at the end.
+Find the most exciting new features this project should add by comparing it to similar, adjacent, and best-in-class repositories/tools/products/services. This command is project-agnostic: infer what THIS project is before choosing comparisons. This command is report-first and feature-first — the only deliverable is a single ranked table of exciting, user-facing features. Do not edit, install, or implement anything until the user chooses an option at the end.
+
+Focus on what users actually get excited about: the new, killer, user-facing capabilities that make a product stand out. Security audits, refactors, code-quality cleanups, tests, CI, and ops/DX hygiene are OUT OF SCOPE here — exclude them unless a specific item is itself an exciting user-facing feature.
 
 ## Phase 0: Profile this project first
 
 Before external research, inspect the local project and write a private working profile:
 
-- What the project does, who it serves, and how it ships/runs.
-- Core workflows, entrypoints, packages/modules, integrations, and user-facing surfaces.
-- Existing features, security controls, developer tooling, docs, tests, release/ops setup, and architecture patterns.
-- The most relevant comparison categories for THIS project. Do not assume this is an AI-agent app unless the repo proves it.
+- What the project does, who its users are, and how they use it.
+- Core user-facing surfaces, workflows, commands/routes/screens, and the features that already exist.
+- The feature categories most relevant to THIS project. Do not assume a stack or product type.
 
-Use this profile to decide what kinds of external projects are relevant. If the user passed arguments to /expand, treat them as a focus area and prioritize that lens while still validating project relevance.
+Use this profile to decide which features are relevant and genuinely missing. If the user passed arguments to /expand, treat them as a focus area and prioritize that lens while still validating relevance.
 
-## Phase 1: Parallel expansion research
+## Phase 1: Parallel feature research
 
-Spawn exactly 5 sub-agents in parallel using the subagent tool (call the subagent tool 5 times in a single response). Give each sub-agent the project profile and a different comparison lens. Adapt the lenses to the project, but cover these defaults unless clearly irrelevant:
+Spawn exactly 5 sub-agents in parallel using the subagent tool (call the subagent tool 5 times in a single response). Give each sub-agent the project profile and a different feature-hunting lens:
 
-**Agent 1 - Direct peers & product features**: Find actively maintained projects/tools/services closest to this project. Look for user-facing capabilities, workflows, integrations, onboarding, and monetizable/retention-driving features they have that this project lacks.
+**Agent 1 - Direct competitor killer features**: The standout, most-loved user-facing features in the closest peer projects/tools/products that this project lacks.
 
-**Agent 2 - Security, privacy & recent incidents**: Find recent security/privacy hardening, dependency ecosystem changes, advisories, exploit mitigations, auth/session patterns, sandboxing, supply-chain defenses, and issue/PR fixes from comparable projects that this project should consider.
+**Agent 2 - Adjacent & emerging tools**: Exciting user-facing features from adjacent products that would translate well to this project.
 
-**Agent 3 - Architecture, code quality & implementation shape**: Compare code organization, APIs, extensibility, agent/runtime loops, data models, concurrency, error handling, configuration, plugin systems, and maintainability patterns. Include cleaner implementation ideas only when they produce concrete user/developer value.
+**Agent 3 - User demand signals**: Highly requested or trending features — top-voted issues, roadmap items, community asks, reviews, discussions — that point at what users want next.
 
-**Agent 4 - Developer experience, ops & release maturity**: Compare tests, CI/CD, docs, examples, templates, telemetry/observability, migrations, upgrade paths, packaging, installation, local dev, debugging, and support workflows.
+**Agent 4 - Platform & ecosystem trends**: New user-facing capabilities unlocked by recent framework/API/model/platform releases that this project has not adopted yet.
 
-**Agent 5 - Ecosystem, trends & adjacent inspiration**: Look beyond direct peers to adjacent current tools, libraries, SaaS products, standards, RFCs, framework releases, and recent commits/releases that suggest important missing directions.
+**Agent 5 - Differentiators & wow-factor**: Novel or innovative features that would make this project stand out, even if no single peer has shipped them yet.
 
 Each sub-agent must:
 
-1. Use current sources: prefer repos/releases/commits/docs/articles updated within the last 6 months. Drop old or stale sources unless they are canonical and still actively maintained.
-2. Return only candidates that appear absent or materially weaker in this project.
-3. Include source names/URLs, freshness date (commit/release/article/doc date), and the local search anchors they used or recommend to verify absence.
-4. Separate findings into useful categories for the final report, such as Security, Product, Architecture, Developer Experience, Operations, or Ecosystem.
-5. Avoid generic wishlist items. Every candidate must be grounded in an external comparison and relevant to this project profile.
+1. Use current sources: prefer repos/releases/changelogs/docs/articles updated within the last 6 months. Drop old or stale sources unless they are canonical and still actively maintained.
+2. Return only user-facing FEATURES that appear absent in this project — not refactors, hardening, tooling, tests, or internal cleanup.
+3. Include source names/URLs, freshness date (commit/release/article/doc date), and the local search anchors they used or recommend to verify the feature is absent.
+4. Rank its own candidates by how exciting and valuable they would be to users, and state why each is exciting.
+5. Avoid generic wishlist items. Every feature must be grounded in an external comparison or a real user-demand signal and relevant to this project profile.
 
 ## Phase 2: Main-agent validation against this repo
 
 For every candidate from the sub-agents, validate it yourself before reporting:
 
 1. Confirm the external source is relevant to this project and fresh enough (normally within 6 months).
-2. Search this repo with grep/find and language-aware anchors to check whether the feature/pattern/control already exists under another name.
-3. Check manifests, docs, configs, package exports, routes, CLI commands, tests, CI, examples, and framework conventions before calling something missing.
-4. Use mcp__kencode-search__searchCode when code-level comparison would clarify whether the external implementation is materially cleaner or more complete. Use literal imports, functions, config keys, CLI flags, route names, or package names — not conceptual phrases.
-5. Drop anything already present, not applicable, too vague, too stale, or unsupported by evidence.
-6. Keep the report short: prioritize the highest-value gaps over completeness.
-
-## What counts as a reportable gap
-
-Report only gaps that are:
-
-- **Missing capability**: A relevant current peer has a feature, integration, workflow, or user-facing behavior this project lacks.
-- **Security/privacy hardening**: A current source addressed a meaningful risk this project has not addressed.
-- **Operational maturity**: A relevant project has CI, release, observability, packaging, migration, or support practices this project lacks.
-- **Developer experience**: A relevant project has docs, examples, tests, debugging, local dev, extension points, or generated commands that would materially improve this project.
-- **Implementation quality**: A comparable codebase handles a shared concern more simply, safely, extensibly, or robustly, and this repo lacks that pattern.
-- **Ecosystem alignment**: A recent framework/API/standard/release changed expectations and this project has not caught up.
-
-Do not report:
-
-- Ideas not tied to a real current source.
-- Things this repo already has, even if named differently.
-- Stale comparisons with no activity in the last 6 months unless canonical and still relevant.
-- Pure taste or style preferences.
-- Massive rewrites unless there is a specific incremental gap to implement.
-- Low-confidence guesses.
-
-## Priority levels
-
-- **P0**: Critical gap: security exposure, data loss risk, broken compatibility, major missing core workflow, or urgent ecosystem change.
-- **P1**: High-value gap: important feature/hardening/DX/ops improvement with strong external evidence and clear fit.
-- **P2**: Useful gap: meaningful but not urgent, or requires a scoped design decision before implementation.
-- **P3**: Exploratory gap: promising but lower confidence or lower immediate impact. Use sparingly.
+2. Search this repo with grep/find and language-aware anchors to confirm the feature is not already present under another name.
+3. Check routes, CLI commands, UI surfaces, package exports, config, docs, and examples before calling a feature missing.
+4. Use mcp__kencode-search__searchCode when a code-level look clarifies how peers actually ship the feature. Use literal imports, functions, config keys, CLI flags, route names, or package names — not conceptual phrases.
+5. Drop anything already present, irrelevant, too vague, too stale, or that is not a real user-facing feature.
+6. Merge duplicates and keep only the most exciting 5–10 features.
 
 ## Final output
 
-Output separate category sections only for categories with findings. No prose before the first section. Each section must use a table with exactly these 3 columns:
+Output ONLY a single table, ranked most exciting (rank 1) to least exciting. No prose before or after the table except the options below. Include 5–10 rows. The table must have exactly 3 columns:
 
-| Repo/tool/source | Feature or gap | Priority |
+| Rank | Feature | Why it's exciting + evidence |
 |---|---|---|
-| name + fresh date | concise gap, evidence, and why this repo lacks it | P0/P1/P2/P3 |
+| 1 | concise feature name + what it does | why users would love it, which peers/tools have it, source + fresh date, and local proof it is missing |
 
 Rules:
 
-- The table must have exactly 3 columns. Put source URL/date/evidence and local absence proof inside the first two cells, not extra columns.
-- Sort rows by priority within each category: P0, then P1, then P2, then P3.
+- 5–10 rows, ordered most exciting first (rank 1 = most exciting).
+- Only user-facing features. No security, refactor, ops, tooling, or test rows.
+- The table must have exactly 3 columns. Put source URL/date/evidence and local absence proof inside the cells, not extra columns.
 - Keep each cell concise but specific enough to be actionable.
-- If no validated gaps are found, output one table row saying no fresh validated gaps were found.
-- Do not include implementation prose after the tables except the options below.
+- If no exciting validated features are found, output one row saying no fresh validated features were found.
 
-After the tables, ask exactly:
+After the table, ask exactly:
 
 What should I do?
-A) Create tasks for all P0/P1 gaps
-B) Create tasks for only the top priority gap from each category
-C) Skip
+A) Build all of these features in plan mode
+B) Build only the top priority ones in plan mode
+C) Other
 
 Do not start implementing until the user chooses.
 
-If the user chooses A or B, do not implement gaps directly. Instead, use the tasks tool to create one implementation task per selected gap, ordered by dependency and priority.
-
-Each task prompt must be standalone and include:
-
-1. The specific gap, including relevant local files/anchors and source evidence from the /expand report.
-2. Instructions to compare the implementation approach with kencode search before editing, using literal code tokens and current real-world examples.
-3. Instructions to implement the gap in the local codebase.
-4. Instructions to verify correctness after implementation by running project checks and by comparing the final implementation with kencode search again before marking the task complete.
-
-Do not create planning tasks, do not instruct tasks to use planning-only workflows, and do not create or write implementation plans from /expand selections.
+If the user chooses A or B, do not implement directly. First call the enter_plan tool, then research and design an implementation plan for the selected features (all of them for A; the top 3 most exciting — ranks 1-3 — for B). The plan must cover, per feature: the user-facing behavior, the local files/anchors it touches, the implementation approach (compared against real-world examples via kencode search using literal code tokens), and how it will be verified. Write the plan to .ezcoder/plans/<name>.md, then call exit_plan with the plan path so the user can review and approve it. Do not begin implementing until the user approves the plan.
 
-After creating tasks, tell the user exactly: "Tasks created. Press CTRL + T to open the Tasks Pane and press R to run all tasks." Do not begin executing them unless the user explicitly starts a task.`,
+If the user chooses C, ask what they would like — pick specific features by rank, refine or re-scope the list, or skip — and do not implement anything until they say so.`,
     },
     {
         name: "bullet-proof",
         aliases: ["bp"],
-        description: "Defensive security review — audit the project for exploitable weaknesses",
+        description: "Audit exploitable weaknesses",
         prompt: `# Bullet-Proof: Defensive Security Review
 
 You are a defensive security auditor reviewing this codebase to identify exploitable weaknesses so they can be patched before the project ships. Think rigorously about realistic threat scenarios — boundary checks, edge cases, race conditions, trust assumptions, supply-chain risks, agent-mediated paths.
@@ -464,14 +228,14 @@ Threat model: [from recon]
 After the report, ask:
 
 > Which (if any) should I fix? Options:
-> - A) Create tasks for all Critical + High
-> - B) Create tasks for specific findings (give IDs, e.g. "BP-001, BP-004")
-> - C) Create tasks for a category (auth, supply chain, secrets, …)
+> - A) Add tasks for all Critical + High
+> - B) Add tasks for specific findings (give IDs, e.g. "BP-001, BP-004")
+> - C) Add tasks for a category (auth, supply chain, secrets, …)
 > - D) None — report only
 
 **Do not start fixing until the user picks.**
 
-If the user chooses A, B, or C, do not fix directly. Instead, use the tasks tool to create one task per selected finding or tightly coupled finding group, ordered by severity, exploitability, and dependency. Each task prompt must be standalone and include the finding ID, vulnerability scenario, affected local files/anchors, concrete remediation, instructions to compare security-sensitive implementation details with kencode search or authoritative docs before editing, project verification commands, and instructions to compare the final fix with kencode search or authoritative docs again before marking the task complete. After creating tasks, tell the user exactly: "Tasks created. Press CTRL + T to open the Tasks Pane and press R to run all tasks." Do not begin executing them unless the user explicitly starts a task.
+If the user chooses A, B, or C, do not fix directly. Instead, add one task per selected finding or tightly coupled finding group using the \`tasks\` tool (action=add), ordered by severity, exploitability, and dependency. Each task needs a short title and a standalone prompt that includes the finding ID, vulnerability scenario, affected local files/anchors, concrete remediation, instructions to compare security-sensitive implementation details with kencode search or authoritative docs before editing, project verification commands, and instructions to compare the final fix with kencode search or authoritative docs again before completing the task. After adding the tasks, tell the user exactly: "Tasks added. Press Ctrl+T to open the task list and run them." Do not begin executing them unless the user explicitly says so.
 
 ## Threat reference (May 2026)
 
@@ -516,147 +280,6 @@ Cite these as needed per audit. Do not dump them into the report — use them to
 - **Strict confidence gate (≥0.8).** Drop everything else, even if it looks suspicious.
 - **Adapt to the stack, always.** The audit catalog and threat reference above are guidance, not a checklist to apply uniformly.
 - **Report only.** Wait for the user to pick what to fix in Phase 6.`,
-    },
-    {
-        name: "source",
-        aliases: ["depcheck", "depsource"],
-        description: "Plan, source-check, adjust, and verify dependency-aligned code",
-        prompt: `# Source: Plan → Research → Adjust → Verify
-
-Use exact installed dependency source as the source of truth, then align this project end-to-end. This command is action-oriented like /verify and /compare: plan the investigation, research with source_path, adjust the code, and verify everything before finishing.
-
-## Phase 1: Plan the source check
-
-Do a short, private plan before tool-heavy work:
-
-1. Identify the dependency surface to check.
-   - If the user passed args, treat them as the package/repo/spec plus optional focus area.
-   - If no args were passed, inspect recent changes, changed files, imports, manifests, and current conversation context to pick the 1-3 dependencies most likely to matter.
-2. Decide what “aligned” means for this run: APIs/types, exports, CLI flags, config schema, runtime behavior, lifecycle/cleanup, error handling, package subpaths, tests, docs examples, or UI/tool wording.
-3. Decide the parallel research slices. Use up to 3 sub-agents; use fewer when the scope is obvious. Do not pad.
-
-Do not ask the user for confirmation. Proceed unless the focus is impossible to infer.
-
-## Phase 2: Research exact dependency source
-
-For every in-scope dependency, call \`source_path\` before making claims about APIs, types, flags, config, exports, or runtime behavior.
-
-Inspect the returned absolute source path with \`read\`, \`grep\`, \`find\`, and \`ls\`. Prefer dependency source files, package manifests, type definitions, exports, tests, examples, changelogs, and README sections inside that source checkout. Use web docs only when source alone is ambiguous.
-
-Spawn the research sub-agents in parallel in one response when useful:
-
-- **Local Usage Agent**: find local imports, wrappers, tool calls, config keys, CLI flags, tests, docs, and assumptions tied to the dependency. Return exact file:line anchors.
-- **Dependency Source Agent**: inspect the exact source_path checkout. Return exact source file paths and authoritative facts about APIs, types, exports, lifecycle, errors, config, and gotchas.
-- **Alignment Agent**: compare local assumptions to dependency facts. Return concrete mismatches, missing handling, stale usage, brittle assumptions, or simplifications backed by exact source evidence.
-
-Every finding must include both local file paths and dependency-source file paths. Mark unproven items as \`aligned\` or \`inconclusive\`; do not turn them into fixes.
-
-## Phase 3: Adjust the code
-
-Validate every candidate yourself, then fix all confirmed issues directly.
-
-Valid adjustments include:
-
-- Correct wrong/stale API or type usage for the installed version
-- Fix import/export/package-subpath usage
-- Fix config keys, option shapes, CLI flags, or tool schemas
-- Add missing lifecycle cleanup, abort handling, error handling, or edge-case handling proven by source
-- Align local tests/docs/examples with the installed dependency source
-- Align local tool prompts/TUI wording when they misrepresent dependency behavior
-- Remove small custom workarounds when the installed dependency source shows a supported built-in path
-
-Rules:
-
-- Read each local file before editing it.
-- Match neighboring local patterns and tone.
-- Keep edits minimal and focused; no broad refactors.
-- Do not upgrade dependencies unless the user explicitly asked for an upgrade.
-- Do not edit just because upstream source uses a different style.
-- If a formatter, codegen, or autofix mutates files, re-read before more edits.
-
-## Phase 4: Verify everything
-
-Run the relevant project checks for changed files. If this project specifies commands, use them. Otherwise infer from manifests. For TypeScript, run lint, typecheck, format check, and tests when available.
-
-If verification fails, read the failure, fix it, and rerun. Do not report success with failing or unrun checks.
-
-## Final response
-
-Keep it short:
-
-- Dependencies/source paths checked
-- Adjustments made, or \`No changes needed — local usage aligns with installed source\`
-- Verification commands run
-
-Do not ask what to do next unless blocked by missing information or an external failure.`,
-    },
-    {
-        name: "research",
-        aliases: [],
-        description: "Research best tools, deps, and patterns",
-        prompt: `Research the best tools, dependencies, and architecture for this project.
-
-First, if it's not clear what the project is building, ask me to describe the features, target platform, and any constraints. If you can infer this from the codebase, proceed directly.
-
-Then spawn 6 sub-agents in parallel using the subagent tool (call the subagent tool 6 times in a single response, each with a different task). Every agent must verify ALL recommendations with current official docs, package registries, releases, or maintained source repositories - no training-data assumptions allowed. Use kencode search for architecture and implementation-shape comparisons where real code examples matter.
-
-**Agent 1 - Project Scan**: Read the current working directory. Catalog what already exists: config files, installed deps, directory structure, language/framework already chosen. Report exactly what's in place.
-
-**Agent 2 - Stack Validation**: Research whether the current framework/language is the best choice for this project. Compare top 2-3 alternatives on performance, ecosystem, and developer experience. Pick ONE winner with evidence.
-
-**Agent 3 - Core Dependencies**: For EACH feature, find the single best library for this stack. Confirm latest stable versions. No outdated packages. Output: package name, version, one-line purpose.
-
-**Agent 4 - Dev Tooling**: Research the best dev tooling for this stack: package manager, bundler, linter, formatter, test framework, type checker. Pick ONE per category with exact versions.
-
-**Agent 5 - Architecture**: Find how real projects of this type structure their code. Look for directory layouts, file naming conventions, and key patterns. Output a concrete directory tree and list of patterns.
-
-**Agent 6 - Config & Integration**: Research required config files for the chosen stack and tools. Cover: linter config, formatter config, TS/type config, env setup, CI/CD basics.
-
-## Agent Rules
-
-1. Every recommendation MUST be verified with a source URL/date - no guessing
-2. Confirm latest stable versions from official registries or release pages - do not assume version numbers
-3. Verify CLI flags, config keys, and file formats against official docs before recommending them
-4. Pick ONE best option per category - no "you could also use X"
-5. No prose, no hedging, no alternatives lists - decisive answers only
-
-## Output
-
-After all agents complete, synthesize findings into a single RESEARCH.md file:
-
-\`\`\`markdown
-# RESEARCH: [short project description]
-Generated: [today's date]
-Stack: [framework + language + runtime]
-
-## INSTALL
-[exact shell commands - copy-paste ready]
-
-## DEPENDENCIES
-| package | version | purpose |
-[each purpose max 5 words]
-
-## DEV DEPENDENCIES
-| package | version | purpose |
-
-## CONFIG FILES TO CREATE
-### [filename]
-[exact file contents or key settings]
-
-## PROJECT STRUCTURE
-[tree showing recommended directories]
-
-## SETUP STEPS
-1. [concrete action]
-
-## KEY PATTERNS
-[brief list of architectural patterns]
-
-## SOURCES
-[URLs used for verification]
-\`\`\`
-
-Write the file, then summarize what was researched and list the verification sources used. If any recommendation could not be verified from current official sources or maintained repos, omit it rather than guessing.`,
     },
     {
         name: "init",
@@ -664,7 +287,7 @@ Write the file, then summarize what was researched and list the verification sou
         description: "Generate or update CLAUDE.md for this project",
         prompt: `Generate or update a minimal CLAUDE.md with project-specific context only: what this project is, how it is structured, and commands/workflows that are unique to it.
 
-Do NOT add generic agent behavior already covered by the system prompt, including: read before edit/write, re-read after formatters, ask before destructive actions, no fake verification, generic code-quality advice, single-responsibility rules, one-file-per-component rules, or language-style conventions. Include only project-specific overrides or stricter local requirements.
+Do NOT add generic agent behavior already covered by the system prompt, including: read before edit/write, re-read after formatters, ask before destructive actions, no fake verification, generic code-quality advice, single-responsibility rules, one-file-per-component rules, or language-style conventions. Never add guidance that requires running checks, builds, or the full quality suite after every edit or every file change. Include only project-specific overrides or stricter local requirements.
 
 ## Step 1: Check if CLAUDE.md Exists
 
@@ -679,11 +302,13 @@ If CLAUDE.md does NOT exist:
 
 ## Step 2: Analyze Project (Use Sub-agents in Parallel)
 
+Derive every fact from the actual project — source code, entry points, manifests, and config. Treat README, docs, and code comments as unverified hints that are frequently stale: never copy claims from them, and only state things you can confirm from the code and config themselves.
+
 Spawn 3 sub-agents in parallel using the subagent tool (call the subagent tool 3 times in a single response):
 
-1. **Project Purpose Agent**: Analyze README, package.json description, main files to understand what the project does
+1. **Project Purpose Agent**: Determine what the project actually does from its real code — entry points, main modules, exported/public APIs, CLI commands, routes, and manifests. Do not rely on the README's description.
 2. **Directory Structure Agent**: Map out the folder structure and what each folder contains
-3. **Tech Stack Agent**: Identify languages, frameworks, tools, dependencies
+3. **Tech Stack Agent**: Identify languages, frameworks, tools, and dependencies from manifests/lockfiles and config (not from prose docs)
 
 Wait for all sub-agents to complete, then synthesize the information.
 
@@ -695,11 +320,11 @@ Check for config files:
 - go.mod -> Go
 - Cargo.toml -> Rust
 
-Extract exact commands that are useful project facts. Verify commands against local package scripts, manifests, Makefiles, CI, or documented project workflows; do not invent commands from convention alone. Do not restate generic "run checks after edits" behavior unless this project requires a stricter command sequence than the system prompt's Verification section.
+Extract exact commands that are useful project facts. Take commands from authoritative sources — package scripts, manifests, Makefiles, and CI config; do not invent them from convention, and do not trust README/doc command snippets unless a script or manifest confirms they still exist. Do not restate generic "run checks after edits" behavior, and do not turn discovered commands into mandatory after-every-edit requirements unless local docs or CI explicitly require that stricter sequence.
 
 ## Step 4: Summarize Stable Structure
 
-If useful, create a concise structure summary for future agents showing only key stable directories and files with brief descriptions. Do NOT embed generated symbol maps, exhaustive file indexes, generated repo maps, auto-generated directory listings, or large trees in CLAUDE.md.
+If useful, create a concise structure summary for future agents showing only key stable directories and files with brief descriptions. Do NOT embed generated symbol maps, exhaustive file indexes, auto-generated directory listings, or large trees in CLAUDE.md.
 
 ## Step 5: Generate or Update CLAUDE.md
 
@@ -711,7 +336,7 @@ Create CLAUDE.md with only sections that add project-specific value. Prefer this
 - Exact local commands (install/build/check/test/dev/publish/deploy) when they are not obvious from package scripts alone
 - Project-specific constraints that override defaults (for example required publish order, generated-file workflow, auth/secrets storage, deployment caveats)
 
-Avoid generic sections named "Code Quality", "Organization Rules", or "How to Work" unless every bullet is specific to this project. Do not duplicate language style packs or generic verification rules. Do not add generated repo maps, symbol indexes, exhaustive file indexes, or auto-generated project inventories; CLAUDE.md must remain durable, agent-focused project context.
+Avoid generic sections named "Code Quality", "Organization Rules", or "How to Work" unless every bullet is specific to this project. Do not duplicate language style packs, generic verification rules, or boilerplate quality gates such as "After editing ANY file" / "Code Quality — Zero Tolerance". Do not add symbol indexes, exhaustive file indexes, or auto-generated project inventories; CLAUDE.md must remain durable, agent-focused project context.
 
 Keep total file under 100 lines. If updating, preserve any custom sections the user added. After writing, re-read CLAUDE.md and confirm it contains only project-specific facts supported by local files.
 
@@ -720,79 +345,11 @@ Keep total file under 100 lines. If updating, preserve any custom sections the u
 End your reply with this exact notice so the user doesn't miss it:
 
 > ⚠️ CLAUDE.md was created/updated. ezcoder loads it at startup, so **exit and restart ezcoder** (\`/quit\` then run \`ezcoder\` again) before continuing. Without a restart, I won't see the new context.`,
-    },
-    {
-        name: "setup-lint",
-        aliases: [],
-        description: "Generate a /fix command for linting and typechecking",
-        prompt: `Detect the project type and generate a /fix command for linting and typechecking.
-
-## Step 1: Detect Project Type
-
-Check for config files:
-- package.json -> JavaScript/TypeScript
-- pyproject.toml or requirements.txt -> Python
-- go.mod -> Go
-- Cargo.toml -> Rust
-- composer.json -> PHP
-
-Read the relevant config file to understand the project structure.
-
-## Step 2: Check Existing Tools
-
-Based on the project type, check if linting/typechecking tools are already configured:
-
-- **JS/TS**: eslint, prettier, typescript — check package.json scripts and config files
-- **Python**: mypy, pylint, black, ruff — check dependencies and config files
-- **Go**: go vet, gofmt, staticcheck
-- **Rust**: clippy, rustfmt
-
-## Step 3: Install Missing Tools (if needed)
-
-Only install what's missing. Use the detected package manager. Before installing or writing config, verify current recommended setup, CLI flags, and config filenames against official docs for the selected tools.
-
-## Step 4: Generate /fix Command
-
-Create the directory \`.ezcoder/commands/\` if it doesn't exist, then write \`.ezcoder/commands/fix.md\`:
-
-\`\`\`markdown
----
-name: fix
-description: Run typechecking and linting, then spawn parallel agents to fix all issues
----
-
-Run all linting and typechecking tools, collect errors, group them by domain, and use the subagent tool to spawn parallel sub-agents to fix them.
-
-## Step 1: Run Checks
-
-[INSERT PROJECT-SPECIFIC COMMANDS — e.g. npm run lint, npm run typecheck, etc.]
-
-## Step 2: Collect and Group Errors
-
-Parse the output. Group errors by domain:
-- **Type errors**: Issues from TypeScript, mypy, etc.
-- **Lint errors**: Issues from eslint, pylint, ruff, clippy, etc.
-- **Format errors**: Issues from prettier, black, rustfmt, gofmt
-
-## Step 3: Spawn Parallel Agents
-
-For each domain with issues, use the subagent tool to spawn a sub-agent to fix all errors in that domain.
-
-## Step 4: Verify
-
-After all agents complete, re-run all checks to verify all issues are resolved.
-\`\`\`
-
-Replace [INSERT PROJECT-SPECIFIC COMMANDS] with the actual commands for the detected project.
-
-## Step 5: Confirm
-
-Report what was detected, what official docs or local configs were used to verify it, what was installed, and that /fix is now available.`,
     },
     {
         name: "setup-commit",
         aliases: [],
-        description: "Generate a /commit command with quality checks",
+        description: "Generate a /commit command",
         prompt: `Detect the project type and generate a /commit command that enforces quality checks before committing.
 
 ## Step 1: Detect Project and Extract Commands
@@ -839,398 +396,11 @@ Keep the command file under 20 lines.
 ## Step 3: Confirm
 
 Report that /commit is now available with quality checks and AI-generated commit messages, and mention which local scripts/docs verified the commands.`,
-    },
-    {
-        name: "setup-tests",
-        aliases: [],
-        description: "Set up testing and generate a /test command",
-        prompt: `Set up comprehensive testing for this project and generate a /test command.
-
-## Step 1: Analyze Project
-
-Detect the project type, framework, and architecture. Identify all critical business logic that needs testing.
-
-## Step 2: Determine Testing Strategy
-
-Use these tools based on project type (2025-2026 best practices), but verify current versions, install commands, config files, and runner flags against official docs before installing anything:
-
-| Language | Unit/Integration | E2E | Notes |
-|----------|------------------|-----|-------|
-| JS/TS | Vitest (not Jest) | Playwright | Vitest is faster, native ESM/TS. Use Testing Library for components. |
-| Python | pytest | Playwright | pytest-django for Django, httpx+pytest-asyncio for FastAPI. |
-| Go | testing + testify | httptest | testcontainers-go for integration. Table-driven tests. |
-| Rust | #[test] + rstest | axum-test | assert_cmd for CLI, proptest for property-based. |
-| PHP | Pest 4 (Laravel) / PHPUnit 12 | Laravel Dusk | Pest preferred for Laravel. |
-
-## Step 3: Set Up Testing Infrastructure
-
-Spawn 4 sub-agents in parallel using the subagent tool (call the subagent tool 4 times in a single response):
-
-**Agent 1 - Dependencies & Config**: Install test frameworks and create config files
-**Agent 2 - Unit Tests**: Create comprehensive unit tests for all business logic, utilities, and core functions
-**Agent 3 - Integration Tests**: Create integration tests for APIs, database operations, and service interactions
-**Agent 4 - E2E Tests** (if applicable): Create end-to-end tests for critical user flows
-
-Each agent should create COMPREHENSIVE tests covering all critical code paths - not just samples. Each agent must verify test framework APIs and helper patterns against official docs or current maintained examples before adding tests.
-
-## Step 4: Verify and Generate /test Command
-
-Run the tests to verify everything works. Fix any issues.
-
-Then create the directory \`.ezcoder/commands/\` if it doesn't exist and write \`.ezcoder/commands/test.md\` with:
-
-\`\`\`markdown
----
-name: test
-description: Run tests, then spawn parallel agents to fix failures
----
-
-Run all tests for this project, collect failures, and use the subagent tool to spawn parallel sub-agents to fix them.
-
-## Step 1: Run Tests
-
-[PROJECT-SPECIFIC TEST COMMANDS with options for watch mode, coverage, filtering]
-
-## Step 2: If Failures
-
-For each failing test, use the subagent tool to spawn a sub-agent to fix the underlying issue (not the test).
-
-## Step 3: Re-run
-
-Re-run tests to verify all fixes.
-\`\`\`
-
-Replace placeholders with the actual test commands for this project.
-
-## Step 5: Report
-
-Summarize what was set up, how many tests were created, what official docs/current examples verified the setup, and that /test is now available.`,
-    },
-    {
-        name: "setup-update",
-        aliases: [],
-        description: "Generate an /update command for dependency updates",
-        prompt: `Detect the project type and generate an /update command for dependency updates and deprecation fixes.
-
-## Step 1: Detect Project Type & Package Manager
-
-Check for config files and lock files:
-- package.json + package-lock.json -> npm
-- package.json + yarn.lock -> yarn
-- package.json + pnpm-lock.yaml -> pnpm
-- pyproject.toml + poetry.lock -> poetry
-- requirements.txt -> pip
-- go.mod -> Go
-- Cargo.toml -> Rust
-
-## Step 2: Generate /update Command
-
-Create the directory \`.ezcoder/commands/\` if it doesn't exist, then write \`.ezcoder/commands/update.md\`:
-
-\`\`\`markdown
----
-name: update
-description: Update dependencies, fix deprecations and warnings
----
-
-## Step 1: Check for Updates
-
-[OUTDATED CHECK COMMAND for detected package manager]
-
-## Step 2: Update Dependencies
-
-[UPDATE COMMAND + SECURITY AUDIT]
-
-## Step 3: Check for Deprecations & Warnings
-
-Run a clean install and read ALL output carefully. Look for:
-- Deprecation warnings
-- Security vulnerabilities
-- Peer dependency warnings
-- Breaking changes
-
-## Step 4: Fix Issues
-
-For each warning/deprecation:
-1. Research the recommended replacement or fix using official changelogs, migration guides, advisories, or package docs
-2. Update code/dependencies accordingly
-3. Re-run installation
-4. Verify no warnings remain
-
-## Step 5: Run Quality Checks
-
-[PROJECT-SPECIFIC LINT/TYPECHECK COMMANDS]
-
-Fix all errors before completing.
-
-## Step 6: Verify Clean Install
-
-Delete dependency folders/caches, run a fresh install, verify ZERO warnings/errors.
-\`\`\`
-
-Replace all placeholders with the actual commands for the detected project type and package manager.
-
-## Step 3: Confirm
-
-Report that /update is now available with dependency updates, security audits, and deprecation fixes, and mention that generated update steps require official changelog/migration-guide verification before applying changes.`,
-    },
-    {
-        name: "setup-eyes",
-        aliases: [],
-        description: "Set up project perception probes and document them",
-        prompt: `# Eyes: Set Up or Expand Project Perception
-
-Build the perception probes this project needs and document them in CLAUDE.md so any future agent can use them. The \`ezcoder eyes\` CLI does the mechanical work (detect, install, verify); your job is **judgment** (which capabilities matter for THIS project) and **prose** (the project-specific triggers in CLAUDE.md). Re-run this command anytime to add or fix probes.
-
-## Steps
-
-1. \`ezcoder eyes list\` — see what's already installed/verified. **Resume**, don't restart. Skip verified probes; re-run failed ones.
-2. \`ezcoder eyes detect\` — emits JSON of \`{capability: {candidates, primary}}\` for this project.
-3. **Pick 3–8 capabilities to install this run.** Verify any capability assumptions against \`ezcoder eyes\` help output or official/local CLI docs before installing. Heuristics:
-   - Universal: \`http\` for any API/backend, \`runtime_logs\` for anything with a server.
-   - UI: \`visual\` — for multi-stack projects (e.g. React Native), install all primary candidates with distinct names: \`install visual --impl playwright --as visual-web\`, \`install visual --impl adb --as visual-android\`, \`install visual --impl simctl --as visual-ios\`.
-   - Backend with email/webhooks: \`capture_email\`, \`capture_webhook\`.
-   - **Always defer** opt-ins: \`load\`, \`chaos\`, \`remote\`, \`apm\` — unless the user explicitly asked.
-4. For each pick: \`ezcoder eyes install <cap> [--impl <name>] [--as <name>]\`. On failure: retry once, then mark and continue — don't abort the whole run.
-5. \`ezcoder eyes verify\` — runs every installed probe's self-test. Some failures (\`adb\` no device, \`simctl\` no booted simulator) are expected; they get recorded.
-6. **Write/update the \`## Eyes\` section in CLAUDE.md** (create CLAUDE.md if missing; do NOT clobber other sections). Use the template below. The triggers are the load-bearing piece — make them project-specific and actionable.
-7. **Report**: list verified ✓ / failed ✗ / deferred, and note which probe self-tests or docs verified the setup. End with the restart notice.
-
-## CLAUDE.md \`## Eyes\` template
-
-\`\`\`markdown
-## Eyes
-
-Perception probes live in \`.ezcoder/eyes/\`. All headless. Artifacts → \`.ezcoder/eyes/out/\` (gitignored). Invoke probes yourself; don't ask the user to verify what you can verify.
-
-### Available probes
-
-| Need | Run | Then |
-|---|---|---|
-| <one-line need> | \`.ezcoder/eyes/<id>.sh <args>\` | <how to consume the output> |
-| ... | ... | ... |
-
-### When to use these eyes (automatically, without being asked)
-
-Reach for probes ON YOUR OWN INITIATIVE when any of these apply:
-
-- <project-specific trigger 1, e.g. "After editing any \`.tsx\` file under \`src/components/\`, screenshot the affected page with \`.ezcoder/eyes/visual.sh http://localhost:3000/<path>\`.">
-- <trigger 2, e.g. "After adding/modifying a route under \`src/routes/\`, hit it with \`.ezcoder/eyes/http.sh\` and confirm the response shape.">
-- <trigger 3>
-
-If a probe fails or returns unexpected results, investigate the artifact directly before assuming the probe itself is broken.
-
-### When NOT to use
-
-- Docs-only changes, comments, formatting.
-- Refactors covered by tests.
-- Dev server / simulator / sink isn't up AND the task doesn't require runtime verification.
-- Same probe already ran this turn on the same artifact — reuse the output.
-
-### When to escalate a capability gap (the self-improvement loop)
-
-If you're about to **guess**, **skip verification**, or **hand-wave** about something a better probe would show you — STOP and surface the tradeoff inline. Phrasing like:
-
-> "I tried screenshotting but the failure is a JS error I can only see in the browser console — and there's no \`browser_console\` probe. Two paths: (a) ~3 min to add it, then I can diagnose properly. (b) Workaround: I'd guess from the DOM state. Your call?"
-
-Wait for the user's choice. **Don't escalate more than once per request** — if the user picked the workaround, don't re-ask in the same turn.
-
-For minor friction (worked around it but wished it were better), don't interrupt — log it for later review:
-- \`ezcoder eyes log rough "<reason>" [--probe <name>]\` — minor friction, you handled it
-- \`ezcoder eyes log wish "<gap>"\` — capability you wished existed
-- \`ezcoder eyes log blocked "<reason>"\` — call this AFTER the user approves an inline-escalation fix, for the audit trail
-
-These accumulate quietly. The user reviews them periodically. Open signals will appear in your context on future turns until they're acked.
-\`\`\`
-
-## Trigger writing rules
-
-The "When to use" triggers are project-specific and the load-bearing piece — without them the agent has probes but no instinct to use them. Rules:
-- For each verified probe, write at least one trigger that names a real **file pattern** or **task type** the agent will recognize ("after editing \`*.tsx\` under \`src/ui/\`", not "after UI changes").
-- Be **actionable** ("screenshot the page", "hit the endpoint") not **vague** ("verify it works").
-- Match density to the project: a UI-heavy app warrants strong visual triggers; a pure backend library does not.
-
-## Restart notice
-
-End your report with:
-
-> ⚠ CLAUDE.md was updated. ezcoder loads CLAUDE.md at startup, so **exit and restart ezcoder** (\`/quit\` then \`ezcoder\` again) before asking me to use these probes. Without a restart, I won't see the new instructions in my context.`,
-    },
-    {
-        name: "eyes-improve",
-        aliases: [],
-        description: "Triage eyes signals and apply approved probe fixes",
-        prompt: `# Eyes Improve: Triage Accumulated Signals
-
-Read the open signals in \`.ezcoder/eyes/journal.jsonl\`, group related ones, propose concrete fixes, and apply what the user approves. This isn't unbounded refactoring — it's incremental probe improvement driven by real use.
-
-## Steps
-
-1. \`ezcoder eyes log list --status open\` — if zero entries, say "nothing to triage" and stop.
-2. **Group** signals by likely fix:
-   - Multiple \`rough\` entries naming the same probe / same frustration → one patch to that probe.
-   - \`wish\` entries naming a capability not installed → one \`ezcoder eyes install <cap>\` proposal.
-   - \`blocked\` entries are historical (user already resolved inline) → ack them, no new work.
-3. **Cap at 5 proposals this run.** If more would apply, mention them and stop — they'll resurface next run.
-4. For each group, propose ONE concrete change:
-   - **Probe tweak**: read \`.ezcoder/eyes/<name>.sh\`, show a diff, explain what it fixes.
-   - **New probe**: \`ezcoder eyes install <cap>\` with a one-line justification.
-   - **New/updated trigger**: bullet added under \`## Eyes → When to use\` in CLAUDE.md.
-5. Present all proposals as a numbered list with diffs inline. Ask: **"Accept which? Reply with numbers (e.g. '1, 3') or 'none'."**
-6. On user reply:
-   - For accepted: apply the change. Then run the relevant probe self-test or a focused command that exercises the changed probe/trigger. Then \`ezcoder eyes log ack <id>\` for every journal entry the proposal covers.
-   - For unmentioned / rejected: \`ezcoder eyes log defer <id>\` so they stop appearing in context every turn. The user can resurrect deferred entries later.
-7. **Report**: applied changes (one line each), verification run, entries acked, entries deferred.
-
-## Rules
-
-- **No fishing.** Only act on entries already in the journal. Don't scan the repo for hypothetical gaps.
-- **No scope creep.** "Add a \`--wait-for-selector\` flag to the visual probe" is in scope. "Rewrite the probe in TypeScript" is not.
-- **Preserve user edits.** If \`.ezcoder/eyes/<name>.sh\` has diverged from the shipped impl (user hand-edited), point this out and ask before overwriting.
-- **Be honest about tradeoffs.** If a proposed fix might break existing invocations, say so in the proposal.
-- **Decline when appropriate.** If open signals are all vague or low-value, say so and defer them — don't manufacture fixes.`,
-    },
-    {
-        name: "simplify",
-        aliases: [],
-        description: "Review changed code and fix issues found",
-        prompt: `# Simplify: Code Review and Cleanup
-
-Review all changed files for reuse, quality, and efficiency. Fix any issues found.
-
-## Phase 1: Identify Changes
-
-Run \`git diff\` (or \`git diff HEAD\` if there are staged changes) to see what changed. If there are no git changes, review the most recently modified files that the user mentioned or that you edited earlier in this conversation.
-
-## Phase 2: Launch Three Review Agents in Parallel
-
-Use the subagent tool to launch all three agents concurrently in a single response (call the subagent tool 3 times in one message). Pass each agent the full diff so it has the complete context.
-
-### Agent 1: Code Reuse Review
-
-For each change:
-
-1. **Search for existing utilities and helpers** that could replace newly written code. Look for similar patterns elsewhere in the codebase — common locations are utility directories, shared modules, and files adjacent to the changed ones.
-2. **Flag any new function that duplicates existing functionality.** Suggest the existing function to use instead.
-3. **Flag any inline logic that could use an existing utility** — hand-rolled string manipulation, manual path handling, custom environment checks, ad-hoc type guards, and similar patterns are common candidates.
-
-### Agent 2: Code Quality Review
-
-Review the same changes for hacky patterns:
-
-1. **Redundant state**: state that duplicates existing state, cached values that could be derived, observers/effects that could be direct calls
-2. **Parameter sprawl**: adding new parameters to a function instead of generalizing or restructuring existing ones
-3. **Copy-paste with slight variation**: near-duplicate code blocks that should be unified with a shared abstraction
-4. **Leaky abstractions**: exposing internal details that should be encapsulated, or breaking existing abstraction boundaries
-5. **Stringly-typed code**: using raw strings where constants, enums (string unions), or branded types already exist in the codebase
-6. **Unnecessary JSX nesting**: wrapper Boxes/elements that add no layout value — check if inner component props (flexShrink, alignItems, etc.) already provide the needed behavior
-7. **Unnecessary comments**: comments explaining WHAT the code does (well-named identifiers already do that), narrating the change, or referencing the task/caller — delete; keep only non-obvious WHY (hidden constraints, subtle invariants, workarounds)
-
-### Agent 3: Efficiency Review
-
-Review the same changes for efficiency:
-
-1. **Unnecessary work**: redundant computations, repeated file reads, duplicate network/API calls, N+1 patterns
-2. **Missed concurrency**: independent operations run sequentially when they could run in parallel
-3. **Hot-path bloat**: new blocking work added to startup or per-request/per-render hot paths
-4. **Recurring no-op updates**: state/store updates inside polling loops, intervals, or event handlers that fire unconditionally — add a change-detection guard so downstream consumers aren't notified when nothing changed. Also: if a wrapper function takes an updater/reducer callback, verify it honors same-reference returns (or whatever the "no change" signal is) — otherwise callers' early-return no-ops are silently defeated
-5. **Unnecessary existence checks**: pre-checking file/resource existence before operating (TOCTOU anti-pattern) — operate directly and handle the error
-6. **Memory**: unbounded data structures, missing cleanup, event listener leaks
-7. **Overly broad operations**: reading entire files when only a portion is needed, loading all items when filtering for one
-
-## Phase 3: Fix Issues
-
-Wait for all three agents to complete. Aggregate their findings and fix each issue directly. If a finding is a false positive or not worth addressing, note it and move on — do not argue with the finding, just skip it.
-
-Before making any non-trivial pattern/API change, verify the intended approach against local neighboring code first; use kencode search or official docs when the change touches framework APIs, lifecycle behavior, concurrency, cleanup, or other conventions where real-world practice matters.
-
-When done, run relevant project checks/tests, then briefly summarize what was fixed (or confirm the code was already clean) and what verification ran.`,
-    },
-    {
-        name: "batch",
-        aliases: [],
-        description: "Plan a large change, execute in parallel PRs",
-        prompt: `# Batch: Parallel Work Orchestration
-
-You are orchestrating a large, parallelizable change across this codebase.
-
-## Phase 1: Research
-
-Launch one or more subagents using the subagent tool with \`agent: "researcher"\` to deeply research what this instruction touches. You need their results before proceeding, so wait for them to complete. Have them:
-
-- Find ALL files, patterns, and call sites that need to change
-- Understand existing conventions so the migration is consistent
-- Quantify the surface area (how many files, how many call sites)
-- Note any risks or complications
-
-## Phase 2: Plan
-
-After research completes, call the enter_plan tool to enter plan mode. Using the research findings:
-
-1. **Decompose into independent units.** Break the work into 5–30 self-contained units. Each unit must:
-   - Be independently implementable on its own git branch (no shared state with sibling units)
-   - Be mergeable on its own without depending on another unit's PR landing first
-   - Be roughly uniform in size (split large units, merge trivial ones)
-
-   Scale the count to the actual work: few files → closer to 5; hundreds of files → closer to 30. Prefer per-directory or per-module slicing over arbitrary file lists.
-
-2. **Determine the test recipe.** Figure out how a worker can verify its change actually works — not just that unit tests pass. Look for:
-   - An existing e2e/integration test suite the worker can run
-   - A dev-server + curl pattern (for API changes)
-   - A CLI verification pattern (for CLI changes)
-
-   If you cannot find a concrete verification path, ask the user how to verify. Offer 2–3 specific options based on what the researcher found. Do not skip this — the workers cannot ask the user themselves.
-
-3. **Write the plan** to \`.ezcoder/plans/batch.md\` with:
-   - Summary of research findings
-   - Numbered list of work units — each with: title, file list, one-line description
-   - The test recipe (or "skip e2e because …")
-   - Note that each worker will use the \`worker\` agent (branch-isolated)
-
-4. Call exit_plan to present the plan for approval.
-
-## Phase 3: Spawn Workers (After Plan Approval)
-
-Record the current branch name first: \`git branch --show-current\`.
-
-Spawn one subagent per work unit using the subagent tool with \`agent: "worker"\`. **Launch them all in a single message block so they run in parallel.**
-
-For each worker, the task must be fully self-contained. Include:
-- The overall goal (the user's instruction)
-- The starting branch to branch from (the branch name you recorded above)
-- This unit's specific task (title, file list, change description — copied verbatim from your plan)
-- Any codebase conventions discovered during research
-- The test recipe from your plan (or "skip e2e because …")
-- These additional instructions, copied verbatim:
-
-\`\`\`
-After you finish implementing the change:
-1. Self-review your diff for code reuse, quality, and efficiency. Search the codebase for existing utilities that could replace new code. Fix any issues found.
-2. For framework/API/config changes, compare the approach with official docs or kencode search examples before finalizing. Do not use kencode for purely local renames or mechanical edits.
-3. Run the project's test suite (check for package.json scripts, Makefile targets, or common commands like npm test, pnpm test, pytest, go test). If tests fail, fix them.
-4. Follow the e2e test recipe above. If it says to skip e2e, skip it.
-5. Commit all changes with a clear message, push the branch, and create a PR with gh pr create. Use a descriptive title.
-6. Switch back to the original branch with git checkout -.
-7. End with exactly: PR: <url> or PR: none — <reason>
-\`\`\`
-
-## Phase 4: Track Results
-
-After launching all workers, render an initial status table:
-
-| # | Unit | Status | PR |
-|---|------|--------|----|
-| 1 | <title> | running | — |
-| 2 | <title> | running | — |
-
-As workers complete, parse the \`PR: <url>\` line from each result and re-render the table with updated status (\`done\` / \`failed\`) and PR links. Keep a brief failure note for any worker that did not produce a PR.
-
-When all workers have reported, render the final table and a one-line summary (e.g., "22/24 units landed as PRs").`,
     },
     {
         name: "compare",
         aliases: [],
-        description: "Compare code against real-world implementations via kencode-search",
+        description: "Compare real-world code",
         prompt: `Compare the code you just created or modified in this conversation against real-world implementations using the \`mcp__kencode-search__searchCode\` tool.
 
 You already know what you just built. For each file you created or modified, use \`mcp__kencode-search__searchCode\` to search for how real projects implement the same patterns. Look at the specific APIs, hooks, functions, and architecture you used.
@@ -1251,7 +421,7 @@ If the code aligns well with real-world patterns, say so. That's a good outcome.
     {
         name: "setup-skills",
         aliases: [],
-        description: "Audit project, recommend skills ranked by impact",
+        description: "Recommend useful skills",
         prompt: `# Skills Audit: Find useful skills for this project
 
 Analyze this project and recommend skills from the open ecosystem that would make **working on this project more efficient, easier, and safer**. That is the goal, full stop. Every recommendation must pass the test: does this skill save real time, lower real cognitive load, or prevent real mistakes for someone working on THIS project, repeatedly?
@@ -1350,7 +520,7 @@ After presenting the list, ask which (if any) to install. Install nothing withou
     {
         name: "setup",
         aliases: ["setup-project"],
-        description: "Audit project hygiene, tooling, verify pipeline, and style-pack alignment",
+        description: "Audit project setup",
         prompt: `Audit this project across six categories and report gaps. **Do not fix anything yet.** Wait for me to choose what to address after the report.
 
 Language-agnostic and project-agnostic — adapt findings to the languages and stack actually present. Ignore categories that don't apply (e.g. skip CI for a local-only scratchpad).
@@ -1425,16 +595,16 @@ At the end:
 <N> gaps in hygiene, <N> in tooling, <N> in verify pipeline, <N> in style-pack alignment.
 
 Which (if any) would you like me to fix? Options:
-- A) Create tasks for all [GAP] items that are safe + additive (no overwrites)
-- B) Create tasks for a category: hygiene / tooling / verify / style-pack alignment
-- C) Create tasks for specific items — tell me which
+- A) Add tasks for all [GAP] items that are safe + additive (no overwrites)
+- B) Add tasks for a category: hygiene / tooling / verify / style-pack alignment
+- C) Add tasks for specific items — tell me which
 - D) None — just the report
 \`\`\`
 
 ## Rules
 
 - **Report only.** No edits, no installs, no commits without explicit user confirmation after the report.
-- **Task handoff for fixes.** If the user chooses A, B, or C, do not fix directly. Use the tasks tool to create one standalone task per selected gap or tightly coupled gap group. Each task must include the gap, affected files/configs, safe-additive constraints, implementation instructions, project verification commands, and instructions to verify relevant tool/config semantics against official docs before marking the task complete. Use kencode search only for code-level examples, not as proof of scaffolding requirements. After creating tasks, tell the user exactly: "Tasks created. Press CTRL + T to open the Tasks Pane and press R to run all tasks." Do not begin executing them unless the user explicitly starts a task.
+- **Task handoff for fixes.** If the user chooses A, B, or C, do not fix directly. Add one task per selected gap or tightly coupled gap group using the \`tasks\` tool (action=add). Each task needs a short title and a standalone prompt that includes the gap, affected files/configs, safe-additive constraints, implementation instructions, project verification commands, and instructions to verify relevant tool/config semantics against official docs before completing the task. Use kencode search only for code-level examples, not as proof of scaffolding requirements. After adding the tasks, tell the user exactly: "Tasks added. Press Ctrl+T to open the task list and run them." Do not begin executing them unless the user explicitly says so.
 - **No code refactors recommended.** This audit is about scaffolding/tooling, not code review. Use \`/scan\` or \`/verify\` for code-level findings.
 - **No dependency installations in the report.** Listing them as observations is fine; recommending installation is not — that's the user's call.
 - **Skip empty categories.** If a category has no findings, omit it.