feat: v6.0.0-alpha.0 - the future is now

This commit is contained in:
Brian Madison
2025-09-28 23:17:07 -05:00
parent 52f6889089
commit 0a6a3f3015
747 changed files with 52759 additions and 235199 deletions

View File

@@ -0,0 +1,146 @@
# Technical Decisions Curator
## Purpose
Specialized sub-agent for maintaining and organizing the technical-decisions.md document throughout project lifecycle.
## Capabilities
### Primary Functions
1. **Capture & Append**: Add new technical decisions with proper context
2. **Organize & Categorize**: Structure decisions into logical sections
3. **Deduplicate**: Identify and merge duplicate or conflicting entries
4. **Validate**: Ensure decisions align and don't contradict
5. **Prioritize**: Mark decisions as confirmed vs. preferences vs. constraints
### Decision Categories
- **Confirmed Decisions**: Explicitly agreed technical choices
- **Preferences**: Non-binding preferences mentioned in discussions
- **Constraints**: Hard requirements from infrastructure/compliance
- **To Investigate**: Technical questions needing research
- **Deprecated**: Decisions that were later changed
## Trigger Conditions
### Automatic Triggers
- Any mention of technology, framework, or tool
- Architecture pattern discussions
- Performance or scaling requirements
- Integration or API mentions
- Deployment or infrastructure topics
### Manual Triggers
- User explicitly asks to record a decision
- End of any planning session
- Before transitioning between agents
## Operation Format
### When Capturing
```markdown
## [DATE] - [SESSION/AGENT]
**Context**: [Where/how this came up]
**Decision**: [What was decided/mentioned]
**Type**: [Confirmed/Preference/Constraint/Investigation]
**Rationale**: [Why, if provided]
```
### When Organizing
1. Group related decisions together
2. Elevate confirmed decisions to top
3. Flag conflicts for resolution
4. Summarize patterns (e.g., "Frontend: React ecosystem preferred")
## Integration Points
### Input Sources
- PRD workflow discussions
- Brief creation sessions
- Architecture planning
- Any user conversation mentioning tech
### Output Consumers
- Architecture document creation
- Solution design documents
- Technical story generation
- Development environment setup
## Usage Examples
### Example 1: During PRD Discussion
```
User: "We'll need to integrate with Stripe for payments"
Curator Action: Append to technical-decisions.md:
- **Integration**: Stripe for payment processing (Confirmed - PRD discussion)
```
### Example 2: Casual Mention
```
User: "I've been thinking PostgreSQL would be better than MySQL here"
Curator Action: Append to technical-decisions.md:
- **Database**: PostgreSQL preferred over MySQL (Preference - user consideration)
```
### Example 3: Constraint Discovery
```
User: "We have to use our existing Kubernetes cluster"
Curator Action: Append to technical-decisions.md:
- **Infrastructure**: Must use existing Kubernetes cluster (Constraint - existing infrastructure)
```
## Quality Rules
1. **Never Delete**: Only mark as deprecated, never remove
2. **Always Date**: Every entry needs timestamp
3. **Maintain Context**: Include where/why decision was made
4. **Flag Conflicts**: Don't silently resolve contradictions
5. **Stay Technical**: Don't capture business/product decisions
## File Management
### Initial Creation
If technical-decisions.md doesn't exist:
```markdown
# Technical Decisions
_This document captures all technical decisions, preferences, and constraints discovered during project planning._
---
```
### Maintenance Pattern
- Append new decisions at the end during capture
- Periodically reorganize into sections
- Keep chronological record in addition to organized view
- Archive old decisions when projects complete
## Invocation
The curator can be invoked:
1. **Inline**: During any conversation when tech is mentioned
2. **Batch**: At session end to review and capture
3. **Review**: To organize and clean up existing file
4. **Conflict Resolution**: When contradictions are found
## Success Metrics
- No technical decisions lost between sessions
- Clear traceability of why each technology was chosen
- Smooth handoff to architecture and solution design phases
- Reduced repeated discussions about same technical choices