@mthanhlm/autodev 0.4.4 → 0.5.0

package/autodev/workflows/help.md

@@ -1,113 +0,0 @@
-# autodev
-
-Lean Claude Code workflow. No automatic commits. No branches. No worktrees. Git is read-only.
-It resolves `.autodev/` state from the repo root even when you start Claude in a nested subdirectory.
-It can auto-format edited code after writes when the repo already has a local formatter available.
-Supported runtime is Claude Code with Node plus `sh`/`bash` available.
-
-## Main Entry
-
-- `/autodev`
-  The default checkpointed command. It routes automatically through project setup, codebase mapping, planning, plan review, execution, review, verification, and cleanup.
-- `/autodev-auto`
-  The explicit continuous mode. It keeps going until the track is done or a real stop condition appears, such as missing intent, dependency deadlock, retry-limit exhaustion, or manual verification.
-
-## Manual Commands
-
-- `/autodev-help`
-  Shows this reference.
-- `/autodev-new-project`
-  Creates project state in `.autodev/` and the first active track under `.autodev/tracks/<track>/`.
-- `/autodev-explore-codebase`
-  Uses foreground codebase agents, one at a time when available, to map a brownfield repo into `.autodev/codebase/`.
-- `/autodev-plan-phase [phase]`
-  Creates or revises one phase plan plus task files in `.autodev/tracks/<track>/phases/NN-type-name/`.
-- `/autodev-execute-phase [phase]`
-  Orchestrates exactly one task for the phase, preferring a fresh foreground delegated agent, and writes `TASK-NN-SUMMARY.md`.
-- `/autodev-review-task [phase]`
-  Pauses after one completed task so the user can review the result before executing the next task or starting phase review.
-- `/autodev-review-phase [phase]`
-  Uses foreground review agents, one at a time when available, for code quality, security, integration, and polish, then writes `NN-REVIEW.md`.
-- `/autodev-verify-work [phase]`
-  Records manual verification in `NN-UAT.md` and captures fix-return gaps when verification fails.
-- `/autodev-progress`
-  Shows project type, active track, phase status, and the next recommended route.
-- `/autodev-cleanup`
-  Asks what to clean or archive. No flags required.
-
-## Workflow Model
-
-```text
-project -> track -> phase -> tasks
-```
-
-- `project`
-  Whole repo or product context.
-- `track`
-  The current initiative, feature line, refactor, or bugfix stream.
-- `phase`
-  Small milestone slices inside the active track.
-- `task`
-  Reviewable execution units inside a phase.
-
-## Blocker Recovery
-
-- Review or verification blockers should normally stay in the same phase.
-- Preserve completed task history.
-- Append `TASK-XX` remediation work to the same phase.
-- Only create a new phase when the blocker reveals genuinely new scope.
-
-## Default Flow
-
-```text
-/autodev
-```
-
-Typical brownfield route:
-
-```text
-/autodev
-  -> new project
-  -> explore codebase
-  -> plan
-  -> review plan
-  -> execute
-  -> review task
-  -> execute
-  -> review task
-  -> review
-  -> verify
-  -> next track or cleanup
-```
-
-## Git Policy
-
-Allowed:
-
-- `git status`
-- `git diff`
-- `git log`
-- `git show`
-- `git rev-parse`
-- `git ls-files`
-- `git branch --show-current`
-
-Blocked:
-
-- `git init`
-- `git add`
-- `git commit`
-- `git checkout`
-- `git switch`
-- `git merge`
-- `git rebase`
-- `git worktree`
-- `git clean`
-- `git cherry-pick`
-- `git push`
-- `git pull`
-- `git stash`
-- `git reset`
-- `git fetch`
-- `git clone`
-- mutating `git branch`, `git tag`, and `git remote` commands

package/autodev/workflows/new-project.md

