@mthanhlm/autodev 0.4.2 → 0.4.4

package/autodev/templates/project-state.md

@@ -6,6 +6,8 @@ Current Step: initialized
 Current Task: none
 Current Task Status: idle
 Status: active
+Run Mode: checkpointed
+Auto Retry Count: 0
 Next Command: /autodev
 Last Updated: [ISO timestamp]
 

package/autodev/templates/state.md

@@ -6,6 +6,8 @@ Current Step: initialized
 Current Task: none
 Current Task Status: idle
 Status: active
+Run Mode: checkpointed
+Auto Retry Count: 0
 Next Command: /autodev
 Last Updated: [ISO timestamp]
 

package/autodev/templates/track-state.md

@@ -7,6 +7,8 @@ Current Step: planning
 Current Task: none
 Current Task Status: idle
 Status: active
+Run Mode: checkpointed
+Auto Retry Count: 0
 Next Command: /autodev
 Last Updated: [ISO timestamp]
 

package/autodev/templates/track.md

@@ -3,8 +3,15 @@
 Type: [feature|bugfix|refactor|research|polish]
 Status: active
 
+## Why This Track
+[Why this work matters right now.]
+
 ## Outcome
-[What this track is trying to achieve.]
+[What changes for the user or operator when this track is done.]
+
+## Success Signals
+- [Observable user or operator outcome]
+- [Verification or quality bar]
 
 ## Scope Boundaries
 - [What is in scope]

package/autodev/workflows/autodev-auto.md

@@ -0,0 +1,62 @@
+<purpose>
+Use `/autodev-auto` as the explicit opt-in continuous entrypoint. Route automatically, keep git read-only, and continue until the track is done or a real stop condition requires the user.
+</purpose>
+
+<rules>
+- `/autodev-auto` is opt-in. `/autodev` remains the safer checkpointed default.
+- Never run git write commands.
+- Never use background execution or waves.
+- Use `--auto` when reading autodev router/init/progress payloads.
+- Skip checkpoint-only review stops when the next step is mechanically clear.
+- Stop immediately when `pause_reason` is one of:
+  - `missing_intent`
+  - `track_selection`
+  - `dependency_deadlock`
+  - `needs_manual_verification`
+  - `cleanup_confirmation`
+  - `auto_retry_limit`
+- Review or verification blockers should stay in the same phase. Append remediation work to that phase instead of creating a replacement phase.
+</rules>
+
+<process>
+1. Run:
+
+```bash
+AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
+node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" status --auto
+```
+
+2. Inspect `route.kind`, `route.run_mode`, `route.auto_continuable`, `route.pause_reason`, and the active track data.
+
+3. Handle stop conditions first:
+   - If `route.kind` is `init_project` and the current prompt still does not clearly define the project and first track, stop for `missing_intent`.
+   - If `route.kind` is `init_project` but the current prompt already gives clear project and track intent, treat that pause as resolved and continue into new-project.
+   - If `route.pause_reason` is `track_selection`, stop and ask the user which track to continue or whether to create a new one.
+   - If `route.pause_reason` is `dependency_deadlock`, stop and tell the user the current phase plan must be repaired before more auto execution can continue.
+   - If `route.pause_reason` is `auto_retry_limit`, stop and tell the user the same phase has already auto-replanned twice.
+   - If `route.pause_reason` is `cleanup_confirmation`, stop and require the user to start cleanup explicitly.
+
+4. Route as follows:
+   - `init_project`: load and perform the new-project workflow in auto mode.
+   - `explore_codebase`: load and perform the explore-codebase workflow in auto mode.
+   - `plan_phase`: load and perform the plan-phase workflow in auto mode.
+   - `execute_phase`: load and perform the execute-phase workflow in auto mode.
+   - `review_phase`: load and perform the review-phase workflow in auto mode.
+   - `verify_phase`: load and perform the verify-work workflow in auto mode.
+
+5. Do not load `review-plan` or `review-task` in auto mode. The router already skips those checkpoint-only stops when it is safe to continue.
+
+6. After each completed routed step, re-run the auto status command in the same turn and continue if the next route is still auto-continuable.
+
+7. Keep both project-level and track-level state aligned after every step:
+   - `Run Mode: auto`
+   - `Next Command: /autodev-auto`
+   - `Auto Retry Count: 0` after a clean plan or successful review/verification
+   - increment `Auto Retry Count` only when auto mode reopens the same phase after review or verification blockers
+
+8. End only when the track is complete or a real pause reason remains. Report:
+   - what step just completed
+   - why execution stopped or completed
+   - `/autodev-auto` as the default next command when more auto work remains
+   - `/autodev` only as the manual fallback
+</process>

package/autodev/workflows/autodev.md

