llm-multiverse-ui/.claude/commands/auto-dev.md

Auto Dev

You are the Auto Dev Orchestrator. You run the full development pipeline in a loop: select a story, plan it, implement it, verify it, code review it, and resolve it.

Gitea Connection

• Owner: llm-multiverse
• Repo: llm-multiverse-ui

Auto-Merge Eligibility

An issue is auto-merge eligible (no user approval needed) if ALL of these are true:

• The issue does NOT have a workflow:manual-review label
• All quality gates pass
• Code review by the review agent returns APPROVE (no critical/major findings)

Issues that ARE auto-merge eligible: component implementation, styling, utilities, hooks, tests, documentation, configuration, and any pure frontend work without external integration concerns.

Issues that are NOT auto-merge eligible: issues with workflow:manual-review label (e.g., complex integrations, breaking API changes, security-sensitive features).

Pipeline Loop

Repeat the following cycle until stopped:

Phase 1 — SELECT

Run the story selection logic (same as /project:select-story):

1. Fetch all open issues via mcp__gitea__list_issues (paginate with perPage: 30)
2. Filter out issues with workflow:manual or workflow:blocked labels
3. Check implementation-plans/_index.md — skip COMPLETED and IMPLEMENTING issues
4. Check dependency readiness — skip issues whose "Blocked by" issues are still open
5. Sort by milestone priority: earliest milestone due date first, no milestone last
6. Within milestone, sort by priority label: priority:critical > priority:high > priority:medium > priority:low > unlabeled
7. Present the top candidate to the user with issue number, title, milestone, labels, and summary

PAUSE HERE — Wait for user confirmation before proceeding. The user may:

• Confirm the selection
• Pick a different issue number
• Say "stop" to end the loop

Phase 2 — PLAN

Once confirmed, run the planning logic autonomously (same as /project:plan-story):

1. Fetch issue details and comments from Gitea
2. Read CLAUDE.md (if exists), package.json, implementation-plans/_index.md
3. Find and read related plans
4. Explore the codebase for relevant patterns
5. Draft implementation plan
6. Write plan to implementation-plans/issue-NNN.md
7. Update implementation-plans/_index.md

Phase 3 — IMPLEMENT

Run the implementation logic autonomously (same as /project:implement-story):

1. Read the plan (must be PLANNED or RETRY)
2. Create feature branch: feature/issue-NNN-short-description
3. Create branch from main, set plan status to IMPLEMENTING
4. Implement phase by phase (Types > Core Logic > Components > API Integration > Tests)
5. Follow all project conventions from CLAUDE.md
6. Write tests for new functionality
7. Log deviations in the plan
8. Run quality gates (build, lint, typecheck, test)
9. Commit with descriptive conventional commit message

Phase 4 — VERIFY

Run the verification logic autonomously (same as /project:verify-story):

1. Read plan and original issue
2. Run quality gates: build, lint, typecheck, tests
3. Architecture review of changed files
4. Verify acceptance criteria against code

Phase 5 — CODE REVIEW

Run the code review logic autonomously (same as /project:code-review):

1. Review all changed files for correctness, security, architecture, quality
2. Categorize findings as Critical/Major/Minor/Suggestion
3. Produce structured review report

Phase 6 — RESOLVE

Based on verification AND code review results:

On PASS (verification passes AND code review APPROVE):

1. Update plan status to COMPLETED
2. Push the feature branch to origin
3. Create a Gitea pull request targeting main
4. Add comment to the Gitea issue summarizing the implementation
5. If auto-merge eligible:
   • Merge the PR via mcp__gitea__pull_request_write
   • Close the Gitea issue
   • Inform the user: "Story #NNN auto-merged."
6. If NOT auto-merge eligible:
   • Do NOT merge — leave PR open for user review
   • Close the Gitea issue
   • Inform the user: "Story #NNN completed. PR #NN created and awaiting manual review."
7. If code review had minor findings: create tech debt issue (see code-review agent)
8. Loop back to Phase 1

On FAIL (attempt 1):

1. Update plan status to RETRY
2. Append retry instructions to the plan (what failed and how to fix it)
3. Loop back to Phase 3 (re-implement with retry instructions)

On FAIL (attempt 2):

1. Update plan status to BLOCKED
2. Add workflow:manual label to the Gitea issue
3. Inform the user: "Story #NNN blocked after 2 attempts. Marked for manual review."
4. Loop back to Phase 1

Phase 7 — MILESTONE CHECK

After each completed story, check if all issues in the story's milestone are now closed. If so:

1. Trigger the release logic (/project:release <milestone>) in milestone-triggered mode
2. The release PR is created but NOT merged — it awaits user approval
3. Inform the user: "All issues in completed. Release PR created for your approval."
4. Continue to the next milestone's stories

Phase 8 — PERIODIC REFACTORING CHECK

After every 5 completed stories (tracked by the completed counter):

1. Run the refactoring review logic (/project:refactor-review)
2. Create refactoring issues as needed
3. Close resolved tech debt issues
4. Inform the user of the review results
5. Continue to Phase 1

Stop Conditions

Stop the loop when any of these occur:

• The user says "stop"
• No eligible issues remain (all are completed, blocked, or have unmet dependencies)
• 3 consecutive stories are BLOCKED

When stopping, display a summary of work completed:

• Stories completed (with PR links)
• Stories auto-merged vs awaiting review
• Stories blocked (with failure reasons)
• Release PRs created (if any milestones were completed)
• Refactoring reviews performed
• Tech debt issues created/closed
• Total issues processed

Tracking

Maintain a running tally during the session:

• completed: list of issue numbers with PR links
• auto_merged: list of issue numbers that were auto-merged
• awaiting_review: list of issue numbers with PRs awaiting manual review
• blocked: list of issue numbers with failure summaries
• consecutive_blocks: counter, reset on each successful completion
• stories_since_refactor: counter, reset after each refactoring review
• tech_debt_created: list of tech debt issue numbers
• tech_debt_closed: list of resolved tech debt issue numbers