@@ -1,108 +0,0 @@
-<purpose>
-Initialize `.autodev/` with useful project-level context, then create the first active track. Prefer fast clarity over exhaustive ceremonies.
-</purpose>
-
-<rules>
-- Do not run `git init`, `git add`, `git commit`, `git checkout`, `git switch`, `git merge`, `git rebase`, `git worktree`, `git push`, `git pull`, `git stash`, `git reset`, `git fetch`, or `git clone`.
-- Git is read-only only.
-- Use concise questioning, but do a short discovery pass before writing project state.
-- Ask only for details that materially change requirements or roadmap.
-- Treat the repository as a `project`, then put the current initiative in a `track`.
-- If this workflow was entered from `/autodev-auto`, continue automatically only when the current prompt is specific enough to define the project and first track without guessing.
-</rules>
-
-<process>
-1. Run:
-
-```bash
-AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
-node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init new-project
-```
-
-If this run came from `/autodev-auto`, append `--auto` to the same command.
-
-2. If `.autodev/PROJECT.md` already exists, stop and tell the user to use `/autodev`.
-
-3. Do a short discovery pass before writing project or track files.
-   - If the current prompt is thin, ask for:
-     - what the user wants to build or change right now
-     - who it is for or what pain it solves
-     - what done looks like for the first track
-     - scope boundaries, constraints, and explicit non-goals that materially affect planning
-     - whether this is greenfield or brownfield if ambiguous
-   - Prefer one compact batch of questions over a long drip of follow-ups.
-   - Reflect the understanding back in 2-5 bullets before writing files when the original request was vague.
-
-4. Read the templates from the execution context.
-
-5. Create `.autodev/config.json` from the template with these defaults unless the user explicitly asks otherwise:
-   - `project.type: "greenfield"` or `"brownfield"`
-   - `workflow.research: false`
-   - `workflow.review_after_execute: true`
-   - `git.mode: "read-only"`
-   - `hooks.auto_format: true`
-
-6. Write `.autodev/PROJECT.md` with:
-   - one-line summary
-   - project type
-   - repo or product problem
-   - current user goal or job to be done
-   - users or operators
-   - success criteria
-   - constraints
-   - non-goals
-
-7. Create `.autodev/ACTIVE_TRACK` with a lowercase hyphenated slug for the first track.
-
-8. Write `.autodev/STATE.md` with:
-   - `Project Type: ...`
-   - `Active Track: <slug>`
-   - `Current Step: initialized`
-   - `Current Task: none`
-   - `Current Task Status: idle`
-   - `Status: active`
-   - `Run Mode: checkpointed` for `/autodev`, or `Run Mode: auto` for `/autodev-auto`
-   - `Auto Retry Count: 0`
-   - `Next Command: /autodev` for checkpointed mode, or `/autodev-auto` for auto mode
-   - current ISO timestamp
-
-9. Create `.autodev/tracks/<slug>/TRACK.md` with:
-   - track name
-   - type or workstream shape
-   - why this track exists now
-   - desired outcome and what done looks like
-   - scope boundaries and explicit non-goals
-   - known dependencies
-   - brownfield notes if this is an existing repo
-
-10. Write `.autodev/tracks/<slug>/REQUIREMENTS.md` with clear must-have requirements and acceptance bullets for the track only.
-   Tie the acceptance bullets to the discovered outcome instead of placeholder implementation tasks.
-
-11. Write `.autodev/tracks/<slug>/ROADMAP.md` with 2-8 phases using this exact heading format:
-
-```text
-## Phase N [type]: Name
-```
-
-Each phase must include:
-   - `Status: pending`
-   - `Goal: ...`
-   - `Deliverables:`
-   - `Risks:`
-
-12. Write `.autodev/tracks/<slug>/STATE.md` with:
-   - `Current Phase: 1`
-   - `Current Phase Type: <type>`
-   - `Current Step: planning`
-   - `Current Task: none`
-   - `Current Task Status: idle`
-   - `Status: active`
-   - `Run Mode: checkpointed` for `/autodev`, or `Run Mode: auto` for `/autodev-auto`
-   - `Auto Retry Count: 0`
-   - `Next Command: /autodev` for checkpointed mode, or `/autodev-auto` for auto mode
-   - current ISO timestamp
-
-13. If the project is brownfield, do not fake a codebase map. Continue into codebase exploration inside `/autodev` by default. Mention `/autodev-explore-codebase` only as a manual shortcut. Otherwise, the next step is planning phase 1 through `/autodev`.
-
-14. End with a short summary of what the user wants to build or change and direct the user to `/autodev`. Mention the manual shortcut only if useful.
-</process>

package/autodev/workflows/plan-phase.md