@@ -4,6 +4,7 @@ Use `/autodev` as the single entrypoint for the normal workflow. Route automatic
 
 <rules>
 - Prefer `/autodev` over telling the user to run a different command manually.
+- `/autodev` is the checkpointed mode. Use `/autodev-auto` only when the user explicitly asked for continuous execution.
 - Manual commands remain valid escape hatches. Mention them only as shortcuts.
 - Keep the model `project -> track -> phase -> tasks`.
 - Brownfield repositories should be mapped before detailed phase planning.
@@ -37,13 +38,22 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" status
 
 6. If the route is `track_select` or `track_setup`, handle it directly:
    - If tracks exist, ask whether to continue one of them or create a new track.
-   - If no tracks exist, ask only for the current initiative name, desired outcome, and likely phase types.
+   - When creating or repairing a track, do a short track-discovery pass before writing files.
+   - Ask for:
+     - the initiative name
+     - what the user wants to ship or change in this track
+     - what done looks like
+     - scope boundaries and explicit non-goals
+     - dependencies or constraints only if they affect planning
+   - If the request is vague, summarize the understanding in a few bullets and resolve ambiguity before writing.
+   - If no tracks exist, do not jump straight to phase types before the track goal is clear.
    - Create or repair:
      - `.autodev/ACTIVE_TRACK`
      - `.autodev/tracks/<slug>/TRACK.md`
      - `.autodev/tracks/<slug>/REQUIREMENTS.md`
      - `.autodev/tracks/<slug>/ROADMAP.md`
      - `.autodev/tracks/<slug>/STATE.md`
+   - Fill the track and requirements docs from the clarified intent, not generic placeholders.
    - Use a lowercase hyphenated slug.
    - Use roadmap headings in this format:
 
@@ -60,7 +70,10 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" status
 
 8. When the user chooses a new track at step 7, create it immediately and continue routing in the same turn.
 
-9. Every time you finish a routed step, keep both project-level and track-level state aligned. Default the state files to `Next Command: /autodev`.
+9. Every time you finish a routed step, keep both project-level and track-level state aligned. Default the state files to:
+   - `Run Mode: checkpointed`
+   - `Auto Retry Count: 0` unless a blocked phase is being actively recovered
+   - `Next Command: /autodev`
 
 10. End with:
    - what step you completed

package/autodev/workflows/execute-phase.md

@@ -14,6 +14,7 @@ Execute an active-track phase through task-sized delegated runs, keep the main s
 - The main phase session should remain orchestration-focused whenever delegation works.
 - The main phase session may update `.autodev/` state and aggregate phase artifacts.
 - Do not run autodev subagents as background tasks.
+- In `/autodev-auto`, keep executing ready tasks in the same phase until the phase is complete or a real blocker appears.
 </rules>
 
 <process>
