mirror of
https://github.com/eyaltoledano/claude-task-master.git
synced 2026-01-30 06:12:05 +00:00
feat: Hamster Integration - Cloud Storage, Sentry Telemetry, and Major CLI UX Improvements (#1452)
This commit is contained in:
Eyal Toledano
@@ -7,7 +7,7 @@
|
||||
```bash
|
||||
# Project Setup
|
||||
task-master init # Initialize Task Master in current project
|
||||
task-master parse-prd .taskmaster/docs/prd.txt # Generate tasks from PRD document
|
||||
task-master parse-prd .taskmaster/docs/prd.md # Generate tasks from PRD document
|
||||
task-master models --setup # Configure AI models interactively
|
||||
|
||||
# Daily Development Workflow
|
||||
@@ -40,10 +40,15 @@ task-master validate-dependencies # Check for depende
|
||||
|
||||
- `.taskmaster/tasks/tasks.json` - Main task data file (auto-managed)
|
||||
- `.taskmaster/config.json` - AI model configuration (use `task-master models` to modify)
|
||||
- `.taskmaster/docs/prd.txt` - Product Requirements Document for parsing
|
||||
- `.taskmaster/docs/prd.md` - Product Requirements Document for parsing (`.md` extension recommended for better editor support)
|
||||
- `.taskmaster/tasks/*.txt` - Individual task files (auto-generated from tasks.json)
|
||||
- `.env` - API keys for CLI usage
|
||||
|
||||
**PRD File Format:** While both `.txt` and `.md` extensions work, **`.md` is recommended** because:
|
||||
- Markdown syntax highlighting in editors improves readability
|
||||
- Proper rendering when previewing in VS Code, GitHub, or other tools
|
||||
- Better collaboration through formatted documentation
|
||||
|
||||
### Claude Code Integration Files
|
||||
|
||||
- `CLAUDE.md` - Auto-loaded context for Claude Code (this file)
|
||||
@@ -61,11 +66,11 @@ project/
|
||||
│ │ ├── task-1.md # Individual task files
|
||||
│ │ └── task-2.md
|
||||
│ ├── docs/ # Documentation directory
|
||||
│ │ ├── prd.txt # Product requirements
|
||||
│ │ ├── prd.md # Product requirements (.md recommended)
|
||||
│ ├── reports/ # Analysis reports directory
|
||||
│ │ └── task-complexity-report.json
|
||||
│ ├── templates/ # Template files
|
||||
│ │ └── example_prd.txt # Example PRD template
|
||||
│ │ └── example_prd.md # Example PRD template (.md recommended)
|
||||
│ └── config.json # AI models & settings
|
||||
├── .claude/
|
||||
│ ├── settings.json # Claude Code configuration
|
||||
@@ -137,8 +142,8 @@ complexity_report; // = task-master complexity-report
|
||||
# Initialize Task Master
|
||||
task-master init
|
||||
|
||||
# Create or obtain PRD, then parse it
|
||||
task-master parse-prd .taskmaster/docs/prd.txt
|
||||
# Create or obtain PRD, then parse it (use .md extension for better editor support)
|
||||
task-master parse-prd .taskmaster/docs/prd.md
|
||||
|
||||
# Analyze complexity and expand tasks
|
||||
task-master analyze-complexity --research
|
||||
|
||||
49
.taskmaster/ascii-art (6).txt
Normal file
49
.taskmaster/ascii-art (6).txt
Normal file
@@ -0,0 +1,49 @@
|
||||
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▒▓▓▓▓▓▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▒▒▓▒▓▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▒▒▒▒▒▒▒▒▓▓▓▒▒▓▒▒▓▓▓▓▓▓▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▒▒▒▒▒▒▒▒▒▒▓▒▓▓▒▓▒▓▓▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓████▓▓▓▓▓▓▓▒▒▒▓▓▓▒▓▓▓▓▓▓▓▒▓▓▓▓▓▓▓▓▓▓▓▓▓████████▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓█ ░░▓▓▒ ▒▓▓▓▓▒▒▒▓▓▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓██ ▒▓░▒▒▓█▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▒▓ ░ ██▒ ▓▓▓▓▒▓▓▓▓▓▓▓▓▓▓█▓▓▓▓▓▓▓▓▓██▒ ▓█░ ░ ▒██▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓░▓ ▒▒▒▒▒░ ▒█▓▒ ▓██████▓█▓▓▓░▓▓████████▒ ▓▓█▒ ▒▒▒▒ ▓░█▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓░░ ░▒▓▓▓▒▒▒ ██▓▓ ▒▓ ░ ░▒▓░▒▒░░ ▒ ▓ ▓█▓█ ▒▓███▓ ▒▒█▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒█ ▒▒█▓▓▒ ▒▒▒ ▒█▒██ ░▒▒▒░░░░░▒▒▒░▒▒▓▓▒▒▒░▓▓▒▓█ ▒░░▒▓█▒▒ █▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓░▒▒▒▒▒▒▒░░░░ █▒▒█▓▒▒▒▒▓▓▓▒▒░░░░▒░▒▒▓▓▒▒▒▒▒█ ░▓▓▒▓▓▓▓▓▓█▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒░█▒▒▒▒░░ ▓█ ▒▓░▒░▒▓▓▓▓▓▓██▓▓▒░░░▒▓▒▓███▓▓█░▓░░▒▒▒▒▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
||||
▒▒▒▒▓▓▓▓▓▓▓▓▒▒▒▒▓░░▒▓▒▒░▒ ▓▒▒░▒▓▓▓██████▓▓▓▓▒░▒▓▓▓████████▒▓ ▒▒▒▒ ██▓▓▓▓▓█▒▒▓████▓▓▓▓▓
|
||||
▒▒▒▓░░ ▒▓ ░░▒▒▒▒▒▓▓ ░▒▒░ ░▒▒▒▒▒▒▓████████▓▓▓█▓▒█▓▒▓█▒ ░▓██▓░░▒ ░██▓▒▓▓▓▓▒░▓░█ ▒▓ █▓▓▓
|
||||
▓▓▒▓ ▓█ ▒░█▒▒▓▒▒▒▒▓██ ░▒▒▒▒▒▒▒▒▒▓▒▓░ ▒▓▒▒▓▓▓▒█▓▓▓▒▒▒██▒▒█▓▓░▓██▓▓▓███▓█ ▒█ ▒█░▒██▓▓
|
||||
▓ ▓▓░ ▓█ █▒ ▓▒▒▒▓▓▒██░ ░░▒▒▓▓▒▒▒▓▓██████▓▒▓▓▒▓▓▓▓▒▓▓██████████▒ █▓▓▓▓▒ ▓░▒ ▒█▓▒█ ░▓▒░▓
|
||||
▓▒ ██░ ████▓ ░▒█▒ ▓▓▓░ ░▒▒▒▒▒▒▓▓▒▒▓█░ ▓▓▓▒▓▒▒▒▓▒▓▒▓▒ ▓▓▓▒▒▒░▓▓▒▓█ ▒█▒░▓█▓████▓ ░█▓
|
||||
░▒▒ ▓██▒▒▒█▒██░ ▓▓▓ ░░▒▒░▒▓▓▒▓▒▓▓ ░█ ▓▓▒▒▒▒▒▒▒▒▓█ ██ ▒▓▓█▓▒ █▓▓▓█ ▒███▒░ ▒█▒▒█▒░▓
|
||||
░ ░▓███▓▒▒ ▓██░░▓▓▓░░▒▒░▒▒▒▒░▒▒▒▒▒ ▓ ▓▒▒▒▒▓▒▓▒▒▒▓ ▒▓▒▒▒░▒█▒▓██ ▓██▒████▒ ▓▓
|
||||
▓▓▓░ ████▓█▒▒░▒██▓░░░░░▓ ░ ░ ▒ ░▒▒▓▓▓▓█████▒ ░ ▒▒▒░▓░ ███▓ ░▓▒▓█▓░ ███▓▒
|
||||
▒▒▒▓▓ ▓██▓▒▒▒░ ▒▓ ░░░░░░▒▒▒█████▓▓ ▒▓▓▓▓██████████▓▓▓▓▓▓████▒▒░ ▒░▓▒▒░ ▒█▓▓▓▓▓
|
||||
▒▒▒▒▓█▒ ▒▒▓█▓▓ ░▒▒░▒▒▓▓▒▒▒▒▒▒▒▒█████▓▓▓▒▒▓█▓░▒▓█▓▒███▓▒██▒▒▒▒▒▒▓▒░ ▒▓▒▒▒▓▓▓▒▒█▓▒▒▒▒▒
|
||||
▒▒▒▒▒█ ░▒▒▒▓▒▓▓███ ░▒▒▒▒▒▓▓▒▒▒▓███▓██▓▒▒████▓▒ ░▒▓▓░ ████▒▓████▓▓██▒ ▓▓▓▓▓▓▓▓ ▓█▒▒▒▒▒▒
|
||||
▒▒▒▒▒█ ░▒▒░▓▓▓▓▓▓█▓░░▒▒▒▒▒▓▓▓█▓▓▒▓▓▓██▓█████████ ▒ ██████▓█▓▒██▓▓█▓▒░▒▒▒▒▒▒▓▒ ▓▓▒▒▒▒▒
|
||||
▒▒▒▒▒█ ▒▒░▒▒▒▒▓▒▓▒▓ ░▓▓▓██▒▒▒▒▒▒░░▒▓▒░░█▓███▓█████▒▒███████░ ▒▓▓▒▒▒▓▓▓██▒▒▒▒▒▒▓░░█▓▒▒▒▒▒
|
||||
▒▒▒▒▒█▒░▒░▒▓▒▒▓▒▒▒▓█ ░▒▒▒▒▓▒▒▒▒▒█▓▓▒ ▓███▓▓▓▒▓▓ ▓███▓▓ ▒▒▓▓▓█▒▓▓▓▒ ░▓█▓▒▒▓ █▓▒▒▒▒▒▒
|
||||
▒▒▒▒▒█ ░▒░░░▓▒▒▒█▒▒▒░ ▒▒▓▒▒▓███▓▓▒▒▒██▒ ░████░░██▒ ▒▓▓▓▓▓▓▓▓█▓▒▓░▒▒▒▒▓▓▒ █▓▒▒▒▒▒▒
|
||||
▒▒▒▒▒▓ ░▒▒░░▒▓▒▒▒▒▒▒▒ ░▒▒█▒██▓▓▓██▓▒▓▓██▒ ░██ █▓▒▒▓▓██▓██▓▓██ ▒▓▒▒▒▒▒░░█▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▓▓ ░▒░░▒░▒▒▒▒▒▒▒░▒░░▓▓▒▒▒▓▓▓▓▓▒▓▓▓██ ██▒▓▓█▓█▒▓▓▓▓▓▒ ▒█▓▒▒▒▒▒ █▓▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▓▒░▒▒░░▒▒▒▒▓▒▒▒░ █░▒▒▒▒▓▓▒▒▓▒▓▓▓▒▓█ ▒█▓▒░░▒▒░ ██▓▓█▓▓▒█▒▒▓▒▓▓ ▒▒▒▒▒▒▒░ ▓▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▒▓ ▒▒░░░░░░▒▒▒▒▓▒▒ ░▒▓▓▓▓▓▓▓▓▓▓▒▓▓▓██ ▓█▓▓█▓░░██▓▓▓▒▓▒▓▒▓█▒▒ ░▓▓▒▓▒▒▒░▒█▓▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▒▓▓ ░░▒▒▒░▒▒▒▒▒▓▒▒░ ░▒▒▓▓▓▓▓▒▒▒▒▒▒▒▓██▓ ▒█▓▒▒▓▒▓▓▓█▓▓░ ▒▓▓▒▒▒░░ █▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▒▒▓░░▓▒░░░░░▒▒░▒▒▒▒▒░ ░▒░▒▓▓▒▓▓▓▒▒▒▓████████▓░▒▓▒▓▒▓░░ ░▒▓▒▒▒▒▓▒▒░░▓▓▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▒▒▒▓ ▒▒▒░░░░░░▒▒▒▒▒▒▒▒▒░░░░░▒▒▒▒▒▒▒▒░ ░▒██▓░ ░▓▒▒▒▒░ ▒▒▒█▓▓▒▒▒▒▒▒▒░ ▒▓▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▒▒▒▓█ ░▒▒░░▒░░▒▒▒▒▒▓▒▒▓▓▓▓▒▒▒░░░░▒▒▒▒▒░ ░▒▒░░░░▒▓▓▓▓▓█▓▓▓▒▒▒▒░ ▓▓▒▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▒▒▒▓ ░ ▒░▒▒▒░▒▒▒▒░▓▓▒▒▒▓▓▒▒▓▓▒▒▓▓▒▒▒░▒▒▒▒▒▒▒▒▓▓▓▓▓▓█▓██▓▓▓▒▓▒▒▒▒▒░ ▒▓▒▒▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▒▒▓█ ░▒░ ░░░░░▒▒▒▒░░▓█▒▒▒▓▓▒▒▓▓▒▒▒▒▒▓▒▓▒▓▒▓▒▒▒▓▒▓███▓▓▓▓▓▒▓▓▒▒░ ░ ▓█▓▒▒▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▒▒▓ ▒▒▒░░░░░░▒░ ▒▒▒▒░▒▒▓▓▓██▓▓▓▓▓▓█░█▒▒█▒▓██▓███▓▓▓▓▓▓▓▓▓▓▒██▒▒░ ▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▒▓▓░░▒▒░░░░░▒▒▒▒▒▒▒▒▒▒▓▒▒▓▓▒▒▓█▓▓██▓█████▓▓▓██▓██▓█▓▓▓▓▓▓▓▓▓▒▒▒▓▓░ █▓▒▒▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▒▓▒ ▒▒░░░░▒▒░░░▒▒▒▒▒▒▓▒▒▒▒▒▒██▒█▓▒▓▓▓▓▓▓▓█▓▓▓█▓▒▒▓██▒▒▒▒▒█▓▓▒▓▓▒▓▓ ▓▒▒▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▒▓▓ ▒▒░░░░▒░▒▒▒▒▒▒▓▒▒▒▓▓▓▓▓▒▒░▒▒▒▓▓█▓▓▓▓▒▓▓▓▒▒▓▓▓▒▒▒▓▓▓▓▓▓▓██▒▓▓▓▒░░▓▓▒▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▓▒ ▒▒░░░░▒▒▒▒▒▒▒▒▓▓▓▓▒▓▓▒▒▒▒▓▒▒▒▒▓▓▒▒▒▓▒▓▒▓▒▒▒▓▒▓▒▓▒█▓▓▓▓▓▓▒▓█▓▒▓▓▓░ ▓▒▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▓ ░▒░░░░░░░▒▒▒▒▒▓▒▓░▒▓▒▒▓▓▒▓▒██▓▓▒▒▓▒▓▓▒▓▓▒█▒▒▒▓█▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▓▓ ░▓▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▒▓▒ ▒▒░░▒▒▒▒▒▒░▓▓▓▒▒▓▓▓▓▓▓▓▓▓█▒▓▓▓▓▓▓▓▓▓▓▓▓▒▓▓▒▓▓▓▓▓▒▓▓▓▓▓▓▓▓▓▓▓▒▓▒▒▒▒▒▓▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▓░ ▒▒░░░░░░░░▒▒▓▒▒▒▒▓▒▒▓▒▒▓▒▓▒▒▒▓▒▓▓▓▓▓▓▓▓▓▓▒▓▓▓▓▓▓▓▓▓▓▓▓█▓▒▓▓▓▓▓▓▒▓▓░ ▒▒▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▓▒░▒░░░░░░░░▒▒▒▒░▓▒▒▒▒▒▓▒▒▓▒▓▓▓▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓█▒▒▓▒▓▒█▓▒█▓▒▒▓▓▒▒▒▒▓▓ ▓▓▒▒▒▒▒▒▒▒▒▒
|
||||
▒▒▒▒▒▓ ▒▒░░▒░░▒░▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒▒▒▓▓▒▒▓▓▒▓▓▒▓▓▒▓▓▓▓▒▒▒▒▓▒▓▓▓▒▒▓▓▓▓▓▓▓▓▓▓▒▒▒▓▒░▓▒▒▒▒▒▒▒▒▒▒
|
||||
░ ░
|
||||
@@ -1,26 +1,26 @@
|
||||
{
|
||||
"models": {
|
||||
"main": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-sonnet-4-5-20250929",
|
||||
"maxTokens": 64000,
|
||||
"provider": "claude-code",
|
||||
"modelId": "haiku",
|
||||
"maxTokens": 200000,
|
||||
"temperature": 0.2
|
||||
},
|
||||
"research": {
|
||||
"provider": "perplexity",
|
||||
"modelId": "sonar-pro",
|
||||
"modelId": "sonar-reasoning-pro",
|
||||
"maxTokens": 8700,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"fallback": {
|
||||
"provider": "anthropic",
|
||||
"modelId": "claude-sonnet-4-20250514",
|
||||
"provider": "claude-code",
|
||||
"modelId": "sonnet",
|
||||
"maxTokens": 64000,
|
||||
"temperature": 0.2
|
||||
}
|
||||
},
|
||||
"global": {
|
||||
"logLevel": "info",
|
||||
"logLevel": "silent",
|
||||
"debug": false,
|
||||
"defaultNumTasks": 10,
|
||||
"defaultSubtasks": 5,
|
||||
@@ -30,6 +30,8 @@
|
||||
"bedrockBaseURL": "https://bedrock.us-east-1.amazonaws.com",
|
||||
"responseLanguage": "English",
|
||||
"enableCodebaseAnalysis": true,
|
||||
"enableProxy": false,
|
||||
"anonymousTelemetry": true,
|
||||
"userId": "1234567890",
|
||||
"azureBaseURL": "https://your-endpoint.azure.com/",
|
||||
"defaultTag": "master"
|
||||
|
||||
@@ -0,0 +1,166 @@
|
||||
---
|
||||
title: Research Session
|
||||
query: "should we be doing the taskmaster gateway even though we have a hamster connection now? how might we serve the ai from hamster as a standalone model?"
|
||||
date: 11/17/2025
|
||||
time: 7:35:00 PM
|
||||
timestamp: 2025-11-18T00:35:00.754Z
|
||||
exchanges: 2
|
||||
---
|
||||
|
||||
# Research Session
|
||||
|
||||
## Initial Query
|
||||
|
||||
**Question:** should we be doing the taskmaster gateway even though we have a hamster connection now? how might we serve the ai from hamster as a standalone model?
|
||||
|
||||
**Response:**
|
||||
|
||||
You do not necessarily need to proceed with the Taskmaster Gateway integration if your current **Hamster connection** already provides the required AI capabilities, but the decision depends on your specific project needs, desired features, and architectural preferences. Serving the AI from Hamster as a standalone model is feasible and may offer advantages in control, cost, and flexibility, but it also comes with trade-offs compared to using a managed gateway.
|
||||
|
||||
---
|
||||
|
||||
## Should You Still Integrate the Taskmaster Gateway?
|
||||
|
||||
**Key considerations:**
|
||||
|
||||
- **Feature Set:**
|
||||
The Taskmaster Gateway is designed to provide access to **premium AI-powered test generation, TDD orchestration, and smart git workflows** via API key authentication. If Hamster already delivers these features (or you can implement them), the gateway may be redundant.
|
||||
|
||||
- **Centralization and Vendor Lock-in:**
|
||||
Using the gateway centralizes premium features and may simplify updates, billing, and support. However, it can introduce vendor lock-in and dependency on external uptime and pricing.
|
||||
|
||||
- **Local vs. Remote AI:**
|
||||
The gateway is intended to maintain local file operations while leveraging remote AI intelligence. If Hamster can run locally or on your own infrastructure, you gain more control over data privacy, latency, and cost.
|
||||
|
||||
- **Testing and Workflow Integration:**
|
||||
If your team values seamless integration with **git workflows** and **test orchestration** as provided by the gateway, and these are not easily replicated with Hamster, the gateway may still be valuable.
|
||||
|
||||
- **Project Roadmap:**
|
||||
If Task 102 is high priority and aligns with your long-term goals (e.g., supporting multiple AI backends or offering users a choice), completing the integration could future-proof your platform.
|
||||
|
||||
---
|
||||
|
||||
## Serving the AI from Hamster as a Standalone Model
|
||||
|
||||
If you decide to use Hamster as your primary AI backend, you can serve it as a **standalone model** in several ways:
|
||||
|
||||
### 1. **Local API Server**
|
||||
- **Wrap the Hamster model** in a lightweight HTTP API (e.g., using FastAPI, Flask, or Express).
|
||||
- Expose endpoints that mimic the Taskmaster Gateway API, allowing your CLI and other tools to interact with Hamster as if it were a remote service.
|
||||
- This approach enables easy swapping between Hamster and other backends by changing the API endpoint.
|
||||
|
||||
### 2. **Direct Integration**
|
||||
- Integrate Hamster directly into your Taskmaster codebase as a module or service.
|
||||
- This reduces network overhead and can simplify error handling, but may require more code changes if you later want to support multiple backends.
|
||||
|
||||
### 3. **Containerization**
|
||||
- Package Hamster and its serving API in a Docker container.
|
||||
- Users can run the container locally or deploy it to their own infrastructure, maintaining isolation and reproducibility.
|
||||
|
||||
### 4. **Configuration and Abstraction**
|
||||
- Add a configuration flag or environment variable to select between Hamster and the Taskmaster Gateway.
|
||||
- Abstract the AI interaction layer so that switching backends requires minimal code changes.
|
||||
|
||||
---
|
||||
|
||||
## Actionable Recommendations
|
||||
|
||||
- **Evaluate Feature Parity:**
|
||||
Compare the features of Hamster and the Taskmaster Gateway. If Hamster meets your needs, prioritize serving it as a standalone model.
|
||||
|
||||
- **Design for Flexibility:**
|
||||
Implement an abstraction layer for AI providers. This allows you to support both Hamster and the Taskmaster Gateway (or others) with minimal friction.
|
||||
|
||||
- **Document the Setup:**
|
||||
Clearly document how to run Hamster as a standalone service, including installation, configuration, and API usage. This will help with onboarding and maintenance.
|
||||
|
||||
- **Consider User Experience:**
|
||||
If your users expect plug-and-play access to premium features (as with the gateway), ensure your Hamster integration matches or exceeds this experience.
|
||||
|
||||
---
|
||||
|
||||
## How This Applies to Your Tasks
|
||||
|
||||
- **Task 102 (Taskmaster Gateway Integration):**
|
||||
If you choose to deprioritize this, document the rationale and ensure stakeholders agree. If you proceed, consider making the gateway optional, with Hamster as a default or fallback.
|
||||
|
||||
- **CLI and Directory Structure:**
|
||||
Ensure that your `.taskmaster/` directory and CLI enhancements (Tasks 95, 57) are compatible with both Hamster and gateway-based workflows.
|
||||
|
||||
- **Installation and Configuration:**
|
||||
Update your installation scripts and documentation (Tasks 64, 65, 31) to support configuration for Hamster as a backend, including any required flags or environment variables.
|
||||
|
||||
---
|
||||
|
||||
**Summary:**
|
||||
If Hamster provides all required AI features, you can serve it as a standalone model via a local API or direct integration, potentially making the Taskmaster Gateway optional. Design your system to support backend flexibility, and ensure your documentation and CLI tools reflect this choice.
|
||||
|
||||
---
|
||||
|
||||
## Follow-up 1
|
||||
|
||||
**Question:** so if i have an ai sdk setup from hamster, could i just expose it as an option and let users pay us directly?
|
||||
|
||||
**Response:**
|
||||
|
||||
Yes, if you have an AI SDK setup from Hamster, you can expose it as an option and allow users to pay you directly—**but there are important technical, legal, and business considerations** to keep in mind for your project.
|
||||
|
||||
---
|
||||
|
||||
### **How It Works Technically**
|
||||
- **SDK as a Service Layer:**
|
||||
You can wrap the Hamster AI SDK in your own API or service layer, exposing endpoints that users interact with. This way, your platform acts as a middleman, routing requests to Hamster’s backend and returning results.
|
||||
- **Billing Integration:**
|
||||
You can implement your own billing logic (e.g., usage-based or subscription) and charge users directly. You’d then pay Hamster for the underlying API usage (if their pricing is usage-based) or manage your own subscription costs.
|
||||
- **User Experience:**
|
||||
Users see your platform as the provider, not Hamster. You control the UX, branding, and support, while Hamster remains the backend engine.
|
||||
|
||||
---
|
||||
|
||||
### **Key Considerations for Your Project**
|
||||
- **Pricing Model Alignment:**
|
||||
Hamster AI offers a **free plan (250 credits/month)** and a **Pro plan (unlimited credits, $3.30/month)**. If you want to charge users, you’ll need to either:
|
||||
- Use the Pro plan and resell access (with your own pricing),
|
||||
- Or use the free plan and limit user access to 250 credits/month (not ideal for heavy usage).
|
||||
- **Usage Tracking:**
|
||||
You’ll need to track user usage (e.g., tokens, requests) to bill them accurately and ensure you don’t exceed Hamster’s limits.
|
||||
- **Legal & Terms of Service:**
|
||||
Check Hamster’s **terms of service** to ensure reselling or white-labeling is allowed. Some AI providers restrict commercial resale or require special agreements.
|
||||
- **Abstraction Layer:**
|
||||
To support flexibility (e.g., switching to other AI backends like Claude or Taskmaster Gateway), design an abstraction layer in your code. This lets you swap providers without breaking your user-facing API.
|
||||
|
||||
---
|
||||
|
||||
### **Actionable Steps for Your Team**
|
||||
1. **Review Hamster’s Terms:**
|
||||
Confirm if reselling or white-labeling is permitted.
|
||||
2. **Implement Usage Tracking:**
|
||||
Add logic to track user requests/tokens and map them to your billing system.
|
||||
3. **Design Your API Layer:**
|
||||
Create endpoints that proxy requests to Hamster, with your own authentication and rate limiting.
|
||||
4. **Set Up Billing:**
|
||||
Integrate a payment processor (e.g., Stripe) to charge users directly.
|
||||
5. **Document the Flow:**
|
||||
Clearly explain to users how billing works and what they’re paying for.
|
||||
|
||||
---
|
||||
|
||||
### **Trade-offs vs. Taskmaster Gateway**
|
||||
- **Pros of Using Hamster Directly:**
|
||||
- Lower cost (especially if you use the Pro plan),
|
||||
- More control over pricing and user experience,
|
||||
- No vendor lock-in with Taskmaster.
|
||||
- **Cons:**
|
||||
- You’re responsible for billing, support, and compliance,
|
||||
- Hamster may not offer all the premium features (e.g., advanced test generation, git workflows) that Taskmaster Gateway provides.
|
||||
|
||||
---
|
||||
|
||||
### **Recommendation**
|
||||
If Hamster meets your AI needs and their terms allow it, **exposing it as a paid option is feasible and can be a cost-effective way to monetize your platform**. However, ensure you have a clear abstraction layer so you can easily switch providers or add new ones (like Taskmaster Gateway) in the future. This approach gives you flexibility and control while keeping costs low.
|
||||
|
||||
|
||||
---
|
||||
|
||||
*Generated by Task Master Research Command*
|
||||
*Timestamp: 2025-11-18T00:35:00.754Z*
|
||||
@@ -1,9 +1,59 @@
|
||||
{
|
||||
"currentTag": "tdd-phase-1-core-rails",
|
||||
"lastSwitched": "2025-11-10T19:45:04.383Z",
|
||||
"branchTagMapping": {
|
||||
"v017-adds": "v017-adds",
|
||||
"next": "next"
|
||||
"currentTag": "tm-core-phase-1",
|
||||
"lastUpdated": "2025-11-28T02:21:32.160Z",
|
||||
"metadata": {
|
||||
"upgradePrompts": {
|
||||
"triggers": {
|
||||
"export_attempt": {
|
||||
"firstShownAt": "2025-11-26T21:02:12.322Z",
|
||||
"lastShownAt": "2025-11-26T21:02:12.322Z",
|
||||
"showCount": 1,
|
||||
"dismissed": false,
|
||||
"action": "accepted",
|
||||
"actionAt": "2025-11-28T02:20:29.155Z"
|
||||
}
|
||||
},
|
||||
"metrics": {
|
||||
"totalTaskCount": 0,
|
||||
"tagCount": 0,
|
||||
"listCommandCount": 0,
|
||||
"tasksWithDependencies": 0
|
||||
},
|
||||
"lastUpdated": "2025-11-28T02:20:29.155Z",
|
||||
"version": "1.0.0"
|
||||
},
|
||||
"exportedTags": {
|
||||
"tm-core-phase-1": {
|
||||
"briefId": "5f36141d-9749-47b4-b64b-7841a42cf68e",
|
||||
"briefUrl": "http://localhost:3000/home/hamster/briefs/5f36141d-9749-47b4-b64b-7841a42cf68e",
|
||||
"exportedAt": "2025-11-27T21:41:38.821Z"
|
||||
},
|
||||
"tdd-workflow-phase-0": {
|
||||
"briefId": "b137627a-0573-4ae6-bda6-afea97e31b4f",
|
||||
"briefUrl": "http://localhost:3000/home/hamster/briefs/b137627a-0573-4ae6-bda6-afea97e31b4f",
|
||||
"exportedAt": "2025-11-27T21:51:39.086Z"
|
||||
},
|
||||
"autonomous-tdd-git-workflow": {
|
||||
"briefId": "3f0e8ef0-c79d-4942-92be-0c9f2b6db0eb",
|
||||
"briefUrl": "http://localhost:3000/home/hamster/briefs/3f0e8ef0-c79d-4942-92be-0c9f2b6db0eb",
|
||||
"exportedAt": "2025-11-27T21:51:39.557Z"
|
||||
},
|
||||
"tdd-phase-1-core-rails": {
|
||||
"briefId": "c14723fb-d1c1-428f-82f3-676c45479f60",
|
||||
"briefUrl": "http://localhost:3000/home/hamster/briefs/c14723fb-d1c1-428f-82f3-676c45479f60",
|
||||
"exportedAt": "2025-11-28T02:20:29.155Z"
|
||||
},
|
||||
"tm-start": {
|
||||
"briefId": "f32d7ba2-1709-4ed1-ad48-e42a10e395dd",
|
||||
"briefUrl": "http://localhost:3000/home/hamster/briefs/f32d7ba2-1709-4ed1-ad48-e42a10e395dd",
|
||||
"exportedAt": "2025-11-28T02:21:31.612Z"
|
||||
},
|
||||
"cc-kiro-hooks": {
|
||||
"briefId": "ee743dbe-f2ff-458e-8ff2-6b192e386805",
|
||||
"briefUrl": "http://localhost:3000/home/hamster/briefs/ee743dbe-f2ff-458e-8ff2-6b192e386805",
|
||||
"exportedAt": "2025-11-28T02:21:32.160Z"
|
||||
}
|
||||
}
|
||||
},
|
||||
"migrationNoticeShown": true
|
||||
}
|
||||
|
||||
47
.taskmaster/templates/example_prd.txt
Normal file
47
.taskmaster/templates/example_prd.txt
Normal file
@@ -0,0 +1,47 @@
|
||||
<context>
|
||||
# Overview
|
||||
[Provide a high-level overview of your product here. Explain what problem it solves, who it's for, and why it's valuable.]
|
||||
|
||||
# Core Features
|
||||
[List and describe the main features of your product. For each feature, include:
|
||||
- What it does
|
||||
- Why it's important
|
||||
- How it works at a high level]
|
||||
|
||||
# User Experience
|
||||
[Describe the user journey and experience. Include:
|
||||
- User personas
|
||||
- Key user flows
|
||||
- UI/UX considerations]
|
||||
</context>
|
||||
<PRD>
|
||||
# Technical Architecture
|
||||
[Outline the technical implementation details:
|
||||
- System components
|
||||
- Data models
|
||||
- APIs and integrations
|
||||
- Infrastructure requirements]
|
||||
|
||||
# Development Roadmap
|
||||
[Break down the development process into phases:
|
||||
- MVP requirements
|
||||
- Future enhancements
|
||||
- Do not think about timelines whatsoever -- all that matters is scope and detailing exactly what needs to be build in each phase so it can later be cut up into tasks]
|
||||
|
||||
# Logical Dependency Chain
|
||||
[Define the logical order of development:
|
||||
- Which features need to be built first (foundation)
|
||||
- Getting as quickly as possible to something usable/visible front end that works
|
||||
- Properly pacing and scoping each feature so it is atomic but can also be built upon and improved as development approaches]
|
||||
|
||||
# Risks and Mitigations
|
||||
[Identify potential risks and how they'll be addressed:
|
||||
- Technical challenges
|
||||
- Figuring out the MVP that we can build upon
|
||||
- Resource constraints]
|
||||
|
||||
# Appendix
|
||||
[Include any additional information:
|
||||
- Research findings
|
||||
- Technical specifications]
|
||||
</PRD>
|
||||
511
.taskmaster/templates/example_prd_rpg.txt
Normal file
511
.taskmaster/templates/example_prd_rpg.txt
Normal file
@@ -0,0 +1,511 @@
|
||||
<rpg-method>
|
||||
# Repository Planning Graph (RPG) Method - PRD Template
|
||||
|
||||
This template teaches you (AI or human) how to create structured, dependency-aware PRDs using the RPG methodology from Microsoft Research. The key insight: separate WHAT (functional) from HOW (structural), then connect them with explicit dependencies.
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **Dual-Semantics**: Think functional (capabilities) AND structural (code organization) separately, then map them
|
||||
2. **Explicit Dependencies**: Never assume - always state what depends on what
|
||||
3. **Topological Order**: Build foundation first, then layers on top
|
||||
4. **Progressive Refinement**: Start broad, refine iteratively
|
||||
|
||||
## How to Use This Template
|
||||
|
||||
- Follow the instructions in each `<instruction>` block
|
||||
- Look at `<example>` blocks to see good vs bad patterns
|
||||
- Fill in the content sections with your project details
|
||||
- The AI reading this will learn the RPG method by following along
|
||||
- Task Master will parse the resulting PRD into dependency-aware tasks
|
||||
|
||||
## Recommended Tools for Creating PRDs
|
||||
|
||||
When using this template to **create** a PRD (not parse it), use **code-context-aware AI assistants** for best results:
|
||||
|
||||
**Why?** The AI needs to understand your existing codebase to make good architectural decisions about modules, dependencies, and integration points.
|
||||
|
||||
**Recommended tools:**
|
||||
- **Claude Code** (claude-code CLI) - Best for structured reasoning and large contexts
|
||||
- **Cursor/Windsurf** - IDE integration with full codebase context
|
||||
- **Gemini CLI** (gemini-cli) - Massive context window for large codebases
|
||||
- **Codex/Grok CLI** - Strong code generation with context awareness
|
||||
|
||||
**Note:** Once your PRD is created, `task-master parse-prd` works with any configured AI model - it just needs to read the PRD text itself, not your codebase.
|
||||
</rpg-method>
|
||||
|
||||
---
|
||||
|
||||
<overview>
|
||||
<instruction>
|
||||
Start with the problem, not the solution. Be specific about:
|
||||
- What pain point exists?
|
||||
- Who experiences it?
|
||||
- Why existing solutions don't work?
|
||||
- What success looks like (measurable outcomes)?
|
||||
|
||||
Keep this section focused - don't jump into implementation details yet.
|
||||
</instruction>
|
||||
|
||||
## Problem Statement
|
||||
[Describe the core problem. Be concrete about user pain points.]
|
||||
|
||||
## Target Users
|
||||
[Define personas, their workflows, and what they're trying to achieve.]
|
||||
|
||||
## Success Metrics
|
||||
[Quantifiable outcomes. Examples: "80% task completion via autopilot", "< 5% manual intervention rate"]
|
||||
|
||||
</overview>
|
||||
|
||||
---
|
||||
|
||||
<functional-decomposition>
|
||||
<instruction>
|
||||
Now think about CAPABILITIES (what the system DOES), not code structure yet.
|
||||
|
||||
Step 1: Identify high-level capability domains
|
||||
- Think: "What major things does this system do?"
|
||||
- Examples: Data Management, Core Processing, Presentation Layer
|
||||
|
||||
Step 2: For each capability, enumerate specific features
|
||||
- Use explore-exploit strategy:
|
||||
* Exploit: What features are REQUIRED for core value?
|
||||
* Explore: What features make this domain COMPLETE?
|
||||
|
||||
Step 3: For each feature, define:
|
||||
- Description: What it does in one sentence
|
||||
- Inputs: What data/context it needs
|
||||
- Outputs: What it produces/returns
|
||||
- Behavior: Key logic or transformations
|
||||
|
||||
<example type="good">
|
||||
Capability: Data Validation
|
||||
Feature: Schema validation
|
||||
- Description: Validate JSON payloads against defined schemas
|
||||
- Inputs: JSON object, schema definition
|
||||
- Outputs: Validation result (pass/fail) + error details
|
||||
- Behavior: Iterate fields, check types, enforce constraints
|
||||
|
||||
Feature: Business rule validation
|
||||
- Description: Apply domain-specific validation rules
|
||||
- Inputs: Validated data object, rule set
|
||||
- Outputs: Boolean + list of violated rules
|
||||
- Behavior: Execute rules sequentially, short-circuit on failure
|
||||
</example>
|
||||
|
||||
<example type="bad">
|
||||
Capability: validation.js
|
||||
(Problem: This is a FILE, not a CAPABILITY. Mixing structure into functional thinking.)
|
||||
|
||||
Capability: Validation
|
||||
Feature: Make sure data is good
|
||||
(Problem: Too vague. No inputs/outputs. Not actionable.)
|
||||
</example>
|
||||
</instruction>
|
||||
|
||||
## Capability Tree
|
||||
|
||||
### Capability: [Name]
|
||||
[Brief description of what this capability domain covers]
|
||||
|
||||
#### Feature: [Name]
|
||||
- **Description**: [One sentence]
|
||||
- **Inputs**: [What it needs]
|
||||
- **Outputs**: [What it produces]
|
||||
- **Behavior**: [Key logic]
|
||||
|
||||
#### Feature: [Name]
|
||||
- **Description**:
|
||||
- **Inputs**:
|
||||
- **Outputs**:
|
||||
- **Behavior**:
|
||||
|
||||
### Capability: [Name]
|
||||
...
|
||||
|
||||
</functional-decomposition>
|
||||
|
||||
---
|
||||
|
||||
<structural-decomposition>
|
||||
<instruction>
|
||||
NOW think about code organization. Map capabilities to actual file/folder structure.
|
||||
|
||||
Rules:
|
||||
1. Each capability maps to a module (folder or file)
|
||||
2. Features within a capability map to functions/classes
|
||||
3. Use clear module boundaries - each module has ONE responsibility
|
||||
4. Define what each module exports (public interface)
|
||||
|
||||
The goal: Create a clear mapping between "what it does" (functional) and "where it lives" (structural).
|
||||
|
||||
<example type="good">
|
||||
Capability: Data Validation
|
||||
→ Maps to: src/validation/
|
||||
├── schema-validator.js (Schema validation feature)
|
||||
├── rule-validator.js (Business rule validation feature)
|
||||
└── index.js (Public exports)
|
||||
|
||||
Exports:
|
||||
- validateSchema(data, schema)
|
||||
- validateRules(data, rules)
|
||||
</example>
|
||||
|
||||
<example type="bad">
|
||||
Capability: Data Validation
|
||||
→ Maps to: src/utils.js
|
||||
(Problem: "utils" is not a clear module boundary. Where do I find validation logic?)
|
||||
|
||||
Capability: Data Validation
|
||||
→ Maps to: src/validation/everything.js
|
||||
(Problem: One giant file. Features should map to separate files for maintainability.)
|
||||
</example>
|
||||
</instruction>
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
project-root/
|
||||
├── src/
|
||||
│ ├── [module-name]/ # Maps to: [Capability Name]
|
||||
│ │ ├── [file].js # Maps to: [Feature Name]
|
||||
│ │ └── index.js # Public exports
|
||||
│ └── [module-name]/
|
||||
├── tests/
|
||||
└── docs/
|
||||
```
|
||||
|
||||
## Module Definitions
|
||||
|
||||
### Module: [Name]
|
||||
- **Maps to capability**: [Capability from functional decomposition]
|
||||
- **Responsibility**: [Single clear purpose]
|
||||
- **File structure**:
|
||||
```
|
||||
module-name/
|
||||
├── feature1.js
|
||||
├── feature2.js
|
||||
└── index.js
|
||||
```
|
||||
- **Exports**:
|
||||
- `functionName()` - [what it does]
|
||||
- `ClassName` - [what it does]
|
||||
|
||||
</structural-decomposition>
|
||||
|
||||
---
|
||||
|
||||
<dependency-graph>
|
||||
<instruction>
|
||||
This is THE CRITICAL SECTION for Task Master parsing.
|
||||
|
||||
Define explicit dependencies between modules. This creates the topological order for task execution.
|
||||
|
||||
Rules:
|
||||
1. List modules in dependency order (foundation first)
|
||||
2. For each module, state what it depends on
|
||||
3. Foundation modules should have NO dependencies
|
||||
4. Every non-foundation module should depend on at least one other module
|
||||
5. Think: "What must EXIST before I can build this module?"
|
||||
|
||||
<example type="good">
|
||||
Foundation Layer (no dependencies):
|
||||
- error-handling: No dependencies
|
||||
- config-manager: No dependencies
|
||||
- base-types: No dependencies
|
||||
|
||||
Data Layer:
|
||||
- schema-validator: Depends on [base-types, error-handling]
|
||||
- data-ingestion: Depends on [schema-validator, config-manager]
|
||||
|
||||
Core Layer:
|
||||
- algorithm-engine: Depends on [base-types, error-handling]
|
||||
- pipeline-orchestrator: Depends on [algorithm-engine, data-ingestion]
|
||||
</example>
|
||||
|
||||
<example type="bad">
|
||||
- validation: Depends on API
|
||||
- API: Depends on validation
|
||||
(Problem: Circular dependency. This will cause build/runtime issues.)
|
||||
|
||||
- user-auth: Depends on everything
|
||||
(Problem: Too many dependencies. Should be more focused.)
|
||||
</example>
|
||||
</instruction>
|
||||
|
||||
## Dependency Chain
|
||||
|
||||
### Foundation Layer (Phase 0)
|
||||
No dependencies - these are built first.
|
||||
|
||||
- **[Module Name]**: [What it provides]
|
||||
- **[Module Name]**: [What it provides]
|
||||
|
||||
### [Layer Name] (Phase 1)
|
||||
- **[Module Name]**: Depends on [[module-from-phase-0], [module-from-phase-0]]
|
||||
- **[Module Name]**: Depends on [[module-from-phase-0]]
|
||||
|
||||
### [Layer Name] (Phase 2)
|
||||
- **[Module Name]**: Depends on [[module-from-phase-1], [module-from-foundation]]
|
||||
|
||||
[Continue building up layers...]
|
||||
|
||||
</dependency-graph>
|
||||
|
||||
---
|
||||
|
||||
<implementation-roadmap>
|
||||
<instruction>
|
||||
Turn the dependency graph into concrete development phases.
|
||||
|
||||
Each phase should:
|
||||
1. Have clear entry criteria (what must exist before starting)
|
||||
2. Contain tasks that can be parallelized (no inter-dependencies within phase)
|
||||
3. Have clear exit criteria (how do we know phase is complete?)
|
||||
4. Build toward something USABLE (not just infrastructure)
|
||||
|
||||
Phase ordering follows topological sort of dependency graph.
|
||||
|
||||
<example type="good">
|
||||
Phase 0: Foundation
|
||||
Entry: Clean repository
|
||||
Tasks:
|
||||
- Implement error handling utilities
|
||||
- Create base type definitions
|
||||
- Setup configuration system
|
||||
Exit: Other modules can import foundation without errors
|
||||
|
||||
Phase 1: Data Layer
|
||||
Entry: Phase 0 complete
|
||||
Tasks:
|
||||
- Implement schema validator (uses: base types, error handling)
|
||||
- Build data ingestion pipeline (uses: validator, config)
|
||||
Exit: End-to-end data flow from input to validated output
|
||||
</example>
|
||||
|
||||
<example type="bad">
|
||||
Phase 1: Build Everything
|
||||
Tasks:
|
||||
- API
|
||||
- Database
|
||||
- UI
|
||||
- Tests
|
||||
(Problem: No clear focus. Too broad. Dependencies not considered.)
|
||||
</example>
|
||||
</instruction>
|
||||
|
||||
## Development Phases
|
||||
|
||||
### Phase 0: [Foundation Name]
|
||||
**Goal**: [What foundational capability this establishes]
|
||||
|
||||
**Entry Criteria**: [What must be true before starting]
|
||||
|
||||
**Tasks**:
|
||||
- [ ] [Task name] (depends on: [none or list])
|
||||
- Acceptance criteria: [How we know it's done]
|
||||
- Test strategy: [What tests prove it works]
|
||||
|
||||
- [ ] [Task name] (depends on: [none or list])
|
||||
|
||||
**Exit Criteria**: [Observable outcome that proves phase complete]
|
||||
|
||||
**Delivers**: [What can users/developers do after this phase?]
|
||||
|
||||
---
|
||||
|
||||
### Phase 1: [Layer Name]
|
||||
**Goal**:
|
||||
|
||||
**Entry Criteria**: Phase 0 complete
|
||||
|
||||
**Tasks**:
|
||||
- [ ] [Task name] (depends on: [[tasks-from-phase-0]])
|
||||
- [ ] [Task name] (depends on: [[tasks-from-phase-0]])
|
||||
|
||||
**Exit Criteria**:
|
||||
|
||||
**Delivers**:
|
||||
|
||||
---
|
||||
|
||||
[Continue with more phases...]
|
||||
|
||||
</implementation-roadmap>
|
||||
|
||||
---
|
||||
|
||||
<test-strategy>
|
||||
<instruction>
|
||||
Define how testing will be integrated throughout development (TDD approach).
|
||||
|
||||
Specify:
|
||||
1. Test pyramid ratios (unit vs integration vs e2e)
|
||||
2. Coverage requirements
|
||||
3. Critical test scenarios
|
||||
4. Test generation guidelines for Surgical Test Generator
|
||||
|
||||
This section guides the AI when generating tests during the RED phase of TDD.
|
||||
|
||||
<example type="good">
|
||||
Critical Test Scenarios for Data Validation module:
|
||||
- Happy path: Valid data passes all checks
|
||||
- Edge cases: Empty strings, null values, boundary numbers
|
||||
- Error cases: Invalid types, missing required fields
|
||||
- Integration: Validator works with ingestion pipeline
|
||||
</example>
|
||||
</instruction>
|
||||
|
||||
## Test Pyramid
|
||||
|
||||
```
|
||||
/\
|
||||
/E2E\ ← [X]% (End-to-end, slow, comprehensive)
|
||||
/------\
|
||||
/Integration\ ← [Y]% (Module interactions)
|
||||
/------------\
|
||||
/ Unit Tests \ ← [Z]% (Fast, isolated, deterministic)
|
||||
/----------------\
|
||||
```
|
||||
|
||||
## Coverage Requirements
|
||||
- Line coverage: [X]% minimum
|
||||
- Branch coverage: [X]% minimum
|
||||
- Function coverage: [X]% minimum
|
||||
- Statement coverage: [X]% minimum
|
||||
|
||||
## Critical Test Scenarios
|
||||
|
||||
### [Module/Feature Name]
|
||||
**Happy path**:
|
||||
- [Scenario description]
|
||||
- Expected: [What should happen]
|
||||
|
||||
**Edge cases**:
|
||||
- [Scenario description]
|
||||
- Expected: [What should happen]
|
||||
|
||||
**Error cases**:
|
||||
- [Scenario description]
|
||||
- Expected: [How system handles failure]
|
||||
|
||||
**Integration points**:
|
||||
- [What interactions to test]
|
||||
- Expected: [End-to-end behavior]
|
||||
|
||||
## Test Generation Guidelines
|
||||
[Specific instructions for Surgical Test Generator about what to focus on, what patterns to follow, project-specific test conventions]
|
||||
|
||||
</test-strategy>
|
||||
|
||||
---
|
||||
|
||||
<architecture>
|
||||
<instruction>
|
||||
Describe technical architecture, data models, and key design decisions.
|
||||
|
||||
Keep this section AFTER functional/structural decomposition - implementation details come after understanding structure.
|
||||
</instruction>
|
||||
|
||||
## System Components
|
||||
[Major architectural pieces and their responsibilities]
|
||||
|
||||
## Data Models
|
||||
[Core data structures, schemas, database design]
|
||||
|
||||
## Technology Stack
|
||||
[Languages, frameworks, key libraries]
|
||||
|
||||
**Decision: [Technology/Pattern]**
|
||||
- **Rationale**: [Why chosen]
|
||||
- **Trade-offs**: [What we're giving up]
|
||||
- **Alternatives considered**: [What else we looked at]
|
||||
|
||||
</architecture>
|
||||
|
||||
---
|
||||
|
||||
<risks>
|
||||
<instruction>
|
||||
Identify risks that could derail development and how to mitigate them.
|
||||
|
||||
Categories:
|
||||
- Technical risks (complexity, unknowns)
|
||||
- Dependency risks (blocking issues)
|
||||
- Scope risks (creep, underestimation)
|
||||
</instruction>
|
||||
|
||||
## Technical Risks
|
||||
**Risk**: [Description]
|
||||
- **Impact**: [High/Medium/Low - effect on project]
|
||||
- **Likelihood**: [High/Medium/Low]
|
||||
- **Mitigation**: [How to address]
|
||||
- **Fallback**: [Plan B if mitigation fails]
|
||||
|
||||
## Dependency Risks
|
||||
[External dependencies, blocking issues]
|
||||
|
||||
## Scope Risks
|
||||
[Scope creep, underestimation, unclear requirements]
|
||||
|
||||
</risks>
|
||||
|
||||
---
|
||||
|
||||
<appendix>
|
||||
## References
|
||||
[Papers, documentation, similar systems]
|
||||
|
||||
## Glossary
|
||||
[Domain-specific terms]
|
||||
|
||||
## Open Questions
|
||||
[Things to resolve during development]
|
||||
</appendix>
|
||||
|
||||
---
|
||||
|
||||
<task-master-integration>
|
||||
# How Task Master Uses This PRD
|
||||
|
||||
When you run `task-master parse-prd <file>.txt`, the parser:
|
||||
|
||||
1. **Extracts capabilities** → Main tasks
|
||||
- Each `### Capability:` becomes a top-level task
|
||||
|
||||
2. **Extracts features** → Subtasks
|
||||
- Each `#### Feature:` becomes a subtask under its capability
|
||||
|
||||
3. **Parses dependencies** → Task dependencies
|
||||
- `Depends on: [X, Y]` sets task.dependencies = ["X", "Y"]
|
||||
|
||||
4. **Orders by phases** → Task priorities
|
||||
- Phase 0 tasks = highest priority
|
||||
- Phase N tasks = lower priority, properly sequenced
|
||||
|
||||
5. **Uses test strategy** → Test generation context
|
||||
- Feeds test scenarios to Surgical Test Generator during implementation
|
||||
|
||||
**Result**: A dependency-aware task graph that can be executed in topological order.
|
||||
|
||||
## Why RPG Structure Matters
|
||||
|
||||
Traditional flat PRDs lead to:
|
||||
- ❌ Unclear task dependencies
|
||||
- ❌ Arbitrary task ordering
|
||||
- ❌ Circular dependencies discovered late
|
||||
- ❌ Poorly scoped tasks
|
||||
|
||||
RPG-structured PRDs provide:
|
||||
- ✅ Explicit dependency chains
|
||||
- ✅ Topological execution order
|
||||
- ✅ Clear module boundaries
|
||||
- ✅ Validated task graph before implementation
|
||||
|
||||
## Tips for Best Results
|
||||
|
||||
1. **Spend time on dependency graph** - This is the most valuable section for Task Master
|
||||
2. **Keep features atomic** - Each feature should be independently testable
|
||||
3. **Progressive refinement** - Start broad, use `task-master expand` to break down complex tasks
|
||||
4. **Use research mode** - `task-master parse-prd --research` leverages AI for better task generation
|
||||
</task-master-integration>
|
||||
Reference in New Issue
Block a user