chore: import upstream snapshot with attribution
This commit is contained in:
wehub-resource-sync
@@ -0,0 +1,414 @@
|
||||
# Orchestration Archive Command
|
||||
|
||||
Properly archive completed orchestrations while preserving valuable data, metrics, and lessons learned for future reference.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/orchestration/archive [options]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Manages the archival process for completed orchestrations, extracting insights, preserving critical data, and organizing historical information for future analysis and learning.
|
||||
|
||||
## Basic Commands
|
||||
|
||||
### Archive Completed Orchestrations
|
||||
```
|
||||
/orchestration/archive
|
||||
```
|
||||
Identifies and archives all fully completed orchestrations automatically.
|
||||
|
||||
### Archive Specific Orchestration
|
||||
```
|
||||
/orchestration/archive --date 03_15_2024 --project auth_system
|
||||
```
|
||||
Archives a specific orchestration with full data preservation.
|
||||
|
||||
### Archive with Analysis
|
||||
```
|
||||
/orchestration/archive --analyze
|
||||
```
|
||||
Performs comprehensive analysis before archiving, extracting lessons learned.
|
||||
|
||||
## Archival Process
|
||||
|
||||
### Pre-Archive Analysis
|
||||
```
|
||||
## Pre-Archive Analysis for: auth_system (03_15_2024)
|
||||
|
||||
Completion Status:
|
||||
- Total Tasks: 24 (24 completed, 0 active)
|
||||
- Duration: 8 days (estimated: 6 days)
|
||||
- Final Velocity: 3.0 tasks/day
|
||||
- Quality Score: 92% (2 QA iterations avg)
|
||||
|
||||
Outstanding Items:
|
||||
- No active tasks
|
||||
- No blocked dependencies
|
||||
- Git branches: 3 merged, 0 pending
|
||||
- Documentation: Complete
|
||||
|
||||
Ready for Archive: ✓
|
||||
```
|
||||
|
||||
### Data Extraction
|
||||
```
|
||||
## Extracting Archive Data
|
||||
|
||||
Performance Metrics:
|
||||
✓ Task completion times
|
||||
✓ Velocity calculations
|
||||
✓ Quality metrics
|
||||
✓ Resource utilization
|
||||
✓ Dependency patterns
|
||||
|
||||
Project Artifacts:
|
||||
✓ All task files and metadata
|
||||
✓ Git commit history correlation
|
||||
✓ Status transition logs
|
||||
✓ Agent assignment patterns
|
||||
|
||||
Learning Points:
|
||||
✓ What worked well
|
||||
✓ Pain points and bottlenecks
|
||||
✓ Estimation accuracy
|
||||
✓ Team collaboration insights
|
||||
```
|
||||
|
||||
### Archive Structure
|
||||
```
|
||||
/archived-orchestrations/
|
||||
└── 2024/
|
||||
└── Q1/
|
||||
└── 03_15_2024_auth_system/
|
||||
├── ARCHIVE-SUMMARY.md
|
||||
├── LESSONS-LEARNED.md
|
||||
├── METRICS-REPORT.json
|
||||
├── original-files/
|
||||
│ ├── MASTER-COORDINATION.md
|
||||
│ ├── EXECUTION-TRACKER.md
|
||||
│ ├── TASK-STATUS-TRACKER.yaml
|
||||
│ └── tasks/
|
||||
├── analytics/
|
||||
│ ├── velocity-chart.png
|
||||
│ ├── dependency-graph.svg
|
||||
│ └── timeline-visualization.html
|
||||
└── git-correlation/
|
||||
├── commit-task-mapping.json
|
||||
└── branch-analysis.md
|
||||
```
|
||||
|
||||
## Archive Options
|
||||
|
||||
### Quick Archive
|
||||
```
|
||||
/orchestration/archive --quick
|
||||
```
|
||||
Fast archival without detailed analysis, suitable for simple orchestrations.
|
||||
|
||||
### Deep Analysis Archive
|
||||
```
|
||||
/orchestration/archive --deep-analysis
|
||||
```
|
||||
Comprehensive analysis including:
|
||||
- Detailed performance metrics
|
||||
- Pattern recognition
|
||||
- Predictive insights
|
||||
- Comparative analysis with similar projects
|
||||
|
||||
### Selective Archive
|
||||
```
|
||||
/orchestration/archive --include tasks,metrics --exclude original-files
|
||||
```
|
||||
Custom archive content selection.
|
||||
|
||||
## Analysis Features
|
||||
|
||||
### Performance Analysis
|
||||
```
|
||||
## Performance Analysis Summary
|
||||
|
||||
Velocity Analysis:
|
||||
- Peak velocity: 4.2 tasks/day (Day 3)
|
||||
- Average velocity: 3.0 tasks/day
|
||||
- Velocity trend: Stable with 15% improvement over time
|
||||
|
||||
Task Metrics:
|
||||
- Average task duration: 3.8h (vs 4.0h estimated)
|
||||
- Estimation accuracy: 87% (excellent)
|
||||
- Most accurate estimates: Backend tasks (95%)
|
||||
- Least accurate estimates: UI tasks (72%)
|
||||
|
||||
Quality Metrics:
|
||||
- First-pass QA success: 78%
|
||||
- Average QA iterations: 1.3
|
||||
- Zero critical bugs in production
|
||||
- Documentation completeness: 95%
|
||||
```
|
||||
|
||||
### Team Performance
|
||||
```
|
||||
## Team Performance Insights
|
||||
|
||||
Agent Effectiveness:
|
||||
┌─────────────────┬──────────────┬─────────────┬──────────────┐
|
||||
│ Agent │ Tasks Done │ Avg Duration│ Quality Score│
|
||||
├─────────────────┼──────────────┼─────────────┼──────────────┤
|
||||
│ dev-backend │ 12 tasks │ 3.2h │ 94% │
|
||||
│ dev-frontend │ 8 tasks │ 4.1h │ 89% │
|
||||
│ qa-engineer │ 4 reviews │ 1.5h │ 96% │
|
||||
│ test-developer │ 6 tasks │ 2.8h │ 91% │
|
||||
└─────────────────┴──────────────┴─────────────┴──────────────┘
|
||||
|
||||
Collaboration Patterns:
|
||||
- Cross-functional tasks: 20% of total
|
||||
- Pair programming events: 8 instances
|
||||
- Knowledge transfer sessions: 3 sessions
|
||||
- Optimal team size: 4 agents (confirmed)
|
||||
```
|
||||
|
||||
### Lessons Learned Extraction
|
||||
```
|
||||
## Lessons Learned
|
||||
|
||||
What Worked Well:
|
||||
1. Early dependency identification prevented major blocks
|
||||
2. JWT implementation pattern reusable for future auth projects
|
||||
3. Parallel testing approach reduced QA bottlenecks
|
||||
4. Daily standup format kept team aligned
|
||||
|
||||
Pain Points:
|
||||
1. OAuth provider documentation was incomplete (external factor)
|
||||
2. Database schema changes mid-project caused 1-day delay
|
||||
3. Test environment instability affected 3 tasks
|
||||
4. Frontend-backend API contract unclear initially
|
||||
|
||||
Process Improvements:
|
||||
1. Add API contract review gate before implementation
|
||||
2. Implement test environment monitoring
|
||||
3. Create OAuth integration template for future use
|
||||
4. Add database change impact assessment
|
||||
|
||||
Estimation Insights:
|
||||
- Security tasks consistently underestimated by 25%
|
||||
- UI tasks with new libraries take 40% longer
|
||||
- Integration tasks require 20% buffer for external dependencies
|
||||
- Testing parallel to development saves 30% overall time
|
||||
```
|
||||
|
||||
## Archive Validation
|
||||
|
||||
### Completeness Check
|
||||
```
|
||||
## Archive Completeness Validation
|
||||
|
||||
Required Data:
|
||||
✓ All 24 task files preserved
|
||||
✓ Status tracking history complete
|
||||
✓ Git commit correlation verified
|
||||
✓ Performance metrics calculated
|
||||
✓ Agent assignments recorded
|
||||
|
||||
Data Integrity:
|
||||
✓ No corrupted files detected
|
||||
✓ Timeline consistency verified
|
||||
✓ Dependency graph validated
|
||||
✓ Metrics calculations confirmed
|
||||
|
||||
Archive Quality: 100% Complete
|
||||
```
|
||||
|
||||
### Historical Correlation
|
||||
```
|
||||
## Historical Correlation Analysis
|
||||
|
||||
Similar Projects Comparison:
|
||||
- user_management (02_20_2024): 85% similar
|
||||
- payment_system (01_15_2024): 60% similar
|
||||
- admin_dashboard (03_01_2024): 45% similar
|
||||
|
||||
Performance Comparison:
|
||||
- This project: 3.0 tasks/day (above average)
|
||||
- Team average: 2.7 tasks/day
|
||||
- Best performance: 3.4 tasks/day (payment_system)
|
||||
- Worst performance: 2.1 tasks/day (admin_dashboard)
|
||||
|
||||
Learning Application Opportunities:
|
||||
- Apply JWT pattern to upcoming mobile_auth project
|
||||
- Use dependency analysis template for API projects
|
||||
- Replicate testing strategy for integration-heavy work
|
||||
```
|
||||
|
||||
## Archive Formats
|
||||
|
||||
### Standard Archive
|
||||
```
|
||||
/orchestration/archive --format standard
|
||||
```
|
||||
Creates structured archive with all essential data and analysis.
|
||||
|
||||
### Lightweight Archive
|
||||
```
|
||||
/orchestration/archive --format light
|
||||
```
|
||||
Minimal archive with key metrics and lessons learned only.
|
||||
|
||||
### Research Archive
|
||||
```
|
||||
/orchestration/archive --format research
|
||||
```
|
||||
Comprehensive archive suitable for academic research or deep analysis.
|
||||
|
||||
### Template Archive
|
||||
```
|
||||
/orchestration/archive --format template
|
||||
```
|
||||
Creates reusable templates from successful patterns.
|
||||
|
||||
## Query and Retrieval
|
||||
|
||||
### Search Archives
|
||||
```
|
||||
/orchestration/archive --search "JWT authentication"
|
||||
```
|
||||
Finds archived orchestrations with similar requirements.
|
||||
|
||||
### Compare Archives
|
||||
```
|
||||
/orchestration/archive --compare 03_15_2024 02_20_2024
|
||||
```
|
||||
Detailed comparison between two archived orchestrations.
|
||||
|
||||
### Extract Templates
|
||||
```
|
||||
/orchestration/archive --extract-template auth_system
|
||||
```
|
||||
Creates orchestration template from successful archive.
|
||||
|
||||
## Integration Features
|
||||
|
||||
### Metrics Dashboard
|
||||
```
|
||||
/orchestration/archive --dashboard
|
||||
```
|
||||
Generates visual dashboard of archived orchestration metrics.
|
||||
|
||||
### Knowledge Base
|
||||
```
|
||||
/orchestration/archive --knowledge-base
|
||||
```
|
||||
Integrates lessons learned into searchable knowledge base.
|
||||
|
||||
### Predictive Analysis
|
||||
```
|
||||
/orchestration/archive --predict similar_to:auth_system
|
||||
```
|
||||
Uses archived data to predict outcomes for similar future projects.
|
||||
|
||||
## Automation Options
|
||||
|
||||
### Auto-Archive Completed
|
||||
```
|
||||
/orchestration/archive --auto-schedule weekly
|
||||
```
|
||||
Automatically archives completed orchestrations weekly.
|
||||
|
||||
### Smart Archive Rules
|
||||
```
|
||||
/orchestration/archive --rules "age:>30days status:completed"
|
||||
```
|
||||
Archives orchestrations meeting specific criteria.
|
||||
|
||||
### Archive Notifications
|
||||
```
|
||||
/orchestration/archive --notify team@company.com
|
||||
```
|
||||
Sends archive completion notifications with key insights.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Standard Project Archive
|
||||
```
|
||||
/orchestration/archive --date 03_15_2024 --project auth_system --analyze
|
||||
```
|
||||
|
||||
### Example 2: Batch Archive Completed
|
||||
```
|
||||
/orchestration/archive --all-completed --since "last month"
|
||||
```
|
||||
|
||||
### Example 3: Create Project Template
|
||||
```
|
||||
/orchestration/archive --date 03_15_2024 --create-template auth_pattern
|
||||
```
|
||||
|
||||
### Example 4: Research Analysis
|
||||
```
|
||||
/orchestration/archive --search "authentication" --analyze-patterns
|
||||
```
|
||||
|
||||
## Storage Management
|
||||
|
||||
### Archive Location
|
||||
```
|
||||
Default: ./archived-orchestrations/
|
||||
Custom: /orchestration/archive --location /shared/archives/
|
||||
```
|
||||
|
||||
### Compression Options
|
||||
```
|
||||
/orchestration/archive --compress high
|
||||
```
|
||||
Reduces storage requirements while preserving data integrity.
|
||||
|
||||
### Retention Policies
|
||||
```
|
||||
/orchestration/archive --retention "keep:2years delete:metrics-only"
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Archive Regularly**: Don't let completed orchestrations accumulate
|
||||
2. **Analyze Before Archive**: Extract maximum learning value
|
||||
3. **Preserve Context**: Include sufficient context for future reference
|
||||
4. **Template Creation**: Convert successful patterns to templates
|
||||
5. **Team Review**: Share insights before archiving
|
||||
6. **Search Optimization**: Use consistent tagging and keywords
|
||||
|
||||
## Configuration
|
||||
|
||||
### Archive Settings
|
||||
```yaml
|
||||
archive:
|
||||
auto_archive_after: "30 days"
|
||||
analysis_depth: "standard"
|
||||
preserve_git_history: true
|
||||
create_visualizations: true
|
||||
retention_period: "2 years"
|
||||
compression_level: "medium"
|
||||
```
|
||||
|
||||
## Recovery Options
|
||||
|
||||
### Restore from Archive
|
||||
```
|
||||
/orchestration/archive --restore 03_15_2024_auth_system
|
||||
```
|
||||
Restores archived orchestration to active state (rare use case).
|
||||
|
||||
### Extract Specific Data
|
||||
```
|
||||
/orchestration/archive --extract metrics 03_15_2024_auth_system
|
||||
```
|
||||
Retrieves specific data from archived orchestration.
|
||||
|
||||
## Notes
|
||||
|
||||
- Archived orchestrations are read-only by default
|
||||
- All archive operations are logged for audit purposes
|
||||
- Archive analysis improves over time with machine learning
|
||||
- Templates created from archives are immediately usable
|
||||
- Archived data contributes to predictive orchestration models
|
||||
- Integration with external backup systems supported
|
||||
@@ -0,0 +1,305 @@
|
||||
# Orchestration Commit Command
|
||||
|
||||
Create git commits aligned with task completion, maintaining clean version control synchronized with task progress.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/orchestration/commit [TASK-ID] [options]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Automatically creates well-structured commits when tasks move to QA or completion, using task metadata to generate meaningful commit messages following Conventional Commits specification.
|
||||
|
||||
## Basic Commands
|
||||
|
||||
### Commit Current Task
|
||||
```
|
||||
/orchestration/commit
|
||||
```
|
||||
Commits changes for the task currently in progress.
|
||||
|
||||
### Commit Specific Task
|
||||
```
|
||||
/orchestration/commit TASK-003
|
||||
```
|
||||
Commits changes related to a specific task.
|
||||
|
||||
### Batch Commit
|
||||
```
|
||||
/orchestration/commit --batch
|
||||
```
|
||||
Groups related completed tasks into logical commits.
|
||||
|
||||
## Commit Message Generation
|
||||
|
||||
### Automatic Format
|
||||
Based on task type and content:
|
||||
```
|
||||
feat(auth): implement JWT token validation
|
||||
|
||||
- Add token verification middleware
|
||||
- Implement refresh token logic
|
||||
- Add expiration handling
|
||||
|
||||
Task: TASK-003
|
||||
Status: todos -> in_progress -> qa
|
||||
Time: 4.5 hours
|
||||
```
|
||||
|
||||
### Type Mapping
|
||||
```
|
||||
Task Type -> Commit Type
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
feature -> feat:
|
||||
bugfix -> fix:
|
||||
refactor -> refactor:
|
||||
test -> test:
|
||||
docs -> docs:
|
||||
performance -> perf:
|
||||
security -> fix: (with security note)
|
||||
```
|
||||
|
||||
## Workflow Integration
|
||||
|
||||
### Auto-commit on Status Change
|
||||
```
|
||||
/orchestration/move TASK-003 qa --auto-commit
|
||||
```
|
||||
Automatically commits when moving to QA status.
|
||||
|
||||
### Pre-commit Validation
|
||||
```
|
||||
/orchestration/commit --validate
|
||||
```
|
||||
Checks:
|
||||
- All tests pass
|
||||
- No linting errors
|
||||
- Task requirements met
|
||||
- Files match task scope
|
||||
|
||||
## Options
|
||||
|
||||
### Custom Message
|
||||
```
|
||||
/orchestration/commit TASK-003 --message "Custom commit message"
|
||||
```
|
||||
Override automatic message generation.
|
||||
|
||||
### Scope Detection
|
||||
```
|
||||
/orchestration/commit --detect-scope
|
||||
```
|
||||
Automatically detects scope from changed files:
|
||||
- `auth` for auth-related files
|
||||
- `api` for API changes
|
||||
- `ui` for frontend changes
|
||||
|
||||
### Breaking Changes
|
||||
```
|
||||
/orchestration/commit --breaking
|
||||
```
|
||||
Adds breaking change indicator:
|
||||
```
|
||||
feat(api)!: restructure authentication endpoints
|
||||
|
||||
BREAKING CHANGE: Auth endpoints moved from /auth to /api/v2/auth
|
||||
```
|
||||
|
||||
## Batch Operations
|
||||
|
||||
### Commit by Feature
|
||||
```
|
||||
/orchestration/commit --feature authentication
|
||||
```
|
||||
Groups all completed auth tasks into one commit.
|
||||
|
||||
### Commit by Status
|
||||
```
|
||||
/orchestration/commit --status qa
|
||||
```
|
||||
Commits all tasks currently in QA.
|
||||
|
||||
### Smart Grouping
|
||||
```
|
||||
/orchestration/commit --smart-group
|
||||
```
|
||||
Intelligently groups related tasks:
|
||||
```
|
||||
Feature Group: Authentication (3 tasks)
|
||||
- TASK-001: Database schema
|
||||
- TASK-003: JWT implementation
|
||||
- TASK-005: Login endpoint
|
||||
|
||||
Suggested commit: feat(auth): implement complete authentication system
|
||||
```
|
||||
|
||||
## Worktree Support
|
||||
|
||||
### Worktree-Aware Commits
|
||||
```
|
||||
/orchestration/commit --worktree
|
||||
```
|
||||
Detects current worktree and commits only relevant tasks.
|
||||
|
||||
### Cross-Worktree Status
|
||||
```
|
||||
/orchestration/commit --all-worktrees
|
||||
```
|
||||
Shows commit status across all worktrees:
|
||||
```
|
||||
Worktree Status:
|
||||
- feature/auth: 2 tasks ready to commit
|
||||
- feature/payments: 1 task ready to commit
|
||||
- feature/ui: No uncommitted changes
|
||||
```
|
||||
|
||||
## Validation Features
|
||||
|
||||
### Pre-commit Checks
|
||||
```
|
||||
## Pre-commit Validation
|
||||
✓ All tests passing
|
||||
✓ No linting errors
|
||||
✓ Task requirements met
|
||||
✗ Uncommitted files outside task scope: src/unrelated.js
|
||||
|
||||
Proceed with commit? [y/n]
|
||||
```
|
||||
|
||||
### Task Alignment
|
||||
```
|
||||
## Task Alignment Check
|
||||
Changed files:
|
||||
- src/auth/jwt.ts ✓ (matches TASK-003)
|
||||
- src/auth/validate.ts ✓ (matches TASK-003)
|
||||
- src/payments/stripe.ts ✗ (not in TASK-003 scope)
|
||||
|
||||
Warning: Changes outside task scope detected
|
||||
```
|
||||
|
||||
## Integration Features
|
||||
|
||||
### Link to Task
|
||||
```
|
||||
/orchestration/commit --link-task
|
||||
```
|
||||
Adds task URL/reference to commit:
|
||||
```
|
||||
feat(auth): implement JWT validation
|
||||
|
||||
Task: TASK-003
|
||||
Link: http://orchestration/03_15_2024/auth_system/tasks/TASK-003
|
||||
```
|
||||
|
||||
### Update Status Tracker
|
||||
```
|
||||
/orchestration/commit --update-tracker
|
||||
```
|
||||
Updates TASK-STATUS-TRACKER.yaml with commit info:
|
||||
```yaml
|
||||
git_tracking:
|
||||
TASK-003:
|
||||
commits: ["abc123def"]
|
||||
commit_message: "feat(auth): implement JWT validation"
|
||||
committed_at: "2024-03-15T14:30:00Z"
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Simple Task Commit
|
||||
```
|
||||
/orchestration/commit TASK-003
|
||||
|
||||
Generated commit:
|
||||
feat(auth): implement JWT token validation
|
||||
|
||||
- Add verification middleware
|
||||
- Handle token expiration
|
||||
- Implement refresh logic
|
||||
|
||||
Task: TASK-003 (4.5 hours)
|
||||
```
|
||||
|
||||
### Example 2: Batch Feature Commit
|
||||
```
|
||||
/orchestration/commit --feature authentication --batch
|
||||
|
||||
Grouping 3 related tasks:
|
||||
feat(auth): complete authentication system implementation
|
||||
|
||||
- Set up database schema (TASK-001)
|
||||
- Implement JWT validation (TASK-003)
|
||||
- Create login endpoints (TASK-005)
|
||||
|
||||
Tasks: TASK-001, TASK-003, TASK-005 (12 hours total)
|
||||
```
|
||||
|
||||
### Example 3: Fix with Test
|
||||
```
|
||||
/orchestration/commit TASK-007
|
||||
|
||||
Generated commit:
|
||||
fix(auth): resolve token expiration race condition
|
||||
|
||||
- Fix async validation timing issue
|
||||
- Add comprehensive test coverage
|
||||
- Prevent edge case in refresh flow
|
||||
|
||||
Fixes: #123
|
||||
Task: TASK-007 (2 hours)
|
||||
```
|
||||
|
||||
## Commit Templates
|
||||
|
||||
### Feature Template
|
||||
```
|
||||
feat(<scope>): <task-title>
|
||||
|
||||
- <implementation-detail-1>
|
||||
- <implementation-detail-2>
|
||||
- <implementation-detail-3>
|
||||
|
||||
Task: <task-id> (<duration>)
|
||||
Status: <status-transition>
|
||||
```
|
||||
|
||||
### Fix Template
|
||||
```
|
||||
fix(<scope>): <issue-description>
|
||||
|
||||
- <root-cause>
|
||||
- <solution>
|
||||
- <test-coverage>
|
||||
|
||||
Fixes: #<issue-number>
|
||||
Task: <task-id>
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Commit at Natural Breakpoints**: When moving tasks to QA
|
||||
2. **Keep Commits Atomic**: One logical change per commit
|
||||
3. **Use Batch Wisely**: Only group truly related tasks
|
||||
4. **Validate First**: Always run validation before committing
|
||||
5. **Update Status**: Ensure task status is current
|
||||
|
||||
## Configuration
|
||||
|
||||
### Auto-commit Rules
|
||||
Set in orchestration config:
|
||||
```yaml
|
||||
auto_commit:
|
||||
on_qa: true
|
||||
on_complete: false
|
||||
require_tests: true
|
||||
require_validation: true
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- Integrates with task-commit-manager agent for complex scenarios
|
||||
- Respects .gitignore and excluded files
|
||||
- Supports conventional commits specification
|
||||
- Maintains traceable history between tasks and commits
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
description: "Turn ideas into fully formed designs and specs through natural collaborative dialogue. Use before implementing new features or making significant changes."
|
||||
argument-hint: Optional feature description
|
||||
allowed-tools: Read, Write, Grep, Glob, Bash, TodoWrite, AskUserQuestion, Skill, Task
|
||||
---
|
||||
|
||||
## Phase 1: Discovery
|
||||
|
||||
**Goal**: Understand what needs to be built
|
||||
|
||||
Initial request: $ARGUMENTS
|
||||
|
||||
**Actions**:
|
||||
1. Create todo list with all phases
|
||||
2. If feature unclear, ask user for:
|
||||
- What problem are they solving?
|
||||
- What should the feature do?
|
||||
- Any constraints or requirements?
|
||||
3. Summarize understanding and confirm with user
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Run with Feature Analyzer Skill
|
||||
|
||||
Use the Skill tool to invoke the "feature-design-assistant" skill and follow its complete process.
|
||||
@@ -0,0 +1,167 @@
|
||||
---
|
||||
description: Guided feature development with codebase understanding and architecture focus
|
||||
argument-hint: Optional feature description
|
||||
---
|
||||
|
||||
# Feature Development
|
||||
|
||||
You are helping a developer implement a new feature. Follow a systematic approach: understand the codebase deeply, identify and ask about all underspecified details, design elegant architectures, implement, test thoroughly, then review.
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **Ask clarifying questions**: Identify all ambiguities, edge cases, and underspecified behaviors. Ask specific, concrete questions rather than making assumptions. Wait for user answers before proceeding with implementation. Ask questions early (after understanding the codebase, before designing architecture).
|
||||
- **Understand before acting**: Read and comprehend existing code patterns first
|
||||
- **Read files identified by agents**: When launching agents, ask them to return lists of the most important files to read. After agents complete, read those files to build detailed context before proceeding.
|
||||
- **Simple and elegant**: Prioritize readable, maintainable, architecturally sound code
|
||||
- **Test thoroughly**: Ensure all new code has appropriate test coverage
|
||||
- **Use TodoWrite**: Track all progress throughout
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Discovery
|
||||
|
||||
**Goal**: Understand what needs to be built
|
||||
|
||||
Initial request: $ARGUMENTS
|
||||
|
||||
**Actions**:
|
||||
1. Create todo list with all phases
|
||||
2. If feature unclear, ask user for:
|
||||
- What problem are they solving?
|
||||
- What should the feature do?
|
||||
- Any constraints or requirements?
|
||||
3. Summarize understanding and confirm with user
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Codebase Exploration
|
||||
|
||||
**Goal**: Understand relevant existing code and patterns at both high and low levels
|
||||
|
||||
**Actions**:
|
||||
1. Launch 2-3 code-explorer agents in parallel. Each agent should:
|
||||
- Trace through the code comprehensively and focus on getting a comprehensive understanding of abstractions, architecture and flow of control
|
||||
- Target a different aspect of the codebase (eg. similar features, high level understanding, architectural understanding, user experience, etc)
|
||||
- Include a list of 5-10 key files to read
|
||||
|
||||
**Example agent prompts**:
|
||||
- "Find features similar to [feature] and trace through their implementation comprehensively"
|
||||
- "Map the architecture and abstractions for [feature area], tracing through the code comprehensively"
|
||||
- "Analyze the current implementation of [existing feature/area], tracing through the code comprehensively"
|
||||
- "Identify UI patterns, testing approaches, or extension points relevant to [feature]"
|
||||
|
||||
2. Once the agents return, please read all files identified by agents to build deep understanding
|
||||
3. Present comprehensive summary of findings and patterns discovered
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Clarifying Questions
|
||||
|
||||
**Goal**: Fill in gaps and resolve all ambiguities before designing
|
||||
|
||||
**CRITICAL**: This is one of the most important phases. DO NOT SKIP.
|
||||
|
||||
**Actions**:
|
||||
1. Review the codebase findings and original feature request
|
||||
2. Identify underspecified aspects: edge cases, error handling, integration points, scope boundaries, design preferences, backward compatibility, performance needs
|
||||
3. **Present all questions to the user in a clear, organized list**
|
||||
4. **Wait for answers before proceeding to architecture design**
|
||||
|
||||
If the user says "whatever you think is best", provide your recommendation and get explicit confirmation.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Architecture Design
|
||||
|
||||
**Goal**: Design multiple implementation approaches with different trade-offs
|
||||
|
||||
**Actions**:
|
||||
1. Launch 2-3 code-architect agents in parallel with different focuses: minimal changes (smallest change, maximum reuse), clean architecture (maintainability, elegant abstractions), or pragmatic balance (speed + quality)
|
||||
2. Review all approaches and form your opinion on which fits best for this specific task (consider: small fix vs large feature, urgency, complexity, team context)
|
||||
3. Present to user: brief summary of each approach, trade-offs comparison, **your recommendation with reasoning**, concrete implementation differences
|
||||
4. **Ask user which approach they prefer**
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Implementation
|
||||
|
||||
**Goal**: Build the feature
|
||||
|
||||
**DO NOT START WITHOUT USER APPROVAL**
|
||||
|
||||
**Actions**:
|
||||
1. Wait for explicit user approval
|
||||
2. Read all relevant files identified in previous phases
|
||||
3. Implement following chosen architecture
|
||||
4. Follow codebase conventions strictly
|
||||
5. Write clean, well-documented code
|
||||
6. Update todos as you progress
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: Automated Testing
|
||||
|
||||
**Goal**: Ensure comprehensive test coverage and all tests pass
|
||||
|
||||
**Actions**:
|
||||
1. **Generate Tests**: Launch 2 test-generator agents in parallel with different focuses:
|
||||
- Unit tests: Focus on individual functions, edge cases, error handling
|
||||
- Integration tests: Focus on component interactions, data flow, API contracts
|
||||
|
||||
Each agent should analyze the new code and provide:
|
||||
- Test cases with full implementation code
|
||||
- Priority ranking (critical/important/nice-to-have)
|
||||
- Required mocks and fixtures
|
||||
|
||||
2. **Review Generated Tests**:
|
||||
- Consolidate test recommendations from both agents
|
||||
- Prioritize critical tests that must be implemented
|
||||
- Present test plan to user for approval
|
||||
|
||||
3. **Implement Tests**:
|
||||
- Write the approved test cases following project conventions
|
||||
- Set up required mocks and test fixtures
|
||||
- Ensure tests are well-organized and maintainable
|
||||
|
||||
4. **Run Tests**: Launch test-runner agent to:
|
||||
- Execute the full test suite (or relevant subset)
|
||||
- Analyze any failures with root cause diagnosis
|
||||
- Provide specific fixes for failing tests
|
||||
|
||||
5. **Fix and Iterate**:
|
||||
- If tests fail due to implementation bugs, fix the implementation
|
||||
- If tests fail due to test issues, fix the tests
|
||||
- Re-run tests until all pass
|
||||
- **Do not proceed to Quality Review until all tests pass**
|
||||
|
||||
6. **Report Coverage**: Summarize test coverage achieved and any gaps
|
||||
|
||||
---
|
||||
|
||||
## Phase 7: Quality Review
|
||||
|
||||
**Goal**: Ensure code is simple, DRY, elegant, easy to read, and functionally correct
|
||||
|
||||
**Actions**:
|
||||
1. Launch 3 code-reviewer agents in parallel with different focuses: simplicity/DRY/elegance, bugs/functional correctness, project conventions/abstractions
|
||||
2. Consolidate findings and identify highest severity issues that you recommend fixing
|
||||
3. **Present findings to user and ask what they want to do** (fix now, fix later, or proceed as-is)
|
||||
4. Address issues based on user decision
|
||||
5. If significant changes were made, re-run tests using test-runner agent to ensure nothing broke
|
||||
|
||||
---
|
||||
|
||||
## Phase 8: Summary
|
||||
|
||||
**Goal**: Document what was accomplished
|
||||
|
||||
**Actions**:
|
||||
1. Mark all todos complete
|
||||
2. Summarize:
|
||||
- What was built
|
||||
- Key decisions made
|
||||
- Files modified
|
||||
- Test coverage achieved
|
||||
- Suggested next steps
|
||||
|
||||
---
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
description: Execute implementation tasks from a design document. Tasks are tracked as markdown checkboxes directly in the design file.
|
||||
argument-hint: <design-file.md>
|
||||
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, TodoWrite, Task, AskUserQuestion
|
||||
---
|
||||
|
||||
# Feature Pipeline
|
||||
|
||||
Execute implementation tasks from a design document using markdown checkboxes.
|
||||
|
||||
## Input Detection
|
||||
|
||||
`$ARGUMENTS` should be a path to a design markdown file (e.g., `docs/designs/xxx.md`)
|
||||
|
||||
If empty or unclear, ask user for the design file path.
|
||||
|
||||
## Phase 1: Initialize
|
||||
|
||||
1. Read the design file
|
||||
2. Run `python3 .claude/skills/task-execution-engine/scripts/task_manager.py status --file <design.md>` to show current progress
|
||||
3. If all tasks completed, report and exit
|
||||
4. Otherwise, proceed to execution
|
||||
|
||||
## Phase 2: Execution Loop
|
||||
|
||||
**UNATTENDED MODE - No questions, no stopping**
|
||||
|
||||
```
|
||||
LOOP:
|
||||
1. RUN: task_manager.py next --file <design.md> --json
|
||||
2. IF no task available → EXIT to Phase 3
|
||||
3. READ task details (files, criteria)
|
||||
4. IMPLEMENT the task
|
||||
- Create/modify files as specified
|
||||
- Follow codebase patterns
|
||||
- Run tests if applicable
|
||||
5. VERIFY acceptance criteria
|
||||
6. UPDATE status:
|
||||
- Success: task_manager.py done --file <design.md> --task "Title"
|
||||
- Failure: task_manager.py fail --file <design.md> --task "Title" --reason "..."
|
||||
7. OUTPUT result summary
|
||||
8. CONTINUE (go to step 1)
|
||||
```
|
||||
|
||||
## Phase 3: Completion
|
||||
|
||||
1. Run `task_manager.py status --file <design.md>` to show final summary
|
||||
2. Report:
|
||||
- Tasks completed
|
||||
- Tasks failed (with reasons)
|
||||
- Files modified
|
||||
3. Ask if user wants to commit changes to git
|
||||
|
||||
## Implementation Guidelines
|
||||
|
||||
### For Each Task:
|
||||
|
||||
1. **Read files** specified in task's `files:` line
|
||||
2. **Understand criteria** from the checkbox items
|
||||
3. **Implement** following existing codebase patterns
|
||||
4. **Verify** each acceptance criterion is met
|
||||
5. **Update** the design file with completion status
|
||||
|
||||
### Decision Making:
|
||||
|
||||
- If unclear about implementation details → use codebase patterns
|
||||
- If blocked by missing dependency → mark as failed, continue
|
||||
- If needs external resource → mark as failed with reason, continue
|
||||
|
||||
### Status Updates:
|
||||
|
||||
```bash
|
||||
# Mark task completed (updates checkbox to [x] ✅)
|
||||
python3 .claude/skills/task-execution-engine/scripts/task_manager.py done \
|
||||
--file <design.md> --task "Task Title"
|
||||
|
||||
# Mark task failed (updates checkbox to [x] ❌ with reason)
|
||||
python3 .claude/skills/task-execution-engine/scripts/task_manager.py fail \
|
||||
--file <design.md> --task "Task Title" --reason "Error description"
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
After each task:
|
||||
|
||||
```
|
||||
---TASK RESULT---
|
||||
task: Task Title
|
||||
status: completed|failed
|
||||
files: [list of modified files]
|
||||
notes: Brief description
|
||||
---END TASK RESULT---
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Error | Action |
|
||||
|-------|--------|
|
||||
| Task implementation fails | Mark failed, continue to next |
|
||||
| Script error | Log error, retry once, then fail task |
|
||||
| No tasks available | Exit loop, show summary |
|
||||
| File not found | Ask user for correct path |
|
||||
|
||||
## Key Rules
|
||||
|
||||
1. **NEVER stop** in the middle of execution loop
|
||||
2. **NEVER ask** questions during execution
|
||||
3. **ALWAYS** update task status in design file
|
||||
4. **Exit only** when no pending tasks remain
|
||||
@@ -0,0 +1,272 @@
|
||||
# Task Find Command
|
||||
|
||||
Search and locate tasks across all orchestrations using various criteria.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/task-find [search-term] [options]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Powerful search functionality to quickly locate tasks by ID, content, status, dependencies, or any other criteria. Supports regex, fuzzy matching, and complex queries.
|
||||
|
||||
## Basic Search
|
||||
|
||||
### By Task ID
|
||||
```
|
||||
/task-find TASK-001
|
||||
/task-find TASK-*
|
||||
```
|
||||
|
||||
### By Title/Content
|
||||
```
|
||||
/task-find "authentication"
|
||||
/task-find "payment processing"
|
||||
```
|
||||
|
||||
### By Status
|
||||
```
|
||||
/task-find --status in_progress
|
||||
/task-find --status qa,completed
|
||||
```
|
||||
|
||||
## Advanced Search
|
||||
|
||||
### Regular Expression
|
||||
```
|
||||
/task-find --regex "JWT|OAuth"
|
||||
/task-find --regex "TASK-0[0-9]{2}"
|
||||
```
|
||||
|
||||
### Fuzzy Search
|
||||
```
|
||||
/task-find --fuzzy "autentication" # finds "authentication"
|
||||
/task-find --fuzzy "paymnt" # finds "payment"
|
||||
```
|
||||
|
||||
### Multiple Criteria
|
||||
```
|
||||
/task-find --status todos --priority high --type feature
|
||||
/task-find --agent dev-backend --created-after yesterday
|
||||
```
|
||||
|
||||
## Search Operators
|
||||
|
||||
### Boolean Operators
|
||||
```
|
||||
/task-find "auth AND login"
|
||||
/task-find "payment OR billing"
|
||||
/task-find "security NOT test"
|
||||
```
|
||||
|
||||
### Field-Specific Search
|
||||
```
|
||||
/task-find title:"user authentication"
|
||||
/task-find description:"security vulnerability"
|
||||
/task-find agent:dev-frontend
|
||||
/task-find blocks:TASK-001
|
||||
```
|
||||
|
||||
### Date Ranges
|
||||
```
|
||||
/task-find --created "2024-03-10..2024-03-15"
|
||||
/task-find --modified "last 3 days"
|
||||
/task-find --completed "this week"
|
||||
```
|
||||
|
||||
## Output Formats
|
||||
|
||||
### Default List View
|
||||
```
|
||||
Found 3 tasks matching "authentication":
|
||||
|
||||
TASK-001: Implement JWT authentication
|
||||
Status: in_progress | Agent: dev-frontend | Created: 2024-03-15
|
||||
Location: /task-orchestration/03_15_2024/auth_system/tasks/in_progress/
|
||||
|
||||
TASK-004: Add OAuth2 authentication
|
||||
Status: todos | Priority: high | Blocked by: TASK-001
|
||||
Location: /task-orchestration/03_15_2024/auth_system/tasks/todos/
|
||||
|
||||
TASK-007: Authentication middleware tests
|
||||
Status: todos | Type: test | Depends on: TASK-001
|
||||
Location: /task-orchestration/03_15_2024/auth_system/tasks/todos/
|
||||
```
|
||||
|
||||
### Detailed View
|
||||
```
|
||||
/task-find TASK-001 --detailed
|
||||
```
|
||||
Shows full task content including description, implementation notes, and history.
|
||||
|
||||
### Tree View
|
||||
```
|
||||
/task-find --tree --root TASK-001
|
||||
```
|
||||
Shows task and all its dependencies in tree format.
|
||||
|
||||
## Filtering Options
|
||||
|
||||
### By Orchestration
|
||||
```
|
||||
/task-find --orchestration "03_15_2024/payment_system"
|
||||
/task-find --orchestration "*/auth_*"
|
||||
```
|
||||
|
||||
### By Properties
|
||||
```
|
||||
/task-find --has-dependencies
|
||||
/task-find --no-dependencies
|
||||
/task-find --blocking-others
|
||||
/task-find --effort ">4h"
|
||||
```
|
||||
|
||||
### By Relationships
|
||||
```
|
||||
/task-find --depends-on TASK-001
|
||||
/task-find --blocks TASK-005
|
||||
/task-find --related-to TASK-003
|
||||
```
|
||||
|
||||
## Special Searches
|
||||
|
||||
### Find Circular Dependencies
|
||||
```
|
||||
/task-find --circular-deps
|
||||
```
|
||||
|
||||
### Find Orphaned Tasks
|
||||
```
|
||||
/task-find --orphaned
|
||||
```
|
||||
|
||||
### Find Duplicate Tasks
|
||||
```
|
||||
/task-find --duplicates
|
||||
```
|
||||
|
||||
### Find Stale Tasks
|
||||
```
|
||||
/task-find --stale --days 7
|
||||
```
|
||||
|
||||
## Quick Filters
|
||||
|
||||
### Ready to Start
|
||||
```
|
||||
/task-find --ready
|
||||
```
|
||||
Shows todos with no blocking dependencies.
|
||||
|
||||
### Critical Path
|
||||
```
|
||||
/task-find --critical-path
|
||||
```
|
||||
Shows tasks on the critical path.
|
||||
|
||||
### High Impact
|
||||
```
|
||||
/task-find --high-impact
|
||||
```
|
||||
Shows tasks blocking multiple others.
|
||||
|
||||
## Export Options
|
||||
|
||||
### Copy Results
|
||||
```
|
||||
/task-find "auth" --copy
|
||||
```
|
||||
Copies results to clipboard.
|
||||
|
||||
### Export Paths
|
||||
```
|
||||
/task-find --status todos --export paths
|
||||
```
|
||||
Exports file paths for batch operations.
|
||||
|
||||
### Generate Report
|
||||
```
|
||||
/task-find --report
|
||||
```
|
||||
Creates detailed search report.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Find Work for Agent
|
||||
```
|
||||
/task-find --status todos --suitable-for dev-frontend --ready
|
||||
```
|
||||
|
||||
### Example 2: Find Blocking Issues
|
||||
```
|
||||
/task-find --status on_hold --show-blockers
|
||||
```
|
||||
|
||||
### Example 3: Security Audit
|
||||
```
|
||||
/task-find "security OR auth OR permission" --type "feature,bugfix"
|
||||
```
|
||||
|
||||
### Example 4: Sprint Planning
|
||||
```
|
||||
/task-find --status todos --effort "<4h" --no-dependencies
|
||||
```
|
||||
|
||||
## Search Shortcuts
|
||||
|
||||
### Recent Tasks
|
||||
```
|
||||
/task-find --recent 10
|
||||
```
|
||||
|
||||
### My Tasks
|
||||
```
|
||||
/task-find --mine # Uses current agent context
|
||||
```
|
||||
|
||||
### Modified Today
|
||||
```
|
||||
/task-find --modified today
|
||||
```
|
||||
|
||||
## Complex Queries
|
||||
|
||||
### Compound Search
|
||||
```
|
||||
/task-find '(title:"auth" OR description:"security") AND status:todos AND -blocks:*'
|
||||
```
|
||||
|
||||
### Saved Searches
|
||||
```
|
||||
/task-find --save "security-todos"
|
||||
/task-find --load "security-todos"
|
||||
```
|
||||
|
||||
## Performance Tips
|
||||
|
||||
1. **Use Indexes**: Status and ID searches are fastest
|
||||
2. **Narrow Scope**: Specify orchestration when possible
|
||||
3. **Cache Results**: Use `--cache` for repeated searches
|
||||
4. **Limit Results**: Use `--limit 20` for large result sets
|
||||
|
||||
## Integration
|
||||
|
||||
### With Other Commands
|
||||
```
|
||||
/task-find "payment" --status todos | /task-move in_progress
|
||||
```
|
||||
|
||||
### Batch Operations
|
||||
```
|
||||
/task-find --filter "priority:low" | /task-update priority:medium
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- Searches across all task files in task-orchestration/
|
||||
- Case-insensitive by default (use --case for case-sensitive)
|
||||
- Results sorted by relevance unless specified otherwise
|
||||
- Supports command chaining with pipe operator
|
||||
- Search index updated automatically on file changes
|
||||
@@ -0,0 +1,355 @@
|
||||
# Orchestration Log Command
|
||||
|
||||
Log work from orchestrated tasks to external project management tools like Linear, Obsidian, Jira, or GitHub Issues.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/orchestration/log [TASK-ID] [options]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Automatically creates work logs in your connected project management tools or knowledge bases, transferring task completion data, time spent, and progress notes to keep external systems synchronized.
|
||||
|
||||
## Basic Commands
|
||||
|
||||
### Log Current Task
|
||||
```
|
||||
/orchestration/log
|
||||
```
|
||||
Logs the currently in-progress task to available tools.
|
||||
|
||||
### Log Specific Task
|
||||
```
|
||||
/orchestration/log TASK-003
|
||||
```
|
||||
Logs a specific task's work.
|
||||
|
||||
### Choose Destination
|
||||
```
|
||||
/orchestration/log TASK-003 --choose
|
||||
```
|
||||
Manually select where to log the work.
|
||||
|
||||
## Destination Selection
|
||||
|
||||
When multiple tools are available or no obvious connection exists:
|
||||
|
||||
```
|
||||
Where would you like to log this work?
|
||||
|
||||
Available destinations:
|
||||
1. Linear (ENG-1234 detected)
|
||||
2. Obsidian (Daily Note)
|
||||
3. Obsidian (Project: Authentication)
|
||||
4. GitHub Issue (#123)
|
||||
5. None - Skip logging
|
||||
|
||||
Choose destination [1-5]:
|
||||
```
|
||||
|
||||
## Obsidian Integration
|
||||
|
||||
### Daily Note Logging
|
||||
```
|
||||
/orchestration/log --obsidian-daily
|
||||
```
|
||||
Appends to today's daily note:
|
||||
|
||||
```markdown
|
||||
## Work Log - 15:30
|
||||
|
||||
### TASK-003: JWT Implementation ✅
|
||||
|
||||
**Time Spent**: 4.5 hours (10:00 - 14:30)
|
||||
**Status**: Completed → QA
|
||||
|
||||
**What I did:**
|
||||
- Implemented JWT token validation middleware
|
||||
- Added refresh token logic
|
||||
- Created comprehensive test suite
|
||||
- Fixed edge case with token expiration
|
||||
|
||||
**Code Stats:**
|
||||
- Files: 8 modified
|
||||
- Lines: +245 -23
|
||||
- Coverage: 95%
|
||||
|
||||
**Related Tasks:**
|
||||
- Next: [[TASK-005]] - User Profile API
|
||||
- Blocked: [[TASK-007]] - Waiting for this
|
||||
|
||||
**Commits:**
|
||||
- `abc123`: feat(auth): implement JWT validation
|
||||
- `def456`: test(auth): add validation tests
|
||||
|
||||
#tasks/completed #project/authentication
|
||||
```
|
||||
|
||||
### Project Note Logging
|
||||
```
|
||||
/orchestration/log --obsidian-project "Authentication System"
|
||||
```
|
||||
Creates or appends to project-specific note.
|
||||
|
||||
### Custom Obsidian Location
|
||||
```
|
||||
/orchestration/log --obsidian-path "Projects/Sprint 24/Work Log"
|
||||
```
|
||||
|
||||
## Linear Integration
|
||||
```
|
||||
/orchestration/log TASK-003 --linear-issue ENG-1234
|
||||
```
|
||||
Creates work log comment in Linear issue.
|
||||
|
||||
## Smart Detection
|
||||
|
||||
The system detects available destinations:
|
||||
|
||||
```
|
||||
Analyzing task context...
|
||||
|
||||
Found connections:
|
||||
✓ Linear: ENG-1234 (from branch name)
|
||||
✓ Obsidian: Project note exists
|
||||
✓ GitHub: No issue reference
|
||||
✗ Jira: Not connected
|
||||
|
||||
Suggested: Linear ENG-1234
|
||||
Use suggestion? [Y/n/choose different]
|
||||
```
|
||||
|
||||
## Work Log Formats
|
||||
|
||||
### Obsidian Format
|
||||
```markdown
|
||||
## 📋 Task: TASK-003 - JWT Implementation
|
||||
|
||||
### Summary
|
||||
- **Status**: 🟢 Completed
|
||||
- **Duration**: 4h 30m
|
||||
- **Date**: 2024-03-15
|
||||
|
||||
### Progress Details
|
||||
- [x] Token structure design
|
||||
- [x] Validation middleware
|
||||
- [x] Refresh mechanism
|
||||
- [x] Test coverage
|
||||
|
||||
### Technical Notes
|
||||
- Used RS256 algorithm for signing
|
||||
- Tokens expire after 15 minutes
|
||||
- Refresh tokens last 7 days
|
||||
|
||||
### Links
|
||||
- Linear: [ENG-1234](linear://issue/ENG-1234)
|
||||
- PR: [#456](github.com/...)
|
||||
- Docs: [[JWT Implementation Guide]]
|
||||
|
||||
### Next Actions
|
||||
- [ ] Code review feedback
|
||||
- [ ] Deploy to staging
|
||||
- [ ] Update API documentation
|
||||
|
||||
---
|
||||
*Logged via Task Orchestration at 15:30*
|
||||
```
|
||||
|
||||
### Linear Format
|
||||
```
|
||||
Work log comment in Linear with task details, time tracking, and progress updates.
|
||||
```
|
||||
|
||||
## Multiple Destination Logging
|
||||
|
||||
```
|
||||
/orchestration/log TASK-003 --multi
|
||||
|
||||
Select all destinations for logging:
|
||||
[x] Linear - ENG-1234
|
||||
[x] Obsidian - Daily Note
|
||||
[ ] Obsidian - Project Note
|
||||
[ ] GitHub - Create new issue
|
||||
|
||||
Press Enter to confirm, Space to toggle
|
||||
```
|
||||
|
||||
## Batch Operations
|
||||
|
||||
### Daily Summary to Obsidian
|
||||
```
|
||||
/orchestration/log --daily-summary --obsidian
|
||||
|
||||
Creates summary in daily note:
|
||||
|
||||
## Work Summary - 2024-03-15
|
||||
|
||||
### Completed Tasks
|
||||
- [[TASK-003]]: JWT Implementation (4.5h) ✅
|
||||
- [[TASK-008]]: Login UI Updates (2h) ✅
|
||||
|
||||
### In Progress
|
||||
- [[TASK-005]]: User Profile API (1.5h) 🔄
|
||||
|
||||
### Total Time: 8 hours
|
||||
|
||||
### Key Achievements
|
||||
- Authentication system core complete
|
||||
- All tests passing
|
||||
- Ready for code review
|
||||
|
||||
### Tomorrow's Focus
|
||||
- Complete user profile endpoints
|
||||
- Start OAuth integration
|
||||
```
|
||||
|
||||
### Weekly Report
|
||||
```
|
||||
/orchestration/log --weekly --obsidian-path "Weekly Reviews/Week 11"
|
||||
```
|
||||
|
||||
## Templates
|
||||
|
||||
### Configure Obsidian Template
|
||||
```yaml
|
||||
obsidian_template:
|
||||
daily_note:
|
||||
heading: "## Work Log - {time}"
|
||||
include_stats: true
|
||||
add_tags: true
|
||||
link_tasks: true
|
||||
|
||||
project_note:
|
||||
create_if_missing: true
|
||||
append_to_section: "## Task Progress"
|
||||
include_commits: true
|
||||
```
|
||||
|
||||
### Configure Linear Template
|
||||
```yaml
|
||||
linear_template:
|
||||
include_time: true
|
||||
update_status: true
|
||||
add_labels: ["from-orchestration"]
|
||||
```
|
||||
|
||||
## Interactive Mode
|
||||
|
||||
```
|
||||
/orchestration/log --interactive
|
||||
|
||||
Task: TASK-003 - JWT Implementation
|
||||
Status: Completed
|
||||
Time: 4.5 hours
|
||||
|
||||
Where to log? (Space to select, Enter to confirm)
|
||||
> [x] Linear (ENG-1234)
|
||||
> [x] Obsidian Daily Note
|
||||
> [ ] Obsidian Project Note
|
||||
> [ ] New GitHub Issue
|
||||
|
||||
Add custom notes? [y/N]: y
|
||||
> Implemented using RS256, ready for review
|
||||
|
||||
Logging to 2 destinations...
|
||||
✓ Linear: Comment added to ENG-1234
|
||||
✓ Obsidian: Added to daily note
|
||||
|
||||
View logs? [y/N]:
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: End of Day Logging
|
||||
```
|
||||
/orchestration/log --eod
|
||||
|
||||
End of Day Summary:
|
||||
- 3 tasks worked on
|
||||
- 7.5 hours logged
|
||||
- 2 completed, 1 in progress
|
||||
|
||||
Log to:
|
||||
1. Obsidian Daily Note (recommended)
|
||||
2. Linear (update all 3 issues)
|
||||
3. Both
|
||||
4. Skip
|
||||
|
||||
Choice [1]: 1
|
||||
|
||||
✓ Daily work log created in Obsidian
|
||||
```
|
||||
|
||||
### Example 2: Sprint Review
|
||||
```
|
||||
/orchestration/log --sprint-review --week 11
|
||||
|
||||
Gathering week 11 data...
|
||||
- 15 tasks completed
|
||||
- 3 in progress
|
||||
- 52 hours logged
|
||||
|
||||
Create sprint review in:
|
||||
1. Obsidian - "Sprint Reviews/Sprint 24"
|
||||
2. Linear - Sprint 24 cycle
|
||||
3. Both
|
||||
|
||||
Choice [3]: 3
|
||||
|
||||
✓ Sprint review created in both systems
|
||||
```
|
||||
|
||||
### Example 3: No Connection Found
|
||||
```
|
||||
/orchestration/log TASK-009
|
||||
|
||||
No automatic destination found for TASK-009.
|
||||
|
||||
Where would you like to log this?
|
||||
1. Obsidian - Daily Note
|
||||
2. Obsidian - Create Project Note
|
||||
3. Linear - Search for issue
|
||||
4. GitHub - Create new issue
|
||||
5. Skip logging
|
||||
|
||||
Choice: 2
|
||||
|
||||
Enter project name: Security Audit
|
||||
✓ Created "Security Audit" note with work log
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
### Default Destinations
|
||||
```yaml
|
||||
log_defaults:
|
||||
no_connection: "ask" # ask|obsidian-daily|skip
|
||||
multi_connection: "ask" # ask|all|first
|
||||
|
||||
obsidian:
|
||||
default_location: "daily" # daily|project|custom
|
||||
project_folder: "Projects"
|
||||
daily_folder: "Daily Notes"
|
||||
|
||||
linear:
|
||||
auto_update_status: true
|
||||
include_commits: true
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Set Preferences**: Configure default destinations
|
||||
2. **Link Early**: Connect tasks to PM tools when creating
|
||||
3. **Use Daily Notes**: Great for personal tracking
|
||||
4. **Project Notes**: Better for team collaboration
|
||||
5. **Regular Syncs**: Don't let logs pile up
|
||||
|
||||
## Notes
|
||||
|
||||
- Respects MCP connections and permissions
|
||||
- Obsidian logs create backlinks automatically
|
||||
- Supports multiple simultaneous destinations
|
||||
- Preserves formatting across systems
|
||||
- Can be automated with task status changes
|
||||
@@ -0,0 +1,220 @@
|
||||
# Task Move Command
|
||||
|
||||
Move tasks between status folders following the task management protocol.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/task-move TASK-ID new-status [reason]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Updates task status by moving files between status folders and updating tracking information. Follows all protocol rules including validation and audit trails.
|
||||
|
||||
## Basic Commands
|
||||
|
||||
### Start Working on a Task
|
||||
```
|
||||
/task-move TASK-001 in_progress
|
||||
```
|
||||
Moves from todos → in_progress
|
||||
|
||||
### Complete Implementation
|
||||
```
|
||||
/task-move TASK-001 qa "Implementation complete, ready for testing"
|
||||
```
|
||||
Moves from in_progress → qa
|
||||
|
||||
### Task Passed QA
|
||||
```
|
||||
/task-move TASK-001 completed "All tests passed"
|
||||
```
|
||||
Moves from qa → completed
|
||||
|
||||
### Block a Task
|
||||
```
|
||||
/task-move TASK-004 on_hold "Waiting for TASK-001 API completion"
|
||||
```
|
||||
Moves to on_hold with reason
|
||||
|
||||
### Unblock a Task
|
||||
```
|
||||
/task-move TASK-004 todos "Dependencies resolved"
|
||||
```
|
||||
Moves from on_hold → todos
|
||||
|
||||
### Failed QA
|
||||
```
|
||||
/task-move TASK-001 in_progress "Failed integration test - fixing null pointer"
|
||||
```
|
||||
Moves from qa → in_progress
|
||||
|
||||
## Bulk Operations
|
||||
|
||||
### Move Multiple Tasks
|
||||
```
|
||||
/task-move TASK-001,TASK-002,TASK-003 in_progress
|
||||
```
|
||||
|
||||
### Move by Filter
|
||||
```
|
||||
/task-move --filter "priority:high status:todos" in_progress
|
||||
```
|
||||
|
||||
### Move with Pattern
|
||||
```
|
||||
/task-move TASK-00* qa "Batch testing ready"
|
||||
```
|
||||
|
||||
## Validation Rules
|
||||
|
||||
The command enforces:
|
||||
1. **Valid Transitions**: Only allowed status changes
|
||||
2. **One Task Per Agent**: Warns if agent has task in_progress
|
||||
3. **Dependency Check**: Warns if dependencies not met
|
||||
4. **File Existence**: Verifies task exists before moving
|
||||
|
||||
## Status Transition Map
|
||||
|
||||
```
|
||||
todos ──────→ in_progress ──────→ qa ──────→ completed
|
||||
↓ ↓ ↓
|
||||
└───────────→ on_hold ←─────────┘
|
||||
↓
|
||||
todos/in_progress
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
### Force Move
|
||||
```
|
||||
/task-move TASK-001 completed --force
|
||||
```
|
||||
Bypasses validation (use with caution)
|
||||
|
||||
### Dry Run
|
||||
```
|
||||
/task-move TASK-001 qa --dry-run
|
||||
```
|
||||
Shows what would happen without executing
|
||||
|
||||
### With Assignment
|
||||
```
|
||||
/task-move TASK-001 in_progress --assign dev-frontend
|
||||
```
|
||||
Assigns task to specific agent
|
||||
|
||||
### With Time Estimate
|
||||
```
|
||||
/task-move TASK-001 in_progress --estimate 4h
|
||||
```
|
||||
Updates time estimate when starting
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Task Not Found
|
||||
```
|
||||
Error: TASK-999 not found in any status folder
|
||||
Suggestion: Use /task-status to see available tasks
|
||||
```
|
||||
|
||||
### Invalid Transition
|
||||
```
|
||||
Error: Cannot move from 'completed' to 'todos'
|
||||
Valid transitions from completed: None (terminal state)
|
||||
```
|
||||
|
||||
### Agent Conflict
|
||||
```
|
||||
Warning: dev-frontend already has TASK-002 in progress
|
||||
Continue? (y/n)
|
||||
```
|
||||
|
||||
### Dependency Block
|
||||
```
|
||||
Warning: TASK-004 depends on TASK-001 (currently in_progress)
|
||||
Moving to on_hold instead? (y/n)
|
||||
```
|
||||
|
||||
## Automation
|
||||
|
||||
### Auto-move on Completion
|
||||
```
|
||||
/task-move TASK-001 --auto-progress
|
||||
```
|
||||
Automatically moves to next status when conditions met
|
||||
|
||||
### Scheduled Moves
|
||||
```
|
||||
/task-move TASK-005 in_progress --at "tomorrow 9am"
|
||||
```
|
||||
|
||||
### Conditional Moves
|
||||
```
|
||||
/task-move TASK-007 qa --when "TASK-006 completed"
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Developer Workflow
|
||||
```
|
||||
# Start work
|
||||
/task-move TASK-001 in_progress
|
||||
|
||||
# Complete and test
|
||||
/task-move TASK-001 qa "Implementation done, tests passing"
|
||||
|
||||
# After review
|
||||
/task-move TASK-001 completed "Code review approved"
|
||||
```
|
||||
|
||||
### Example 2: Handling Blocks
|
||||
```
|
||||
# Block due to dependency
|
||||
/task-move TASK-004 on_hold "Waiting for auth API from TASK-001"
|
||||
|
||||
# Unblock when ready
|
||||
/task-move TASK-004 todos "TASK-001 now in QA, API available"
|
||||
```
|
||||
|
||||
### Example 3: QA Workflow
|
||||
```
|
||||
# QA picks up task
|
||||
/task-move TASK-001 qa --assign qa-engineer
|
||||
|
||||
# Found issues
|
||||
/task-move TASK-001 in_progress "Bug: handling empty responses"
|
||||
|
||||
# Fixed and retesting
|
||||
/task-move TASK-001 qa "Bug fixed, ready for retest"
|
||||
```
|
||||
|
||||
## Status Update Details
|
||||
|
||||
Each move updates:
|
||||
1. **File Location**: Physical file movement
|
||||
2. **Status Tracker**: TASK-STATUS-TRACKER.yaml entry
|
||||
3. **Task Metadata**: Status field in task file
|
||||
4. **Execution Tracker**: Overall progress metrics
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Always Provide Reasons**: Especially for blocks and failures
|
||||
2. **Check Dependencies**: Before moving to in_progress
|
||||
3. **Update Estimates**: When starting work
|
||||
4. **Clear Block Reasons**: Help others understand delays
|
||||
|
||||
## Integration
|
||||
|
||||
- Use after `/task-status` to see available tasks
|
||||
- Updates reflected in `/task-report`
|
||||
- Triggers notifications if configured
|
||||
- Logs all moves for audit trail
|
||||
|
||||
## Notes
|
||||
|
||||
- Moves are atomic - either fully complete or rolled back
|
||||
- Status history is permanent and cannot be edited
|
||||
- Timestamp uses current time in ISO-8601 format
|
||||
- Agent name is automatically detected from context
|
||||
@@ -0,0 +1,375 @@
|
||||
# Orchestration Optimize Command
|
||||
|
||||
Analyze and optimize task orchestrations to improve efficiency, reduce bottlenecks, and maximize team productivity.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/orchestration/optimize [options]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Performs comprehensive analysis of active and historical orchestrations to identify optimization opportunities, suggest workflow improvements, and provide actionable insights for better task management.
|
||||
|
||||
## Basic Commands
|
||||
|
||||
### Analyze Current Orchestration
|
||||
```
|
||||
/orchestration/optimize
|
||||
```
|
||||
Analyzes the most recently active orchestration for bottlenecks and inefficiencies.
|
||||
|
||||
### Optimize Specific Orchestration
|
||||
```
|
||||
/orchestration/optimize --date 03_15_2024 --project auth_system
|
||||
```
|
||||
Deep analysis of a specific orchestration with detailed recommendations.
|
||||
|
||||
### Performance Analysis
|
||||
```
|
||||
/orchestration/optimize --performance
|
||||
```
|
||||
Focuses on timing, velocity, and resource utilization metrics.
|
||||
|
||||
### Dependency Optimization
|
||||
```
|
||||
/orchestration/optimize --dependencies
|
||||
```
|
||||
Analyzes task dependencies for parallelization opportunities.
|
||||
|
||||
## Analysis Areas
|
||||
|
||||
### Bottleneck Detection
|
||||
```
|
||||
## Identified Bottlenecks
|
||||
|
||||
Critical Path Analysis:
|
||||
- TASK-003 (JWT validation): Blocking 4 downstream tasks
|
||||
- Duration: 5.5h (150% of estimate)
|
||||
- Impact: 12h of parallel work delayed
|
||||
|
||||
Queue Analysis:
|
||||
- on_hold queue: 6 tasks (avg 2.3 days waiting)
|
||||
- QA queue: 3 tasks (avg 8h waiting)
|
||||
- Recommendation: Add QA capacity or parallel testing
|
||||
|
||||
Resource Constraints:
|
||||
- dev-backend: 3 active tasks (overloaded)
|
||||
- dev-frontend: 0 active tasks (underutilized)
|
||||
- Suggestion: Cross-train or reassign suitable tasks
|
||||
```
|
||||
|
||||
### Velocity Metrics
|
||||
```
|
||||
## Velocity Analysis
|
||||
|
||||
Current Metrics:
|
||||
- Tasks/day: 2.1 (target: 3.0)
|
||||
- Avg task duration: 4.2h (vs 3.5h estimate)
|
||||
- Status transitions: todos→in_progress (2h avg wait)
|
||||
|
||||
Historical Comparison:
|
||||
- Last week: 2.8 tasks/day (33% faster)
|
||||
- Best week: 3.4 tasks/day (optimal conditions)
|
||||
|
||||
Trending Issues:
|
||||
- Estimate accuracy declining (65% vs 80% last month)
|
||||
- QA feedback loop increased by 40%
|
||||
```
|
||||
|
||||
### Dependency Analysis
|
||||
```
|
||||
## Dependency Optimization
|
||||
|
||||
Parallelization Opportunities:
|
||||
1. TASK-007, TASK-008 can run concurrently with TASK-003
|
||||
Potential time saving: 6 hours
|
||||
|
||||
2. Frontend tasks independent of current backend work
|
||||
Parallelizable: TASK-009, TASK-010, TASK-011
|
||||
|
||||
Critical Path Optimization:
|
||||
- Current: 24 hours (sequential)
|
||||
- Optimized: 16 hours (parallel execution)
|
||||
- Savings: 8 hours (33% improvement)
|
||||
|
||||
Dependency Simplification:
|
||||
- Remove false dependency: TASK-012 → TASK-004
|
||||
- Merge related tasks: TASK-014 + TASK-015
|
||||
```
|
||||
|
||||
## Optimization Strategies
|
||||
|
||||
### Resource Reallocation
|
||||
```
|
||||
/orchestration/optimize --rebalance
|
||||
```
|
||||
|
||||
Suggests optimal task assignments:
|
||||
```
|
||||
## Recommended Resource Changes
|
||||
|
||||
Current Load:
|
||||
┌─────────────────┬────────────┬─────────────┬────────────┐
|
||||
│ Agent │ Active │ Queue │ Utilization│
|
||||
├─────────────────┼────────────┼─────────────┼────────────┤
|
||||
│ dev-backend │ 3 tasks │ 2 tasks │ 180% │
|
||||
│ dev-frontend │ 0 tasks │ 4 tasks │ 0% │
|
||||
│ qa-engineer │ 2 tasks │ 1 task │ 120% │
|
||||
│ test-developer │ 1 task │ 0 tasks │ 60% │
|
||||
└─────────────────┴────────────┴─────────────┴────────────┘
|
||||
|
||||
Recommendations:
|
||||
1. Move TASK-007 (API tests) to test-developer
|
||||
2. Assign TASK-009 (UI components) to dev-frontend
|
||||
3. Split TASK-003 into backend/frontend components
|
||||
```
|
||||
|
||||
### Task Restructuring
|
||||
```
|
||||
/orchestration/optimize --restructure
|
||||
```
|
||||
|
||||
Suggests task modifications:
|
||||
```
|
||||
## Task Restructuring Opportunities
|
||||
|
||||
Oversized Tasks (>6h estimate):
|
||||
- TASK-003: JWT validation (8h)
|
||||
→ Split: JWT core (4h) + JWT middleware (3h) + Tests (1h)
|
||||
|
||||
Undersized Tasks (<1h estimate):
|
||||
- TASK-011: Update config (0.5h)
|
||||
- TASK-012: Fix typos (0.25h)
|
||||
→ Merge into maintenance batch
|
||||
|
||||
Mislabeled Dependencies:
|
||||
- TASK-008 doesn't actually need TASK-003
|
||||
→ Remove dependency, add to parallel execution
|
||||
```
|
||||
|
||||
### Workflow Improvements
|
||||
```
|
||||
/orchestration/optimize --workflow
|
||||
```
|
||||
|
||||
Process optimization suggestions:
|
||||
```
|
||||
## Workflow Optimization
|
||||
|
||||
Status Transition Delays:
|
||||
- todos → in_progress: 4.2h avg (target: <2h)
|
||||
- in_progress → qa: 1.2h avg (good)
|
||||
- qa → completed: 6.8h avg (target: <4h)
|
||||
|
||||
Recommendations:
|
||||
1. Implement auto-assignment rules
|
||||
2. Add QA capacity during peak hours
|
||||
3. Create task preparation checklist
|
||||
|
||||
Communication Improvements:
|
||||
- 23% of blocks due to unclear requirements
|
||||
- 15% of QA failures from missing context
|
||||
- Add requirement review gate before in_progress
|
||||
```
|
||||
|
||||
## Historical Analysis
|
||||
|
||||
### Trend Analysis
|
||||
```
|
||||
/orchestration/optimize --trends --days 30
|
||||
```
|
||||
|
||||
Shows performance trends:
|
||||
```
|
||||
## 30-Day Performance Trends
|
||||
|
||||
Velocity Trend: ↓ -15%
|
||||
- Week 1: 3.2 tasks/day
|
||||
- Week 2: 2.9 tasks/day
|
||||
- Week 3: 2.8 tasks/day
|
||||
- Week 4: 2.7 tasks/day
|
||||
|
||||
Quality Trend: ↓ -8%
|
||||
- QA rejection rate increasing
|
||||
- Rework time per task up 12%
|
||||
|
||||
Efficiency Indicators:
|
||||
- Estimate accuracy: 68% (down from 78%)
|
||||
- Parallel execution rate: 45% (up from 40%)
|
||||
- Blocked task duration: 1.8 days avg (up from 1.2 days)
|
||||
```
|
||||
|
||||
### Pattern Recognition
|
||||
```
|
||||
## Identified Patterns
|
||||
|
||||
Task Types Performance:
|
||||
- Features: 3.2h avg (close to estimates)
|
||||
- Bugfixes: 2.1h avg (underestimated by 40%)
|
||||
- Tests: 1.8h avg (overestimated by 20%)
|
||||
- Security: 5.1h avg (significantly underestimated)
|
||||
|
||||
Time-of-Day Patterns:
|
||||
- Morning starts: 25% faster completion
|
||||
- Post-lunch blocks: 40% more likely
|
||||
- End-of-day QA: 60% higher failure rate
|
||||
|
||||
Agent Specialization:
|
||||
- dev-backend: 2x faster on API tasks
|
||||
- dev-frontend: 30% faster on UI tasks
|
||||
- Cross-functional tasks: 50% slower than specialized
|
||||
```
|
||||
|
||||
## Optimization Actions
|
||||
|
||||
### Immediate Actions
|
||||
```
|
||||
/orchestration/optimize --execute immediate
|
||||
```
|
||||
|
||||
Applies safe optimizations:
|
||||
1. Rebalance current task assignments
|
||||
2. Remove identified false dependencies
|
||||
3. Update task estimates based on historical data
|
||||
4. Reschedule blocked tasks
|
||||
|
||||
### Structural Changes
|
||||
```
|
||||
/orchestration/optimize --execute structural --confirm
|
||||
```
|
||||
|
||||
Requires confirmation for:
|
||||
1. Task splitting/merging
|
||||
2. Workflow process changes
|
||||
3. Agent role modifications
|
||||
4. Dependency restructuring
|
||||
|
||||
### Continuous Optimization
|
||||
```
|
||||
/orchestration/optimize --schedule daily
|
||||
```
|
||||
|
||||
Sets up automated optimization:
|
||||
- Daily velocity monitoring
|
||||
- Weekly bottleneck analysis
|
||||
- Monthly trend reporting
|
||||
- Automated rebalancing suggestions
|
||||
|
||||
## Simulation Mode
|
||||
|
||||
### What-If Analysis
|
||||
```
|
||||
/orchestration/optimize --simulate "add agent:dev-fullstack"
|
||||
```
|
||||
|
||||
Projects impact of changes:
|
||||
```
|
||||
## Simulation Results: Adding dev-fullstack
|
||||
|
||||
Projected Improvements:
|
||||
- Velocity: 2.7 → 3.4 tasks/day (+26%)
|
||||
- Critical path: 24h → 18h (-25%)
|
||||
- Queue time: 4.2h → 2.1h (-50%)
|
||||
|
||||
Resource Utilization:
|
||||
- Backend overload: 180% → 120% (optimal)
|
||||
- Frontend underload: 0% → 80% (good)
|
||||
- Overall efficiency: +35%
|
||||
|
||||
ROI Analysis:
|
||||
- Cost: +1 team member
|
||||
- Delivery speed: +26%
|
||||
- Quality impact: Neutral to positive
|
||||
```
|
||||
|
||||
## Integration Features
|
||||
|
||||
### Automated Optimization
|
||||
```
|
||||
/orchestration/optimize --auto-apply --threshold conservative
|
||||
```
|
||||
|
||||
Automatically applies optimizations meeting conservative safety criteria.
|
||||
|
||||
### Notification System
|
||||
```
|
||||
/orchestration/optimize --alerts bottleneck,velocity,quality
|
||||
```
|
||||
|
||||
Sets up alerts for optimization opportunities.
|
||||
|
||||
### Historical Learning
|
||||
```
|
||||
/orchestration/optimize --learn-from previous_projects/
|
||||
```
|
||||
|
||||
Incorporates lessons from past orchestrations.
|
||||
|
||||
## Reporting
|
||||
|
||||
### Optimization Report
|
||||
```
|
||||
/orchestration/optimize --report detailed
|
||||
```
|
||||
|
||||
Generates comprehensive optimization report with:
|
||||
- Current state analysis
|
||||
- Identified opportunities
|
||||
- Recommended actions
|
||||
- Expected impact metrics
|
||||
- Implementation timeline
|
||||
|
||||
### Executive Summary
|
||||
```
|
||||
/orchestration/optimize --summary executive
|
||||
```
|
||||
|
||||
High-level optimization insights for leadership.
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Regular Analysis**: Run optimization weekly on active orchestrations
|
||||
2. **Incremental Changes**: Apply optimizations gradually to measure impact
|
||||
3. **Monitor Impact**: Track metrics before and after optimization
|
||||
4. **Team Communication**: Share optimization insights with the team
|
||||
5. **Continuous Learning**: Use historical data to improve future orchestrations
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Daily Optimization Check
|
||||
```
|
||||
/orchestration/optimize --quick --auto-rebalance
|
||||
```
|
||||
|
||||
### Example 2: Deep Analysis for Struggling Project
|
||||
```
|
||||
/orchestration/optimize --date 03_15_2024 --project auth_system --deep-analysis
|
||||
```
|
||||
|
||||
### Example 3: Team Performance Review
|
||||
```
|
||||
/orchestration/optimize --trends --days 90 --team-focus
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
### Optimization Rules
|
||||
Set in orchestration config:
|
||||
```yaml
|
||||
optimization:
|
||||
auto_rebalance: true
|
||||
bottleneck_threshold: 2h
|
||||
velocity_target: 3.0
|
||||
quality_threshold: 85%
|
||||
parallel_execution_target: 60%
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- All optimizations are reversible through audit trail
|
||||
- Simulation mode allows safe experimentation
|
||||
- Historical data improves optimization accuracy over time
|
||||
- Integrates with all other orchestration commands
|
||||
- Supports custom optimization rules per project type
|
||||
@@ -0,0 +1,301 @@
|
||||
# Orchestration Remove Command
|
||||
|
||||
Safely remove a task from the orchestration system, updating all references and dependencies.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/orchestration/remove TASK-ID [options]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Removes a task completely from the orchestration system, handling all dependencies, references, and related documentation. Provides impact analysis before removal and ensures system consistency.
|
||||
|
||||
## Basic Commands
|
||||
|
||||
### Remove Single Task
|
||||
```
|
||||
/orchestration/remove TASK-003
|
||||
```
|
||||
Shows impact analysis and confirms before removal.
|
||||
|
||||
### Force Remove
|
||||
```
|
||||
/orchestration/remove TASK-003 --force
|
||||
```
|
||||
Skips confirmation (use with caution).
|
||||
|
||||
### Dry Run
|
||||
```
|
||||
/orchestration/remove TASK-003 --dry-run
|
||||
```
|
||||
Shows what would be affected without making changes.
|
||||
|
||||
## Impact Analysis
|
||||
|
||||
Before removal, the system analyzes:
|
||||
|
||||
```
|
||||
Task Removal Impact Analysis: TASK-003
|
||||
======================================
|
||||
|
||||
Task Details:
|
||||
- Title: JWT token validation
|
||||
- Status: in_progress
|
||||
- Location: /tasks/in_progress/TASK-003-jwt-validation.md
|
||||
|
||||
Dependencies:
|
||||
- Blocks: TASK-005 (User profile API)
|
||||
- Blocks: TASK-007 (Session management)
|
||||
- Depends on: None
|
||||
|
||||
References Found:
|
||||
- MASTER-COORDINATION.md: Line 45 (Wave 1 tasks)
|
||||
- EXECUTION-TRACKER.md: Active task count
|
||||
- TASK-005: Lists TASK-003 as dependency
|
||||
- TASK-007: Lists TASK-003 as dependency
|
||||
|
||||
Git History:
|
||||
- 2 commits reference this task
|
||||
- Branch: feature/jwt-auth
|
||||
|
||||
Warning: This task has downstream dependencies!
|
||||
|
||||
Proceed with removal? [y/N]
|
||||
```
|
||||
|
||||
## Removal Process
|
||||
|
||||
### 1. Update Dependent Tasks
|
||||
```
|
||||
Updating dependent tasks:
|
||||
- TASK-005: Removing dependency on TASK-003
|
||||
New status: Ready to start (no blockers)
|
||||
|
||||
- TASK-007: Removing dependency on TASK-003
|
||||
Warning: Still blocked by TASK-009
|
||||
```
|
||||
|
||||
### 2. Update Tracking Files
|
||||
```yaml
|
||||
# TASK-STATUS-TRACKER.yaml updates:
|
||||
status_history:
|
||||
TASK-003: [REMOVED - archived to .removed/]
|
||||
|
||||
current_status_summary:
|
||||
in_progress: [TASK-003 removed from list]
|
||||
|
||||
removal_log:
|
||||
- task_id: TASK-003
|
||||
removed_at: "2024-03-15T16:00:00Z"
|
||||
removed_by: "user"
|
||||
reason: "Requirement changed"
|
||||
final_status: "in_progress"
|
||||
```
|
||||
|
||||
### 3. Update Coordination Documents
|
||||
```
|
||||
Updates applied:
|
||||
✓ MASTER-COORDINATION.md - Removed from Wave 1
|
||||
✓ EXECUTION-TRACKER.md - Updated task counts
|
||||
✓ TASK-DEPENDENCIES.yaml - Removed all references
|
||||
✓ Dependency graph regenerated
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
### Archive Instead of Delete
|
||||
```
|
||||
/orchestration/remove TASK-003 --archive
|
||||
```
|
||||
Moves to `.removed/` directory instead of deleting.
|
||||
|
||||
### Remove Multiple Tasks
|
||||
```
|
||||
/orchestration/remove TASK-003,TASK-005,TASK-008
|
||||
```
|
||||
Analyzes and removes multiple tasks in dependency order.
|
||||
|
||||
### Remove by Pattern
|
||||
```
|
||||
/orchestration/remove --pattern "oauth-*"
|
||||
```
|
||||
Removes all tasks matching pattern.
|
||||
|
||||
### Cascade Removal
|
||||
```
|
||||
/orchestration/remove TASK-003 --cascade
|
||||
```
|
||||
Also removes tasks that depend on this task.
|
||||
|
||||
## Handling Special Cases
|
||||
|
||||
### Task with Commits
|
||||
```
|
||||
Warning: TASK-003 has associated commits:
|
||||
- abc123: "feat(auth): implement JWT validation"
|
||||
- def456: "test(auth): add JWT tests"
|
||||
|
||||
Options:
|
||||
[1] Keep commits, remove task only
|
||||
[2] Add removal note to commit messages
|
||||
[3] Cancel removal
|
||||
```
|
||||
|
||||
### Task in QA/Completed
|
||||
```
|
||||
Warning: TASK-003 is in 'completed' status
|
||||
|
||||
This usually means work was done. Consider:
|
||||
[1] Archive task instead of removing
|
||||
[2] Document why it's being removed
|
||||
[3] Check if commits should be reverted
|
||||
```
|
||||
|
||||
### Critical Path Task
|
||||
```
|
||||
ERROR: TASK-003 is on the critical path!
|
||||
|
||||
Removing this task will impact project timeline:
|
||||
- Current completion: 5 days
|
||||
- After removal: 7 days (due to replanning)
|
||||
|
||||
Override with --force-critical
|
||||
```
|
||||
|
||||
## Removal Strategies
|
||||
|
||||
### Soft Remove (Default)
|
||||
```
|
||||
/orchestration/remove TASK-003
|
||||
```
|
||||
- Archives task file
|
||||
- Updates all references
|
||||
- Logs removal reason
|
||||
- Preserves git history
|
||||
|
||||
### Hard Remove
|
||||
```
|
||||
/orchestration/remove TASK-003 --hard
|
||||
```
|
||||
- Deletes task file permanently
|
||||
- Removes all traces
|
||||
- Updates git tracking
|
||||
- No recovery possible
|
||||
|
||||
### Replace Remove
|
||||
```
|
||||
/orchestration/remove TASK-003 --replace-with TASK-015
|
||||
```
|
||||
- Transfers dependencies to new task
|
||||
- Updates all references
|
||||
- Maintains continuity
|
||||
|
||||
## Undo Capabilities
|
||||
|
||||
### Recent Removal
|
||||
```
|
||||
/orchestration/remove --undo-last
|
||||
```
|
||||
Restores the most recently removed task.
|
||||
|
||||
### Restore from Archive
|
||||
```
|
||||
/orchestration/remove --restore TASK-003
|
||||
```
|
||||
Restores archived task with all references.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Obsolete Feature
|
||||
```
|
||||
/orchestration/remove TASK-008 --reason "Feature descoped"
|
||||
|
||||
Removing TASK-008: OAuth provider integration
|
||||
- No dependencies
|
||||
- No commits yet
|
||||
- Safe to remove
|
||||
|
||||
Task removed successfully.
|
||||
```
|
||||
|
||||
### Example 2: Duplicate Task
|
||||
```
|
||||
/orchestration/remove TASK-012 --replace-with TASK-005
|
||||
|
||||
Removing duplicate: TASK-012
|
||||
Transferring to: TASK-005
|
||||
- Dependencies transferred: 2
|
||||
- References updated: 4
|
||||
|
||||
Duplicate removed, TASK-005 updated.
|
||||
```
|
||||
|
||||
### Example 3: Changed Requirements
|
||||
```
|
||||
/orchestration/remove TASK-003,TASK-004,TASK-005 --reason "Auth system redesigned"
|
||||
|
||||
Removing authentication task group:
|
||||
- 3 tasks to remove
|
||||
- 2 have commits (will archive)
|
||||
- 5 dependent tasks need updates
|
||||
|
||||
Proceed? [y/N]
|
||||
```
|
||||
|
||||
## Audit Trail
|
||||
|
||||
All removals are logged:
|
||||
```yaml
|
||||
# .orchestration-audit.yaml
|
||||
removals:
|
||||
- task_id: TASK-003
|
||||
removed_at: "2024-03-15T16:00:00Z"
|
||||
removed_by: "user-id"
|
||||
reason: "Requirement changed"
|
||||
status_at_removal: "in_progress"
|
||||
dependencies_affected: ["TASK-005", "TASK-007"]
|
||||
commits_preserved: ["abc123", "def456"]
|
||||
archived_to: ".removed/2024-03-15/TASK-003/"
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Always Check Dependencies**: Review impact before removing
|
||||
2. **Document Reason**: Provide clear removal reason
|
||||
3. **Archive Important Work**: Use --archive for completed work
|
||||
4. **Update Team**: Notify about critical removals
|
||||
5. **Review Commits**: Check if code needs reverting
|
||||
|
||||
## Integration
|
||||
|
||||
### With Other Commands
|
||||
```
|
||||
# First check status
|
||||
/orchestration/status --task TASK-003
|
||||
|
||||
# Then remove if needed
|
||||
/orchestration/remove TASK-003
|
||||
```
|
||||
|
||||
### Bulk Operations
|
||||
```
|
||||
# Find and remove all on-hold tasks older than 30 days
|
||||
/orchestration/find --status on_hold --older-than 30d | /orchestration/remove --batch
|
||||
```
|
||||
|
||||
## Safety Features
|
||||
|
||||
- Confirmation required (unless --force)
|
||||
- Dependencies checked and warned
|
||||
- Commits preserved by default
|
||||
- Audit trail maintained
|
||||
- Undo capability for recent removals
|
||||
|
||||
## Notes
|
||||
|
||||
- Removed tasks are archived for 30 days by default
|
||||
- Git commits are never automatically reverted
|
||||
- Dependencies are gracefully handled
|
||||
- System consistency is maintained throughout
|
||||
@@ -0,0 +1,292 @@
|
||||
# Task Report Command
|
||||
|
||||
Generate comprehensive reports on task execution, progress, and metrics.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/task-report [report-type] [options]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Creates detailed reports for project management, sprint reviews, and performance analysis. Supports multiple report types and output formats.
|
||||
|
||||
## Report Types
|
||||
|
||||
### Executive Summary
|
||||
```
|
||||
/task-report executive
|
||||
```
|
||||
High-level overview for stakeholders with key metrics and progress.
|
||||
|
||||
### Sprint Report
|
||||
```
|
||||
/task-report sprint --date 03_15_2024
|
||||
```
|
||||
Detailed sprint progress with burndown charts and velocity.
|
||||
|
||||
### Daily Standup
|
||||
```
|
||||
/task-report standup
|
||||
```
|
||||
What was completed, in progress, and blocked.
|
||||
|
||||
### Performance Report
|
||||
```
|
||||
/task-report performance --period week
|
||||
```
|
||||
Team and individual performance metrics.
|
||||
|
||||
### Dependency Report
|
||||
```
|
||||
/task-report dependencies
|
||||
```
|
||||
Visual dependency graph and bottleneck analysis.
|
||||
|
||||
## Output Examples
|
||||
|
||||
### Executive Summary Report
|
||||
```
|
||||
EXECUTIVE SUMMARY - Authentication System Project
|
||||
================================================
|
||||
Report Date: 2024-03-15
|
||||
Project Start: 2024-03-13
|
||||
Duration: 3 days (60% complete)
|
||||
|
||||
KEY METRICS
|
||||
-----------
|
||||
• Total Tasks: 24
|
||||
• Completed: 12 (50%)
|
||||
• In Progress: 3 (12.5%)
|
||||
• Blocked: 2 (8.3%)
|
||||
• Remaining: 7 (29.2%)
|
||||
|
||||
TIMELINE
|
||||
--------
|
||||
• Original Estimate: 5 days
|
||||
• Current Projection: 5.5 days
|
||||
• Risk Level: Low
|
||||
|
||||
HIGHLIGHTS
|
||||
----------
|
||||
✓ Core authentication API completed
|
||||
✓ Database schema migrated
|
||||
✓ Unit tests passing (98% coverage)
|
||||
|
||||
BLOCKERS
|
||||
--------
|
||||
⚠ Payment integration waiting on external API
|
||||
⚠ UI components need design approval
|
||||
|
||||
NEXT MILESTONES
|
||||
--------------
|
||||
→ Complete JWT implementation (Today)
|
||||
→ Integration testing (Tomorrow)
|
||||
→ Security audit (Day 4)
|
||||
```
|
||||
|
||||
### Sprint Burndown Report
|
||||
```
|
||||
/task-report burndown --sprint current
|
||||
```
|
||||
```
|
||||
SPRINT BURNDOWN - Sprint 24
|
||||
===========================
|
||||
|
||||
Tasks Remaining by Day:
|
||||
Day 1: ████████████████████ 24
|
||||
Day 2: ████████████████ 20
|
||||
Day 3: ████████████ 15 (TODAY)
|
||||
Day 4: ████████ 10 (projected)
|
||||
Day 5: ████ 5 (projected)
|
||||
|
||||
Velocity Metrics:
|
||||
- Average: 4.5 tasks/day
|
||||
- Yesterday: 5 tasks
|
||||
- Today: 3 tasks (in progress)
|
||||
|
||||
Risk Assessment: ON TRACK
|
||||
```
|
||||
|
||||
### Performance Report
|
||||
```
|
||||
TEAM PERFORMANCE REPORT - Week 11
|
||||
=================================
|
||||
|
||||
By Agent:
|
||||
┌─────────────────┬────────┬───────────┬─────────┬────────────┐
|
||||
│ Agent │ Completed │ Avg Time │ Quality │ Efficiency │
|
||||
├─────────────────┼────────┼───────────┼─────────┼────────────┤
|
||||
│ dev-frontend │ 8 │ 3.2h │ 95% │ 125% │
|
||||
│ dev-backend │ 6 │ 4.1h │ 98% │ 110% │
|
||||
│ test-developer │ 4 │ 2.8h │ 100% │ 115% │
|
||||
└─────────────────┴────────┴───────────┴─────────┴────────────┘
|
||||
|
||||
By Task Type:
|
||||
- Features: 12 completed (avg 3.8h)
|
||||
- Bugfixes: 4 completed (avg 1.5h)
|
||||
- Tests: 8 completed (avg 2.2h)
|
||||
|
||||
Quality Metrics:
|
||||
- First-time pass rate: 88%
|
||||
- Rework required: 2 tasks
|
||||
- Blocked time: 4.5 hours total
|
||||
```
|
||||
|
||||
## Customization Options
|
||||
|
||||
### Time Period
|
||||
```
|
||||
/task-report summary --from 2024-03-01 --to 2024-03-15
|
||||
/task-report summary --last 7d
|
||||
/task-report summary --this-month
|
||||
```
|
||||
|
||||
### Specific Project
|
||||
```
|
||||
/task-report sprint --project authentication_system
|
||||
```
|
||||
|
||||
### Format Options
|
||||
```
|
||||
/task-report executive --format markdown
|
||||
/task-report executive --format html
|
||||
/task-report executive --format pdf
|
||||
```
|
||||
|
||||
### Include/Exclude
|
||||
```
|
||||
/task-report summary --include completed,qa
|
||||
/task-report summary --exclude on_hold
|
||||
```
|
||||
|
||||
## Specialized Reports
|
||||
|
||||
### Critical Path Analysis
|
||||
```
|
||||
/task-report critical-path
|
||||
```
|
||||
Shows tasks that directly impact completion time.
|
||||
|
||||
### Bottleneck Analysis
|
||||
```
|
||||
/task-report bottlenecks
|
||||
```
|
||||
Identifies tasks causing delays.
|
||||
|
||||
### Resource Utilization
|
||||
```
|
||||
/task-report resources
|
||||
```
|
||||
Shows agent allocation and availability.
|
||||
|
||||
### Risk Assessment
|
||||
```
|
||||
/task-report risks
|
||||
```
|
||||
Identifies potential delays and issues.
|
||||
|
||||
## Visualization Options
|
||||
|
||||
### Gantt Chart
|
||||
```
|
||||
/task-report gantt --weeks 2
|
||||
```
|
||||
|
||||
### Dependency Graph
|
||||
```
|
||||
/task-report dependencies --visual
|
||||
```
|
||||
|
||||
### Status Flow
|
||||
```
|
||||
/task-report flow --animated
|
||||
```
|
||||
|
||||
## Automated Reports
|
||||
|
||||
### Schedule Reports
|
||||
```
|
||||
/task-report schedule daily-standup --at "9am"
|
||||
/task-report schedule weekly-summary --every friday
|
||||
```
|
||||
|
||||
### Email Reports
|
||||
```
|
||||
/task-report executive --email team@company.com
|
||||
```
|
||||
|
||||
## Comparison Reports
|
||||
|
||||
### Sprint Comparison
|
||||
```
|
||||
/task-report compare --sprint 23 24
|
||||
```
|
||||
|
||||
### Week over Week
|
||||
```
|
||||
/task-report trends --weeks 4
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Morning Status
|
||||
```
|
||||
/task-report standup --format slack
|
||||
```
|
||||
Generates Slack-formatted standup report.
|
||||
|
||||
### Example 2: Sprint Review
|
||||
```
|
||||
/task-report sprint --include-velocity --include-burndown
|
||||
```
|
||||
Comprehensive sprint metrics for review meeting.
|
||||
|
||||
### Example 3: Blocker Focus
|
||||
```
|
||||
/task-report blockers --show-dependencies --show-resolution
|
||||
```
|
||||
Deep dive into what's blocking progress.
|
||||
|
||||
## Integration Features
|
||||
|
||||
### Export to Tools
|
||||
```
|
||||
/task-report export-jira
|
||||
/task-report export-asana
|
||||
/task-report export-github
|
||||
```
|
||||
|
||||
### API Endpoints
|
||||
```
|
||||
/task-report api --generate-endpoint
|
||||
```
|
||||
Creates API endpoint for external access.
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Daily Reviews**: Run standup report each morning
|
||||
2. **Weekly Summaries**: Generate performance reports on Fridays
|
||||
3. **Sprint Planning**: Use velocity trends for estimation
|
||||
4. **Stakeholder Updates**: Schedule automated executive summaries
|
||||
|
||||
## Report Components
|
||||
|
||||
Each report can include:
|
||||
- Summary statistics
|
||||
- Timeline visualization
|
||||
- Task lists by status
|
||||
- Agent performance
|
||||
- Dependency analysis
|
||||
- Risk assessment
|
||||
- Recommendations
|
||||
- Historical trends
|
||||
|
||||
## Notes
|
||||
|
||||
- Reports use data from all TASK-STATUS-TRACKER.yaml files
|
||||
- Completed tasks are included in historical metrics
|
||||
- Time calculations use business hours by default
|
||||
- All times shown in local timezone
|
||||
- Charts require terminal unicode support
|
||||
@@ -0,0 +1,256 @@
|
||||
# Orchestration Resume Command
|
||||
|
||||
Resume work on existing task orchestrations after session loss or context switch.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/orchestration/resume [options]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Restores full context for active orchestrations, showing current progress, identifying next actions, and providing all necessary information to continue work seamlessly.
|
||||
|
||||
## Basic Commands
|
||||
|
||||
### List Active Orchestrations
|
||||
```
|
||||
/orchestration/resume
|
||||
```
|
||||
Shows all orchestrations with active (non-completed) tasks.
|
||||
|
||||
### Resume Specific Orchestration
|
||||
```
|
||||
/orchestration/resume --date 03_15_2024 --project auth_system
|
||||
```
|
||||
Loads complete context for a specific orchestration.
|
||||
|
||||
### Resume Most Recent
|
||||
```
|
||||
/orchestration/resume --latest
|
||||
```
|
||||
Automatically resumes the most recently active orchestration.
|
||||
|
||||
## Output Format
|
||||
|
||||
### Orchestration List View
|
||||
```
|
||||
Active Task Orchestrations
|
||||
==========================
|
||||
|
||||
1. 03_15_2024/authentication_system
|
||||
Started: 3 days ago | Progress: 65% | Active Tasks: 3
|
||||
└─ Focus: JWT implementation, OAuth integration
|
||||
|
||||
2. 03_14_2024/payment_processing
|
||||
Started: 4 days ago | Progress: 40% | Active Tasks: 2
|
||||
└─ Focus: Stripe webhooks, refund handling
|
||||
|
||||
3. 03_12_2024/admin_dashboard
|
||||
Started: 1 week ago | Progress: 85% | Active Tasks: 1
|
||||
└─ Focus: Final testing and deployment
|
||||
|
||||
Select orchestration to resume: [1-3] or use --date and --project
|
||||
```
|
||||
|
||||
### Detailed Resume View
|
||||
```
|
||||
Resuming: authentication_system (03_15_2024)
|
||||
============================================
|
||||
|
||||
## Current Status Summary
|
||||
- Total Tasks: 24 (12 completed, 3 in progress, 2 on hold, 7 todos)
|
||||
- Time Elapsed: 3 days
|
||||
- Estimated Remaining: 2 days
|
||||
|
||||
## Tasks In Progress
|
||||
┌──────────┬────────────────────────────┬───────────────┬──────────────┐
|
||||
│ Task ID │ Title │ Agent │ Duration │
|
||||
├──────────┼────────────────────────────┼───────────────┼──────────────┤
|
||||
│ TASK-003 │ JWT token validation │ dev-backend │ 2.5h │
|
||||
│ TASK-007 │ OAuth provider setup │ dev-frontend │ 1h │
|
||||
│ TASK-011 │ Integration tests │ test-dev │ 30m │
|
||||
└──────────┴────────────────────────────┴───────────────┴──────────────┘
|
||||
|
||||
## Blocked Tasks (Require Attention)
|
||||
- TASK-005: User profile API - Blocked by TASK-003 (JWT validation)
|
||||
- TASK-009: OAuth callback handling - Waiting for provider credentials
|
||||
|
||||
## Next Available Tasks (Ready to Start)
|
||||
1. TASK-013: Password reset flow (4h, frontend)
|
||||
Files: src/auth/reset.tsx, src/api/auth.ts
|
||||
|
||||
2. TASK-014: Session management (3h, backend)
|
||||
Files: src/services/session.ts, src/middleware/auth.ts
|
||||
|
||||
## Recent Git Activity
|
||||
- feature/jwt-auth: 2 commits behind, last commit 2h ago
|
||||
- feature/oauth-setup: clean, last commit 1h ago
|
||||
|
||||
## Quick Actions
|
||||
[1] Show TASK-003 details (current focus)
|
||||
[2] Pick up TASK-013 (password reset)
|
||||
[3] View dependency graph
|
||||
[4] Show recent commits
|
||||
[5] Generate status report
|
||||
```
|
||||
|
||||
## Context Recovery Features
|
||||
|
||||
### Task Context
|
||||
```
|
||||
/orchestration/resume --task TASK-003
|
||||
```
|
||||
Shows:
|
||||
- Full task description and requirements
|
||||
- Implementation progress and notes
|
||||
- Related files with recent changes
|
||||
- Test requirements and status
|
||||
- Dependencies and blockers
|
||||
|
||||
### File Context
|
||||
```
|
||||
/orchestration/resume --show-files
|
||||
```
|
||||
Lists all files mentioned in active tasks with:
|
||||
- Last modified time
|
||||
- Current git status
|
||||
- Which tasks reference them
|
||||
|
||||
### Dependency Context
|
||||
```
|
||||
/orchestration/resume --deps
|
||||
```
|
||||
Shows dependency graph focused on active tasks.
|
||||
|
||||
## Working State Recovery
|
||||
|
||||
### Git State Summary
|
||||
```
|
||||
## Git Working State
|
||||
Current Branch: feature/jwt-auth
|
||||
Status: 2 files modified, 1 untracked
|
||||
|
||||
Modified Files:
|
||||
- src/auth/jwt.ts (related to TASK-003)
|
||||
- tests/auth.test.ts (related to TASK-003)
|
||||
|
||||
Untracked:
|
||||
- src/auth/jwt.config.ts (new file for TASK-003)
|
||||
|
||||
Recommendation: Commit current changes before switching tasks
|
||||
```
|
||||
|
||||
### Last Session Summary
|
||||
```
|
||||
## Last Session (2 hours ago)
|
||||
- Completed: TASK-002 (Database schema)
|
||||
- Started: TASK-003 (JWT validation)
|
||||
- Commits: 2 (feat: add user auth schema, test: auth unit tests)
|
||||
- Next planned: Continue TASK-003, then TASK-005
|
||||
```
|
||||
|
||||
## Filtering Options
|
||||
|
||||
### By Status
|
||||
```
|
||||
/orchestration/resume --show in_progress,on_hold
|
||||
```
|
||||
|
||||
### By Date Range
|
||||
```
|
||||
/orchestration/resume --since "last week"
|
||||
```
|
||||
|
||||
### By Completion
|
||||
```
|
||||
/orchestration/resume --incomplete # < 50% done
|
||||
/orchestration/resume --nearly-done # > 80% done
|
||||
```
|
||||
|
||||
## Integration Features
|
||||
|
||||
### Direct Task Pickup
|
||||
```
|
||||
/orchestration/resume --pickup TASK-013
|
||||
```
|
||||
Automatically:
|
||||
1. Shows task details
|
||||
2. Moves to in_progress
|
||||
3. Shows relevant files
|
||||
4. Creates feature branch if needed
|
||||
|
||||
### Status Check Integration
|
||||
```
|
||||
/orchestration/resume --with-status
|
||||
```
|
||||
Includes full status report with resume context.
|
||||
|
||||
### Commit History
|
||||
```
|
||||
/orchestration/resume --commits 5
|
||||
```
|
||||
Shows last 5 commits related to the orchestration.
|
||||
|
||||
## Quick Resume Patterns
|
||||
|
||||
### Morning Standup
|
||||
```
|
||||
/orchestration/resume --latest --with-status
|
||||
```
|
||||
Perfect for daily standups - shows what you were working on and current state.
|
||||
|
||||
### Context Switch
|
||||
```
|
||||
/orchestration/resume --save-state
|
||||
```
|
||||
Saves current working state before switching to another orchestration.
|
||||
|
||||
### Team Handoff
|
||||
```
|
||||
/orchestration/resume --handoff
|
||||
```
|
||||
Generates detailed handoff notes for another developer.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Quick Continue
|
||||
```
|
||||
/orchestration/resume --latest --pickup-where-left-off
|
||||
```
|
||||
Resumes exactly where you stopped, showing the in-progress task.
|
||||
|
||||
### Example 2: Monday Morning
|
||||
```
|
||||
/orchestration/resume --since friday --show-completed
|
||||
```
|
||||
Shows what was done Friday and what's next for Monday.
|
||||
|
||||
### Example 3: Multiple Projects
|
||||
```
|
||||
/orchestration/resume --all --summary
|
||||
```
|
||||
Quick overview of all active orchestrations.
|
||||
|
||||
## State Persistence
|
||||
|
||||
The command reads from:
|
||||
- EXECUTION-TRACKER.md for progress metrics
|
||||
- TASK-STATUS-TRACKER.yaml for current state
|
||||
- Task files for detailed context
|
||||
- Git for working directory state
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Use at Session Start**: Run `/orchestration/resume` when starting work
|
||||
2. **Save State**: Use `--save-state` before extended breaks
|
||||
3. **Check Dependencies**: Review blocked tasks that may now be unblocked
|
||||
4. **Commit Regularly**: Keep git state aligned with task progress
|
||||
|
||||
## Notes
|
||||
|
||||
- Automatically detects uncommitted changes related to tasks
|
||||
- Suggests next actions based on dependencies and priorities
|
||||
- Integrates with git worktrees if in use
|
||||
- Preserves task history for full context
|
||||
@@ -0,0 +1,169 @@
|
||||
# Orchestrate Tasks Command
|
||||
|
||||
Initiates the task orchestration workflow using the three-agent system (task-orchestrator, task-decomposer, and dependency-analyzer) to create a comprehensive execution plan.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/orchestrate [task list or file path]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
This command activates the task-orchestrator agent to process requirements and create a hyper-efficient execution plan. The orchestrator will:
|
||||
|
||||
1. **Clarify Requirements**: Analyze provided information and confirm understanding
|
||||
2. **Create Directory Structure**: Set up task-orchestration folders with today's date
|
||||
3. **Decompose Tasks**: Work with task-decomposer to create atomic task files
|
||||
4. **Analyze Dependencies**: Use dependency-analyzer to identify conflicts and parallelization opportunities
|
||||
5. **Generate Master Plan**: Create comprehensive coordination documents
|
||||
|
||||
## Input Formats
|
||||
|
||||
### Direct Task List
|
||||
```
|
||||
/orchestrate
|
||||
- Implement user authentication with JWT
|
||||
- Add payment processing with Stripe
|
||||
- Create admin dashboard
|
||||
- Set up email notifications
|
||||
```
|
||||
|
||||
### File Reference
|
||||
```
|
||||
/orchestrate features.md
|
||||
```
|
||||
|
||||
### Mixed Context
|
||||
```
|
||||
/orchestrate
|
||||
Based on our meeting notes (lots of discussion about UI colors), we need to:
|
||||
1. Fix the security vulnerability in file uploads
|
||||
2. Add rate limiting to APIs
|
||||
3. Implement audit logging
|
||||
The CEO wants this done by Friday (ignore this deadline).
|
||||
```
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Requirement Clarification**
|
||||
- The orchestrator will extract actionable tasks from provided context
|
||||
- Confirm understanding before proceeding
|
||||
- Ask clarifying questions if needed
|
||||
|
||||
2. **Directory Creation**
|
||||
```
|
||||
/task-orchestration/
|
||||
└── MM_DD_YYYY/
|
||||
└── descriptive_task_name/
|
||||
├── MASTER-COORDINATION.md
|
||||
├── EXECUTION-TRACKER.md
|
||||
├── TASK-STATUS-TRACKER.yaml
|
||||
└── tasks/
|
||||
├── todos/
|
||||
├── in_progress/
|
||||
├── on_hold/
|
||||
├── qa/
|
||||
└── completed/
|
||||
```
|
||||
|
||||
3. **Task Processing**
|
||||
- Creates individual task files in todos/
|
||||
- Analyzes dependencies and conflicts
|
||||
- Generates execution strategy
|
||||
|
||||
4. **Deliverables**
|
||||
- Master coordination plan
|
||||
- Task dependency graph
|
||||
- Resource allocation matrix
|
||||
- Execution timeline
|
||||
|
||||
## Options
|
||||
|
||||
### Focused Mode
|
||||
```
|
||||
/orchestrate --focus security
|
||||
[task list]
|
||||
```
|
||||
Prioritizes tasks related to the specified focus area.
|
||||
|
||||
### Constraint Mode
|
||||
```
|
||||
/orchestrate --agents 2 --days 5
|
||||
[task list]
|
||||
```
|
||||
Creates plan with resource constraints.
|
||||
|
||||
### Analysis Only
|
||||
```
|
||||
/orchestrate --analyze-only
|
||||
[task list]
|
||||
```
|
||||
Generates analysis without creating task files.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Clear Task List
|
||||
```
|
||||
/orchestrate
|
||||
1. Implement OAuth2 authentication
|
||||
2. Add user profile management
|
||||
3. Create password reset flow
|
||||
4. Set up 2FA
|
||||
```
|
||||
|
||||
### Example 2: From Requirements Doc
|
||||
```
|
||||
/orchestrate requirements/sprint-24.md
|
||||
```
|
||||
|
||||
### Example 3: Mixed Context Extraction
|
||||
```
|
||||
/orchestrate
|
||||
From the customer feedback:
|
||||
"The app is too slow" - Need performance optimization
|
||||
"Can't find the export button" - UI improvement needed
|
||||
"Want dark mode" - New feature request
|
||||
|
||||
Technical debt from last sprint:
|
||||
- Refactor authentication service
|
||||
- Update deprecated dependencies
|
||||
```
|
||||
|
||||
## Interactive Mode
|
||||
|
||||
The orchestrator will:
|
||||
1. Present extracted tasks for confirmation
|
||||
2. Ask about priorities and constraints
|
||||
3. Suggest optimal approach
|
||||
4. Request approval before creating files
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If tasks are unclear: Asks for clarification
|
||||
- If file not found: Prompts for correct path
|
||||
- If conflicts detected: Presents options
|
||||
- If dependencies circular: Suggests resolution
|
||||
|
||||
## Integration
|
||||
|
||||
Works seamlessly with:
|
||||
- `/task-status` - Check progress
|
||||
- `/task-move` - Update task status
|
||||
- `/task-report` - Generate reports
|
||||
- `/task-assign` - Allocate to agents
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Provide Context**: Include relevant background information
|
||||
2. **Be Specific**: Clear task descriptions enable better planning
|
||||
3. **Mention Constraints**: Include deadlines, resources, or blockers
|
||||
4. **Review Output**: Confirm the extracted tasks match your intent
|
||||
|
||||
## Notes
|
||||
|
||||
- The orchestrator filters out irrelevant context automatically
|
||||
- Tasks are created in todos/ status by default
|
||||
- All tasks get unique IDs (TASK-XXX format)
|
||||
- Status tracking begins immediately
|
||||
- Supports incremental additions to existing orchestrations
|
||||
@@ -0,0 +1,219 @@
|
||||
# Task Status Command
|
||||
|
||||
Check the current status of tasks in the orchestration system with various filtering and reporting options.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/task-status [options]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Provides comprehensive visibility into task progress, status distribution, and execution metrics across all active orchestrations.
|
||||
|
||||
## Command Variants
|
||||
|
||||
### Basic Status Overview
|
||||
```
|
||||
/task-status
|
||||
```
|
||||
Shows summary of all tasks across all active orchestrations.
|
||||
|
||||
### Today's Tasks
|
||||
```
|
||||
/task-status --today
|
||||
```
|
||||
Shows only tasks from today's orchestrations.
|
||||
|
||||
### Specific Orchestration
|
||||
```
|
||||
/task-status --date 03_15_2024 --project payment_integration
|
||||
```
|
||||
Shows tasks from a specific orchestration.
|
||||
|
||||
### Status Filter
|
||||
```
|
||||
/task-status --status in_progress
|
||||
/task-status --status qa
|
||||
/task-status --status on_hold
|
||||
```
|
||||
Shows only tasks with specified status.
|
||||
|
||||
### Detailed View
|
||||
```
|
||||
/task-status --detailed
|
||||
```
|
||||
Shows comprehensive information for each task.
|
||||
|
||||
## Output Formats
|
||||
|
||||
### Summary View (Default)
|
||||
```
|
||||
Task Orchestration Status Summary
|
||||
=================================
|
||||
|
||||
Active Orchestrations: 3
|
||||
Total Tasks: 47
|
||||
|
||||
Status Distribution:
|
||||
┌─────────────┬───────┬────────────┐
|
||||
│ Status │ Count │ Percentage │
|
||||
├─────────────┼───────┼────────────┤
|
||||
│ completed │ 12 │ 26% │
|
||||
│ qa │ 5 │ 11% │
|
||||
│ in_progress │ 3 │ 6% │
|
||||
│ on_hold │ 2 │ 4% │
|
||||
│ todos │ 25 │ 53% │
|
||||
└─────────────┴───────┴────────────┘
|
||||
|
||||
Active Tasks (in_progress):
|
||||
- TASK-001: Implement JWT authentication (Agent: dev-frontend)
|
||||
- TASK-007: Create payment webhook handler (Agent: dev-backend)
|
||||
- TASK-012: Write integration tests (Agent: test-developer)
|
||||
|
||||
Blocked Tasks (on_hold):
|
||||
- TASK-004: User profile API (Blocked by: TASK-001)
|
||||
- TASK-009: Payment confirmation UI (Blocked by: TASK-007)
|
||||
```
|
||||
|
||||
### Detailed View
|
||||
```
|
||||
Task Details for: 03_15_2024/authentication_system
|
||||
==================================================
|
||||
|
||||
TASK-001: Implement JWT authentication
|
||||
Status: in_progress
|
||||
Agent: dev-frontend
|
||||
Started: 2024-03-15T14:30:00Z
|
||||
Duration: 3.5 hours
|
||||
Progress: 75% (est. 1 hour remaining)
|
||||
Dependencies: None
|
||||
Blocks: TASK-004, TASK-005
|
||||
Location: /task-orchestration/03_15_2024/authentication_system/tasks/in_progress/
|
||||
|
||||
Status History:
|
||||
- todos → in_progress (2024-03-15T14:30:00Z) by dev-frontend
|
||||
```
|
||||
|
||||
### Timeline View
|
||||
```
|
||||
/task-status --timeline
|
||||
```
|
||||
Shows Gantt-style timeline of task execution.
|
||||
|
||||
### Velocity Report
|
||||
```
|
||||
/task-status --velocity
|
||||
```
|
||||
Shows completion rates and performance metrics.
|
||||
|
||||
## Filtering Options
|
||||
|
||||
### By Agent
|
||||
```
|
||||
/task-status --agent dev-frontend
|
||||
```
|
||||
|
||||
### By Priority
|
||||
```
|
||||
/task-status --priority high
|
||||
```
|
||||
|
||||
### By Type
|
||||
```
|
||||
/task-status --type feature
|
||||
/task-status --type bugfix
|
||||
```
|
||||
|
||||
### Multiple Filters
|
||||
```
|
||||
/task-status --status todos --priority high --type security
|
||||
```
|
||||
|
||||
## Quick Actions
|
||||
|
||||
### Show Critical Path
|
||||
```
|
||||
/task-status --critical-path
|
||||
```
|
||||
Highlights tasks that are blocking others.
|
||||
|
||||
### Show Overdue
|
||||
```
|
||||
/task-status --overdue
|
||||
```
|
||||
Shows tasks exceeding estimated time.
|
||||
|
||||
### Show Available
|
||||
```
|
||||
/task-status --available
|
||||
```
|
||||
Shows todos tasks ready to be picked up.
|
||||
|
||||
## Integration Commands
|
||||
|
||||
### Export Status
|
||||
```
|
||||
/task-status --export markdown
|
||||
/task-status --export csv
|
||||
```
|
||||
|
||||
### Watch Mode
|
||||
```
|
||||
/task-status --watch
|
||||
```
|
||||
Updates status in real-time (refreshes every 30 seconds).
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Morning Standup View
|
||||
```
|
||||
/task-status --today --detailed
|
||||
```
|
||||
|
||||
### Example 2: Find Blocked Work
|
||||
```
|
||||
/task-status --status on_hold --show-blockers
|
||||
```
|
||||
|
||||
### Example 3: Agent Workload
|
||||
```
|
||||
/task-status --by-agent --status in_progress
|
||||
```
|
||||
|
||||
### Example 4: Sprint Progress
|
||||
```
|
||||
/task-status --date 03_15_2024 --metrics
|
||||
```
|
||||
|
||||
## Metrics and Analytics
|
||||
|
||||
### Completion Metrics
|
||||
- Average time per task
|
||||
- Tasks completed per day
|
||||
- Status transition times
|
||||
|
||||
### Bottleneck Analysis
|
||||
- Most blocking tasks
|
||||
- Longest on_hold duration
|
||||
- Critical path duration
|
||||
|
||||
### Agent Performance
|
||||
- Tasks per agent
|
||||
- Average completion time
|
||||
- Current workload
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Daily Check**: Run `/task-status --today` each morning
|
||||
2. **Blocker Review**: Check `/task-status --status on_hold` regularly
|
||||
3. **Progress Tracking**: Use `/task-status --velocity` for trends
|
||||
4. **Resource Planning**: Monitor `/task-status --by-agent`
|
||||
|
||||
## Notes
|
||||
|
||||
- Status data is read from TASK-STATUS-TRACKER.yaml files
|
||||
- All times are shown in local timezone
|
||||
- Completed tasks are included in metrics but not in active lists
|
||||
- Use `--all` flag to include historical orchestrations
|
||||
@@ -0,0 +1,294 @@
|
||||
# Orchestration Sync Command
|
||||
|
||||
Synchronize task status with git commits, ensuring consistency between version control and task tracking.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/orchestration/sync [options]
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
Analyzes git history and task status to identify discrepancies, automatically updating task tracking based on commit evidence and maintaining bidirectional consistency.
|
||||
|
||||
## Basic Commands
|
||||
|
||||
### Full Sync
|
||||
```
|
||||
/orchestration/sync
|
||||
```
|
||||
Performs complete synchronization between git and task status.
|
||||
|
||||
### Check Sync Status
|
||||
```
|
||||
/orchestration/sync --check
|
||||
```
|
||||
Reports inconsistencies without making changes.
|
||||
|
||||
### Sync Specific Orchestration
|
||||
```
|
||||
/orchestration/sync --date 03_15_2024 --project auth_system
|
||||
```
|
||||
|
||||
## Sync Operations
|
||||
|
||||
### Git → Task Status
|
||||
Updates task status based on commit messages:
|
||||
```
|
||||
Found commits:
|
||||
- feat(auth): implement JWT validation (TASK-003) ✓
|
||||
Status: in_progress → qa (based on commit)
|
||||
|
||||
- test(auth): add JWT validation tests (TASK-003) ✓
|
||||
Status: qa → completed (tests indicate completion)
|
||||
|
||||
- fix(auth): resolve token expiration (TASK-007) ✓
|
||||
Status: todos → in_progress (work started)
|
||||
```
|
||||
|
||||
### Task Status → Git
|
||||
Identifies tasks marked complete without commits:
|
||||
```
|
||||
Status Discrepancies:
|
||||
- TASK-005: Marked 'completed' but no commits found
|
||||
- TASK-008: In 'qa' but no implementation commits
|
||||
- TASK-010: Multiple commits but still in 'todos'
|
||||
```
|
||||
|
||||
## Detection Patterns
|
||||
|
||||
### Commit Pattern Matching
|
||||
```
|
||||
Patterns detected:
|
||||
- "feat(auth): implement" → Implementation complete
|
||||
- "test(auth): add" → Testing phase
|
||||
- "fix(auth): resolve" → Bug fix complete
|
||||
- "docs(auth): update" → Documentation done
|
||||
- "refactor(auth):" → Code improvement
|
||||
```
|
||||
|
||||
### Task Reference Extraction
|
||||
```
|
||||
Scanning commits for task references:
|
||||
- Explicit: "Task: TASK-003" ✓
|
||||
- In body: "Implements TASK-003" ✓
|
||||
- Branch name: "feature/TASK-003-jwt" ✓
|
||||
- PR title: "TASK-003: JWT implementation" ✓
|
||||
```
|
||||
|
||||
## Sync Rules
|
||||
|
||||
### Automatic Status Updates
|
||||
```yaml
|
||||
sync_rules:
|
||||
commit_patterns:
|
||||
- pattern: "feat.*TASK-(\d+)"
|
||||
action: "move to qa if in_progress"
|
||||
- pattern: "test.*TASK-(\d+).*pass"
|
||||
action: "move to completed if in qa"
|
||||
- pattern: "fix.*TASK-(\d+)"
|
||||
action: "move to qa if in_progress"
|
||||
- pattern: "WIP.*TASK-(\d+)"
|
||||
action: "keep in in_progress"
|
||||
```
|
||||
|
||||
### Conflict Resolution
|
||||
```
|
||||
Conflict detected for TASK-003:
|
||||
- Git evidence: 3 commits, tests passing
|
||||
- Task status: in_progress
|
||||
- Recommended: Move to completed
|
||||
|
||||
Resolution options:
|
||||
[1] Trust git (move to completed)
|
||||
[2] Trust tracker (keep in_progress)
|
||||
[3] Manual review
|
||||
[4] Skip
|
||||
```
|
||||
|
||||
## Analysis Reports
|
||||
|
||||
### Sync Summary
|
||||
```
|
||||
Synchronization Report
|
||||
======================
|
||||
|
||||
Analyzed: 45 commits across 3 branches
|
||||
Tasks referenced: 12
|
||||
Status updates needed: 4
|
||||
|
||||
Updates to apply:
|
||||
- TASK-003: in_progress → completed (3 commits)
|
||||
- TASK-007: todos → in_progress (1 commit)
|
||||
- TASK-009: qa → completed (tests added)
|
||||
- TASK-011: on_hold → in_progress (blocker resolved)
|
||||
|
||||
Warnings:
|
||||
- TASK-005: Completed without commits
|
||||
- TASK-013: Commits without task reference
|
||||
```
|
||||
|
||||
### Detailed Analysis
|
||||
```
|
||||
Task: TASK-003 - JWT Implementation
|
||||
Current Status: in_progress
|
||||
Git Evidence:
|
||||
- feat(auth): implement JWT validation (2 days ago)
|
||||
- test(auth): add validation tests (1 day ago)
|
||||
- fix(auth): handle edge cases (1 day ago)
|
||||
|
||||
Recommendation: Move to completed
|
||||
Confidence: High (95%)
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
### Dry Run
|
||||
```
|
||||
/orchestration/sync --dry-run
|
||||
```
|
||||
Shows what would change without applying updates.
|
||||
|
||||
### Force Sync
|
||||
```
|
||||
/orchestration/sync --force
|
||||
```
|
||||
Applies all recommendations without prompting.
|
||||
|
||||
### Time Range
|
||||
```
|
||||
/orchestration/sync --since "1 week ago"
|
||||
```
|
||||
Only analyzes recent commits.
|
||||
|
||||
### Branch Specific
|
||||
```
|
||||
/orchestration/sync --branch feature/auth
|
||||
```
|
||||
Syncs only tasks related to specific branch.
|
||||
|
||||
## Integration Features
|
||||
|
||||
### Update Tracking Files
|
||||
```
|
||||
/orchestration/sync --update-trackers
|
||||
```
|
||||
Updates TASK-STATUS-TRACKER.yaml with:
|
||||
```yaml
|
||||
git_tracking:
|
||||
TASK-003:
|
||||
status_from_git: completed
|
||||
confidence: 0.95
|
||||
evidence:
|
||||
- commit: abc123
|
||||
message: "feat(auth): implement JWT"
|
||||
date: "2024-03-13"
|
||||
- commit: def456
|
||||
message: "test(auth): add tests"
|
||||
date: "2024-03-14"
|
||||
```
|
||||
|
||||
### Generate Commit Report
|
||||
```
|
||||
/orchestration/sync --commit-report
|
||||
```
|
||||
Creates report of all task-related commits.
|
||||
|
||||
### Fix Orphaned Commits
|
||||
```
|
||||
/orchestration/sync --link-orphans
|
||||
```
|
||||
Associates commits without task references.
|
||||
|
||||
## Sync Strategies
|
||||
|
||||
### Conservative
|
||||
```
|
||||
/orchestration/sync --conservative
|
||||
```
|
||||
Only updates with high confidence matches.
|
||||
|
||||
### Aggressive
|
||||
```
|
||||
/orchestration/sync --aggressive
|
||||
```
|
||||
Updates based on any evidence.
|
||||
|
||||
### Interactive
|
||||
```
|
||||
/orchestration/sync --interactive
|
||||
```
|
||||
Prompts for each potential update.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Daily Sync
|
||||
```
|
||||
/orchestration/sync --since yesterday
|
||||
|
||||
Quick sync results:
|
||||
- 5 commits analyzed
|
||||
- 2 tasks updated
|
||||
- All changes applied successfully
|
||||
```
|
||||
|
||||
### Example 2: Branch Merge Sync
|
||||
```
|
||||
/orchestration/sync --after-merge feature/auth
|
||||
|
||||
Post-merge sync:
|
||||
- 15 commits from feature/auth
|
||||
- 5 tasks moved to completed
|
||||
- 2 tasks have test failures (kept in qa)
|
||||
```
|
||||
|
||||
### Example 3: Audit Mode
|
||||
```
|
||||
/orchestration/sync --audit --report
|
||||
|
||||
Audit Report:
|
||||
- Tasks with commits: 85%
|
||||
- Commits with task refs: 92%
|
||||
- Average commits per task: 2.3
|
||||
- Orphaned commits: 3
|
||||
```
|
||||
|
||||
## Webhook Integration
|
||||
|
||||
### Auto-sync on Push
|
||||
```yaml
|
||||
git_hooks:
|
||||
post-commit: /orchestration/sync --last-commit
|
||||
post-merge: /orchestration/sync --branch HEAD
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Regular Syncs**: Run daily or after major commits
|
||||
2. **Review Before Force**: Check dry-run output first
|
||||
3. **Maintain References**: Include task IDs in commits
|
||||
4. **Handle Conflicts**: Don't ignore sync warnings
|
||||
5. **Document Decisions**: Note why status differs from git
|
||||
|
||||
## Configuration
|
||||
|
||||
### Sync Preferences
|
||||
```yaml
|
||||
sync_config:
|
||||
auto_sync: true
|
||||
confidence_threshold: 0.8
|
||||
require_tests: true
|
||||
trust_git_over_tracker: true
|
||||
patterns:
|
||||
- implementation: "feat|feature"
|
||||
- testing: "test|spec"
|
||||
- completion: "done|complete|finish"
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- Requires git access to all relevant branches
|
||||
- Preserves manual status overrides with flags
|
||||
- Supports custom commit message patterns
|
||||
- Integrates with CI/CD for automated syncing
|
||||
Reference in New Issue
Block a user