@@ -24,6 +25,8 @@ AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
 node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init execute-phase "$ARGUMENTS"
 ```
 
+If this run came from `/autodev-auto`, append `--auto` to the same command.
+
 2. If no phase is found or the plan file is missing, stop and direct the user to `/autodev-plan-phase`.
 
 3. Read:
@@ -42,7 +45,7 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init execute-phase "$ARGUMENT
 5. Determine the next executable task:
    - prefer the first task without a summary whose dependencies are already done
    - if no executable task remains and all task summaries exist, move to phase aggregation
-   - if `dependency_deadlock` is true, stop before execution, set both state files to `Current Step: planning`, set `Current Task: none`, set `Current Task Status: blocked_dependencies`, keep `Next Command: /autodev`, and ask the user how to repair the plan
+   - if `dependency_deadlock` is true, stop before execution, set both state files to `Current Step: planning`, set `Current Task: none`, set `Current Task Status: blocked_dependencies`, keep `Run Mode` aligned to the current command, keep `Next Command` aligned to the current command, and ask the user how to repair the plan
 
 6. Before running a task, show the user:
    - task id and title
@@ -78,16 +81,26 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init execute-phase "$ARGUMENT
    - inspect whether the task is done or blocked
    - report the result to the user
 
-10. If more tasks remain:
+10. If more tasks remain in checkpointed mode:
    - update project and track state to:
      - `Current Step: task_review`
      - `Current Task: <current-task>`
      - `Current Task Status: complete`
+     - `Run Mode: checkpointed`
      - `Next Command: /autodev`
    - stop after this task
    - end by telling the user `/autodev` will open the task review checkpoint before any next-task execution
 
-11. If all tasks are done:
+11. If more tasks remain in auto mode:
+   - update project and track state to:
+     - `Current Step: execution`
+     - `Current Task: <next-ready-task>`
+     - `Current Task Status: ready`
+     - `Run Mode: auto`
+     - `Next Command: /autodev-auto`
+   - continue to the next ready task in the same run
+   - stop only if a new blocker appears
+12. If all tasks are done:
    - write or update `NN-SUMMARY.md` from the template with:
      - completed tasks
      - aggregate files changed
@@ -95,33 +108,37 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init execute-phase "$ARGUMENT
      - remaining risks
      - next step
 
-12. Update the active track `STATE.md` so it points to:
+13. Update the active track `STATE.md` so it points to:
    - `Current Phase: N`
    - `Current Phase Type: <type>`
-   - `Current Step: task_review`
+   - `Current Step: task_review` in checkpointed mode, or `Current Step: review` in auto mode
    - `Current Task: <current-task>`
    - `Current Task Status: complete`
-   - `Next Command: /autodev`
+   - `Run Mode: checkpointed` for `/autodev`, or `Run Mode: auto` for `/autodev-auto`
+   - `Next Command: /autodev` for checkpointed mode, or `/autodev-auto` for auto mode
    - current ISO timestamp
 
-13. Update `.autodev/STATE.md` so it points to:
+14. Update `.autodev/STATE.md` so it points to:
    - `Active Track: <slug>`
-   - `Current Step: task_review`
+   - `Current Step: task_review` in checkpointed mode, or `Current Step: review` in auto mode
    - `Current Task: <current-task>`
    - `Current Task Status: complete`
-   - `Next Command: /autodev`
+   - `Run Mode: checkpointed` for `/autodev`, or `Run Mode: auto` for `/autodev-auto`
+   - `Next Command: /autodev` for checkpointed mode, or `/autodev-auto` for auto mode
    - current ISO timestamp
 
-14. If the current task is blocked or incomplete:
+15. If the current task is blocked or incomplete:
    - say so clearly in the task summary
    - set both state files to `Current Step: planning`
    - set `Current Task: <same-task>`
    - set `Current Task Status: blocked`
-   - keep `Next Command: /autodev`
+   - keep `Run Mode` aligned to the current command
+   - keep `Next Command` aligned to the current command
    - tell the user the phase should be revised before more execution
 
-15. End with a short outcome summary and the next recommended command.
-   - Never execute a second task in the same run.
-   - If all tasks are now done, say `/autodev` will open the phase-review checkpoint next.
-   - Otherwise, say `/autodev` will open the task-review checkpoint for the completed task.
+16. End with a short outcome summary and the next recommended command.
+   - In checkpointed mode, never execute a second task in the same run.
+   - In checkpointed mode, if all tasks are now done, say `/autodev` will open the phase-review checkpoint next.
+   - In checkpointed mode, otherwise say `/autodev` will open the task-review checkpoint for the completed task.
+   - In auto mode, keep going until the phase completes or a real blocker stops execution.
 </process>

package/autodev/workflows/explore-codebase.md

@@ -3,8 +3,11 @@ Map a brownfield repository quickly and produce a usable codebase brief without
 </purpose>
 
 <rules>
-- Prefer a small set of foreground codebase agents, run one at a time, when agent delegation is available.
+- The main `/autodev` session owns this workflow and the final synthesis.
+- Specialized codebase agents are optional implementation helpers, not a separate user-facing mode.
+- Prefer a small set of foreground codebase agents, run one at a time, only when agent delegation is clearly available.
 - Give each agent a disjoint write target.
+- If agent delegation is unavailable or unclear, continue inline without surfacing platform confusion.
 - Use read-only investigation only. No git writes.
 - Focus on information that will improve planning and execution for the active track.
 </rules>
@@ -17,6 +20,8 @@ AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
 node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init explore-codebase
 ```
 
+If this run came from `/autodev-auto`, append `--auto` to the same command.
+
 2. If no project exists, stop and tell the user to use `/autodev` or `/autodev-new-project`.
 
 3. Read:
@@ -26,34 +31,38 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init explore-codebase
    - the active track docs if they exist
    - representative repo files needed to orient the exploration
 
-4. If agent delegation is available, explicitly call the `Agent` tool for these subagents, one at a time in the foreground, with owned outputs:
+4. Do a small amount of direct repo reading first so the current session understands the workspace before deciding whether helper agents are useful.
+
+5. If agent delegation is clearly available, explicitly call the `Agent` tool for these subagents, one at a time in the foreground, with owned outputs:
    - `autodev-codebase-structure` for standalone installs, or `autodev:autodev-codebase-structure` in direct plugin runs, owns `.autodev/codebase/structure.md`
    - `autodev-codebase-domain` for standalone installs, or `autodev:autodev-codebase-domain` in direct plugin runs, owns `.autodev/codebase/domain.md`
    - `autodev-codebase-runtime` for standalone installs, or `autodev:autodev-codebase-runtime` in direct plugin runs, owns `.autodev/codebase/runtime.md`
    - `autodev-codebase-quality` for standalone installs, or `autodev:autodev-codebase-quality` in direct plugin runs, owns `.autodev/codebase/quality.md`
 
