Initial Auto-Build plugin structure
This commit is contained in:
18
.claude-plugin/marketplace.json
Normal file
18
.claude-plugin/marketplace.json
Normal file
@@ -0,0 +1,18 @@
|
|||||||
|
{
|
||||||
|
"name": "roa2web-tools",
|
||||||
|
"owner": {
|
||||||
|
"name": "ROA2WEB Team"
|
||||||
|
},
|
||||||
|
"metadata": {
|
||||||
|
"description": "Auto-Build plugin for spec-driven development workflows"
|
||||||
|
},
|
||||||
|
"plugins": [
|
||||||
|
{
|
||||||
|
"name": "auto-build",
|
||||||
|
"source": "./plugin",
|
||||||
|
"description": "Spec-driven build orchestration with git worktree isolation and session memory",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"keywords": ["build", "spec", "automation", "worktree", "qa"]
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
10
.gitignore
vendored
Normal file
10
.gitignore
vendored
Normal file
@@ -0,0 +1,10 @@
|
|||||||
|
# IDE
|
||||||
|
.vscode/
|
||||||
|
.idea/
|
||||||
|
|
||||||
|
# OS
|
||||||
|
.DS_Store
|
||||||
|
Thumbs.db
|
||||||
|
|
||||||
|
# Test data (if testing locally)
|
||||||
|
.auto-build-data/
|
||||||
21
LICENSE
Normal file
21
LICENSE
Normal file
@@ -0,0 +1,21 @@
|
|||||||
|
MIT License
|
||||||
|
|
||||||
|
Copyright (c) 2025 ROA2WEB Team
|
||||||
|
|
||||||
|
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||||
|
of this software and associated documentation files (the "Software"), to deal
|
||||||
|
in the Software without restriction, including without limitation the rights
|
||||||
|
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||||
|
copies of the Software, and to permit persons to whom the Software is
|
||||||
|
furnished to do so, subject to the following conditions:
|
||||||
|
|
||||||
|
The above copyright notice and this permission notice shall be included in all
|
||||||
|
copies or substantial portions of the Software.
|
||||||
|
|
||||||
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||||
|
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||||
|
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||||
|
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||||
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||||
|
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||||
|
SOFTWARE.
|
||||||
45
README.md
Normal file
45
README.md
Normal file
@@ -0,0 +1,45 @@
|
|||||||
|
# ROA2WEB Auto-Build Plugin Marketplace
|
||||||
|
|
||||||
|
Marketplace pentru plugin-ul Auto-Build - sistem de build orchestration bazat pe specificații.
|
||||||
|
|
||||||
|
## Instalare
|
||||||
|
|
||||||
|
### 1. Adaugă Marketplace
|
||||||
|
```bash
|
||||||
|
/plugin marketplace add https://gitea.romfast.ro/your-org/auto-build.git
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Instalează Plugin
|
||||||
|
```bash
|
||||||
|
/plugin install ab@roa2web-tools
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. Inițializare în Proiect
|
||||||
|
```bash
|
||||||
|
/ab:help
|
||||||
|
# Urmează instrucțiunile pentru setup
|
||||||
|
```
|
||||||
|
|
||||||
|
## Comenzi Disponibile
|
||||||
|
|
||||||
|
- `/ab:spec <name>` - Creează specificație feature
|
||||||
|
- `/ab:build <name>` - Build feature din spec
|
||||||
|
- `/ab:worktree <action>` - Gestionare git worktrees
|
||||||
|
- `/ab:qa-review` - QA validation loop
|
||||||
|
- `/ab:memory-save` - Salvează insights
|
||||||
|
- `/ab:memory-search <query>` - Caută patterns
|
||||||
|
- `/ab:status` - Status curent
|
||||||
|
- `/ab:help` - Ajutor detaliat
|
||||||
|
|
||||||
|
## Autentificare Gitea
|
||||||
|
|
||||||
|
Pentru access la Gitea privat, configurează Git credentials:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git config --global credential.helper store
|
||||||
|
git clone https://gitea.romfast.ro/test-repo # Autentifică o dată
|
||||||
|
```
|
||||||
|
|
||||||
|
## Documentație
|
||||||
|
|
||||||
|
Vezi `plugin/README.md` pentru detalii despre utilizare.
|
||||||
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