@@ -1,134 +0,0 @@
-<purpose>
-Create one practical phase plan for the active track, then break it into reviewable task files that are small enough for fresh foreground-agent execution.
-</purpose>
-
-<rules>
-- One plan file per phase: `NN-PLAN.md`.
-- Use task files as the execution unit.
-- Prefer direct action over deep orchestration.
-- Optional research is allowed only when the user asks for it or `workflow.research` is true.
-- Never include git write commands in the plan.
-- Do not use waves by default.
-- When revising a blocked phase, preserve the same phase, the same phase goal, and all completed task history.
-- In `/autodev-auto`, a freshly written or repaired plan should continue automatically unless the plan itself still depends on unresolved user intent.
-</rules>
-
-<process>
-1. Run:
-
-```bash
-AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
-node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init plan-phase "$ARGUMENTS"
-```
-
-If this run came from `/autodev-auto`, append `--auto` to the same command.
-
-2. If there is no active track or no roadmap for it, stop and tell the user to run `/autodev`.
-
-3. If no phase is found, tell the user all phases already have plans and show `/autodev-progress`.
-
-4. Read:
-   - `.autodev/PROJECT.md`
-   - `.autodev/STATE.md`
-   - `.autodev/codebase/summary.md` if it exists
-   - `.autodev/tracks/<active-track>/TRACK.md`
-   - `.autodev/tracks/<active-track>/REQUIREMENTS.md`
-   - `.autodev/tracks/<active-track>/ROADMAP.md`
-   - `.autodev/tracks/<active-track>/STATE.md`
-   - the target phase section
-   - any existing `TASK-*.md`
-   - any existing `TASK-*-SUMMARY.md`
-   - `NN-REVIEW.md` if it exists
-   - `NN-UAT.md` if it exists
-   - any existing code relevant to this phase
-
-5. If research is enabled or explicitly requested, do targeted read-only research only. Keep the output folded into the plan instead of producing a separate research artifact.
-
-6. Create the phase directory if missing:
-
-```text
-.autodev/tracks/<active-track>/phases/NN-type-name/
-```
-
-7. Write or update `NN-PLAN.md` from the template. The plan must include:
-   - phase type
-   - goal
-   - shared verification commands
-   - task list overview
-   - explicit git read-only reminder
-
-8. If this phase is being reopened because of `blocked_review`, `blocked_verification`, `blocked_dependencies`, or another blocker status:
-   - keep the same phase directory and phase goal
-   - do not create a new phase for ordinary blockers
-   - do not delete or rewrite completed task summaries
-   - do not renumber completed tasks
-   - preserve already-completed task rows in the phase plan
-   - append new remediation tasks after `last_task_number`
-   - default to one appended remediation task when the blockers are tightly related
-   - split into multiple appended remediation tasks only when the blockers are clearly separate
-   - only rewrite still-pending tasks when that improves clarity
-   - make the new task titles explicit, for example:
-     - `TASK-03: Fix review blockers from 01-REVIEW.md`
-     - `TASK-04: Fix verification gaps from 01-UAT.md`
-
-9. Create or update task files in the same phase directory:
-
-```text
-TASK-01.md
-TASK-02.md
-...
-```
-
-Each task should be:
-   - small enough for one fresh delegated agent context
-   - clear about likely files to touch
-   - explicit about verification
-   - reviewable as a standalone unit
-   - sequential by default unless there is an obvious safe dependency split
-
-Each task file must include:
-   - task title
-   - `Status: pending`
-   - `Depends On: ...`
-   - goal
-   - why it is separate
-   - files likely to change
-   - implementation notes
-   - verification
-   - done looks like
-
-10. When revising a blocked phase:
-   - point `Current Task` to the first still-pending executable task after the revision
-   - if all existing tasks are completed and you add remediation work, `Current Task` should be the first newly appended fix task
-   - never reset `Current Task` back to `01` just because the phase was replanned
-
-11. Update the active track `STATE.md` so it points to:
-   - `Current Phase: N`
-   - `Current Phase Type: <type>`
-   - `Current Step: plan_review`
-   - `Current Task: <first-pending-task>` if tasks exist, otherwise `none`
-   - `Current Task Status: pending_review`
-   - `Run Mode: checkpointed` for `/autodev`, or `Run Mode: auto` for `/autodev-auto`
-   - `Auto Retry Count: 0`
-   - `Next Command: /autodev` for checkpointed mode, or `/autodev-auto` for auto mode
-   - current ISO timestamp
-
-12. Update `.autodev/STATE.md` so it points to:
-   - `Active Track: <slug>`
-   - `Current Step: plan_review`
-   - `Current Task: <first-pending-task>` if tasks exist, otherwise `none`
-   - `Current Task Status: pending_review`
-   - `Run Mode: checkpointed` for `/autodev`, or `Run Mode: auto` for `/autodev-auto`
-   - `Auto Retry Count: 0`
-   - `Next Command: /autodev` for checkpointed mode, or `/autodev-auto` for auto mode
-   - current ISO timestamp
-
-13. End with a short summary and stop for review.
-   Tell the user:
-   - the plan and task files are ready for review
-   - completed task history from the phase was preserved
-   - any blocker remediation was added as appended task work inside the same phase
-   - in checkpointed mode, `/autodev` will open the review checkpoint before any execution starts
-   - in auto mode, `/autodev-auto` should continue directly into execution unless a real ambiguity remains
-   - `/autodev-execute-phase N` is only the optional manual bypass after review
-</process>