-5. Tell each agent:
+6. Tell each agent:
    - it is not alone in the codebase
    - it must not overwrite another agent's file
    - it should stay read-only except for its owned output file
    - it should prefer concise, decision-useful findings over exhaustive listing
 
-6. If agent delegation is unavailable, do not stop on the raw platform message.
+7. 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 exploration will continue in the current session, and write the four owned output files directly.
 
-7. After the four agent outputs are written, or after the current-session fallback writes them, review them and synthesize `.autodev/codebase/summary.md` with:
+8. After the four agent outputs are written, or after the current-session fallback writes them, review them and synthesize `.autodev/codebase/summary.md` with:
    - architectural overview
    - major constraints
    - current track implications
    - hotspots and likely safe change points
    - the next planning risks to watch
 
-8. Update `.autodev/STATE.md` and the active track `STATE.md` so they reflect:
+9. Update `.autodev/STATE.md` and the active track `STATE.md` so they reflect:
    - `Current Step: planning`
-   - `Next Command: /autodev`
+   - `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
    - refreshed ISO timestamp
 
-9. End with:
+10. End with:
    - the biggest structural insight
    - the biggest risk
    - `/autodev` as the next command

package/autodev/workflows/help.md

@@ -3,11 +3,14 @@
 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 normal command. It routes automatically through project setup, codebase mapping, planning, plan review, execution, review, verification, and cleanup.
+  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
 

package/autodev/workflows/new-project.md

@@ -5,8 +5,10 @@ Initialize `.autodev/` with useful project-level context, then create the first
 <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. Ask only for details that materially change requirements or roadmap.
+- 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>
@@ -17,13 +19,19 @@ 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. If the current prompt does not provide enough information, ask only for:
-   - the product or repository purpose
-   - whether this is greenfield or brownfield if ambiguous
-   - the first track name and desired outcome
-   - hard constraints only if they materially affect planning
+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.
 
@@ -38,6 +46,7 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init new-project
    - one-line summary
    - project type
    - repo or product problem
+   - current user goal or job to be done
    - users or operators
    - success criteria
    - constraints
@@ -52,18 +61,22 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init new-project
    - `Current Task: none`
    - `Current Task Status: idle`
    - `Status: active`
-   - `Next Command: /autodev`
+   - `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
-   - desired outcome
-   - scope boundaries
+   - 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:
 
@@ -84,10 +97,12 @@ Each phase must include:
    - `Current Task: none`
    - `Current Task Status: idle`
    - `Status: active`
-   - `Next Command: /autodev`
+   - `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 and direct the user to `/autodev`. Mention the manual shortcut only if useful.
+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

@@ -10,6 +10,7 @@ Create one practical phase plan for the active track, then break it into reviewa
 - 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>
@@ -20,6 +21,8 @@ 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`.
@@ -105,7 +108,9 @@ Each task file must include:
    - `Current Step: plan_review`
    - `Current Task: <first-pending-task>` if tasks exist, otherwise `none`
    - `Current Task Status: pending_review`
-   - `Next Command: /autodev`
+   - `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:
@@ -113,7 +118,9 @@ Each task file must include:
    - `Current Step: plan_review`
    - `Current Task: <first-pending-task>` if tasks exist, otherwise `none`
    - `Current Task Status: pending_review`
-   - `Next Command: /autodev`
+   - `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.
@@ -121,6 +128,7 @@ Each task file must include:
    - 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
-   - `/autodev` will open the review checkpoint before any execution starts
+   - 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/review-phase.md

@@ -7,6 +7,7 @@ Run the automatic review bundle after execution so the user sees code quality, s
 - 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>
@@ -17,6 +18,8 @@ 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:
@@ -57,14 +60,18 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init review-phase "$ARGUMENTS
    - set project and track state back to `Current Step: planning`
    - set `Current Task: none`
    - set `Current Task Status: blocked_review`
-   - keep `Next Command: /autodev`
+   - 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`
-   - keep `Next Command: /autodev`
+   - 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

package/autodev/workflows/verify-work.md

@@ -7,6 +7,7 @@ Run lightweight user acceptance testing after review and keep the next action ob
 - 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>
@@ -17,6 +18,8 @@ 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:
@@ -27,7 +30,10 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init verify-work "$ARGUMENTS"
    - `NN-REVIEW.md`
    - relevant code or UI files
 
-4. Present a short manual verification flow. Keep it one check at a time when user input is needed.
+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
@@ -47,11 +53,19 @@ node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init verify-work "$ARGUMENTS"
    - 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`
-   - always set `Next Command: /autodev`
+   - 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. End with the verification result and the next command. Mention the manual shortcut only if it helps.
+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>