Initial Auto-Build plugin structure
This commit is contained in:
172
plugin/commands/build.md
Normal file
172
plugin/commands/build.md
Normal file
@@ -0,0 +1,172 @@
|
||||
---
|
||||
description: Orchestrate feature implementation from specification
|
||||
argument-hint: <feature-name>
|
||||
---
|
||||
|
||||
# Build Feature from Specification
|
||||
|
||||
Orchestrate the complete implementation of a feature using its specification. This is the core command that coordinates planning, coding, and progress tracking.
|
||||
|
||||
## Input
|
||||
|
||||
- **Feature name**: $ARGUMENTS (required, must match existing spec)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Spec must exist at `.auto-build-data/specs/{feature-name}/spec.md`
|
||||
- Status must be `SPEC_COMPLETE` or `PLANNING_COMPLETE` or `IMPLEMENTING`
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Load Specification
|
||||
|
||||
- Read `.auto-build-data/specs/{feature-name}/spec.md`
|
||||
- Read `.auto-build-data/specs/{feature-name}/status.json`
|
||||
- Validate spec exists and is complete
|
||||
- If status is `IMPLEMENTING`, resume from current task
|
||||
|
||||
### 2. Offer Worktree (for new builds)
|
||||
|
||||
If status is `SPEC_COMPLETE`:
|
||||
```
|
||||
This feature may modify multiple files.
|
||||
Create an isolated git worktree? (recommended for larger features)
|
||||
[Yes] [No]
|
||||
```
|
||||
|
||||
If yes:
|
||||
- Run: `bash .auto-build/scripts/worktree-create.sh {feature-name}`
|
||||
- Update status.json with worktree path
|
||||
- Inform user of worktree location
|
||||
|
||||
### 3. Planning Phase
|
||||
|
||||
If status is `SPEC_COMPLETE`:
|
||||
|
||||
1. Load memory context:
|
||||
- Read `.auto-build-data/memory/patterns.json`
|
||||
- Read `.auto-build-data/memory/gotchas.json`
|
||||
|
||||
2. Launch **planner** agent with:
|
||||
- The complete spec.md content
|
||||
- Relevant patterns from memory
|
||||
- Instruction to create ordered implementation tasks
|
||||
|
||||
3. The planner creates `.auto-build-data/specs/{feature-name}/plan.md`:
|
||||
```markdown
|
||||
# Implementation Plan: {feature-name}
|
||||
|
||||
## Tasks
|
||||
|
||||
### Task 1: [Title]
|
||||
**Files**: file1.ts, file2.ts
|
||||
**Description**: What to do
|
||||
**Dependencies**: None
|
||||
|
||||
### Task 2: [Title]
|
||||
**Files**: file3.ts
|
||||
**Description**: What to do
|
||||
**Dependencies**: Task 1
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
4. Update status to `PLANNING_COMPLETE`
|
||||
|
||||
### 4. Implementation Loop
|
||||
|
||||
For each task in plan.md:
|
||||
|
||||
1. Update status to `IMPLEMENTING`, set `currentTask`
|
||||
|
||||
2. Display task info:
|
||||
```
|
||||
Task 3/7: Add API endpoint for user stats
|
||||
Files: src/api/users.ts, src/types/user.ts
|
||||
```
|
||||
|
||||
3. Launch **coder** agent with:
|
||||
- Current task details
|
||||
- Spec context
|
||||
- Relevant patterns from memory
|
||||
- Files to modify
|
||||
|
||||
4. After coder completes:
|
||||
- Update status.json with task progress
|
||||
- Ask: "Continue to next task? [Yes] [No] [Skip]"
|
||||
|
||||
5. Repeat until all tasks complete
|
||||
|
||||
### 5. Completion
|
||||
|
||||
When all tasks done:
|
||||
- Update status to `IMPLEMENTATION_COMPLETE`
|
||||
- Display summary:
|
||||
```
|
||||
Build complete: {feature-name}
|
||||
|
||||
Tasks completed: 7/7
|
||||
Files modified: 12
|
||||
|
||||
Next steps:
|
||||
- Run QA review: /ab:qa-review
|
||||
- Or test manually and save learnings: /ab:memory-save
|
||||
```
|
||||
|
||||
## State Machine
|
||||
|
||||
```
|
||||
SPEC_COMPLETE
|
||||
|
|
||||
v
|
||||
PLANNING (planner agent running)
|
||||
|
|
||||
v
|
||||
PLANNING_COMPLETE
|
||||
|
|
||||
v
|
||||
IMPLEMENTING (coder agent loop)
|
||||
|
|
||||
+---> [user skips/aborts] ---> PAUSED
|
||||
|
|
||||
v
|
||||
IMPLEMENTATION_COMPLETE
|
||||
|
|
||||
v
|
||||
[/ab:qa-review] ---> QA_REVIEW ---> COMPLETE
|
||||
```
|
||||
|
||||
## Resume Logic
|
||||
|
||||
If status is already `IMPLEMENTING`:
|
||||
- Read `currentTask` from status.json
|
||||
- Ask: "Resume from task {n}/{total}? [Yes] [Restart] [Cancel]"
|
||||
- If yes: Continue from that task
|
||||
- If restart: Reset to task 1
|
||||
|
||||
## Status JSON During Build
|
||||
|
||||
```json
|
||||
{
|
||||
"feature": "user-dashboard",
|
||||
"status": "IMPLEMENTING",
|
||||
"currentTask": 3,
|
||||
"totalTasks": 7,
|
||||
"worktree": "../ab-worktrees/project-user-dashboard/",
|
||||
"created": "2025-01-15T10:00:00Z",
|
||||
"updated": "2025-01-15T14:30:00Z",
|
||||
"history": [
|
||||
{"status": "SPEC_COMPLETE", "at": "..."},
|
||||
{"status": "PLANNING_COMPLETE", "at": "..."},
|
||||
{"status": "IMPLEMENTING", "at": "...", "task": 1},
|
||||
{"status": "IMPLEMENTING", "at": "...", "task": 2},
|
||||
{"status": "IMPLEMENTING", "at": "...", "task": 3}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If coder fails on a task: Mark task as failed, ask user to continue or fix manually
|
||||
- If worktree creation fails: Continue without worktree, warn user
|
||||
- If spec not found: "Spec not found. Create with: /ab:spec {name}"
|
||||
75
plugin/commands/help.md
Normal file
75
plugin/commands/help.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
description: Show Auto-Build help and available commands
|
||||
---
|
||||
|
||||
# Auto-Build Help
|
||||
|
||||
Display comprehensive help for the Auto-Build system.
|
||||
|
||||
## Available Commands
|
||||
|
||||
### Core Workflow
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/ab:spec <name>` | Create detailed feature specification |
|
||||
| `/ab:build <name>` | Orchestrate feature implementation from spec |
|
||||
| `/ab:status` | Show current build status |
|
||||
|
||||
### Quality Assurance
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/ab:qa-review` | Run QA validation loop (max 50 iterations) |
|
||||
|
||||
### Git Worktrees
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/ab:worktree create <name>` | Create isolated git worktree |
|
||||
| `/ab:worktree list` | List active worktrees |
|
||||
| `/ab:worktree cleanup` | Remove completed worktrees |
|
||||
|
||||
### Memory System
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/ab:memory-save` | Save session insights to memory |
|
||||
| `/ab:memory-search <query>` | Search patterns from past sessions |
|
||||
|
||||
## Typical Workflow
|
||||
|
||||
```
|
||||
1. /ab:spec "Add user dashboard"
|
||||
-> Creates specification in .auto-build-data/specs/user-dashboard/
|
||||
|
||||
2. /ab:build user-dashboard
|
||||
-> Plans subtasks, creates worktree (optional), implements code
|
||||
|
||||
3. /ab:qa-review
|
||||
-> Reviews code, fixes issues automatically (up to 50 iterations)
|
||||
|
||||
4. /ab:memory-save
|
||||
-> Saves patterns and lessons learned for future sessions
|
||||
```
|
||||
|
||||
## Agents Used
|
||||
|
||||
- **spec-writer**: Creates detailed specifications (sonnet)
|
||||
- **planner**: Breaks specs into implementation tasks (opus)
|
||||
- **coder**: Implements code following patterns (sonnet)
|
||||
- **qa-reviewer**: Reviews code for issues (sonnet)
|
||||
- **qa-fixer**: Fixes identified issues (sonnet)
|
||||
|
||||
## Data Locations
|
||||
|
||||
- **Specs**: `.auto-build-data/specs/{feature-name}/`
|
||||
- **Memory**: `.auto-build-data/memory/`
|
||||
- **Worktrees**: `../ab-worktrees/{project}-{feature}/`
|
||||
|
||||
## Setup
|
||||
|
||||
If not already set up:
|
||||
```bash
|
||||
bash .auto-build/scripts/setup.sh
|
||||
```
|
||||
|
||||
## More Information
|
||||
|
||||
See `.auto-build/README.md` for complete documentation.
|
||||
208
plugin/commands/memory-save.md
Normal file
208
plugin/commands/memory-save.md
Normal file
@@ -0,0 +1,208 @@
|
||||
---
|
||||
description: Save session insights to memory
|
||||
argument-hint: [category] - Optional: patterns, gotchas, or auto-detect
|
||||
---
|
||||
|
||||
# Save Session Insights to Memory
|
||||
|
||||
Persist learned insights from the current session for future use. This builds up a knowledge base that improves subsequent builds.
|
||||
|
||||
## Memory Categories
|
||||
|
||||
| Category | File | Purpose |
|
||||
|----------|------|---------|
|
||||
| `patterns` | `patterns.json` | Reusable code patterns discovered |
|
||||
| `gotchas` | `gotchas.json` | Issues encountered and their solutions |
|
||||
| `codebase` | `codebase-map.json` | Structural insights about the project |
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Gather Session Context
|
||||
|
||||
- Review the current conversation/session
|
||||
- Identify what was learned:
|
||||
- New patterns discovered
|
||||
- Problems encountered and solved
|
||||
- Insights about code structure
|
||||
- Effective approaches that worked
|
||||
|
||||
### 2. Ask User for Input
|
||||
|
||||
```
|
||||
What insights should be saved from this session?
|
||||
|
||||
Categories:
|
||||
1. [P] Pattern - A reusable code approach
|
||||
2. [G] Gotcha - A problem and its solution
|
||||
3. [C] Codebase - Insight about project structure
|
||||
|
||||
Enter category and description, or 'auto' to auto-detect:
|
||||
>
|
||||
```
|
||||
|
||||
### 3. Generate Memory Entry
|
||||
|
||||
For **patterns**:
|
||||
```json
|
||||
{
|
||||
"id": "pat_20250115_143000",
|
||||
"timestamp": "2025-01-15T14:30:00Z",
|
||||
"title": "API Error Handling Pattern",
|
||||
"description": "All API calls should be wrapped in try-catch with consistent error response format",
|
||||
"context": "Discovered while implementing user dashboard API",
|
||||
"example": {
|
||||
"file": "src/api/users.ts",
|
||||
"lines": "45-52",
|
||||
"snippet": "try { ... } catch (e) { return errorResponse(e) }"
|
||||
},
|
||||
"tags": ["error-handling", "api", "patterns"],
|
||||
"feature": "user-dashboard",
|
||||
"usageCount": 0
|
||||
}
|
||||
```
|
||||
|
||||
For **gotchas**:
|
||||
```json
|
||||
{
|
||||
"id": "got_20250115_143000",
|
||||
"timestamp": "2025-01-15T14:30:00Z",
|
||||
"title": "Oracle Pool Connection Timeout",
|
||||
"problem": "Connections timeout after 30s if pool is exhausted",
|
||||
"solution": "Increase POOL_MAX in .env or optimize query execution",
|
||||
"context": "Encountered during load testing",
|
||||
"tags": ["database", "oracle", "performance"],
|
||||
"feature": "user-dashboard"
|
||||
}
|
||||
```
|
||||
|
||||
For **codebase**:
|
||||
```json
|
||||
{
|
||||
"id": "cb_20250115_143000",
|
||||
"timestamp": "2025-01-15T14:30:00Z",
|
||||
"path": "src/services/",
|
||||
"insight": "All services follow singleton pattern with lazy initialization",
|
||||
"examples": ["UserService", "AuthService", "ReportService"],
|
||||
"tags": ["architecture", "services"]
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Merge with Existing Memory
|
||||
|
||||
1. Load existing memory file (e.g., `patterns.json`)
|
||||
2. Check for duplicates by:
|
||||
- Matching titles
|
||||
- Overlapping tags
|
||||
- Similar descriptions
|
||||
3. If duplicate found: Ask "Update existing or add as new?"
|
||||
4. Append new entry or update existing
|
||||
5. Update `updated` timestamp
|
||||
|
||||
### 5. Create Session Record
|
||||
|
||||
Save comprehensive session record:
|
||||
`.auto-build-data/memory/sessions/{timestamp}-{feature}.json`
|
||||
|
||||
```json
|
||||
{
|
||||
"session_id": "ses_20250115_143000",
|
||||
"timestamp": "2025-01-15T14:30:00Z",
|
||||
"feature": "user-dashboard",
|
||||
"duration": "2h 30m",
|
||||
"insights_saved": [
|
||||
{"type": "pattern", "id": "pat_20250115_143000"},
|
||||
{"type": "gotcha", "id": "got_20250115_143000"}
|
||||
],
|
||||
"files_modified": ["src/api/users.ts", "src/types/user.ts"],
|
||||
"summary": "Implemented user dashboard with stats API"
|
||||
}
|
||||
```
|
||||
|
||||
### 6. Sync to .claude/rules/ (AUTO-LOADING)
|
||||
|
||||
After saving to JSON files, convert and sync to CLAUDE.md-compatible format:
|
||||
|
||||
1. **Load memory files**:
|
||||
- Read `.auto-build-data/memory/patterns.json`
|
||||
- Read `.auto-build-data/memory/gotchas.json`
|
||||
|
||||
2. **Convert to Markdown**:
|
||||
```markdown
|
||||
---
|
||||
paths: **/*
|
||||
---
|
||||
|
||||
# Auto-Build Learned Patterns
|
||||
|
||||
Last updated: {TIMESTAMP}
|
||||
|
||||
## Patterns
|
||||
|
||||
### {Pattern Title}
|
||||
**Discovered**: {date} (feature: {feature-name})
|
||||
**Description**: {description}
|
||||
|
||||
**Example** (`{file}:{lines}`):
|
||||
\```{language}
|
||||
{code snippet}
|
||||
\```
|
||||
|
||||
**Tags**: {tag1}, {tag2}
|
||||
|
||||
---
|
||||
|
||||
## Gotchas
|
||||
|
||||
### {Gotcha Title}
|
||||
**Discovered**: {date} (feature: {feature-name})
|
||||
**Problem**: {problem description}
|
||||
**Solution**: {solution}
|
||||
|
||||
**Tags**: {tag1}, {tag2}
|
||||
```
|
||||
|
||||
3. **Write to .claude/rules/auto-build-memory.md**:
|
||||
- Overwrites entire file
|
||||
- This file is auto-loaded by Claude Code
|
||||
- Patterns become part of project context automatically
|
||||
|
||||
### 7. Confirmation
|
||||
|
||||
```
|
||||
Saved to memory:
|
||||
|
||||
[PATTERN] API Error Handling Pattern
|
||||
File: patterns.json (searchable)
|
||||
File: .claude/rules/auto-build-memory.md (auto-loaded)
|
||||
|
||||
[GOTCHA] Oracle Pool Connection Timeout
|
||||
File: gotchas.json (searchable)
|
||||
File: .claude/rules/auto-build-memory.md (auto-loaded)
|
||||
|
||||
Session recorded: sessions/20250115-143000-user-dashboard.json
|
||||
|
||||
Memory stats:
|
||||
- Total patterns: 15
|
||||
- Total gotchas: 8
|
||||
- Sessions recorded: 23
|
||||
- Auto-loaded in CLAUDE.md: ✅
|
||||
```
|
||||
|
||||
## Auto-Detection
|
||||
|
||||
If user enters 'auto' or runs without arguments after a build:
|
||||
|
||||
1. Analyze modified files from status.json
|
||||
2. Look for:
|
||||
- New patterns introduced
|
||||
- Error handling approaches
|
||||
- Code structure decisions
|
||||
3. Suggest entries for each category
|
||||
4. Ask user to confirm/edit before saving
|
||||
|
||||
## Memory File Limits
|
||||
|
||||
- Keep max 100 patterns (remove oldest unused)
|
||||
- Keep max 50 gotchas (remove oldest)
|
||||
- Keep all session records (for history)
|
||||
- Update `usageCount` when pattern is referenced in `/ab:memory-search`
|
||||
133
plugin/commands/memory-search.md
Normal file
133
plugin/commands/memory-search.md
Normal file
@@ -0,0 +1,133 @@
|
||||
---
|
||||
description: Search patterns and insights from previous sessions
|
||||
argument-hint: <query>
|
||||
---
|
||||
|
||||
# Search Memory
|
||||
|
||||
Search through accumulated patterns, gotchas, and session insights to find relevant knowledge for the current task.
|
||||
|
||||
## Input
|
||||
|
||||
- **Query**: $ARGUMENTS (required)
|
||||
|
||||
## Search Scope
|
||||
|
||||
Searches across:
|
||||
1. `.auto-build-data/memory/patterns.json`
|
||||
2. `.auto-build-data/memory/gotchas.json`
|
||||
3. `.auto-build-data/memory/sessions/*.json`
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Load Memory Files
|
||||
|
||||
Read all memory files into searchable format.
|
||||
|
||||
### 2. Search Strategy
|
||||
|
||||
**Keyword Matching** (primary):
|
||||
- Match query words against:
|
||||
- Title
|
||||
- Description
|
||||
- Tags
|
||||
- Context
|
||||
- File paths
|
||||
|
||||
**Scoring**:
|
||||
- Title match: +10 points
|
||||
- Tag match: +5 points
|
||||
- Description match: +3 points
|
||||
- Context match: +2 points
|
||||
- Recent (< 7 days): +3 points
|
||||
- High usage count: +2 points
|
||||
|
||||
### 3. Present Results
|
||||
|
||||
```
|
||||
Found 4 relevant insights for "error handling":
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
[PATTERN] API Error Handling Pattern
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Score: 18 | Used: 5 times | Added: 3 days ago
|
||||
|
||||
All API calls should be wrapped in try-catch with
|
||||
consistent error response format.
|
||||
|
||||
File: src/api/users.ts (lines 45-52)
|
||||
Tags: error-handling, api, patterns
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
[GOTCHA] Database Connection Error Recovery
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Score: 12 | Added: 1 week ago
|
||||
|
||||
Problem: Oracle connections sometimes drop silently
|
||||
Solution: Implement connection health check with auto-reconnect
|
||||
|
||||
Tags: database, error-handling, oracle
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
[SESSION] Feature: user-auth (2025-01-10)
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Score: 8
|
||||
|
||||
Related insight about auth error handling...
|
||||
See: sessions/20250110-user-auth.json
|
||||
```
|
||||
|
||||
### 4. Apply to Context
|
||||
|
||||
After showing results:
|
||||
|
||||
```
|
||||
Apply any of these to current work?
|
||||
[1] View full pattern details
|
||||
[2] View gotcha details
|
||||
[A] Apply all relevant to context
|
||||
[N] No, just searching
|
||||
>
|
||||
```
|
||||
|
||||
If user selects to apply:
|
||||
- Read full entry details
|
||||
- Add to current conversation context
|
||||
- Increment `usageCount` for selected entries
|
||||
|
||||
### 5. Update Usage Stats
|
||||
|
||||
For each entry shown and especially those applied:
|
||||
- Increment `usageCount` in the original file
|
||||
- Track "last used" timestamp
|
||||
- This helps prioritize frequently useful patterns
|
||||
|
||||
## Search Examples
|
||||
|
||||
| Query | Likely Matches |
|
||||
|-------|---------------|
|
||||
| "auth error" | Auth patterns, login gotchas |
|
||||
| "oracle pool" | Database connection patterns |
|
||||
| "vue component" | Frontend patterns, component gotchas |
|
||||
| "api response" | API patterns, error handling |
|
||||
|
||||
## No Results
|
||||
|
||||
If no matches found:
|
||||
```
|
||||
No insights found for "exotic query"
|
||||
|
||||
Try:
|
||||
- Broader terms: "database" instead of "oracle connection pool"
|
||||
- Category search: /ab:memory-search patterns
|
||||
- Browse all: /ab:memory-search *
|
||||
|
||||
Or save new insights: /ab:memory-save
|
||||
```
|
||||
|
||||
## Browse All
|
||||
|
||||
If query is `*` or `all`:
|
||||
- Show summary of all memory entries
|
||||
- Group by category
|
||||
- Sort by usage count (most used first)
|
||||
172
plugin/commands/qa-review.md
Normal file
172
plugin/commands/qa-review.md
Normal file
@@ -0,0 +1,172 @@
|
||||
---
|
||||
description: Run QA validation loop with automatic fixes
|
||||
argument-hint: [feature-name] - Optional, uses current feature if omitted
|
||||
---
|
||||
|
||||
# QA Review and Fix Loop
|
||||
|
||||
Run iterative QA review with automatic fix attempts. The system will review code, identify issues, and attempt fixes up to 50 iterations.
|
||||
|
||||
## Configuration
|
||||
|
||||
- **MAX_ITERATIONS**: 50
|
||||
- **AUTO_FIX**: Ask user before each fix round
|
||||
|
||||
## Input
|
||||
|
||||
- **Feature name**: $ARGUMENTS or infer from current active build
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Initialize
|
||||
|
||||
- Determine feature from argument or find active build in status files
|
||||
- Load spec and plan from `.auto-build-data/specs/{feature-name}/`
|
||||
- Create QA iteration directory: `.auto-build-data/cache/qa-iterations/{feature-name}/`
|
||||
- Set iteration counter to 0
|
||||
- Update status to `QA_REVIEW`
|
||||
|
||||
### 2. Review Loop
|
||||
|
||||
```
|
||||
iteration = 0
|
||||
while iteration < MAX_ITERATIONS:
|
||||
|
||||
# 2a. Launch QA Reviewer
|
||||
Launch qa-reviewer agent with:
|
||||
- Spec and plan context
|
||||
- List of modified files (from status.json)
|
||||
- Previous iteration results (if any)
|
||||
|
||||
# 2b. Collect Issues
|
||||
Agent returns issues with severity:
|
||||
- error: Must fix
|
||||
- warning: Should fix
|
||||
- info: Nice to fix
|
||||
|
||||
Save to: .auto-build-data/cache/qa-iterations/{feature-name}/iteration-{n}.json
|
||||
|
||||
# 2c. Check Exit Condition
|
||||
if no errors and no warnings:
|
||||
status = "PASSED"
|
||||
break
|
||||
|
||||
# 2d. Present Issues
|
||||
Display:
|
||||
```
|
||||
QA Review - Iteration {n}
|
||||
|
||||
Found 3 issues:
|
||||
[ERROR] src/api/users.ts:42 - Potential null dereference
|
||||
[WARNING] src/types/user.ts:15 - Missing type annotation
|
||||
[INFO] src/utils/format.ts:8 - Could use const instead of let
|
||||
|
||||
Auto-fix these issues? [Yes] [Select] [Skip] [Abort]
|
||||
```
|
||||
|
||||
# 2e. Fix Issues
|
||||
if user says yes:
|
||||
for each error/warning:
|
||||
Launch qa-fixer agent with issue details
|
||||
Track fix result
|
||||
|
||||
# 2f. Increment
|
||||
iteration++
|
||||
```
|
||||
|
||||
### 3. Exit Conditions
|
||||
|
||||
| Condition | Status | Action |
|
||||
|-----------|--------|--------|
|
||||
| No errors/warnings | `PASSED` | Proceed to completion |
|
||||
| Max iterations | `NEEDS_MANUAL_REVIEW` | Show remaining issues |
|
||||
| User abort | `ABORTED` | Save current state |
|
||||
|
||||
### 4. Final Report
|
||||
|
||||
```
|
||||
======================================
|
||||
QA Review Complete
|
||||
======================================
|
||||
|
||||
Status: PASSED (after 3 iterations)
|
||||
|
||||
Summary:
|
||||
- Total issues found: 8
|
||||
- Issues fixed: 7
|
||||
- Issues skipped: 1 (info level)
|
||||
|
||||
Iterations:
|
||||
1. Found 5 issues, fixed 5
|
||||
2. Found 2 issues, fixed 2
|
||||
3. Found 1 issue (info), skipped
|
||||
|
||||
Files reviewed: 12
|
||||
Files modified during fixes: 6
|
||||
|
||||
Next steps:
|
||||
- Save learnings: /ab:memory-save
|
||||
- If using worktree: /ab:worktree cleanup feature-name
|
||||
```
|
||||
|
||||
## Iteration Record Format
|
||||
|
||||
`.auto-build-data/cache/qa-iterations/{feature-name}/iteration-{n}.json`:
|
||||
```json
|
||||
{
|
||||
"iteration": 1,
|
||||
"timestamp": "2025-01-15T14:30:00Z",
|
||||
"issues_found": [
|
||||
{
|
||||
"severity": "error",
|
||||
"category": "correctness",
|
||||
"file": "src/api/users.ts",
|
||||
"line": 42,
|
||||
"code": "const x = data.value",
|
||||
"description": "Potential null dereference - data could be undefined",
|
||||
"suggestion": "Add null check: const x = data?.value ?? defaultValue"
|
||||
}
|
||||
],
|
||||
"issues_fixed": [
|
||||
{
|
||||
"issue_id": 0,
|
||||
"fix_applied": "Added optional chaining and default value",
|
||||
"success": true
|
||||
}
|
||||
],
|
||||
"issues_remaining": 0,
|
||||
"status": "all_fixed"
|
||||
}
|
||||
```
|
||||
|
||||
## QA Categories
|
||||
|
||||
The qa-reviewer checks for:
|
||||
|
||||
1. **Correctness**
|
||||
- Logic errors
|
||||
- Null/undefined handling
|
||||
- Type mismatches
|
||||
|
||||
2. **Patterns**
|
||||
- Following codebase conventions
|
||||
- Consistent error handling
|
||||
|
||||
3. **Security**
|
||||
- Input validation
|
||||
- Injection risks
|
||||
|
||||
4. **Performance**
|
||||
- Unnecessary loops
|
||||
- N+1 queries
|
||||
|
||||
5. **Maintainability**
|
||||
- Code clarity
|
||||
- DRY violations
|
||||
|
||||
## User Controls
|
||||
|
||||
- **Yes**: Fix all errors and warnings automatically
|
||||
- **Select**: Choose which issues to fix
|
||||
- **Skip**: Move to next iteration without fixing
|
||||
- **Abort**: Stop QA review, save current state
|
||||
132
plugin/commands/spec.md
Normal file
132
plugin/commands/spec.md
Normal file
@@ -0,0 +1,132 @@
|
||||
---
|
||||
description: Create detailed feature specification
|
||||
argument-hint: <feature-name> [description]
|
||||
---
|
||||
|
||||
# Create Feature Specification
|
||||
|
||||
Create a comprehensive specification for a new feature using the spec-writer agent.
|
||||
|
||||
## Input
|
||||
|
||||
- **Feature name**: First word of $ARGUMENTS (required)
|
||||
- **Description**: Rest of $ARGUMENTS (optional, will prompt if missing)
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Initialize
|
||||
|
||||
- Parse feature name from arguments (kebab-case: "User Dashboard" -> "user-dashboard")
|
||||
- Check if `.auto-build-data/` exists
|
||||
- If not: Run `bash .auto-build/scripts/setup.sh` first
|
||||
- Check if spec already exists at `.auto-build-data/specs/{feature-name}/`
|
||||
- If exists: Ask "Update existing spec or create new version?"
|
||||
|
||||
### 2. Gather Requirements
|
||||
|
||||
Ask the user these questions (one at a time, adapt based on answers):
|
||||
|
||||
1. **Problem Statement**
|
||||
"What problem does this feature solve? Who are the users?"
|
||||
|
||||
2. **Success Criteria**
|
||||
"How will we know this feature is complete? What are the acceptance criteria?"
|
||||
|
||||
3. **Constraints**
|
||||
"Are there any constraints? (performance, compatibility, existing patterns to follow)"
|
||||
|
||||
4. **Scope**
|
||||
"What is explicitly NOT included in this feature?"
|
||||
|
||||
### 3. Codebase Analysis
|
||||
|
||||
Launch the **spec-writer** agent with:
|
||||
- Feature name and description
|
||||
- User's answers to requirements questions
|
||||
- Instruction to analyze the codebase for:
|
||||
- Similar existing features
|
||||
- Patterns to follow
|
||||
- Files likely to be affected
|
||||
- Dependencies and integrations
|
||||
|
||||
### 4. Generate Specification
|
||||
|
||||
The spec-writer agent creates:
|
||||
- `.auto-build-data/specs/{feature-name}/spec.md` using the template
|
||||
- `.auto-build-data/specs/{feature-name}/status.json` with state: "SPEC_COMPLETE"
|
||||
|
||||
### 5. Confirmation
|
||||
|
||||
Display:
|
||||
```
|
||||
Specification created: .auto-build-data/specs/{feature-name}/spec.md
|
||||
|
||||
Summary:
|
||||
- [Key requirement 1]
|
||||
- [Key requirement 2]
|
||||
- [Key requirement 3]
|
||||
|
||||
Affected files identified: X files
|
||||
Estimated complexity: [Low/Medium/High]
|
||||
|
||||
Next steps:
|
||||
- Review the spec: Read .auto-build-data/specs/{feature-name}/spec.md
|
||||
- Start implementation: /ab:build {feature-name}
|
||||
```
|
||||
|
||||
## Spec Template
|
||||
|
||||
The generated spec.md follows this structure:
|
||||
|
||||
```markdown
|
||||
# Feature: {name}
|
||||
|
||||
## Overview
|
||||
Brief description and purpose
|
||||
|
||||
## Problem Statement
|
||||
What problem this solves
|
||||
|
||||
## User Stories
|
||||
- As a [user], I want [action] so that [benefit]
|
||||
|
||||
## Functional Requirements
|
||||
1. [Requirement 1]
|
||||
2. [Requirement 2]
|
||||
|
||||
## Technical Requirements
|
||||
- Files to modify: [list]
|
||||
- New files to create: [list]
|
||||
- Dependencies: [list]
|
||||
- Database changes: [if any]
|
||||
- API changes: [if any]
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Criterion 1
|
||||
- [ ] Criterion 2
|
||||
|
||||
## Out of Scope
|
||||
What is NOT included
|
||||
|
||||
## Risks and Mitigations
|
||||
| Risk | Mitigation |
|
||||
|------|------------|
|
||||
|
||||
## Open Questions
|
||||
- [Any unresolved questions]
|
||||
```
|
||||
|
||||
## Status JSON Format
|
||||
|
||||
```json
|
||||
{
|
||||
"feature": "feature-name",
|
||||
"status": "SPEC_COMPLETE",
|
||||
"created": "2025-01-15T10:00:00Z",
|
||||
"updated": "2025-01-15T10:30:00Z",
|
||||
"history": [
|
||||
{"status": "SPEC_DRAFT", "at": "2025-01-15T10:00:00Z"},
|
||||
{"status": "SPEC_COMPLETE", "at": "2025-01-15T10:30:00Z"}
|
||||
]
|
||||
}
|
||||
```
|
||||
77
plugin/commands/status.md
Normal file
77
plugin/commands/status.md
Normal file
@@ -0,0 +1,77 @@
|
||||
---
|
||||
description: Show current Auto-Build status
|
||||
---
|
||||
|
||||
# Auto-Build Status
|
||||
|
||||
Display the current status of Auto-Build, including active specs and builds.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Check Data Directory**
|
||||
- Verify `.auto-build-data/` exists
|
||||
- If not, inform user to run setup: `bash .auto-build/scripts/setup.sh`
|
||||
|
||||
2. **List Active Specs**
|
||||
- Read all directories in `.auto-build-data/specs/`
|
||||
- For each spec, read `status.json` to get current state
|
||||
- Display in table format:
|
||||
```
|
||||
| Feature | Status | Progress | Last Updated |
|
||||
|---------|--------|----------|--------------|
|
||||
| user-dashboard | IMPLEMENTING | 3/7 tasks | 2h ago |
|
||||
| api-refactor | SPEC_COMPLETE | - | 1d ago |
|
||||
```
|
||||
|
||||
3. **Show Active Worktrees**
|
||||
- Read `.auto-build-data/worktrees/worktree-registry.json`
|
||||
- Display active worktrees with their paths
|
||||
|
||||
4. **Memory Summary**
|
||||
- Count entries in `patterns.json` and `gotchas.json`
|
||||
- Show last update timestamp
|
||||
|
||||
## Status States
|
||||
|
||||
| State | Description |
|
||||
|-------|-------------|
|
||||
| `SPEC_DRAFT` | Specification in progress |
|
||||
| `SPEC_COMPLETE` | Specification ready, awaiting build |
|
||||
| `PLANNING` | Creating implementation plan |
|
||||
| `PLANNING_COMPLETE` | Plan ready, awaiting implementation |
|
||||
| `IMPLEMENTING` | Code implementation in progress |
|
||||
| `IMPLEMENTATION_COMPLETE` | Code done, awaiting QA |
|
||||
| `QA_REVIEW` | QA validation in progress |
|
||||
| `QA_FAILED` | QA found issues, needs fixes |
|
||||
| `COMPLETE` | Feature fully implemented and validated |
|
||||
|
||||
## Output Format
|
||||
|
||||
```
|
||||
======================================
|
||||
Auto-Build Status
|
||||
======================================
|
||||
|
||||
Active Builds:
|
||||
- user-dashboard: IMPLEMENTING (3/7 tasks)
|
||||
Worktree: ../ab-worktrees/project-user-dashboard/
|
||||
Last update: 2 hours ago
|
||||
|
||||
- api-refactor: SPEC_COMPLETE
|
||||
No worktree
|
||||
Last update: 1 day ago
|
||||
|
||||
Memory:
|
||||
- Patterns: 12 entries
|
||||
- Gotchas: 5 entries
|
||||
- Last updated: 3 days ago
|
||||
|
||||
Quick Actions:
|
||||
- Continue build: /ab:build user-dashboard
|
||||
- Start new: /ab:spec "Feature Name"
|
||||
```
|
||||
|
||||
## Edge Cases
|
||||
|
||||
- If no specs exist: "No active builds. Start with /ab:spec <name>"
|
||||
- If data directory missing: "Run setup first: bash .auto-build/scripts/setup.sh"
|
||||
146
plugin/commands/worktree.md
Normal file
146
plugin/commands/worktree.md
Normal file
@@ -0,0 +1,146 @@
|
||||
---
|
||||
description: Manage git worktrees for feature isolation
|
||||
argument-hint: <action> [name] - Actions: create, list, switch, cleanup
|
||||
---
|
||||
|
||||
# Git Worktree Management
|
||||
|
||||
Manage isolated git worktrees for feature development. Worktrees provide complete isolation between features, preventing conflicts during parallel development.
|
||||
|
||||
## Actions
|
||||
|
||||
### create <feature-name>
|
||||
|
||||
Create a new isolated worktree for a feature.
|
||||
|
||||
**Workflow:**
|
||||
1. Validate feature name provided
|
||||
2. Determine project name from current directory
|
||||
3. Create branch: `feature/ab-{feature-name}`
|
||||
4. Create worktree at: `../ab-worktrees/{project}-{feature-name}/`
|
||||
5. Register in `.auto-build-data/worktrees/worktree-registry.json`
|
||||
6. Display success message with path
|
||||
|
||||
**Command:**
|
||||
```bash
|
||||
bash .auto-build/scripts/worktree-create.sh {feature-name}
|
||||
```
|
||||
|
||||
**Output:**
|
||||
```
|
||||
Created worktree for: feature-name
|
||||
Branch: feature/ab-feature-name
|
||||
Path: ../ab-worktrees/project-feature-name/
|
||||
|
||||
To work in this worktree:
|
||||
cd ../ab-worktrees/project-feature-name/
|
||||
```
|
||||
|
||||
### list
|
||||
|
||||
List all active worktrees.
|
||||
|
||||
**Workflow:**
|
||||
1. Read `.auto-build-data/worktrees/worktree-registry.json`
|
||||
2. Verify each worktree still exists (git worktree list)
|
||||
3. Display table:
|
||||
```
|
||||
Active Worktrees:
|
||||
| Feature | Branch | Path | Created |
|
||||
|---------|--------|------|---------|
|
||||
| user-dashboard | feature/ab-user-dashboard | ../ab-worktrees/project-user-dashboard/ | 2h ago |
|
||||
```
|
||||
|
||||
**Command:**
|
||||
```bash
|
||||
bash .auto-build/scripts/worktree-list.sh
|
||||
```
|
||||
|
||||
### switch <feature-name>
|
||||
|
||||
Provide instructions to switch to a worktree.
|
||||
|
||||
**Workflow:**
|
||||
1. Look up worktree path from registry
|
||||
2. Verify worktree exists
|
||||
3. Display switch instructions:
|
||||
```
|
||||
To switch to feature-name worktree:
|
||||
|
||||
cd ../ab-worktrees/project-feature-name/
|
||||
|
||||
Or start a new Claude Code session in that directory.
|
||||
```
|
||||
|
||||
**Note:** Claude Code sessions are directory-bound, so actual switching requires changing the working directory.
|
||||
|
||||
### cleanup [feature-name]
|
||||
|
||||
Remove completed worktrees.
|
||||
|
||||
**Workflow:**
|
||||
If feature-name provided:
|
||||
1. Look up worktree in registry
|
||||
2. Check if branch is merged to main
|
||||
3. If merged or user confirms: Remove worktree and branch
|
||||
4. Update registry
|
||||
|
||||
If no feature-name:
|
||||
1. List all worktrees
|
||||
2. Check which branches are merged
|
||||
3. Offer to cleanup merged ones:
|
||||
```
|
||||
Found 2 merged worktrees:
|
||||
- old-feature (merged 3 days ago)
|
||||
- bug-fix (merged 1 week ago)
|
||||
|
||||
Remove these? [Yes] [Select] [No]
|
||||
```
|
||||
|
||||
**Command:**
|
||||
```bash
|
||||
bash .auto-build/scripts/worktree-cleanup.sh [feature-name]
|
||||
```
|
||||
|
||||
## Registry Format
|
||||
|
||||
`.auto-build-data/worktrees/worktree-registry.json`:
|
||||
```json
|
||||
{
|
||||
"worktrees": [
|
||||
{
|
||||
"name": "user-dashboard",
|
||||
"branch": "feature/ab-user-dashboard",
|
||||
"path": "../ab-worktrees/project-user-dashboard/",
|
||||
"created": "2025-01-15T10:30:00Z",
|
||||
"status": "active",
|
||||
"spec": ".auto-build-data/specs/user-dashboard/"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Worktree Location
|
||||
|
||||
Worktrees are created **outside** the project directory to avoid:
|
||||
- Nested git repository issues
|
||||
- IDE confusion
|
||||
- Accidental commits from wrong directory
|
||||
|
||||
Structure:
|
||||
```
|
||||
/projects/
|
||||
├── my-project/ # Main project
|
||||
│ ├── .auto-build/
|
||||
│ └── .auto-build-data/
|
||||
└── ab-worktrees/ # Worktrees directory
|
||||
├── my-project-user-dashboard/
|
||||
└── my-project-api-refactor/
|
||||
```
|
||||
|
||||
## Error Cases
|
||||
|
||||
- **Branch already exists**: Ask to use existing or create new
|
||||
- **Worktree path exists**: Ask to reuse or choose different path
|
||||
- **Not a git repository**: Inform user and abort
|
||||
- **Uncommitted changes**: Warn user before creating worktree
|
||||
Reference in New Issue
Block a user