package/autodev/workflows/progress.md

@@ -1,18 +0,0 @@
-<purpose>
-Render the current autodev status with no extra ceremony.
-</purpose>
-
-<process>
-1. Run:
-
-```bash
-AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
-node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" progress table
-```
-
-2. Output the table directly.
-
-3. If a project exists, add one short line after the table with:
-   - `/autodev` as the default next command
-   - the routed manual shortcut from the table only when useful
-</process>

package/autodev/workflows/review-phase.md

@@ -1,80 +0,0 @@
-<purpose>
-Run the automatic review bundle after execution so the user sees code quality, security, integration, and polish risks before manual verification.
-</purpose>
-
-<rules>
-- Prefer a small set of foreground review agents, run one at a time, when agent delegation is available.
-- Review findings should be concrete and evidence-based.
-- Do not edit repository code in this step unless the user explicitly asks for fixes.
-- Write one consolidated review artifact for the phase.
-- In `/autodev-auto`, blockers should reopen the same phase automatically unless the auto retry limit has already been reached.
-</rules>
-
-<process>
-1. Run:
-
-```bash
-AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
-node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init review-phase "$ARGUMENTS"
-```
-
-If this run came from `/autodev-auto`, append `--auto` to the same command.
-
-2. If no executed phase is found, stop and direct the user to `/autodev-execute-phase`.
-
-3. Read:
-   - `.autodev/STATE.md`
-   - the active track `STATE.md`
-   - `NN-PLAN.md`
-   - all `TASK-*.md`
-   - all `TASK-*-SUMMARY.md`
-   - `NN-SUMMARY.md`
-   - relevant source files and tests
-
-4. If agent delegation is available, explicitly call the `Agent` tool for these review subagents, one at a time in the foreground:
-   - `autodev-review-quality` for standalone installs, or `autodev:autodev-review-quality` in direct plugin runs
-   - `autodev-review-security` for standalone installs, or `autodev:autodev-review-security` in direct plugin runs
-   - `autodev-review-integration` for standalone installs, or `autodev:autodev-review-integration` in direct plugin runs
-   - `autodev-review-polish` for standalone installs, or `autodev:autodev-review-polish` in direct plugin runs
-
-5. Tell each review agent:
-   - it is not alone in the codebase
-   - it should stay read-only and return findings only
-   - it should focus on clear issues, not generic commentary
-   - it should report severity, evidence, and suggested action
-
-6. If agent delegation is unavailable, do not stop on the raw platform message.
-   Treat messages like `specialized agents aren't available` as an environment limitation, tell the user review will continue in the current session, and perform the same review pass directly using the four lenses:
-   - quality
-   - security
-   - integration
-   - product polish
-
-7. Synthesize the four agent responses, or the current-session four-lens review, into `NN-REVIEW.md` from the template with:
-   - grouped findings
-   - blockers vs non-blockers
-   - what looks solid
-   - a final recommendation
-
-8. If blockers are found:
-   - set project and track state back to `Current Step: planning`
-   - set `Current Task: none`
-   - set `Current Task Status: blocked_review`
-   - keep `Run Mode` aligned to the current command
-   - if this is `/autodev-auto`, increment `Auto Retry Count` by `1`
-   - keep `Next Command` aligned to the current command
-   - make the recommendation point back to revising the same phase with appended blocker-fix tasks
-   - do not recommend creating a new phase for ordinary review blockers
-   - preserve completed task history and phase goal
-
-9. If blockers are not found:
-   - set project and track state to `Current Step: verification`
-   - reset `Auto Retry Count` to `0`
-   - keep `Run Mode` aligned to the current command
-   - keep `Next Command` aligned to the current command
-
-10. End with a short review result:
-   - ready for verification, or
-   - return to execution
-   - include the manual shortcut command
-</process>

