978325565d
Initialize the llm-multiverse-ui project with: - SvelteKit + Svelte 5 (runes mode enabled) - Tailwind CSS v4 via @tailwindcss/vite plugin - TypeScript strict mode - ESLint 9 flat config with svelte and typescript-eslint plugins - Prettier with svelte plugin - Directory structure: src/lib/components/, src/lib/services/ - All required scripts: dev, build, preview, lint, format, check Closes #1 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
170 lines
6.4 KiB
Markdown
170 lines
6.4 KiB
Markdown
# 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 <milestone> 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
|