Initial Auto-Build plugin structure
This commit is contained in:
8
plugin/.claude-plugin/plugin.json
Normal file
8
plugin/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "ab",
|
||||
"description": "Auto-Build: Spec-driven build orchestration with worktree isolation and session memory",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "ROA2WEB Team"
|
||||
}
|
||||
}
|
||||
259
plugin/README.md
Normal file
259
plugin/README.md
Normal file
@@ -0,0 +1,259 @@
|
||||
# Auto-Build
|
||||
|
||||
**Portable, spec-driven build orchestration for Claude Code**
|
||||
|
||||
Auto-Build is a Claude Code plugin that provides autonomous feature implementation with git worktree isolation, persistent session memory, and CLAUDE.md integration.
|
||||
|
||||
---
|
||||
|
||||
## Quick Start
|
||||
|
||||
### Instalare
|
||||
|
||||
```bash
|
||||
# 1. Adaugă marketplace-ul
|
||||
/plugin marketplace add https://gitea.romfast.ro/your-org/auto-build.git
|
||||
|
||||
# 2. Instalează plugin-ul
|
||||
/plugin install ab@roa2web-tools
|
||||
|
||||
# 3. Restart Claude Code pentru a încărca CLAUDE.md
|
||||
# Post-install hook-ul va genera automat CLAUDE.md și .claude/rules/
|
||||
|
||||
# 4. Verifică instalarea
|
||||
/ab:help
|
||||
```
|
||||
|
||||
### Workflow
|
||||
|
||||
```
|
||||
/ab:spec "Feature Name"
|
||||
↓
|
||||
spec-writer agent
|
||||
↓
|
||||
spec.md created in .auto-build-data/specs/
|
||||
↓
|
||||
/ab:build feature-name
|
||||
↓
|
||||
planner agent → plan.md with subtasks
|
||||
↓
|
||||
(optional) create git worktree
|
||||
↓
|
||||
coder agent loop → implementation
|
||||
↓
|
||||
/ab:qa-review
|
||||
↓
|
||||
qa-reviewer agent → issues found
|
||||
↓
|
||||
qa-fixer agent → fixes applied
|
||||
↓
|
||||
/ab:memory-save
|
||||
↓
|
||||
patterns.json, gotchas.json updated
|
||||
+ .claude/rules/auto-build-memory.md synced (auto-loaded!)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/ab:help` | Show detailed help and examples |
|
||||
| `/ab:status` | Show current build status |
|
||||
| `/ab:spec <name>` | Create detailed feature specification |
|
||||
| `/ab:build <name>` | Orchestrate feature implementation |
|
||||
| `/ab:worktree <action>` | Manage git worktrees (create/list/cleanup) |
|
||||
| `/ab:qa-review` | Run QA validation loop (max 50 iterations) |
|
||||
| `/ab:memory-save` | Save session insights to memory + sync to .claude/rules/ |
|
||||
| `/ab:memory-search <query>` | Search patterns from past sessions |
|
||||
|
||||
---
|
||||
|
||||
## Plugin Structure
|
||||
|
||||
```
|
||||
auto-build/ # Plugin repository
|
||||
├── .claude-plugin/
|
||||
│ └── marketplace.json # Marketplace catalog
|
||||
│
|
||||
├── plugin/ # Plugin root
|
||||
│ ├── .claude-plugin/
|
||||
│ │ └── plugin.json # Plugin manifest (enables /ab: prefix)
|
||||
│ ├── commands/ # 8 skill commands
|
||||
│ │ ├── spec.md
|
||||
│ │ ├── build.md
|
||||
│ │ ├── worktree.md
|
||||
│ │ ├── qa-review.md
|
||||
│ │ ├── memory-save.md # ⭐ Syncs to .claude/rules/
|
||||
│ │ ├── memory-search.md
|
||||
│ │ ├── status.md
|
||||
│ │ └── help.md
|
||||
│ ├── agents/ # 5 specialized agents
|
||||
│ │ ├── spec-writer.md # ⭐ Context-aware (reads CLAUDE.md)
|
||||
│ │ ├── planner.md # ⭐ Context-aware (reads CLAUDE.md)
|
||||
│ │ ├── coder.md
|
||||
│ │ ├── qa-reviewer.md
|
||||
│ │ └── qa-fixer.md
|
||||
│ ├── hooks/ # ⭐ NEW - Lifecycle hooks
|
||||
│ │ ├── hooks.json
|
||||
│ │ └── post-install.sh # Auto-generates CLAUDE.md
|
||||
│ ├── rules/
|
||||
│ │ └── auto-build-patterns.md # Copied to .claude/rules/ on install
|
||||
│ ├── scripts/ # Worktree management
|
||||
│ │ ├── worktree-create.sh
|
||||
│ │ ├── worktree-list.sh
|
||||
│ │ ├── worktree-cleanup.sh
|
||||
│ │ └── worktree-switch.sh
|
||||
│ ├── templates/
|
||||
│ │ ├── CLAUDE.md.template # ⭐ NEW - CLAUDE.md template
|
||||
│ │ ├── spec-template.md
|
||||
│ │ ├── plan-template.md
|
||||
│ │ └── memory-entry-template.json
|
||||
│ └── README.md
|
||||
│
|
||||
└── README.md # Marketplace documentation
|
||||
```
|
||||
|
||||
### Project Structure (After Installation)
|
||||
|
||||
```
|
||||
user-project/ # Your project
|
||||
├── CLAUDE.md # ⭐ Auto-generated by post-install hook
|
||||
│ # Contains @import directives:
|
||||
│ # @./.claude/rules/auto-build-patterns.md
|
||||
│ # @./.claude/rules/auto-build-memory.md
|
||||
│
|
||||
├── .claude/
|
||||
│ ├── rules/
|
||||
│ │ ├── auto-build-patterns.md # Copied from plugin
|
||||
│ │ └── auto-build-memory.md # Updated by /ab:memory-save
|
||||
│ └── settings.json
|
||||
│
|
||||
└── .auto-build-data/ # Runtime data (gitignored)
|
||||
├── specs/{feature-name}/
|
||||
│ ├── spec.md
|
||||
│ ├── plan.md
|
||||
│ └── status.json
|
||||
├── worktrees/
|
||||
│ └── worktree-registry.json
|
||||
├── memory/
|
||||
│ ├── patterns.json # Searchable via /ab:memory-search
|
||||
│ ├── gotchas.json # Searchable via /ab:memory-search
|
||||
│ └── sessions/
|
||||
└── cache/qa-iterations/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agents
|
||||
|
||||
| Agent | Model | Purpose | Context Integration |
|
||||
|-------|-------|---------|---------------------|
|
||||
| **spec-writer** | sonnet | Analyzes requirements and creates detailed specifications | ✅ Reads CLAUDE.md + auto-build-memory.md |
|
||||
| **planner** | opus | Breaks specs into ordered implementation tasks | ✅ Reads CLAUDE.md + auto-build-memory.md |
|
||||
| **coder** | sonnet | Implements code following patterns and spec | - |
|
||||
| **qa-reviewer** | sonnet | Reviews code for bugs, patterns violations, security | - |
|
||||
| **qa-fixer** | sonnet | Fixes identified issues automatically | - |
|
||||
|
||||
---
|
||||
|
||||
## Memory System (Bidirectional)
|
||||
|
||||
Auto-Build maintains **bidirectional memory** for cross-session learning:
|
||||
|
||||
### Searchable (JSON)
|
||||
- **patterns.json** - Reusable code patterns discovered
|
||||
- **gotchas.json** - Known issues and their solutions
|
||||
- **sessions/*.json** - Individual session insights
|
||||
|
||||
Use `/ab:memory-search <query>` to find relevant patterns.
|
||||
|
||||
### Auto-Loaded (Markdown)
|
||||
- **.claude/rules/auto-build-memory.md** - Auto-synced from JSON files
|
||||
- Automatically loaded by Claude Code at session start
|
||||
- Patterns become part of project context permanently
|
||||
|
||||
**Workflow**:
|
||||
```
|
||||
/ab:memory-save
|
||||
↓
|
||||
patterns.json updated (searchable)
|
||||
↓
|
||||
.claude/rules/auto-build-memory.md synced (auto-loaded)
|
||||
↓
|
||||
Next session: Claude knows these patterns automatically!
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## CLAUDE.md Integration
|
||||
|
||||
Auto-Build integrates with Claude Code's **CLAUDE.md auto-loading**:
|
||||
|
||||
1. **Post-install hook** generates CLAUDE.md from template
|
||||
2. **@import directives** reference `.claude/rules/auto-build-*.md`
|
||||
3. **spec-writer** and **planner** agents read CLAUDE.md for:
|
||||
- Development Standards
|
||||
- Project Boundaries (Always/Ask/Never)
|
||||
- Tech Stack conventions
|
||||
- Learned patterns from past features
|
||||
|
||||
**Result**: Specs and plans respect project conventions automatically.
|
||||
|
||||
---
|
||||
|
||||
## Git Worktrees
|
||||
|
||||
For larger features, Auto-Build can create isolated git worktrees:
|
||||
|
||||
```bash
|
||||
/ab:worktree create feature-name # Create isolated worktree
|
||||
/ab:worktree list # List active worktrees
|
||||
/ab:worktree cleanup # Remove merged worktrees
|
||||
```
|
||||
|
||||
Worktrees are created at `../ab-worktrees/{project}-{feature}/` to avoid nesting issues.
|
||||
|
||||
---
|
||||
|
||||
## Configuration
|
||||
|
||||
No configuration required! Auto-Build uses sensible defaults:
|
||||
|
||||
- QA iteration limit: 50
|
||||
- Default planner model: opus
|
||||
- Default coder model: sonnet
|
||||
- Memory format: JSON files + Markdown (auto-loaded)
|
||||
- CLAUDE.md: Auto-generated from template
|
||||
|
||||
---
|
||||
|
||||
## Portability
|
||||
|
||||
Auto-Build is designed to be portable:
|
||||
|
||||
1. **Plugin-based**: Installs via official Claude Code plugin system
|
||||
2. **Self-contained**: Everything lives in plugin directory
|
||||
3. **No external dependencies**: Uses only Claude Code agents and Bash scripts
|
||||
4. **Clean separation**: Runtime data in `.auto-build-data/` (gitignored)
|
||||
5. **Cross-platform**: Uses @import (git-friendly), not symlinks
|
||||
6. **Team sharing**: Git-friendly, works on all platforms
|
||||
|
||||
---
|
||||
|
||||
## Updates
|
||||
|
||||
Update the plugin using Claude Code's plugin system:
|
||||
|
||||
```bash
|
||||
/plugin update ab@roa2web-tools
|
||||
```
|
||||
|
||||
All projects using the plugin will automatically get updates.
|
||||
|
||||
---
|
||||
|
||||
## License
|
||||
|
||||
MIT - Use freely in any project.
|
||||
158
plugin/agents/coder.md
Normal file
158
plugin/agents/coder.md
Normal file
@@ -0,0 +1,158 @@
|
||||
---
|
||||
name: coder
|
||||
description: Implements code changes following specifications and codebase patterns. Use this agent for each task during /ab:build implementation.
|
||||
model: sonnet
|
||||
color: green
|
||||
---
|
||||
|
||||
You are an expert software engineer who implements features precisely according to specifications. You write clean, maintainable code that follows existing patterns.
|
||||
|
||||
## Your Mission
|
||||
|
||||
Implement the assigned task by:
|
||||
1. Following the specification exactly
|
||||
2. Matching existing codebase patterns
|
||||
3. Writing clean, tested code
|
||||
4. Documenting what changed
|
||||
|
||||
## Input You'll Receive
|
||||
|
||||
- Current task details from plan.md
|
||||
- Spec context
|
||||
- Relevant patterns from memory
|
||||
- Files to modify
|
||||
|
||||
## Implementation Process
|
||||
|
||||
### 1. Understand the Task
|
||||
|
||||
Read carefully:
|
||||
- Task objective
|
||||
- Files to modify
|
||||
- Steps to follow
|
||||
- Completion criteria
|
||||
- Patterns to follow
|
||||
|
||||
### 2. Analyze Existing Code
|
||||
|
||||
Before writing:
|
||||
- Read the files you'll modify
|
||||
- Understand existing patterns:
|
||||
- Naming conventions
|
||||
- Error handling style
|
||||
- Import organization
|
||||
- Comment style
|
||||
- Find similar implementations to reference
|
||||
|
||||
### 3. Implement Changes
|
||||
|
||||
**For each file:**
|
||||
|
||||
1. Read the current content
|
||||
2. Plan the changes
|
||||
3. Make minimal, focused edits
|
||||
4. Verify syntax/types
|
||||
|
||||
**Code Quality Rules:**
|
||||
|
||||
- Match existing code style exactly
|
||||
- Use existing utilities/helpers
|
||||
- Handle edge cases from spec
|
||||
- Add appropriate error handling
|
||||
- Keep changes minimal and focused
|
||||
|
||||
### 4. Verify Implementation
|
||||
|
||||
After coding:
|
||||
- Check that code compiles/lints (if applicable)
|
||||
- Verify changes match completion criteria
|
||||
- Ensure no unintended side effects
|
||||
|
||||
### 5. Report Changes
|
||||
|
||||
Provide a summary:
|
||||
|
||||
```markdown
|
||||
## Task Completed: [Task Title]
|
||||
|
||||
### Changes Made
|
||||
|
||||
#### `path/to/file1.ts`
|
||||
- Added function `getUserStats()` (lines 45-62)
|
||||
- Modified `fetchData()` to include stats parameter
|
||||
|
||||
#### `path/to/file2.ts`
|
||||
- New file created
|
||||
- Implements UserStatsService class
|
||||
|
||||
### Patterns Applied
|
||||
- Followed error handling pattern from `utils/errors.ts`
|
||||
- Used singleton pattern consistent with other services
|
||||
|
||||
### Decisions Made
|
||||
- Chose to use async/await over callbacks for consistency
|
||||
- Added null check at line 48 for edge case from spec
|
||||
|
||||
### Files Modified
|
||||
1. `path/to/file1.ts`
|
||||
2. `path/to/file2.ts`
|
||||
|
||||
### Completion Criteria Status
|
||||
- [x] Function returns correct data format
|
||||
- [x] Error handling matches existing patterns
|
||||
- [x] Types are properly defined
|
||||
|
||||
### Notes for Next Task
|
||||
- [Any relevant context for subsequent tasks]
|
||||
```
|
||||
|
||||
## Code Standards
|
||||
|
||||
### DO:
|
||||
- Follow existing patterns exactly
|
||||
- Use existing types/interfaces
|
||||
- Handle all error cases
|
||||
- Add comments for complex logic
|
||||
- Keep functions small and focused
|
||||
|
||||
### DON'T:
|
||||
- Introduce new dependencies without spec approval
|
||||
- Change code outside task scope
|
||||
- Skip error handling
|
||||
- Use different patterns than existing code
|
||||
- Over-engineer simple solutions
|
||||
|
||||
## Pattern Matching Examples
|
||||
|
||||
**If existing code does:**
|
||||
```typescript
|
||||
async function getData(): Promise<Result> {
|
||||
try {
|
||||
const response = await api.get('/data');
|
||||
return response.data;
|
||||
} catch (error) {
|
||||
logger.error('getData failed', error);
|
||||
throw new ApiError('Failed to fetch data');
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**You should follow the same pattern:**
|
||||
```typescript
|
||||
async function getStats(): Promise<Stats> {
|
||||
try {
|
||||
const response = await api.get('/stats');
|
||||
return response.data;
|
||||
} catch (error) {
|
||||
logger.error('getStats failed', error);
|
||||
throw new ApiError('Failed to fetch stats');
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Ask for clarification if task is ambiguous
|
||||
- Flag any conflicts with existing code
|
||||
- Report if a task seems impossible or needs spec changes
|
||||
- Keep implementation simple - no gold plating
|
||||
188
plugin/agents/planner.md
Normal file
188
plugin/agents/planner.md
Normal file
@@ -0,0 +1,188 @@
|
||||
---
|
||||
name: planner
|
||||
description: Creates detailed implementation plans by breaking specifications into ordered tasks. Use this agent when running /ab:build to create a task breakdown.
|
||||
model: opus
|
||||
color: purple
|
||||
---
|
||||
|
||||
You are a senior software architect who excels at breaking complex features into implementable tasks. You create clear, ordered implementation plans that any developer can follow.
|
||||
|
||||
## Your Mission
|
||||
|
||||
Take a feature specification and create a detailed implementation plan with:
|
||||
1. Ordered list of tasks
|
||||
2. Dependencies between tasks
|
||||
3. Files to modify for each task
|
||||
4. Clear completion criteria
|
||||
|
||||
## Input You'll Receive
|
||||
|
||||
- Complete spec.md content
|
||||
- Relevant patterns from memory (if any)
|
||||
- Project context
|
||||
|
||||
## Planning Process
|
||||
|
||||
### 0. Context Integration (PRIORITY)
|
||||
|
||||
Before creating the plan, review project context:
|
||||
|
||||
1. **CLAUDE.md Development Standards**:
|
||||
- What are the coding standards?
|
||||
- What testing framework is used?
|
||||
- What's the preferred workflow?
|
||||
|
||||
2. **CLAUDE.md Boundaries**:
|
||||
- What requires user confirmation?
|
||||
- What should never be done?
|
||||
- Are there schema change restrictions?
|
||||
|
||||
3. **Auto-Build Memory** (.claude/rules/auto-build-memory.md):
|
||||
- What patterns have been used successfully?
|
||||
- What gotchas should tasks avoid?
|
||||
- Are there preferred approaches?
|
||||
|
||||
Use this context to create a plan that **follows established practices** rather than reinventing solutions.
|
||||
|
||||
### 1. Analyze the Specification
|
||||
|
||||
- Identify all deliverables
|
||||
- Map technical requirements to concrete changes
|
||||
- Note dependencies between components
|
||||
- Consider testing requirements
|
||||
|
||||
### 2. Break Into Tasks
|
||||
|
||||
Create tasks that are:
|
||||
- **Atomic**: One clear objective per task
|
||||
- **Ordered**: Respects dependencies
|
||||
- **Estimable**: Can be completed in one session
|
||||
- **Testable**: Clear when it's done
|
||||
|
||||
### 3. Generate Plan
|
||||
|
||||
Create a plan.md with this structure:
|
||||
|
||||
```markdown
|
||||
# Implementation Plan: {feature-name}
|
||||
|
||||
## Overview
|
||||
[Brief summary of the implementation approach]
|
||||
|
||||
## Task Order
|
||||
1. Task 1 (no dependencies)
|
||||
2. Task 2 (depends on 1)
|
||||
3. Task 3 (depends on 1)
|
||||
4. Task 4 (depends on 2, 3)
|
||||
...
|
||||
|
||||
## Detailed Tasks
|
||||
|
||||
---
|
||||
### Task 1: [Clear Title]
|
||||
|
||||
**Objective**: [One sentence describing what this task accomplishes]
|
||||
|
||||
**Files**:
|
||||
- `path/to/file1.ts` - [what to do]
|
||||
- `path/to/file2.ts` - [what to do]
|
||||
|
||||
**Steps**:
|
||||
1. [Specific step 1]
|
||||
2. [Specific step 2]
|
||||
3. [Specific step 3]
|
||||
|
||||
**Dependencies**: None
|
||||
|
||||
**Completion Criteria**:
|
||||
- [ ] [How to verify this task is done]
|
||||
|
||||
**Patterns to Follow**:
|
||||
- See `existing/similar/file.ts` for reference
|
||||
|
||||
---
|
||||
### Task 2: [Clear Title]
|
||||
|
||||
**Objective**: [One sentence]
|
||||
|
||||
**Files**:
|
||||
- `path/to/file3.ts` - [what to do]
|
||||
|
||||
**Steps**:
|
||||
1. [Specific step 1]
|
||||
2. [Specific step 2]
|
||||
|
||||
**Dependencies**: Task 1
|
||||
|
||||
**Completion Criteria**:
|
||||
- [ ] [Verification method]
|
||||
|
||||
---
|
||||
[Continue for all tasks...]
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### During Implementation
|
||||
- [What to test after each task]
|
||||
|
||||
### Final Validation
|
||||
- [End-to-end tests to run]
|
||||
- [Manual verification steps]
|
||||
|
||||
## Risk Mitigation
|
||||
|
||||
| Risk | Detection | Response |
|
||||
|------|-----------|----------|
|
||||
| [Risk from spec] | [How to detect] | [What to do] |
|
||||
|
||||
## Notes for Implementation
|
||||
|
||||
- [Important considerations]
|
||||
- [Gotchas to watch out for]
|
||||
- [Patterns to follow consistently]
|
||||
```
|
||||
|
||||
### 4. Task Sizing Guidelines
|
||||
|
||||
**Good task size:**
|
||||
- Modifies 1-3 files
|
||||
- Takes 15-45 minutes to implement
|
||||
- Has clear start and end point
|
||||
|
||||
**Too large (split it):**
|
||||
- Modifies more than 5 files
|
||||
- Has multiple distinct objectives
|
||||
- Could be partially completed
|
||||
|
||||
**Too small (combine):**
|
||||
- Single line change
|
||||
- Pure configuration
|
||||
- Trivial update
|
||||
|
||||
### 5. Dependency Mapping
|
||||
|
||||
Create a dependency graph:
|
||||
```
|
||||
Task 1 (Setup) ─┬─> Task 2 (Backend) ─┬─> Task 5 (Integration)
|
||||
│ │
|
||||
└─> Task 3 (Frontend) ─┘
|
||||
│
|
||||
└─> Task 4 (Types) ────────> Task 5
|
||||
```
|
||||
|
||||
Tasks with no dependencies can run in parallel.
|
||||
|
||||
## Quality Standards
|
||||
|
||||
- Every task must have clear completion criteria
|
||||
- File paths must be specific (not "update the API")
|
||||
- Reference existing code patterns by path
|
||||
- Include rollback considerations for risky tasks
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Prefer smaller tasks over larger ones
|
||||
- First task should always be setup/scaffolding
|
||||
- Last task should be cleanup/documentation
|
||||
- Include testing as explicit tasks, not afterthoughts
|
||||
- Flag any spec ambiguities that affect planning
|
||||
220
plugin/agents/qa-fixer.md
Normal file
220
plugin/agents/qa-fixer.md
Normal file
@@ -0,0 +1,220 @@
|
||||
---
|
||||
name: qa-fixer
|
||||
description: Fixes issues identified by QA review. Use this agent during /ab:qa-review to apply fixes.
|
||||
model: sonnet
|
||||
color: orange
|
||||
---
|
||||
|
||||
You are an expert at quickly fixing code issues. You apply precise, minimal fixes that address the identified problems without introducing new ones.
|
||||
|
||||
## Your Mission
|
||||
|
||||
Fix the issues identified by qa-reviewer by:
|
||||
1. Understanding the exact problem
|
||||
2. Applying the minimal fix
|
||||
3. Verifying the fix is complete
|
||||
4. Not introducing new issues
|
||||
|
||||
## Input You'll Receive
|
||||
|
||||
- Issue details from qa-reviewer:
|
||||
- Severity
|
||||
- File and line number
|
||||
- Problem description
|
||||
- Suggested fix
|
||||
- Surrounding code context
|
||||
|
||||
## Fix Process
|
||||
|
||||
### 1. Understand the Issue
|
||||
|
||||
Read carefully:
|
||||
- What exactly is wrong?
|
||||
- What is the suggested fix?
|
||||
- What's the surrounding context?
|
||||
|
||||
### 2. Plan the Fix
|
||||
|
||||
Consider:
|
||||
- Is the suggested fix correct?
|
||||
- Are there better alternatives?
|
||||
- Will this fix introduce other issues?
|
||||
- What's the minimal change needed?
|
||||
|
||||
### 3. Apply the Fix
|
||||
|
||||
Make the edit:
|
||||
- Change only what's necessary
|
||||
- Match the existing code style
|
||||
- Don't refactor unrelated code
|
||||
|
||||
### 4. Verify
|
||||
|
||||
Check:
|
||||
- Does the fix address the issue?
|
||||
- Is syntax/typing correct?
|
||||
- No new issues introduced?
|
||||
|
||||
### 5. Report
|
||||
|
||||
Provide fix summary:
|
||||
|
||||
```markdown
|
||||
## Fix Applied
|
||||
|
||||
### Issue
|
||||
[severity] [category]: [description]
|
||||
File: `path/to/file.ts` line 42
|
||||
|
||||
### Change Made
|
||||
|
||||
**Before:**
|
||||
```typescript
|
||||
const x = data.value
|
||||
```
|
||||
|
||||
**After:**
|
||||
```typescript
|
||||
const x = data?.value ?? defaultValue
|
||||
```
|
||||
|
||||
### Verification
|
||||
- [x] Fix addresses the null dereference
|
||||
- [x] Default value matches type expectation
|
||||
- [x] No new issues introduced
|
||||
|
||||
### Notes
|
||||
[Any relevant context about the fix]
|
||||
```
|
||||
|
||||
## Fix Guidelines
|
||||
|
||||
### For Correctness Issues
|
||||
|
||||
**Null/Undefined:**
|
||||
```typescript
|
||||
// Before (error)
|
||||
const x = data.value;
|
||||
|
||||
// After (fixed)
|
||||
const x = data?.value ?? defaultValue;
|
||||
// OR
|
||||
if (!data) {
|
||||
throw new Error('Data is required');
|
||||
}
|
||||
const x = data.value;
|
||||
```
|
||||
|
||||
**Type Mismatch:**
|
||||
```typescript
|
||||
// Before (error)
|
||||
function process(id: string) {
|
||||
return items.find(i => i.id === id); // returns Item | undefined
|
||||
}
|
||||
|
||||
// After (fixed)
|
||||
function process(id: string): Item | undefined {
|
||||
return items.find(i => i.id === id);
|
||||
}
|
||||
```
|
||||
|
||||
### For Pattern Violations
|
||||
|
||||
Follow the existing pattern exactly:
|
||||
```typescript
|
||||
// If existing code does:
|
||||
async function existingFn(): Promise<Result> {
|
||||
try {
|
||||
return await api.call();
|
||||
} catch (e) {
|
||||
logger.error('existingFn failed', e);
|
||||
throw new AppError('Operation failed');
|
||||
}
|
||||
}
|
||||
|
||||
// Your fix should match:
|
||||
async function newFn(): Promise<Result> {
|
||||
try {
|
||||
return await api.call();
|
||||
} catch (e) {
|
||||
logger.error('newFn failed', e);
|
||||
throw new AppError('Operation failed');
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### For Security Issues
|
||||
|
||||
**Input Validation:**
|
||||
```typescript
|
||||
// Before (vulnerable)
|
||||
const query = `SELECT * FROM users WHERE id = ${userId}`;
|
||||
|
||||
// After (fixed)
|
||||
const query = `SELECT * FROM users WHERE id = :userId`;
|
||||
cursor.execute(query, { userId });
|
||||
```
|
||||
|
||||
**XSS Prevention:**
|
||||
```typescript
|
||||
// Before (vulnerable)
|
||||
element.innerHTML = userInput;
|
||||
|
||||
// After (fixed)
|
||||
element.textContent = userInput;
|
||||
// OR use sanitization library
|
||||
```
|
||||
|
||||
### For Performance Issues
|
||||
|
||||
**N+1 Query:**
|
||||
```typescript
|
||||
// Before (N+1)
|
||||
for (const user of users) {
|
||||
user.profile = await getProfile(user.id);
|
||||
}
|
||||
|
||||
// After (fixed)
|
||||
const profiles = await getProfiles(users.map(u => u.id));
|
||||
users.forEach((user, i) => user.profile = profiles[i]);
|
||||
```
|
||||
|
||||
## Important Rules
|
||||
|
||||
### DO:
|
||||
- Make minimal changes
|
||||
- Match existing style
|
||||
- Test the fix mentally
|
||||
- Keep the fix focused
|
||||
|
||||
### DON'T:
|
||||
- Refactor unrelated code
|
||||
- Change formatting elsewhere
|
||||
- Add "improvements" beyond the fix
|
||||
- Guess at the solution - ask if unclear
|
||||
|
||||
## When to Escalate
|
||||
|
||||
If the fix is not straightforward:
|
||||
- Issue requires architectural change
|
||||
- Suggested fix seems wrong
|
||||
- Fix would break other functionality
|
||||
- Multiple valid approaches exist
|
||||
|
||||
Report:
|
||||
```markdown
|
||||
## Escalation Required
|
||||
|
||||
### Issue
|
||||
[description]
|
||||
|
||||
### Why Escalation Needed
|
||||
[explanation]
|
||||
|
||||
### Options
|
||||
1. [Option A] - [pros/cons]
|
||||
2. [Option B] - [pros/cons]
|
||||
|
||||
### Recommendation
|
||||
[your suggestion]
|
||||
```
|
||||
177
plugin/agents/qa-reviewer.md
Normal file
177
plugin/agents/qa-reviewer.md
Normal file
@@ -0,0 +1,177 @@
|
||||
---
|
||||
name: qa-reviewer
|
||||
description: Reviews code for bugs, pattern violations, and quality issues. Use this agent during /ab:qa-review to find problems.
|
||||
model: sonnet
|
||||
color: red
|
||||
---
|
||||
|
||||
You are a meticulous senior code reviewer focused on finding issues before they reach production. You review code with a critical eye for correctness, patterns, security, and maintainability.
|
||||
|
||||
## Your Mission
|
||||
|
||||
Review the implemented code and identify:
|
||||
1. Bugs and potential errors
|
||||
2. Pattern violations
|
||||
3. Security vulnerabilities
|
||||
4. Performance issues
|
||||
5. Maintainability concerns
|
||||
|
||||
## Input You'll Receive
|
||||
|
||||
- Spec and plan context
|
||||
- List of modified files
|
||||
- Previous iteration results (if any)
|
||||
|
||||
## Review Process
|
||||
|
||||
### 1. Understand Context
|
||||
|
||||
- Read the spec to understand intent
|
||||
- Review the plan to understand approach
|
||||
- Check previous issues (if iterating)
|
||||
|
||||
### 2. Review Each File
|
||||
|
||||
For each modified file:
|
||||
|
||||
**Read the changes carefully:**
|
||||
```
|
||||
Read file: path/to/modified/file.ts
|
||||
```
|
||||
|
||||
**Check against categories:**
|
||||
|
||||
#### Correctness
|
||||
- Logic errors
|
||||
- Off-by-one errors
|
||||
- Null/undefined handling
|
||||
- Type mismatches
|
||||
- Race conditions
|
||||
- Edge cases not handled
|
||||
|
||||
#### Pattern Compliance
|
||||
- Does it follow existing conventions?
|
||||
- Is error handling consistent?
|
||||
- Are abstractions appropriate?
|
||||
- Is naming consistent?
|
||||
|
||||
#### Security
|
||||
- Input validation present?
|
||||
- SQL/NoSQL injection risks?
|
||||
- XSS vulnerabilities?
|
||||
- Auth/authz properly checked?
|
||||
- Sensitive data exposed?
|
||||
|
||||
#### Performance
|
||||
- Unnecessary loops?
|
||||
- N+1 query patterns?
|
||||
- Missing indexes (DB)?
|
||||
- Memory leaks?
|
||||
- Blocking operations?
|
||||
|
||||
#### Maintainability
|
||||
- Is code readable?
|
||||
- Are there DRY violations?
|
||||
- Complex conditionals?
|
||||
- Missing error messages?
|
||||
- Unclear variable names?
|
||||
|
||||
### 3. Classify Issues
|
||||
|
||||
Assign severity to each issue:
|
||||
|
||||
| Severity | Meaning | Action |
|
||||
|----------|---------|--------|
|
||||
| `error` | Must fix before shipping | Block deployment |
|
||||
| `warning` | Should fix, quality issue | Fix recommended |
|
||||
| `info` | Nice to fix, minor | Optional improvement |
|
||||
|
||||
### 4. Provide Output
|
||||
|
||||
Return a structured review:
|
||||
|
||||
```json
|
||||
{
|
||||
"summary": "Found 3 issues (1 error, 1 warning, 1 info)",
|
||||
"files_reviewed": [
|
||||
"src/api/users.ts",
|
||||
"src/types/user.ts"
|
||||
],
|
||||
"issues": [
|
||||
{
|
||||
"severity": "error",
|
||||
"category": "correctness",
|
||||
"file": "src/api/users.ts",
|
||||
"line": 42,
|
||||
"code": "const x = data.value",
|
||||
"description": "Potential null dereference - 'data' could be undefined when API returns 404",
|
||||
"suggestion": "Add null check: const x = data?.value ?? defaultValue",
|
||||
"reference": "Spec requires handling missing data case"
|
||||
},
|
||||
{
|
||||
"severity": "warning",
|
||||
"category": "patterns",
|
||||
"file": "src/types/user.ts",
|
||||
"line": 15,
|
||||
"code": "interface User {",
|
||||
"description": "Interface missing JSDoc comments, unlike other interfaces in this file",
|
||||
"suggestion": "Add JSDoc: /** @description User data from API */",
|
||||
"reference": "See src/types/auth.ts for pattern"
|
||||
},
|
||||
{
|
||||
"severity": "info",
|
||||
"category": "maintainability",
|
||||
"file": "src/api/users.ts",
|
||||
"line": 30,
|
||||
"code": "let result = []",
|
||||
"description": "Could use const instead of let since array is not reassigned",
|
||||
"suggestion": "Change to: const result = []",
|
||||
"reference": null
|
||||
}
|
||||
],
|
||||
"passed_checks": [
|
||||
"No SQL injection vulnerabilities found",
|
||||
"Error handling follows existing patterns",
|
||||
"Types are properly defined",
|
||||
"No obvious performance issues"
|
||||
],
|
||||
"recommendations": [
|
||||
"Consider adding unit tests for the new getUserStats function",
|
||||
"The error messages could be more descriptive for debugging"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Review Checklist
|
||||
|
||||
### For Every File
|
||||
- [ ] All new functions have proper error handling
|
||||
- [ ] Types are correct and complete
|
||||
- [ ] No hardcoded values that should be config
|
||||
- [ ] No console.log or debug code left in
|
||||
- [ ] Imports are used (no dead imports)
|
||||
|
||||
### For API Changes
|
||||
- [ ] Input validation present
|
||||
- [ ] Auth check in place
|
||||
- [ ] Response format matches spec
|
||||
- [ ] Error responses are consistent
|
||||
|
||||
### For Database Changes
|
||||
- [ ] Queries are parameterized
|
||||
- [ ] Transactions used where needed
|
||||
- [ ] Indexes considered for new queries
|
||||
|
||||
### For Frontend Changes
|
||||
- [ ] No XSS vulnerabilities
|
||||
- [ ] Loading states handled
|
||||
- [ ] Error states handled
|
||||
- [ ] Accessibility considered
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Be specific about line numbers and exact code
|
||||
- Provide actionable suggestions, not just complaints
|
||||
- Reference existing code when pointing out pattern violations
|
||||
- Don't flag style preferences as errors
|
||||
- If code looks correct, say so in passed_checks
|
||||
174
plugin/agents/spec-writer.md
Normal file
174
plugin/agents/spec-writer.md
Normal file
@@ -0,0 +1,174 @@
|
||||
---
|
||||
name: spec-writer
|
||||
description: Creates detailed feature specifications by analyzing requirements and existing codebase patterns. Use this agent when running /ab:spec to generate comprehensive specs.
|
||||
model: sonnet
|
||||
color: blue
|
||||
---
|
||||
|
||||
You are a senior technical product manager and software architect who creates precise, actionable feature specifications.
|
||||
|
||||
## Your Mission
|
||||
|
||||
Create a comprehensive specification document that:
|
||||
1. Clearly defines what should be built
|
||||
2. Maps to existing codebase patterns
|
||||
3. Identifies all edge cases and requirements
|
||||
4. Provides clear acceptance criteria
|
||||
|
||||
## Input You'll Receive
|
||||
|
||||
- Feature name and description
|
||||
- User requirements (answers to discovery questions)
|
||||
- Instructions to analyze the codebase
|
||||
|
||||
## Analysis Process
|
||||
|
||||
### 0. Context Integration (PRIORITY)
|
||||
|
||||
Before analyzing the codebase, extract project context:
|
||||
|
||||
1. **Read CLAUDE.md** (auto-loaded in context):
|
||||
- Extract Development Standards
|
||||
- Extract Boundaries (Always/Ask/Never)
|
||||
- Extract Common Commands
|
||||
- Extract Tech Stack
|
||||
|
||||
2. **Read .claude/rules/auto-build-memory.md**:
|
||||
- Review learned patterns from past features
|
||||
- Review known gotchas and solutions
|
||||
- Apply relevant patterns to this feature
|
||||
|
||||
3. **Apply Context to Spec**:
|
||||
- Ensure spec follows established patterns
|
||||
- Respect project boundaries
|
||||
- Use correct tech stack conventions
|
||||
- Reference known gotchas in "Risks" section
|
||||
- Include relevant commands in examples
|
||||
|
||||
This ensures the spec is **contextually aware** and aligned with project conventions.
|
||||
|
||||
### 1. Understand the Request
|
||||
- Parse the feature description
|
||||
- Identify core functionality vs nice-to-haves
|
||||
- List any ambiguities or questions
|
||||
|
||||
### 2. Codebase Analysis
|
||||
|
||||
Use these tools to understand the project:
|
||||
|
||||
**Find similar features:**
|
||||
```
|
||||
Glob: **/*.{ts,vue,py}
|
||||
Grep: patterns related to feature description
|
||||
```
|
||||
|
||||
**Identify conventions:**
|
||||
- Directory structure patterns
|
||||
- Naming conventions
|
||||
- Error handling approach
|
||||
- Testing patterns
|
||||
|
||||
**Map dependencies:**
|
||||
- Which modules will be affected
|
||||
- External integrations needed
|
||||
- Database/API changes required
|
||||
|
||||
### 3. Create Specification
|
||||
|
||||
Generate a spec.md following this structure:
|
||||
|
||||
```markdown
|
||||
# Feature: {name}
|
||||
|
||||
## Overview
|
||||
[2-3 sentences describing the feature and its value]
|
||||
|
||||
## Problem Statement
|
||||
[What problem does this solve? Who benefits?]
|
||||
|
||||
## User Stories
|
||||
- As a [user type], I want [action] so that [benefit]
|
||||
- As a [user type], I want [action] so that [benefit]
|
||||
|
||||
## Functional Requirements
|
||||
|
||||
### Core Requirements
|
||||
1. [Must-have requirement 1]
|
||||
2. [Must-have requirement 2]
|
||||
|
||||
### Secondary Requirements
|
||||
1. [Nice-to-have requirement 1]
|
||||
|
||||
## Technical Requirements
|
||||
|
||||
### Files to Modify
|
||||
| File | Changes |
|
||||
|------|---------|
|
||||
| path/to/file.ts | Add X, modify Y |
|
||||
|
||||
### New Files to Create
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| path/to/new.ts | Description |
|
||||
|
||||
### Dependencies
|
||||
- [Existing module to use]
|
||||
- [New dependency if needed]
|
||||
|
||||
### Database Changes
|
||||
[None / Describe changes]
|
||||
|
||||
### API Changes
|
||||
[None / Describe new endpoints or modifications]
|
||||
|
||||
## Design Decisions
|
||||
|
||||
### Approach
|
||||
[Why this approach was chosen]
|
||||
|
||||
### Alternatives Considered
|
||||
[What other approaches were considered and why rejected]
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] [Testable criterion 1]
|
||||
- [ ] [Testable criterion 2]
|
||||
- [ ] [Testable criterion 3]
|
||||
|
||||
## Out of Scope
|
||||
- [Explicitly what is NOT included]
|
||||
- [Future enhancements to consider later]
|
||||
|
||||
## Risks and Mitigations
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|------|------------|--------|------------|
|
||||
| [Risk 1] | Medium | High | [How to mitigate] |
|
||||
|
||||
## Open Questions
|
||||
- [Any unresolved questions that need clarification]
|
||||
|
||||
## Estimated Complexity
|
||||
[Low / Medium / High] - [Brief justification]
|
||||
```
|
||||
|
||||
### 4. Return Summary
|
||||
|
||||
After creating the spec, provide:
|
||||
1. Path to the created spec file
|
||||
2. Summary of key requirements (3-5 bullet points)
|
||||
3. List of 5-10 critical files that will be affected
|
||||
4. Estimated complexity with justification
|
||||
|
||||
## Quality Standards
|
||||
|
||||
- Be specific, not vague
|
||||
- Include concrete file paths
|
||||
- Reference existing patterns by example
|
||||
- Make acceptance criteria testable
|
||||
- Keep scope focused and achievable
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Focus on WHAT, not HOW (implementation details come in planning)
|
||||
- Identify risks early
|
||||
- Flag any requirements that seem contradictory
|
||||
- Suggest scope reductions if feature seems too large
|
||||
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
|
||||
9
plugin/hooks/hooks.json
Normal file
9
plugin/hooks/hooks.json
Normal file
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"hooks": [
|
||||
{
|
||||
"name": "post-install",
|
||||
"script": "./hooks/post-install.sh",
|
||||
"description": "Initialize CLAUDE.md and Auto-Build rules in project"
|
||||
}
|
||||
]
|
||||
}
|
||||
86
plugin/hooks/post-install.sh
Normal file
86
plugin/hooks/post-install.sh
Normal file
@@ -0,0 +1,86 @@
|
||||
#!/bin/bash
|
||||
# Post-install hook - runs after plugin installation
|
||||
set -e
|
||||
|
||||
PROJECT_ROOT="$(pwd)"
|
||||
PLUGIN_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
|
||||
|
||||
echo "========================================"
|
||||
echo " Auto-Build Post-Install"
|
||||
echo "========================================"
|
||||
echo ""
|
||||
echo "Project: $PROJECT_ROOT"
|
||||
echo ""
|
||||
|
||||
# 1. Create .claude/rules/ if missing
|
||||
mkdir -p "$PROJECT_ROOT/.claude/rules"
|
||||
|
||||
# 2. Copy auto-build-patterns.md to project
|
||||
echo "Installing Auto-Build patterns..."
|
||||
cp "$PLUGIN_DIR/rules/auto-build-patterns.md" "$PROJECT_ROOT/.claude/rules/"
|
||||
|
||||
# 3. Create empty auto-build-memory.md (will be populated by /ab:memory-save)
|
||||
echo "# Auto-Build Learned Patterns
|
||||
|
||||
Last updated: Never
|
||||
|
||||
(This file is automatically updated by /ab:memory-save)" > "$PROJECT_ROOT/.claude/rules/auto-build-memory.md"
|
||||
|
||||
# 4. Create .auto-build-data/ structure
|
||||
echo "Creating .auto-build-data/ structure..."
|
||||
mkdir -p "$PROJECT_ROOT/.auto-build-data"/{specs,worktrees,memory/sessions,cache/qa-iterations}
|
||||
|
||||
# Initialize memory files
|
||||
echo '{"patterns": [], "updated": null}' > "$PROJECT_ROOT/.auto-build-data/memory/patterns.json"
|
||||
echo '{"gotchas": [], "updated": null}' > "$PROJECT_ROOT/.auto-build-data/memory/gotchas.json"
|
||||
echo '{"worktrees": []}' > "$PROJECT_ROOT/.auto-build-data/worktrees/worktree-registry.json"
|
||||
|
||||
# 5. Add .auto-build-data/ to .gitignore if not present
|
||||
if [ -f "$PROJECT_ROOT/.gitignore" ]; then
|
||||
if ! grep -q "^\.auto-build-data/" "$PROJECT_ROOT/.gitignore" 2>/dev/null; then
|
||||
echo "" >> "$PROJECT_ROOT/.gitignore"
|
||||
echo "# Auto-Build runtime data (local only)" >> "$PROJECT_ROOT/.gitignore"
|
||||
echo ".auto-build-data/" >> "$PROJECT_ROOT/.gitignore"
|
||||
echo "Added .auto-build-data/ to .gitignore"
|
||||
fi
|
||||
else
|
||||
echo "# Auto-Build runtime data (local only)" > "$PROJECT_ROOT/.gitignore"
|
||||
echo ".auto-build-data/" >> "$PROJECT_ROOT/.gitignore"
|
||||
echo "Created .gitignore with .auto-build-data/ entry"
|
||||
fi
|
||||
|
||||
# 6. Initialize or update CLAUDE.md
|
||||
if [ ! -f "$PROJECT_ROOT/CLAUDE.md" ]; then
|
||||
echo "Generating CLAUDE.md from template..."
|
||||
cp "$PLUGIN_DIR/templates/CLAUDE.md.template" "$PROJECT_ROOT/CLAUDE.md"
|
||||
echo "✅ Created CLAUDE.md"
|
||||
else
|
||||
# Add Auto-Build imports if not present
|
||||
if ! grep -q "auto-build-patterns.md" "$PROJECT_ROOT/CLAUDE.md"; then
|
||||
echo "" >> "$PROJECT_ROOT/CLAUDE.md"
|
||||
echo "# Auto-Build Integration" >> "$PROJECT_ROOT/CLAUDE.md"
|
||||
echo "@./.claude/rules/auto-build-patterns.md" >> "$PROJECT_ROOT/CLAUDE.md"
|
||||
echo "@./.claude/rules/auto-build-memory.md" >> "$PROJECT_ROOT/CLAUDE.md"
|
||||
echo "✅ Updated CLAUDE.md with Auto-Build imports"
|
||||
else
|
||||
echo "⚠️ CLAUDE.md already has Auto-Build imports"
|
||||
fi
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "========================================"
|
||||
echo " Installation Complete!"
|
||||
echo "========================================"
|
||||
echo ""
|
||||
echo "What was installed:"
|
||||
echo " ✅ .claude/rules/auto-build-patterns.md"
|
||||
echo " ✅ .claude/rules/auto-build-memory.md"
|
||||
echo " ✅ .auto-build-data/ structure"
|
||||
echo " ✅ CLAUDE.md (created or updated)"
|
||||
echo " ✅ .gitignore updated"
|
||||
echo ""
|
||||
echo "Quick Start:"
|
||||
echo " 1. Restart Claude Code to load CLAUDE.md"
|
||||
echo " 2. Run /ab:help for available commands"
|
||||
echo " 3. Create your first spec: /ab:spec \"My Feature\""
|
||||
echo ""
|
||||
110
plugin/rules/auto-build-patterns.md
Normal file
110
plugin/rules/auto-build-patterns.md
Normal file
@@ -0,0 +1,110 @@
|
||||
---
|
||||
paths: .auto-build/**/*
|
||||
---
|
||||
|
||||
# Auto-Build Patterns and Rules
|
||||
|
||||
These rules apply to all Auto-Build related files and workflows.
|
||||
|
||||
## Core Principles
|
||||
|
||||
### 1. Portability First
|
||||
- All paths must be relative or dynamically determined
|
||||
- No hardcoded project-specific values in .auto-build/
|
||||
- Data lives in .auto-build-data/ which is gitignored
|
||||
|
||||
### 2. Minimal Footprint
|
||||
- Never modify files outside the current task scope
|
||||
- Keep changes focused and reversible
|
||||
- Prefer editing existing files over creating new ones
|
||||
|
||||
### 3. Pattern Consistency
|
||||
- Match existing codebase patterns exactly
|
||||
- Use the same error handling approach throughout
|
||||
- Follow naming conventions from the host project
|
||||
|
||||
## Command Execution Rules
|
||||
|
||||
### When Running /ab:spec
|
||||
- Always analyze the codebase before writing spec
|
||||
- Include at least 3 acceptance criteria
|
||||
- Identify affected files explicitly
|
||||
- Save to .auto-build-data/specs/{name}/
|
||||
|
||||
### When Running /ab:build
|
||||
- Check for existing spec before proceeding
|
||||
- Offer worktree creation for multi-file changes
|
||||
- Track progress in status.json after each task
|
||||
- Never skip the planning phase
|
||||
|
||||
### When Running /ab:qa-review
|
||||
- Review all modified files from the build
|
||||
- Classify issues by severity (error/warning/info)
|
||||
- Stop at 50 iterations to prevent infinite loops
|
||||
- Save iteration history for debugging
|
||||
|
||||
### When Running Memory Commands
|
||||
- Deduplicate entries before saving
|
||||
- Keep patterns.json under 100 entries
|
||||
- Always include tags for searchability
|
||||
- Update usageCount when patterns are referenced
|
||||
|
||||
## Agent Guidelines
|
||||
|
||||
### spec-writer Agent
|
||||
- Focus on WHAT, not HOW
|
||||
- Include out-of-scope section
|
||||
- Map to existing codebase patterns
|
||||
- Flag risks and open questions
|
||||
|
||||
### planner Agent
|
||||
- Create atomic, testable tasks
|
||||
- Explicit dependencies between tasks
|
||||
- First task is always setup/scaffolding
|
||||
- Include testing as explicit tasks
|
||||
|
||||
### coder Agent
|
||||
- Read files before modifying
|
||||
- Match existing code style
|
||||
- Handle all error cases from spec
|
||||
- Report changes made clearly
|
||||
|
||||
### qa-reviewer Agent
|
||||
- Check correctness, patterns, security, performance
|
||||
- Provide actionable suggestions
|
||||
- Reference existing code for patterns
|
||||
- Don't flag style preferences as errors
|
||||
|
||||
### qa-fixer Agent
|
||||
- Make minimal changes only
|
||||
- Don't refactor beyond the fix
|
||||
- Verify fix doesn't introduce new issues
|
||||
- Escalate if fix is not straightforward
|
||||
|
||||
## File Formats
|
||||
|
||||
### status.json States
|
||||
```
|
||||
SPEC_DRAFT → SPEC_COMPLETE → PLANNING → PLANNING_COMPLETE →
|
||||
IMPLEMENTING → IMPLEMENTATION_COMPLETE → QA_REVIEW → COMPLETE
|
||||
```
|
||||
|
||||
### Memory Files
|
||||
- patterns.json: Reusable code patterns
|
||||
- gotchas.json: Problems and solutions
|
||||
- codebase-map.json: Structural insights
|
||||
- sessions/*.json: Session history
|
||||
|
||||
## Git Worktree Rules
|
||||
|
||||
- Create worktrees outside project: ../ab-worktrees/
|
||||
- Branch naming: feature/ab-{feature-name}
|
||||
- Registry tracking in worktree-registry.json
|
||||
- Cleanup only merged branches automatically
|
||||
|
||||
## Error Handling
|
||||
|
||||
- Log errors with context
|
||||
- Provide recovery instructions
|
||||
- Never leave status in inconsistent state
|
||||
- Offer rollback options when appropriate
|
||||
108
plugin/scripts/worktree-cleanup.sh
Normal file
108
plugin/scripts/worktree-cleanup.sh
Normal file
@@ -0,0 +1,108 @@
|
||||
#!/bin/bash
|
||||
# Cleanup git worktrees
|
||||
# Usage: worktree-cleanup.sh [feature-name]
|
||||
# If no feature-name provided, lists candidates for cleanup
|
||||
|
||||
set -e
|
||||
|
||||
FEATURE_NAME="$1"
|
||||
|
||||
# Get project root (parent of .auto-build)
|
||||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
PROJECT_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
|
||||
PROJECT_NAME=$(basename "$PROJECT_ROOT")
|
||||
WORKTREES_DIR="$(dirname "$PROJECT_ROOT")/ab-worktrees"
|
||||
|
||||
echo "========================================"
|
||||
echo " Worktree Cleanup"
|
||||
echo "========================================"
|
||||
echo ""
|
||||
|
||||
cd "$PROJECT_ROOT"
|
||||
|
||||
# If specific feature provided, cleanup that one
|
||||
if [ -n "$FEATURE_NAME" ]; then
|
||||
BRANCH_NAME="feature/ab-${FEATURE_NAME}"
|
||||
WORKTREE_PATH="${WORKTREES_DIR}/${PROJECT_NAME}-${FEATURE_NAME}"
|
||||
|
||||
echo "Cleaning up: $FEATURE_NAME"
|
||||
echo " Branch: $BRANCH_NAME"
|
||||
echo " Path: $WORKTREE_PATH"
|
||||
echo ""
|
||||
|
||||
# Check if worktree exists
|
||||
if [ ! -d "$WORKTREE_PATH" ]; then
|
||||
echo "Worktree not found at: $WORKTREE_PATH"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Check if branch is merged
|
||||
MAIN_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "main")
|
||||
|
||||
if git branch --merged "$MAIN_BRANCH" | grep -q "$BRANCH_NAME"; then
|
||||
echo "Branch is merged to $MAIN_BRANCH"
|
||||
else
|
||||
echo "Warning: Branch is NOT merged to $MAIN_BRANCH"
|
||||
echo "Proceed with cleanup? (y/n)"
|
||||
read -r CONFIRM
|
||||
if [ "$CONFIRM" != "y" ]; then
|
||||
echo "Aborted"
|
||||
exit 0
|
||||
fi
|
||||
fi
|
||||
|
||||
# Remove worktree
|
||||
echo "Removing worktree..."
|
||||
git worktree remove "$WORKTREE_PATH" --force
|
||||
|
||||
# Remove branch
|
||||
echo "Removing branch..."
|
||||
git branch -D "$BRANCH_NAME" 2>/dev/null || echo "Branch already removed or doesn't exist"
|
||||
|
||||
# Update registry
|
||||
REGISTRY_FILE="$PROJECT_ROOT/.auto-build-data/worktrees/worktree-registry.json"
|
||||
if [ -f "$REGISTRY_FILE" ] && command -v jq &> /dev/null; then
|
||||
TEMP_FILE=$(mktemp)
|
||||
jq --arg name "$FEATURE_NAME" '.worktrees |= map(select(.name != $name))' "$REGISTRY_FILE" > "$TEMP_FILE" && mv "$TEMP_FILE" "$REGISTRY_FILE"
|
||||
echo "Registry updated"
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "Cleanup complete!"
|
||||
|
||||
else
|
||||
# List all worktrees and show which can be cleaned up
|
||||
echo "Checking worktrees for cleanup..."
|
||||
echo ""
|
||||
|
||||
MAIN_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "main")
|
||||
|
||||
echo "Merged branches (safe to cleanup):"
|
||||
MERGED_BRANCHES=$(git branch --merged "$MAIN_BRANCH" | grep "feature/ab-" || echo "")
|
||||
|
||||
if [ -n "$MERGED_BRANCHES" ]; then
|
||||
echo "$MERGED_BRANCHES" | while read -r branch; do
|
||||
FEATURE=$(echo "$branch" | sed 's/.*feature\/ab-//')
|
||||
echo " - $FEATURE"
|
||||
done
|
||||
else
|
||||
echo " (none)"
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "Unmerged branches:"
|
||||
UNMERGED_BRANCHES=$(git branch --no-merged "$MAIN_BRANCH" | grep "feature/ab-" || echo "")
|
||||
|
||||
if [ -n "$UNMERGED_BRANCHES" ]; then
|
||||
echo "$UNMERGED_BRANCHES" | while read -r branch; do
|
||||
FEATURE=$(echo "$branch" | sed 's/.*feature\/ab-//')
|
||||
echo " - $FEATURE (NOT merged)"
|
||||
done
|
||||
else
|
||||
echo " (none)"
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "To cleanup a specific worktree:"
|
||||
echo " bash .auto-build/scripts/worktree-cleanup.sh <feature-name>"
|
||||
fi
|
||||
111
plugin/scripts/worktree-create.sh
Normal file
111
plugin/scripts/worktree-create.sh
Normal file
@@ -0,0 +1,111 @@
|
||||
#!/bin/bash
|
||||
# Create a git worktree for feature isolation
|
||||
# Usage: worktree-create.sh <feature-name>
|
||||
|
||||
set -e
|
||||
|
||||
FEATURE_NAME="$1"
|
||||
|
||||
if [ -z "$FEATURE_NAME" ]; then
|
||||
echo "Error: Feature name required"
|
||||
echo "Usage: worktree-create.sh <feature-name>"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Get project root (parent of .auto-build)
|
||||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
PROJECT_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
|
||||
PROJECT_NAME=$(basename "$PROJECT_ROOT")
|
||||
|
||||
# Define paths
|
||||
BRANCH_NAME="feature/ab-${FEATURE_NAME}"
|
||||
WORKTREES_DIR="$(dirname "$PROJECT_ROOT")/ab-worktrees"
|
||||
WORKTREE_PATH="${WORKTREES_DIR}/${PROJECT_NAME}-${FEATURE_NAME}"
|
||||
|
||||
echo "========================================"
|
||||
echo " Creating Git Worktree"
|
||||
echo "========================================"
|
||||
echo ""
|
||||
echo "Feature: $FEATURE_NAME"
|
||||
echo "Branch: $BRANCH_NAME"
|
||||
echo "Path: $WORKTREE_PATH"
|
||||
echo ""
|
||||
|
||||
# Check if we're in a git repository
|
||||
if ! git -C "$PROJECT_ROOT" rev-parse --git-dir > /dev/null 2>&1; then
|
||||
echo "Error: Not a git repository"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Check for uncommitted changes
|
||||
if ! git -C "$PROJECT_ROOT" diff-index --quiet HEAD -- 2>/dev/null; then
|
||||
echo "Warning: You have uncommitted changes in the main repository"
|
||||
echo ""
|
||||
fi
|
||||
|
||||
# Create worktrees directory if needed
|
||||
mkdir -p "$WORKTREES_DIR"
|
||||
|
||||
# Create branch if it doesn't exist
|
||||
cd "$PROJECT_ROOT"
|
||||
if git show-ref --verify --quiet "refs/heads/${BRANCH_NAME}"; then
|
||||
echo "Branch already exists: ${BRANCH_NAME}"
|
||||
else
|
||||
echo "Creating branch: ${BRANCH_NAME}"
|
||||
git branch "${BRANCH_NAME}"
|
||||
fi
|
||||
|
||||
# Check if worktree already exists
|
||||
if [ -d "$WORKTREE_PATH" ]; then
|
||||
echo "Error: Worktree directory already exists: $WORKTREE_PATH"
|
||||
echo "Use 'git worktree remove' to clean up first, or choose a different name"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Create worktree
|
||||
echo "Creating worktree..."
|
||||
git worktree add "$WORKTREE_PATH" "$BRANCH_NAME"
|
||||
|
||||
# Update registry
|
||||
REGISTRY_FILE="$PROJECT_ROOT/.auto-build-data/worktrees/worktree-registry.json"
|
||||
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
|
||||
|
||||
if [ -f "$REGISTRY_FILE" ]; then
|
||||
# Add to existing registry using jq if available, otherwise use simple append
|
||||
if command -v jq &> /dev/null; then
|
||||
TEMP_FILE=$(mktemp)
|
||||
jq --arg name "$FEATURE_NAME" \
|
||||
--arg branch "$BRANCH_NAME" \
|
||||
--arg path "$WORKTREE_PATH" \
|
||||
--arg created "$TIMESTAMP" \
|
||||
'.worktrees += [{
|
||||
"name": $name,
|
||||
"branch": $branch,
|
||||
"path": $path,
|
||||
"created": $created,
|
||||
"status": "active"
|
||||
}]' "$REGISTRY_FILE" > "$TEMP_FILE" && mv "$TEMP_FILE" "$REGISTRY_FILE"
|
||||
else
|
||||
# Fallback: Just note the worktree was created
|
||||
echo "Note: Install jq for automatic registry updates"
|
||||
fi
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "========================================"
|
||||
echo " Worktree Created Successfully"
|
||||
echo "========================================"
|
||||
echo ""
|
||||
echo "To work in this worktree:"
|
||||
echo " cd $WORKTREE_PATH"
|
||||
echo ""
|
||||
echo "To return to main project:"
|
||||
echo " cd $PROJECT_ROOT"
|
||||
echo ""
|
||||
echo "When done with the feature:"
|
||||
echo " /ab:worktree cleanup $FEATURE_NAME"
|
||||
echo ""
|
||||
|
||||
# Output for script parsing
|
||||
echo "WORKTREE_CREATED=$WORKTREE_PATH"
|
||||
echo "BRANCH=$BRANCH_NAME"
|
||||
56
plugin/scripts/worktree-list.sh
Normal file
56
plugin/scripts/worktree-list.sh
Normal file
@@ -0,0 +1,56 @@
|
||||
#!/bin/bash
|
||||
# List all git worktrees
|
||||
# Usage: worktree-list.sh
|
||||
|
||||
set -e
|
||||
|
||||
# Get project root (parent of .auto-build)
|
||||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
PROJECT_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
|
||||
|
||||
echo "========================================"
|
||||
echo " Git Worktrees"
|
||||
echo "========================================"
|
||||
echo ""
|
||||
|
||||
# Check if we're in a git repository
|
||||
if ! git -C "$PROJECT_ROOT" rev-parse --git-dir > /dev/null 2>&1; then
|
||||
echo "Error: Not a git repository"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# List all worktrees from git
|
||||
echo "Active Worktrees:"
|
||||
echo ""
|
||||
|
||||
cd "$PROJECT_ROOT"
|
||||
WORKTREES=$(git worktree list --porcelain)
|
||||
|
||||
if [ -z "$WORKTREES" ]; then
|
||||
echo " No worktrees found"
|
||||
else
|
||||
git worktree list
|
||||
fi
|
||||
|
||||
echo ""
|
||||
|
||||
# Show registry info if available
|
||||
REGISTRY_FILE="$PROJECT_ROOT/.auto-build-data/worktrees/worktree-registry.json"
|
||||
|
||||
if [ -f "$REGISTRY_FILE" ]; then
|
||||
echo "Auto-Build Registry:"
|
||||
echo ""
|
||||
|
||||
if command -v jq &> /dev/null; then
|
||||
jq -r '.worktrees[] | " \(.name) (\(.status))\n Branch: \(.branch)\n Path: \(.path)\n Created: \(.created)\n"' "$REGISTRY_FILE" 2>/dev/null || echo " (empty)"
|
||||
else
|
||||
cat "$REGISTRY_FILE"
|
||||
fi
|
||||
else
|
||||
echo "Registry not found. Run /ab:worktree create first."
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "Commands:"
|
||||
echo " Create: /ab:worktree create <name>"
|
||||
echo " Cleanup: /ab:worktree cleanup [name]"
|
||||
49
plugin/scripts/worktree-switch.sh
Normal file
49
plugin/scripts/worktree-switch.sh
Normal file
@@ -0,0 +1,49 @@
|
||||
#!/bin/bash
|
||||
# Show instructions for switching to a worktree
|
||||
# Usage: worktree-switch.sh <feature-name>
|
||||
|
||||
set -e
|
||||
|
||||
FEATURE_NAME="$1"
|
||||
|
||||
# Get project root (parent of .auto-build)
|
||||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
PROJECT_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
|
||||
PROJECT_NAME=$(basename "$PROJECT_ROOT")
|
||||
WORKTREES_DIR="$(dirname "$PROJECT_ROOT")/ab-worktrees"
|
||||
|
||||
if [ -z "$FEATURE_NAME" ]; then
|
||||
echo "Error: Feature name required"
|
||||
echo "Usage: worktree-switch.sh <feature-name>"
|
||||
echo ""
|
||||
echo "Available worktrees:"
|
||||
ls -1 "$WORKTREES_DIR" 2>/dev/null | grep "^${PROJECT_NAME}-" | sed "s/${PROJECT_NAME}-/ /" || echo " (none)"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
WORKTREE_PATH="${WORKTREES_DIR}/${PROJECT_NAME}-${FEATURE_NAME}"
|
||||
|
||||
if [ ! -d "$WORKTREE_PATH" ]; then
|
||||
echo "Error: Worktree not found at: $WORKTREE_PATH"
|
||||
echo ""
|
||||
echo "Available worktrees:"
|
||||
ls -1 "$WORKTREES_DIR" 2>/dev/null | grep "^${PROJECT_NAME}-" | sed "s/${PROJECT_NAME}-/ /" || echo " (none)"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "========================================"
|
||||
echo " Switch to Worktree"
|
||||
echo "========================================"
|
||||
echo ""
|
||||
echo "Feature: $FEATURE_NAME"
|
||||
echo "Path: $WORKTREE_PATH"
|
||||
echo ""
|
||||
echo "To switch to this worktree, run:"
|
||||
echo ""
|
||||
echo " cd $WORKTREE_PATH"
|
||||
echo ""
|
||||
echo "Or start a new terminal/Claude Code session in that directory."
|
||||
echo ""
|
||||
echo "To return to main project:"
|
||||
echo " cd $PROJECT_ROOT"
|
||||
echo ""
|
||||
70
plugin/templates/CLAUDE.md.template
Normal file
70
plugin/templates/CLAUDE.md.template
Normal file
@@ -0,0 +1,70 @@
|
||||
# Project Context
|
||||
|
||||
## About
|
||||
[Brief description of this project]
|
||||
|
||||
## Tech Stack
|
||||
- **Language**: [e.g., Python 3.11, TypeScript 5.0]
|
||||
- **Framework**: [e.g., FastAPI, React, Vue.js]
|
||||
- **Build Tool**: [e.g., npm, poetry, gradle]
|
||||
- **Testing**: [e.g., pytest, vitest, jest]
|
||||
- **Database**: [e.g., PostgreSQL, Oracle, SQLite]
|
||||
|
||||
## Project Structure
|
||||
```
|
||||
/src # Source code
|
||||
/tests # Test files
|
||||
/docs # Documentation
|
||||
/config # Configuration
|
||||
```
|
||||
|
||||
## Common Commands
|
||||
```bash
|
||||
# Development
|
||||
npm run dev # Start dev server
|
||||
npm test # Run tests
|
||||
|
||||
# Build
|
||||
npm run build # Production build
|
||||
```
|
||||
|
||||
## Development Standards
|
||||
- [Add your coding standards here]
|
||||
- Use type annotations
|
||||
- Write tests for new features
|
||||
|
||||
## Workflows
|
||||
|
||||
### Feature Development
|
||||
1. Create feature branch: `git checkout -b feature/name`
|
||||
2. Write tests first (TDD)
|
||||
3. Implement feature
|
||||
4. Run tests and linting
|
||||
5. Create PR
|
||||
|
||||
## Boundaries
|
||||
|
||||
✅ **Always:**
|
||||
- Write tests for new features
|
||||
- Use type annotations
|
||||
- Document public APIs
|
||||
|
||||
⚠️ **Ask First:**
|
||||
- Modifying database schema
|
||||
- Changing API contracts
|
||||
- Major architectural changes
|
||||
|
||||
🚫 **Never:**
|
||||
- Commit secrets/credentials
|
||||
- Delete failing tests
|
||||
- Bypass CI checks
|
||||
- Push directly to main/master
|
||||
|
||||
## Common Gotchas
|
||||
[Add project-specific gotchas as you discover them]
|
||||
|
||||
---
|
||||
|
||||
# Auto-Build Integration
|
||||
@./.claude/rules/auto-build-patterns.md
|
||||
@./.claude/rules/auto-build-memory.md
|
||||
53
plugin/templates/memory-entry-template.json
Normal file
53
plugin/templates/memory-entry-template.json
Normal file
@@ -0,0 +1,53 @@
|
||||
{
|
||||
"pattern": {
|
||||
"id": "pat_{{TIMESTAMP_ID}}",
|
||||
"timestamp": "{{ISO_TIMESTAMP}}",
|
||||
"title": "{{Pattern Title}}",
|
||||
"description": "{{Detailed description of the pattern}}",
|
||||
"context": "{{Where/when this pattern was discovered}}",
|
||||
"example": {
|
||||
"file": "{{path/to/example/file}}",
|
||||
"lines": "{{start}}-{{end}}",
|
||||
"snippet": "{{Code snippet demonstrating the pattern}}"
|
||||
},
|
||||
"tags": ["{{tag1}}", "{{tag2}}", "{{tag3}}"],
|
||||
"feature": "{{feature-name}}",
|
||||
"usageCount": 0
|
||||
},
|
||||
|
||||
"gotcha": {
|
||||
"id": "got_{{TIMESTAMP_ID}}",
|
||||
"timestamp": "{{ISO_TIMESTAMP}}",
|
||||
"title": "{{Issue Title}}",
|
||||
"problem": "{{Description of the problem encountered}}",
|
||||
"solution": "{{How to solve/avoid the problem}}",
|
||||
"context": "{{When/where this was encountered}}",
|
||||
"tags": ["{{tag1}}", "{{tag2}}"],
|
||||
"feature": "{{feature-name}}"
|
||||
},
|
||||
|
||||
"codebase": {
|
||||
"id": "cb_{{TIMESTAMP_ID}}",
|
||||
"timestamp": "{{ISO_TIMESTAMP}}",
|
||||
"path": "{{directory/path/}}",
|
||||
"insight": "{{Structural insight about this part of codebase}}",
|
||||
"examples": ["{{Example1}}", "{{Example2}}"],
|
||||
"tags": ["{{tag1}}", "{{tag2}}"]
|
||||
},
|
||||
|
||||
"session": {
|
||||
"session_id": "ses_{{TIMESTAMP_ID}}",
|
||||
"timestamp": "{{ISO_TIMESTAMP}}",
|
||||
"feature": "{{feature-name}}",
|
||||
"duration": "{{Xh Ym}}",
|
||||
"insights_saved": [
|
||||
{"type": "pattern", "id": "{{pattern_id}}"},
|
||||
{"type": "gotcha", "id": "{{gotcha_id}}"}
|
||||
],
|
||||
"files_modified": [
|
||||
"{{path/to/file1}}",
|
||||
"{{path/to/file2}}"
|
||||
],
|
||||
"summary": "{{Brief summary of what was accomplished}}"
|
||||
}
|
||||
}
|
||||
123
plugin/templates/plan-template.md
Normal file
123
plugin/templates/plan-template.md
Normal file
@@ -0,0 +1,123 @@
|
||||
# Implementation Plan: {{FEATURE_NAME}}
|
||||
|
||||
## Overview
|
||||
|
||||
{{Brief summary of the implementation approach}}
|
||||
|
||||
## Task Order Summary
|
||||
|
||||
```
|
||||
1. {{Task 1 title}} (no dependencies)
|
||||
2. {{Task 2 title}} (depends on 1)
|
||||
3. {{Task 3 title}} (depends on 1)
|
||||
4. {{Task 4 title}} (depends on 2, 3)
|
||||
...
|
||||
```
|
||||
|
||||
## Dependency Graph
|
||||
|
||||
```
|
||||
Task 1 ──┬──> Task 2 ──┬──> Task 5
|
||||
│ │
|
||||
└──> Task 3 ──┘
|
||||
│
|
||||
└──> Task 4 ──────> Task 5
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Detailed Tasks
|
||||
|
||||
### Task 1: {{Title}}
|
||||
|
||||
**Objective**: {{One sentence describing what this task accomplishes}}
|
||||
|
||||
**Files**:
|
||||
- `{{path/to/file1}}` - {{what to do}}
|
||||
- `{{path/to/file2}}` - {{what to do}}
|
||||
|
||||
**Steps**:
|
||||
1. {{Specific step 1}}
|
||||
2. {{Specific step 2}}
|
||||
3. {{Specific step 3}}
|
||||
|
||||
**Dependencies**: None
|
||||
|
||||
**Completion Criteria**:
|
||||
- [ ] {{How to verify this task is done}}
|
||||
- [ ] {{Another verification}}
|
||||
|
||||
**Patterns to Follow**:
|
||||
- See `{{existing/similar/file}}` for reference
|
||||
|
||||
---
|
||||
|
||||
### Task 2: {{Title}}
|
||||
|
||||
**Objective**: {{One sentence}}
|
||||
|
||||
**Files**:
|
||||
- `{{path/to/file}}` - {{what to do}}
|
||||
|
||||
**Steps**:
|
||||
1. {{Specific step 1}}
|
||||
2. {{Specific step 2}}
|
||||
|
||||
**Dependencies**: Task 1
|
||||
|
||||
**Completion Criteria**:
|
||||
- [ ] {{Verification method}}
|
||||
|
||||
**Patterns to Follow**:
|
||||
- {{Reference to existing pattern}}
|
||||
|
||||
---
|
||||
|
||||
### Task N: {{Title}}
|
||||
|
||||
**Objective**: {{One sentence}}
|
||||
|
||||
**Files**:
|
||||
- `{{path/to/file}}` - {{what to do}}
|
||||
|
||||
**Steps**:
|
||||
1. {{Specific step}}
|
||||
|
||||
**Dependencies**: {{List task numbers}}
|
||||
|
||||
**Completion Criteria**:
|
||||
- [ ] {{Verification}}
|
||||
|
||||
---
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### During Implementation
|
||||
|
||||
After each task, verify:
|
||||
- [ ] {{Quick check 1}}
|
||||
- [ ] {{Quick check 2}}
|
||||
|
||||
### Final Validation
|
||||
|
||||
- [ ] {{End-to-end test 1}}
|
||||
- [ ] {{End-to-end test 2}}
|
||||
- [ ] {{Manual verification step}}
|
||||
|
||||
## Risk Mitigation
|
||||
|
||||
| Risk | Detection | Response |
|
||||
|------|-----------|----------|
|
||||
| {{Risk from spec}} | {{How to detect early}} | {{What to do if it happens}} |
|
||||
|
||||
## Notes for Implementation
|
||||
|
||||
- {{Important consideration 1}}
|
||||
- {{Gotcha to watch out for}}
|
||||
- {{Pattern to follow consistently}}
|
||||
|
||||
---
|
||||
|
||||
*Generated by Auto-Build planner*
|
||||
*Date: {{TIMESTAMP}}*
|
||||
*Spec: {{SPEC_PATH}}*
|
||||
106
plugin/templates/spec-template.md
Normal file
106
plugin/templates/spec-template.md
Normal file
@@ -0,0 +1,106 @@
|
||||
# Feature: {{FEATURE_NAME}}
|
||||
|
||||
## Overview
|
||||
|
||||
{{Brief description of the feature and its value}}
|
||||
|
||||
## Problem Statement
|
||||
|
||||
{{What problem does this solve? Who benefits?}}
|
||||
|
||||
## User Stories
|
||||
|
||||
- As a {{user type}}, I want {{action}} so that {{benefit}}
|
||||
- As a {{user type}}, I want {{action}} so that {{benefit}}
|
||||
|
||||
## Functional Requirements
|
||||
|
||||
### Core Requirements (Must Have)
|
||||
|
||||
1. {{Requirement 1}}
|
||||
2. {{Requirement 2}}
|
||||
3. {{Requirement 3}}
|
||||
|
||||
### Secondary Requirements (Nice to Have)
|
||||
|
||||
1. {{Requirement 1}}
|
||||
2. {{Requirement 2}}
|
||||
|
||||
## Technical Requirements
|
||||
|
||||
### Files to Modify
|
||||
|
||||
| File | Changes |
|
||||
|------|---------|
|
||||
| `{{path/to/file1}}` | {{What to change}} |
|
||||
| `{{path/to/file2}}` | {{What to change}} |
|
||||
|
||||
### New Files to Create
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `{{path/to/new/file}}` | {{What this file does}} |
|
||||
|
||||
### Dependencies
|
||||
|
||||
- {{Existing module/library to use}}
|
||||
- {{New dependency if needed}}
|
||||
|
||||
### Database Changes
|
||||
|
||||
{{None / Describe any schema changes, migrations, or queries}}
|
||||
|
||||
### API Changes
|
||||
|
||||
{{None / Describe new endpoints or modifications to existing ones}}
|
||||
|
||||
## Design Decisions
|
||||
|
||||
### Chosen Approach
|
||||
|
||||
{{Why this approach was selected}}
|
||||
|
||||
### Alternatives Considered
|
||||
|
||||
| Alternative | Pros | Cons | Why Not Chosen |
|
||||
|-------------|------|------|----------------|
|
||||
| {{Option A}} | {{Pros}} | {{Cons}} | {{Reason}} |
|
||||
| {{Option B}} | {{Pros}} | {{Cons}} | {{Reason}} |
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] {{Testable criterion 1}}
|
||||
- [ ] {{Testable criterion 2}}
|
||||
- [ ] {{Testable criterion 3}}
|
||||
- [ ] {{Testable criterion 4}}
|
||||
|
||||
## Out of Scope
|
||||
|
||||
The following are explicitly NOT included in this feature:
|
||||
|
||||
- {{Item 1}}
|
||||
- {{Item 2}}
|
||||
- {{Future enhancement to consider later}}
|
||||
|
||||
## Risks and Mitigations
|
||||
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|------|------------|--------|------------|
|
||||
| {{Risk 1}} | Low/Medium/High | Low/Medium/High | {{How to mitigate}} |
|
||||
| {{Risk 2}} | Low/Medium/High | Low/Medium/High | {{How to mitigate}} |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- [ ] {{Question that needs clarification}}
|
||||
- [ ] {{Another open question}}
|
||||
|
||||
## Estimated Complexity
|
||||
|
||||
**{{Low / Medium / High}}**
|
||||
|
||||
Justification: {{Brief explanation of complexity assessment}}
|
||||
|
||||
---
|
||||
|
||||
*Generated by Auto-Build spec-writer*
|
||||
*Date: {{TIMESTAMP}}*
|
||||
Reference in New Issue
Block a user