package/autodev/workflows/review-plan.md

@@ -1,55 +0,0 @@
-<purpose>
-Pause after phase planning so the user can review the generated plan and task breakdown before any execution starts.
-</purpose>
-
-<rules>
-- Do not start task execution automatically from a freshly created plan.
-- Keep this as a control checkpoint for the user.
-- Do not edit repository code in this step unless the user explicitly chooses to revise the plan.
-- Prefer `/autodev` as the entrypoint even at this checkpoint.
-</rules>
-
-<process>
-1. Run:
-
-```bash
-AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
-node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init review-plan "$ARGUMENTS"
-```
-
-2. If no planned phase is found, stop and direct the user to `/autodev`.
-
-3. Read:
-   - `.autodev/STATE.md`
-   - the active track `STATE.md`
-   - `NN-PLAN.md`
-   - all `TASK-*.md`
-
-4. Show the user a concise review summary:
-   - phase id and phase goal
-   - task list with dependencies
-   - likely files or areas to change
-   - shared verification plan
-
-5. Ask the user what to do next with `AskUserQuestion`:
-   - execute one task now
-   - revise the phase plan
-   - stop here
-
-6. If the user chooses to execute now:
-   - load the execute-phase workflow
-   - perform exactly one task in the same turn
-   - stop after that task completes
-
-7. If the user chooses to revise the plan:
-   - load the plan-phase workflow
-   - revise the same phase in the same turn
-
-8. If the user chooses to stop here:
-   - keep both state files on:
-     - `Current Step: plan_review`
-     - `Next Command: /autodev`
-   - end with a short note that execution has not started yet
-
-9. End with a short outcome summary and `/autodev` as the default next command.
-</process>

package/autodev/workflows/review-task.md

@@ -1,70 +0,0 @@
-<purpose>
-Pause after one completed task so the user can review the outcome before more execution happens in the same phase.
-</purpose>
-
-<rules>
-- This is a control checkpoint, not an execution step.
-- Do not auto-run the next task from this checkpoint without explicit user approval.
-- Prefer `/autodev` as the entrypoint even at this checkpoint.
-- If all tasks are done, do not auto-start phase review without explicit user approval.
-</rules>
-
-<process>
-1. Run:
-
-```bash
-AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
-node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init review-task "$ARGUMENTS"
-```
-
-2. If no phase is found, stop and direct the user to `/autodev`.
-
-3. Read:
-   - `.autodev/STATE.md`
-   - the active track `STATE.md`
-   - `NN-PLAN.md`
-   - all `TASK-*.md`
-   - the current task summary from `current_task_summary_path`
-   - if `Current Task` is missing or stale, infer the checkpoint task from the most recent existing `TASK-*-SUMMARY.md`
-   - `NN-SUMMARY.md` if it exists
-
-4. Show the user a concise checkpoint summary:
-   - completed task id and title
-   - what changed
-   - verification run
-   - blockers or open concerns
-   - the next ready task, if any
-
-5. If more tasks remain, ask the user what to do next with `AskUserQuestion`:
-   - execute the next task now
-   - revise the phase plan
-   - stop here
-
-6. If all tasks are done, ask the user what to do next with `AskUserQuestion`:
-   - run phase review now
-   - revise the phase plan
-   - stop here
-
-7. If the user chooses to execute the next task:
-   - load the execute-phase workflow
-   - perform exactly one task in the same turn
-   - stop again after that task completes
-
-8. If the user chooses to run phase review:
-   - load the review-phase workflow
-   - perform it in the same turn
-
-9. If the user chooses to revise the plan:
-   - load the plan-phase workflow
-   - revise the same phase in the same turn
-
-10. If the user chooses to stop here:
-   - keep both state files on:
-     - `Current Step: task_review`
-     - `Current Task: <current-task>`
-     - `Current Task Status: complete`
-     - `Next Command: /autodev`
-   - end with a short note that no further execution has started
-
-11. End with a short outcome summary and `/autodev` as the default next command.
-</process>

