@mthanhlm/autodev 0.4.3 → 0.5.0

package/autodev/workflows/new-project.md

@@ -1,101 +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`.
-</rules>
-
-<process>
-1. Run:
-
-```bash
-AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
-node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init new-project
-```
-
-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`
-   - `Next Command: /autodev`
-   - 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`
-   - `Next Command: /autodev`
-   - 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,126 +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.
-</rules>
-
-<process>
-1. Run:
-
-```bash
-AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
-node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init plan-phase "$ARGUMENTS"
-```
-
-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`
-   - `Next Command: /autodev`
-   - 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`
-   - `Next Command: /autodev`
-   - 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
-   - `/autodev` will open the review checkpoint before any execution starts
-   - `/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,73 +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.
-</rules>
-
-<process>
-1. Run:
-
-```bash
-AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
-node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init review-phase "$ARGUMENTS"
-```
-
-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 `Next Command: /autodev`
-   - 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`
-
-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,57 +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.
-</rules>
-
-<process>
-1. Run:
-
-```bash
-AUTODEV_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude}"
-node "$AUTODEV_ROOT/autodev/bin/autodev-tools.cjs" init verify-work "$ARGUMENTS"
-```
-
-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. Present a short manual verification flow. Keep it one check at a time when user input is needed.
-
-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`
-   - always set `Next Command: /autodev`
-   - 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.
-</process>

package/commands/autodev/cleanup.md

@@ -1,23 +0,0 @@
----
-name: autodev:cleanup
-description: Clean or archive autodev state with an interactive prompt
-allowed-tools:
-  - Read
-  - Write
-  - Edit
-  - Bash
-  - AskUserQuestion
-  - Grep
-  - Glob
----
-<objective>
-Offer interactive cleanup choices for `.autodev/`, with archive-first behavior.
-</objective>
-
-<execution_context>
-@~/.claude/autodev/workflows/cleanup.md
-</execution_context>
-
-<process>
-Execute the workflow in @~/.claude/autodev/workflows/cleanup.md end-to-end.
-</process>

package/commands/autodev/execute-phase.md

@@ -1,29 +0,0 @@
----
-name: autodev:execute-phase
-description: Execute exactly one active-track task at a time, preferring a fresh foreground agent with clean fallback when unavailable
-argument-hint: "[phase-number]"
-allowed-tools:
-  - Read
-  - Write
-  - Edit
-  - Bash
-  - Grep
-  - Glob
-  - TodoWrite
-  - AskUserQuestion
-  - Agent
----
-<objective>
-Execute exactly one task-sized unit for the active phase, then stop at the post-task checkpoint.
-</objective>
-
-<execution_context>
-@~/.claude/autodev/workflows/execute-phase.md
-@~/.claude/autodev/templates/summary.md
-@~/.claude/autodev/templates/task-summary.md
-@~/.claude/autodev/agents/autodev-task-worker.md
-</execution_context>
-
-<process>
-Execute the workflow in @~/.claude/autodev/workflows/execute-phase.md end-to-end.
-</process>

package/commands/autodev/explore-codebase.md

@@ -1,33 +0,0 @@
----
-name: autodev:explore-codebase
-description: Map an existing codebase, preferring foreground delegated agents with clean fallback when unavailable
-allowed-tools:
-  - Read
-  - Write
-  - Edit
-  - Bash
-  - Grep
-  - Glob
-  - AskUserQuestion
-  - Agent
----
-<objective>
-Explore the current repository, use foreground codebase agents when available, and write the brownfield map into `.autodev/codebase/`.
-</objective>
-
-<execution_context>
-@~/.claude/autodev/workflows/explore-codebase.md
-@~/.claude/autodev/templates/codebase/structure.md
-@~/.claude/autodev/templates/codebase/domain.md
-@~/.claude/autodev/templates/codebase/runtime.md
-@~/.claude/autodev/templates/codebase/quality.md
-@~/.claude/autodev/templates/codebase/summary.md
-@~/.claude/autodev/agents/autodev-codebase-structure.md
-@~/.claude/autodev/agents/autodev-codebase-domain.md
-@~/.claude/autodev/agents/autodev-codebase-runtime.md
-@~/.claude/autodev/agents/autodev-codebase-quality.md
-</execution_context>
-
-<process>
-Execute the workflow in @~/.claude/autodev/workflows/explore-codebase.md end-to-end.
-</process>

package/commands/autodev/help.md

@@ -1,18 +0,0 @@
----
-name: autodev:help
-description: Show the compact autodev command reference
-allowed-tools:
-  - Read
-  - Bash
----
-<objective>
-Show the autodev command reference, with `/autodev` as the main entrypoint.
-</objective>
-
-<execution_context>
-@~/.claude/autodev/workflows/help.md
-</execution_context>
-
-<process>
-Output the reference from @~/.claude/autodev/workflows/help.md directly.
-</process>

package/commands/autodev/new-project.md

@@ -1,30 +0,0 @@
----
-name: autodev:new-project
-description: Initialize autodev project state and create the first active track
-argument-hint: "[project and current track goals]"
-allowed-tools:
-  - Read
-  - Write
-  - Bash
-  - AskUserQuestion
-  - Grep
-  - Glob
----
-<objective>
-Create the `.autodev/` project state for a new or existing codebase, then create the first active track.
-</objective>
-
-<execution_context>
-@~/.claude/autodev/workflows/new-project.md
-@~/.claude/autodev/templates/config.json
-@~/.claude/autodev/templates/project.md
-@~/.claude/autodev/templates/project-state.md
-@~/.claude/autodev/templates/track.md
-@~/.claude/autodev/templates/requirements.md
-@~/.claude/autodev/templates/roadmap.md
-@~/.claude/autodev/templates/track-state.md
-</execution_context>
-
-<process>
-Execute the workflow in @~/.claude/autodev/workflows/new-project.md end-to-end.
-</process>

package/commands/autodev/plan-phase.md

@@ -1,26 +0,0 @@
----
-name: autodev:plan-phase
-description: Create a practical phase plan and break it into reviewable task files
-argument-hint: "[phase-number]"
-allowed-tools:
-  - Read
-  - Write
-  - Bash
-  - AskUserQuestion
-  - Grep
-  - Glob
-  - WebFetch
----
-<objective>
-Create or update a single executable phase plan under the active track in `.autodev/tracks/<track>/phases/`, plus task files for controlled execution.
-</objective>
-
-<execution_context>
-@~/.claude/autodev/workflows/plan-phase.md
-@~/.claude/autodev/templates/plan.md
-@~/.claude/autodev/templates/task.md
-</execution_context>
-
-<process>
-Execute the workflow in @~/.claude/autodev/workflows/plan-phase.md end-to-end.
-</process>