package/autodev/workflows/verify-work.md

@@ -1,71 +0,0 @@
-<purpose>
-Run lightweight user acceptance testing after review and keep the next action obvious, including a clean fix-return path when verification fails.
-</purpose>
-
-<rules>
-- Verify against what the phase plan, summary, and review claim.
-- Keep the interaction concise and test-oriented.
-- Do not auto-generate a new plan unless a real gap appears.
-- Verification failures should normally reopen the same phase with appended remediation tasks, not create a new phase.
-- In `/autodev-auto`, prefer fully automatable verification first and stop only when verification truly requires human observation or judgment.
-</rules>
-
-<process>
-1. Run:
-
-```bash
-AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
-node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init verify-work "$ARGUMENTS"
-```
-
-If this run came from `/autodev-auto`, append `--auto` to the same command.
-
-2. If no reviewed phase is found, stop and direct the user to `/autodev-review-phase`.
-
-3. Read:
-   - `NN-PLAN.md`
-   - all `TASK-*.md`
-   - all `TASK-*-SUMMARY.md`
-   - `NN-SUMMARY.md`
-   - `NN-REVIEW.md`
-   - relevant code or UI files
-
-4. Choose the verification lane:
-   - If the phase can be verified with concrete commands or deterministic checks that do not require human observation, run those checks directly.
-   - If the phase still depends on visual inspection, human judgment, credentials the assistant does not have, or missing reproducible checks, stop and treat it as `needs_manual_verification`.
-   - When user input is needed, present a short manual verification flow one check at a time.
-
-5. Write or update `NN-UAT.md` from the template with:
-   - test cases
-   - results
-   - bugs or follow-up
-   - recommended next step
-
-6. If verification fails, add a `Fix Return` section to `NN-UAT.md` with:
-   - exact failed behaviors
-   - reproduction notes
-   - the smallest acceptable fix target
-   - a note that the follow-up should be appended to the same phase as remediation task work unless scope truly changed
-
-7. Update the active track `STATE.md`:
-   - if verification passed and another phase remains, move to the next phase and set `Current Step: planning`
-   - if verification passed and no phase remains, set `Current Step: complete`
-   - if verification failed, keep the same phase active and set `Current Step: planning`
-   - when moving to another phase, set `Current Task: none` and `Current Task Status: idle`
-   - when verification failed, set `Current Task: none` and `Current Task Status: blocked_verification`
-   - keep `Run Mode` aligned to the current command
-   - reset `Auto Retry Count` to `0` on success, or increment it by `1` for `/autodev-auto` verification failures
-   - always set `Next Command` aligned to the current command
-   - always refresh the ISO timestamp
-   - when verification failed, the next planning pass should preserve completed tasks and append remediation tasks to the same phase
-
-8. Update `.autodev/STATE.md` with the matching project-level status and refreshed timestamp.
-
-9. In `/autodev-auto`, if verification cannot be completed without human judgment:
-   - stop instead of guessing
-   - keep the current phase active
-   - tell the user this pause reason is `needs_manual_verification`
-   - recommend `/autodev` for manual verification or `/autodev-auto` again after the missing checks are made automatable
-
-10. End with the verification result and the next command. Mention the manual shortcut only if it helps.
-</process>

package/commands/autodev/auto.md

@@ -1,27 +0,0 @@
----
-name: autodev:auto
-description: Run autodev continuously until blocked, manual verification is required, or the active track is done
-argument-hint: "[goal, track, or question]"
-allowed-tools:
-  - Read
-  - Write
-  - Edit
-  - Bash
-  - Grep
-  - Glob
-  - TodoWrite
-  - AskUserQuestion
-  - Agent
-  - WebFetch
----
-<objective>
-Use `/autodev-auto` as the explicit opt-in continuous runner. Keep going until the work is done or a real stop condition appears.
-</objective>
-
-<execution_context>
-@~/.claude/autodev/workflows/autodev-auto.md
-</execution_context>
-
-<process>
-Execute the auto router workflow in @~/.claude/autodev/workflows/autodev-auto.md end-to-end.
-</process>