Initial commit
This commit is contained in:
Zhongwei Li
475
skills/dependency-orchestration/SKILL.md
Normal file
475
skills/dependency-orchestration/SKILL.md
Normal file
@@ -0,0 +1,475 @@
|
||||
---
|
||||
skill: dependency-orchestration
|
||||
description: Advanced dependency analysis, critical path identification, bottleneck detection, and parallel opportunity discovery using MCP tool orchestration patterns.
|
||||
---
|
||||
|
||||
# Dependency Orchestration Skill
|
||||
|
||||
Comprehensive dependency analysis and resolution strategies for optimizing task execution workflows through systematic MCP tool usage.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
**Activate for:**
|
||||
- "Analyze dependencies for feature X"
|
||||
- "What's blocking task Y?"
|
||||
- "Find bottlenecks in feature Z"
|
||||
- "Show critical path"
|
||||
- "Find parallel opportunities"
|
||||
- "Resolve circular dependencies"
|
||||
|
||||
**This skill handles:**
|
||||
- Systematic dependency analysis using query patterns
|
||||
- Critical path identification through recursive queries
|
||||
- Bottleneck detection by analyzing outgoing dependencies
|
||||
- Parallel opportunity discovery
|
||||
- Circular dependency detection
|
||||
- Resolution strategy recommendations
|
||||
|
||||
## Tools Available
|
||||
|
||||
- `query_dependencies` - Query task dependencies
|
||||
- `query_container` - Read tasks and features
|
||||
- `manage_dependency` - Create/delete dependencies
|
||||
|
||||
## Core Workflows
|
||||
|
||||
### 1. Analyze Feature Dependencies
|
||||
|
||||
**Tool Orchestration Pattern:**
|
||||
|
||||
```
|
||||
Step 1: Get all tasks in feature
|
||||
query_container(operation="search", containerType="task", featureId="...")
|
||||
|
||||
Step 2: For each task, get dependencies
|
||||
query_dependencies(taskId="...", direction="all", includeTaskInfo=true)
|
||||
|
||||
Step 3: Build dependency understanding
|
||||
For each task, track:
|
||||
- Incoming dependencies (what blocks this task)
|
||||
- Outgoing dependencies (what this task blocks)
|
||||
- Dependency status (complete/incomplete)
|
||||
|
||||
Step 4: Identify patterns
|
||||
- Tasks with no incoming deps = can start immediately
|
||||
- Tasks with many outgoing deps = potential bottlenecks
|
||||
- Tasks blocked by incomplete deps = currently blocked
|
||||
```
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
User: "Analyze dependencies for authentication feature"
|
||||
|
||||
Actions:
|
||||
1. query_container(operation="search", containerType="task", featureId="auth-feature-id")
|
||||
Returns: 8 tasks
|
||||
|
||||
2. For each of 8 tasks:
|
||||
query_dependencies(taskId="...", direction="all", includeTaskInfo=true)
|
||||
|
||||
3. Analysis results:
|
||||
- 2 tasks have no incoming dependencies (can start now)
|
||||
- 1 task blocks 4 other tasks (BOTTLENECK)
|
||||
- 3 tasks are blocked by incomplete dependencies
|
||||
- 2 tasks are independent (can run in parallel)
|
||||
|
||||
4. Report:
|
||||
"Feature has 8 tasks with 1 critical bottleneck.
|
||||
Recommend completing 'Implement auth API' first (unblocks 4 tasks).
|
||||
2 tasks can start immediately in parallel."
|
||||
```
|
||||
|
||||
### 2. Critical Path Identification
|
||||
|
||||
**Tool Orchestration Pattern:**
|
||||
|
||||
```
|
||||
Step 1: Get all tasks
|
||||
query_container(operation="search", containerType="task", featureId="...")
|
||||
|
||||
Step 2: Build dependency chains recursively
|
||||
For each task with no outgoing dependencies (end tasks):
|
||||
Work backwards using incoming dependencies
|
||||
Track: task1 ← task2 ← task3 ← task4
|
||||
|
||||
Step 3: Calculate path lengths
|
||||
Sum complexity values along each path
|
||||
|
||||
Step 4: Identify longest path
|
||||
Path with highest total complexity = critical path
|
||||
|
||||
Step 5: Report findings
|
||||
"Critical path: [tasks] with total complexity X"
|
||||
```
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
User: "Show critical path for feature X"
|
||||
|
||||
Actions:
|
||||
1. query_container(operation="search", containerType="task", featureId="...")
|
||||
Returns: Tasks T1, T2, T3, T4
|
||||
|
||||
2. For each task: query_dependencies(taskId="...", direction="incoming", includeTaskInfo=true)
|
||||
|
||||
3. Trace paths:
|
||||
Path A: T1 (complexity 5) → T2 (complexity 7) → T4 (complexity 5) = 17
|
||||
Path B: T3 (complexity 6) → T4 (complexity 5) = 11
|
||||
|
||||
4. Report:
|
||||
"Critical path: T1 → T2 → T4 (total complexity: 17, 68% of work)
|
||||
This path determines minimum feature completion time."
|
||||
```
|
||||
|
||||
### 3. Bottleneck Detection
|
||||
|
||||
**Tool Orchestration Pattern:**
|
||||
|
||||
```
|
||||
Step 1: Get all incomplete tasks
|
||||
query_container(operation="search", containerType="task", featureId="...", status="pending,in-progress")
|
||||
|
||||
Step 2: For each task, count outgoing dependencies
|
||||
query_dependencies(taskId="...", direction="outgoing", includeTaskInfo=true)
|
||||
Count how many tasks are blocked by this task
|
||||
|
||||
Step 3: Identify high-impact tasks
|
||||
Tasks blocking 3+ other tasks = HIGH impact bottleneck
|
||||
Tasks blocking 2 other tasks = MEDIUM impact
|
||||
|
||||
Step 4: Prioritize by impact and status
|
||||
- In-progress bottlenecks = highest priority (complete ASAP)
|
||||
- Pending bottlenecks = high priority (start soon)
|
||||
- Include task complexity in recommendations
|
||||
|
||||
Step 5: Report with actions
|
||||
"Bottleneck: [Task X] blocks [N] tasks. Complete this first."
|
||||
```
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
User: "Find bottlenecks in feature Y"
|
||||
|
||||
Actions:
|
||||
1. query_container(operation="search", containerType="task", featureId="...", status="pending,in-progress")
|
||||
Returns: 6 active tasks
|
||||
|
||||
2. For each task: query_dependencies(taskId="...", direction="outgoing", includeTaskInfo=true)
|
||||
Results:
|
||||
- Task A: blocks 4 tasks (HIGH IMPACT)
|
||||
- Task B: blocks 2 tasks (MEDIUM IMPACT)
|
||||
- Task C-F: block 0-1 tasks (LOW IMPACT)
|
||||
|
||||
3. Report:
|
||||
"HIGH IMPACT BOTTLENECK:
|
||||
'Implement auth API' (in-progress, complexity 7) blocks 4 tasks.
|
||||
Recommend: Prioritize completion immediately.
|
||||
|
||||
MEDIUM IMPACT:
|
||||
'Setup database' (pending, complexity 5) blocks 2 tasks.
|
||||
Recommend: Start after auth API."
|
||||
```
|
||||
|
||||
### 4. Parallel Opportunity Discovery
|
||||
|
||||
**Tool Orchestration Pattern:**
|
||||
|
||||
```
|
||||
Step 1: Get all pending tasks
|
||||
query_container(operation="search", containerType="task", featureId="...", status="pending")
|
||||
|
||||
Step 2: For each task, check if unblocked
|
||||
query_dependencies(taskId="...", direction="incoming", includeTaskInfo=true)
|
||||
If all incoming dependencies are complete → task is ready
|
||||
|
||||
Step 3: Group ready tasks by domain
|
||||
Using task tags, group by:
|
||||
- database tasks
|
||||
- backend tasks
|
||||
- frontend tasks
|
||||
- testing tasks
|
||||
|
||||
Step 4: Calculate parallelism benefit
|
||||
Tasks in different domains = can run truly parallel
|
||||
Sum complexity: serial vs parallel time savings
|
||||
|
||||
Step 5: Report opportunities
|
||||
"Can run in parallel: [tasks] - saves X% time"
|
||||
```
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
User: "Find parallel opportunities in feature Z"
|
||||
|
||||
Actions:
|
||||
1. query_container(operation="search", containerType="task", featureId="...", status="pending")
|
||||
Returns: 5 pending tasks
|
||||
|
||||
2. For each: query_dependencies(taskId="...", direction="incoming", includeTaskInfo=true)
|
||||
Results:
|
||||
- T1 (Database): no incomplete dependencies (READY)
|
||||
- T2 (Backend): blocked by T5
|
||||
- T3 (Frontend): no incomplete dependencies (READY)
|
||||
- T4 (Tests): blocked by T2, T3
|
||||
- T5 (Backend): in-progress
|
||||
|
||||
3. Identify parallel group: T1 and T3
|
||||
- Different domains (database + frontend)
|
||||
- No interdependencies
|
||||
- Total complexity: 11
|
||||
- Parallel time: max(5, 6) = 6
|
||||
- Time saved: 5 units (45%)
|
||||
|
||||
4. Report:
|
||||
"Parallel opportunity: Run 'Database schema' and 'UI components' simultaneously.
|
||||
Saves 45% time (11 → 6 complexity units)."
|
||||
```
|
||||
|
||||
### 5. Circular Dependency Detection
|
||||
|
||||
**Tool Orchestration Pattern:**
|
||||
|
||||
```
|
||||
Step 1: Get all tasks
|
||||
query_container(operation="search", containerType="task", featureId="...")
|
||||
|
||||
Step 2: For each task, trace dependency chain
|
||||
query_dependencies(taskId="...", direction="outgoing", includeTaskInfo=true)
|
||||
For each blocked task, recursively query its outgoing dependencies
|
||||
|
||||
Step 3: Track visited tasks
|
||||
If you encounter a task already in current chain → circular dependency found
|
||||
|
||||
Step 4: Identify the cycle
|
||||
Report: TaskA → TaskB → TaskC → TaskA
|
||||
|
||||
Step 5: Suggest resolution
|
||||
Analyze which dependency is weakest/most recent
|
||||
Recommend removal to break cycle
|
||||
```
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
User: "Check for circular dependencies in feature W"
|
||||
|
||||
Actions:
|
||||
1. query_container(operation="search", containerType="task", featureId="...")
|
||||
Returns: 6 tasks
|
||||
|
||||
2. For T1: query_dependencies(taskId="T1", direction="outgoing")
|
||||
T1 blocks T3
|
||||
|
||||
3. For T3: query_dependencies(taskId="T3", direction="outgoing")
|
||||
T3 blocks T5
|
||||
|
||||
4. For T5: query_dependencies(taskId="T5", direction="outgoing")
|
||||
T5 blocks T1 → CIRCULAR DEPENDENCY DETECTED!
|
||||
|
||||
5. Report:
|
||||
"⚠️ Circular dependency detected:
|
||||
T1 → T3 → T5 → T1
|
||||
|
||||
Tasks involved:
|
||||
- T1: Implement API
|
||||
- T3: Add caching
|
||||
- T5: Update API for cache
|
||||
|
||||
Resolution options:
|
||||
1. Remove T5 → T1 (most recent dependency)
|
||||
2. Reorder: Complete T1, then T5 won't need to depend on T1
|
||||
3. Split T5 into two tasks to break cycle"
|
||||
```
|
||||
|
||||
### 6. Generate Resolution Strategy
|
||||
|
||||
**Tool Orchestration Pattern:**
|
||||
|
||||
```
|
||||
Step 1: Identify blocked tasks
|
||||
Use patterns from Workflow 1 and 3
|
||||
|
||||
Step 2: Prioritize bottlenecks
|
||||
Use pattern from Workflow 3
|
||||
|
||||
Step 3: Find parallel opportunities
|
||||
Use pattern from Workflow 4
|
||||
|
||||
Step 4: Create execution plan
|
||||
Priority 1: Bottlenecks on critical path
|
||||
Priority 2: High-impact bottlenecks off critical path
|
||||
Priority 3: Tasks with parallel opportunities
|
||||
|
||||
Step 5: Report actionable strategy
|
||||
"Execute in this order: [sequence] for optimal completion time"
|
||||
```
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
User: "What's the best way to complete feature X?"
|
||||
|
||||
Actions:
|
||||
1. Analyze dependencies (Workflow 1)
|
||||
2. Find critical path (Workflow 2): T1 → T2 → T4
|
||||
3. Find bottlenecks (Workflow 3): T2 blocks 4 tasks
|
||||
4. Find parallel opportunities (Workflow 4): T1 and T3 can run parallel
|
||||
|
||||
5. Strategy:
|
||||
"Optimal execution strategy:
|
||||
|
||||
Phase 1 (Parallel):
|
||||
- Start T1 (Database) and T3 (Frontend) simultaneously
|
||||
- These have no dependencies
|
||||
|
||||
Phase 2 (Critical):
|
||||
- Start T2 (Backend API) after T1 completes
|
||||
- T2 is critical bottleneck blocking 4 tasks
|
||||
|
||||
Phase 3 (Parallel):
|
||||
- After T2 completes, 4 tasks become available
|
||||
- Launch T4, T5, T6, T7 in parallel
|
||||
|
||||
Expected benefit: 40% faster than sequential execution"
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### 1. Always Query Dependencies with includeTaskInfo
|
||||
|
||||
```
|
||||
✅ Good:
|
||||
query_dependencies(taskId="...", direction="all", includeTaskInfo=true)
|
||||
|
||||
❌ Bad:
|
||||
query_dependencies(taskId="...")
|
||||
```
|
||||
|
||||
**Reason:** You need task status to determine if dependencies are complete
|
||||
|
||||
### 2. Use Direction Parameter Appropriately
|
||||
|
||||
- `direction="incoming"` - Find what blocks this task (for unblocking analysis)
|
||||
- `direction="outgoing"` - Find what this task blocks (for bottleneck analysis)
|
||||
- `direction="all"` - Full picture (for comprehensive analysis)
|
||||
|
||||
### 3. Filter by Status for Relevance
|
||||
|
||||
```
|
||||
✅ For active bottlenecks:
|
||||
query_container(operation="search", containerType="task", status="pending,in-progress")
|
||||
|
||||
❌ Including completed tasks:
|
||||
query_container(operation="search", containerType="task")
|
||||
```
|
||||
|
||||
**Reason:** Completed tasks aren't bottlenecks
|
||||
|
||||
### 4. Consider Task Complexity in Analysis
|
||||
|
||||
- Critical path = sum of complexity values
|
||||
- Bottleneck priority = (tasks_blocked × priority) - complexity
|
||||
- Parallel benefit = sum_complexity - max_complexity
|
||||
|
||||
### 5. Report Actionable Recommendations
|
||||
|
||||
Don't just describe problems:
|
||||
- ❌ "Task X has 5 dependencies"
|
||||
- ✅ "Complete these 2 tasks to unblock Task X: [list]"
|
||||
|
||||
## Response Templates
|
||||
|
||||
### Dependency Analysis Summary
|
||||
```
|
||||
Dependency Analysis for "[Feature Name]":
|
||||
|
||||
Total Tasks: [N]
|
||||
Tasks ready to start: [M] ([list])
|
||||
Tasks blocked: [K] ([list with blocking tasks])
|
||||
|
||||
Bottlenecks:
|
||||
- [Task A] blocks [X] tasks
|
||||
- [Task B] blocks [Y] tasks
|
||||
|
||||
Recommendations:
|
||||
1. Start [ready tasks] in parallel
|
||||
2. Prioritize [bottleneck] completion
|
||||
3. Monitor [blocked tasks] for automatic unblocking
|
||||
```
|
||||
|
||||
### Critical Path Report
|
||||
```
|
||||
Critical Path Analysis:
|
||||
|
||||
Path: [T1] → [T2] → [T3] → [T4]
|
||||
Total complexity: [N] ([X]% of all work)
|
||||
Estimated time: [N] units
|
||||
|
||||
Parallel opportunities:
|
||||
- [Tasks] can run alongside critical path
|
||||
- Expected time savings: [X]%
|
||||
|
||||
Recommendation: Focus resources on critical path tasks
|
||||
```
|
||||
|
||||
### Bottleneck Alert
|
||||
```
|
||||
⚠️ Bottleneck Detected:
|
||||
|
||||
Task: "[Task Name]"
|
||||
Status: [status]
|
||||
Complexity: [N]/10
|
||||
Blocks: [M] tasks
|
||||
|
||||
Blocked tasks:
|
||||
- [Task 1]
|
||||
- [Task 2]
|
||||
...
|
||||
|
||||
Action required: Prioritize completion of "[Task Name]" immediately
|
||||
Impact: Unblocking this will enable [M] tasks to proceed
|
||||
```
|
||||
|
||||
## Integration with Other Skills
|
||||
|
||||
**Works alongside:**
|
||||
- **Dependency Analysis Skill** - Provides foundational blocked task queries
|
||||
- **Task Orchestration Skill** - Uses this analysis for batching decisions
|
||||
- **Feature Orchestration Skill** - Informs feature progress assessment
|
||||
|
||||
**Complements:**
|
||||
- Planning Specialist subagent - Informs initial task breakdown
|
||||
- Task completion workflows - Identifies cascade effects
|
||||
|
||||
## Token Efficiency
|
||||
|
||||
This skill is more token-intensive than others due to recursive querying:
|
||||
|
||||
- Simple dependency check: ~200 tokens
|
||||
- Full feature analysis: ~800-1200 tokens
|
||||
- Critical path analysis: ~400-600 tokens
|
||||
- Bottleneck detection: ~300-500 tokens
|
||||
|
||||
**Optimization tips:**
|
||||
- Use `status` filters to reduce task counts
|
||||
- Query dependencies only for relevant tasks
|
||||
- Cache results during analysis session
|
||||
- Use `includeTaskInfo=true` once, reuse data
|
||||
|
||||
## Success Metrics
|
||||
|
||||
- 100% circular dependency detection
|
||||
- Accurate critical path identification
|
||||
- Bottleneck recommendations reduce completion time by 20-40%
|
||||
- Parallel opportunity discovery achieves 30-50% time savings
|
||||
- Zero false positives in blocking analysis
|
||||
|
||||
## See Also
|
||||
|
||||
- **Dependency Analysis Skill**: Basic dependency checking patterns
|
||||
- **Task Orchestration Skill**: Applying dependency analysis to execution
|
||||
- **examples.md**: Detailed usage scenarios
|
||||
505
skills/dependency-orchestration/examples.md
Normal file
505
skills/dependency-orchestration/examples.md
Normal file
@@ -0,0 +1,505 @@
|
||||
# Dependency Orchestration Skill - Examples
|
||||
|
||||
## Example 1: Complete Dependency Analysis
|
||||
|
||||
**User Request:**
|
||||
> "Analyze dependencies for e-commerce checkout feature"
|
||||
|
||||
**Scenario:**
|
||||
- 8 tasks with complex dependencies
|
||||
- Need to identify critical path and bottlenecks
|
||||
|
||||
**Actions:**
|
||||
1. Build dependency graph
|
||||
2. Find critical path
|
||||
3. Identify bottlenecks
|
||||
4. Discover parallel opportunities
|
||||
|
||||
**Output:**
|
||||
```
|
||||
Dependency Analysis: E-commerce Checkout Feature
|
||||
Total Tasks: 8
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
CRITICAL PATH (determines minimum completion time)
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Path: T1 → T3 → T5 → T8
|
||||
Tasks:
|
||||
1. Create database schema (Complexity: 5)
|
||||
2. Implement payment API (Complexity: 8)
|
||||
3. Add order processing (Complexity: 7)
|
||||
4. Integration tests (Complexity: 6)
|
||||
|
||||
Total Complexity: 26 (72% of all work)
|
||||
Length: 4 tasks
|
||||
|
||||
⚠️ This path determines minimum feature completion time.
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
BOTTLENECKS (blocking multiple tasks)
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
HIGH IMPACT:
|
||||
🚨 T3: Implement payment API
|
||||
Status: pending
|
||||
Blocks: 4 tasks
|
||||
• Integration tests
|
||||
• UI payment form
|
||||
• Order processing
|
||||
• Email notifications
|
||||
|
||||
⚡ PRIORITY: Complete this task ASAP
|
||||
|
||||
MEDIUM IMPACT:
|
||||
⚠️ T1: Create database schema
|
||||
Status: pending
|
||||
Blocks: 2 tasks
|
||||
• Payment API
|
||||
• Order processing
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
PARALLEL OPPORTUNITIES
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Opportunity 1 (Level 0): 45% time saved
|
||||
├─ T1: Database schema (Complexity: 5)
|
||||
├─ T2: UI cart component (Complexity: 6)
|
||||
└─ T4: Email templates (Complexity: 4)
|
||||
Sequential: 15 units → Parallel: 6 units
|
||||
|
||||
Opportunity 2 (Level 2): 33% time saved
|
||||
├─ T6: Unit tests (Complexity: 4)
|
||||
└─ T7: Documentation (Complexity: 5)
|
||||
Sequential: 9 units → Parallel: 5 units
|
||||
|
||||
Total Potential Time Savings: 40%
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
RECOMMENDATIONS
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
1. IMMEDIATE: Complete T1 (Database) and T3 (Payment API)
|
||||
→ Unblocks 6 other tasks
|
||||
|
||||
2. PARALLEL: Launch T1, T2, T4 simultaneously
|
||||
→ Saves 45% time on first batch
|
||||
|
||||
3. MONITOR: T3 is critical path bottleneck
|
||||
→ Assign best resources
|
||||
→ Consider breaking into smaller tasks if possible
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example 2: Critical Path Identification
|
||||
|
||||
**User Request:**
|
||||
> "What's the critical path for this feature?"
|
||||
|
||||
**Scenario:**
|
||||
- Multiple paths through dependency graph
|
||||
- Need to find longest path
|
||||
|
||||
**Dependency Graph:**
|
||||
```
|
||||
T1 (DB) → T2 (API) → T5 (Tests) [Path A: 17 complexity]
|
||||
T1 (DB) → T3 (Processing) → T4 (UI) → T5 (Tests) [Path B: 24 complexity]
|
||||
```
|
||||
|
||||
**Output:**
|
||||
```
|
||||
Critical Path Found
|
||||
|
||||
Path: T1 → T3 → T4 → T5
|
||||
Length: 4 tasks
|
||||
Total Complexity: 24
|
||||
|
||||
Tasks on Critical Path:
|
||||
1. T1: Create database schema (5)
|
||||
2. T3: Order processing logic (8)
|
||||
3. T4: UI integration (7)
|
||||
4. T5: Integration tests (4)
|
||||
|
||||
Why This Matters:
|
||||
- This path represents 67% of total work
|
||||
- Determines minimum feature completion time
|
||||
- Cannot be shortened without changing scope
|
||||
- Should receive highest priority
|
||||
|
||||
Optimization Strategy:
|
||||
✓ Prioritize critical path tasks
|
||||
✓ Assign best resources
|
||||
✓ Parallelize non-critical tasks (T2, T6, T7)
|
||||
✗ Don't delay critical path tasks
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example 3: Bottleneck Resolution
|
||||
|
||||
**User Request:**
|
||||
> "Task T3 is blocking everything. What should I do?"
|
||||
|
||||
**Analysis:**
|
||||
```
|
||||
T3: Implement payment API
|
||||
- Status: in-progress (40% complete)
|
||||
- Blocks: 5 tasks
|
||||
- Critical path: Yes
|
||||
- Complexity: 8 (high)
|
||||
```
|
||||
|
||||
**Output:**
|
||||
```
|
||||
Bottleneck Analysis: T3 (Payment API)
|
||||
|
||||
Impact Assessment:
|
||||
🚨 CRITICAL - Blocks 5 tasks
|
||||
- T5: Integration tests
|
||||
- T6: UI payment form
|
||||
- T7: Order processing
|
||||
- T8: Email notifications
|
||||
- T9: Admin dashboard
|
||||
|
||||
Current Status:
|
||||
- In progress: 40% complete
|
||||
- Est. remaining: 3 hours
|
||||
- On critical path: YES
|
||||
|
||||
Resolution Options:
|
||||
|
||||
Option 1: ACCELERATE (Recommended)
|
||||
- Assign additional developer to help
|
||||
- Break into sub-tasks (Auth, Processing, Webhooks)
|
||||
- Complete in parallel
|
||||
- Estimated gain: 40% faster
|
||||
|
||||
Option 2: REPLUMB DEPENDENCIES
|
||||
- Remove T7 → T3 dependency (may not need API)
|
||||
- Allow T6 (UI) to start with mocked API
|
||||
- Estimated gain: Unblock 2 tasks immediately
|
||||
|
||||
Option 3: SIMPLIFY SCOPE
|
||||
- Implement basic payment flow first
|
||||
- Add advanced features in separate task
|
||||
- Estimated gain: Unblock tasks sooner
|
||||
|
||||
Recommendation: Option 1 - Accelerate completion
|
||||
This task is on critical path and high-impact.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example 4: Parallel Opportunity Discovery
|
||||
|
||||
**User Request:**
|
||||
> "What tasks can run in parallel?"
|
||||
|
||||
**Dependency Graph:**
|
||||
```
|
||||
Level 0: T1, T2, T4 (no dependencies)
|
||||
Level 1: T3, T5 (depend on Level 0)
|
||||
Level 2: T6 (depends on Level 1)
|
||||
```
|
||||
|
||||
**Output:**
|
||||
```
|
||||
Parallel Opportunities Found: 2
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Opportunity 1: Level 0 Tasks
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
3 tasks with NO dependencies:
|
||||
|
||||
T1: Database schema (Complexity: 5)
|
||||
└─ Specialist: Database Engineer
|
||||
|
||||
T2: UI components (Complexity: 6)
|
||||
└─ Specialist: Frontend Developer
|
||||
|
||||
T4: Email service (Complexity: 4)
|
||||
└─ Specialist: Backend Engineer
|
||||
|
||||
Sequential Time: 15 units
|
||||
Parallel Time: 6 units (longest task)
|
||||
Time Saved: 9 units (60% faster)
|
||||
|
||||
Launch Command:
|
||||
"Launch parallel batch: Database Engineer (T1),
|
||||
Frontend Developer (T2), Backend Engineer (T4)"
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Opportunity 2: Level 1 Tasks
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
2 tasks can run parallel AFTER Level 0:
|
||||
|
||||
T3: API endpoints (Complexity: 7)
|
||||
└─ Depends on: T1
|
||||
|
||||
T5: Documentation (Complexity: 5)
|
||||
└─ Depends on: T2
|
||||
|
||||
Sequential Time: 12 units
|
||||
Parallel Time: 7 units
|
||||
Time Saved: 5 units (42% faster)
|
||||
|
||||
Total Feature Time Savings: 50%
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example 5: Circular Dependency Detection
|
||||
|
||||
**User Request:**
|
||||
> "Why can't I create an execution plan?"
|
||||
|
||||
**Analysis:**
|
||||
```
|
||||
T2 depends on T5
|
||||
T5 depends on T7
|
||||
T7 depends on T2
|
||||
```
|
||||
|
||||
**Output:**
|
||||
```
|
||||
✗ CIRCULAR DEPENDENCY DETECTED
|
||||
|
||||
Cycle: T2 → T5 → T7 → T2
|
||||
Length: 3 tasks
|
||||
|
||||
Tasks Involved:
|
||||
- T2: Implement API
|
||||
- T5: Add caching layer
|
||||
- T7: Update API for cache
|
||||
|
||||
Problem:
|
||||
This creates an impossible situation:
|
||||
- T2 needs T5 to be complete
|
||||
- T5 needs T7 to be complete
|
||||
- T7 needs T2 to be complete
|
||||
→ Deadlock! No task can start.
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
RESOLUTION OPTIONS
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Option 1: REMOVE UNNECESSARY DEPENDENCY (Recommended)
|
||||
✓ Remove T7 → T2 dependency
|
||||
Reason: "Update API for cache" doesn't truly need
|
||||
the original API implementation. It's an enhancement.
|
||||
|
||||
New flow: T2 → T5 → T7 (sequential, valid)
|
||||
|
||||
Option 2: SPLIT TASK
|
||||
✓ Split T2 into:
|
||||
- T2a: Basic API implementation
|
||||
- T2b: API with cache support
|
||||
|
||||
New flow: T2a → T5 → T7 → T2b (sequential, valid)
|
||||
|
||||
Option 3: REORDER
|
||||
✓ Complete T2 first (remove all dependencies)
|
||||
✓ Then add T5 and T7 as separate feature
|
||||
|
||||
New flow: T2 (standalone) → New Feature (T5, T7)
|
||||
|
||||
Recommended: Option 1
|
||||
Most likely this is a case of over-specified dependencies.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example 6: Deep Dependency Chain Warning
|
||||
|
||||
**User Request:**
|
||||
> "Check dependencies for migration feature"
|
||||
|
||||
**Analysis:**
|
||||
```
|
||||
T1 → T2 → T3 → T4 → T5 → T6 → T7 → T8
|
||||
(8-level chain)
|
||||
```
|
||||
|
||||
**Output:**
|
||||
```
|
||||
⚠️ WARNING: Deep Dependency Chain
|
||||
|
||||
Chain Depth: 8 tasks (sequential)
|
||||
Max Recommended: 5 tasks
|
||||
|
||||
Chain: T1 → T2 → T3 → T4 → T5 → T6 → T7 → T8
|
||||
|
||||
Impact:
|
||||
✗ Zero parallelism possible
|
||||
✗ 8× longer completion time
|
||||
✗ High risk of delays (any task blocks all subsequent)
|
||||
✗ Difficult to recover from issues
|
||||
|
||||
Recommendations:
|
||||
|
||||
1. BREAK DEPENDENCIES
|
||||
Analyze which dependencies are truly required.
|
||||
Example: Does T6 really need T5? Or just T3?
|
||||
|
||||
2. CREATE PARALLEL STREAMS
|
||||
Group related tasks into independent streams:
|
||||
|
||||
Stream A: T1 → T3 → T5 → T7
|
||||
Stream B: T2 → T4 → T6 → T8
|
||||
|
||||
(If dependencies allow)
|
||||
|
||||
3. SPLIT FEATURE
|
||||
Consider breaking into 2 features:
|
||||
- Feature 1: Core migration (T1-T4)
|
||||
- Feature 2: Advanced migration (T5-T8)
|
||||
|
||||
Benefit: Could reduce completion time by 50%
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example 7: Resolution Strategy Generation
|
||||
|
||||
**User Request:**
|
||||
> "Generate a resolution strategy for this feature"
|
||||
|
||||
**Context:**
|
||||
- 2 critical path bottlenecks
|
||||
- 3 parallel opportunities
|
||||
- 10 total tasks
|
||||
|
||||
**Output:**
|
||||
```
|
||||
Resolution Strategy: Authentication Feature
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
PHASE 1: IMMEDIATE (Do Now)
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Critical Path Bottlenecks:
|
||||
1. T1: Database schema
|
||||
- Status: pending
|
||||
- Blocks: 4 tasks
|
||||
- Action: Assign immediately
|
||||
|
||||
2. T3: Authentication API
|
||||
- Status: pending
|
||||
- Blocks: 5 tasks
|
||||
- Action: High priority after T1
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
PHASE 2: PARALLEL (Run Simultaneously)
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Opportunity 1 (Start now):
|
||||
- T1: Database schema
|
||||
- T2: UI components
|
||||
- T4: Email templates
|
||||
→ 60% time savings
|
||||
|
||||
Opportunity 2 (After T3):
|
||||
- T6: Unit tests
|
||||
- T7: Documentation
|
||||
→ 40% time savings
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
PHASE 3: DEFER (Can Wait)
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Non-Critical Tasks:
|
||||
- T8: Admin dashboard (not on critical path)
|
||||
- T9: Reporting (not on critical path)
|
||||
- T10: Logging enhancement (nice-to-have)
|
||||
|
||||
Action: Complete after critical path finished
|
||||
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
EXECUTION TIMELINE
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
|
||||
Week 1:
|
||||
- Launch Parallel Batch 1 (T1, T2, T4)
|
||||
- Complete T1
|
||||
- Start T3 (depends on T1)
|
||||
|
||||
Week 2:
|
||||
- Complete T3
|
||||
- Launch Parallel Batch 2 (T6, T7)
|
||||
- Start T5 (depends on T3)
|
||||
|
||||
Week 3:
|
||||
- Complete T5, T6, T7
|
||||
- Start deferred tasks (T8, T9, T10)
|
||||
|
||||
Estimated Completion: 3 weeks
|
||||
vs Sequential: 5 weeks
|
||||
Time Saved: 40%
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Integration Examples
|
||||
|
||||
### With Task Orchestration
|
||||
```
|
||||
1. Task Orchestration: Needs to create batches
|
||||
2. Dependency Orchestration: Analyzes dependencies
|
||||
3. Dependency Orchestration: Returns batch structure
|
||||
4. Task Orchestration: Uses structure for execution
|
||||
```
|
||||
|
||||
### With Feature Orchestration
|
||||
```
|
||||
User: "This feature has many blockers"
|
||||
1. Feature Orchestration: Requests analysis
|
||||
2. Dependency Orchestration: Finds bottlenecks
|
||||
3. Feature Orchestration: Prioritizes bottlenecks
|
||||
4. Task Orchestration: Executes in optimal order
|
||||
```
|
||||
|
||||
### Standalone Usage
|
||||
```
|
||||
User: "Analyze dependencies"
|
||||
1. Dependency Orchestration: Complete analysis
|
||||
2. Returns: Critical path + bottlenecks + opportunities
|
||||
3. User makes decisions based on analysis
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Visualization Examples
|
||||
|
||||
### ASCII Graph
|
||||
```
|
||||
Database (T1)
|
||||
├─→ Backend API (T2)
|
||||
│ ├─→ UI Integration (T5)
|
||||
│ │ └─→ E2E Tests (T7)
|
||||
│ └─→ Unit Tests (T6)
|
||||
│
|
||||
UI Components (T3)
|
||||
└─→ UI Integration (T5)
|
||||
└─→ E2E Tests (T7)
|
||||
|
||||
Documentation (T4)
|
||||
(no dependencies, can run parallel)
|
||||
```
|
||||
|
||||
### Dependency Matrix
|
||||
```
|
||||
T1 T2 T3 T4 T5 T6 T7
|
||||
T1 - ✓ - - - - -
|
||||
T2 - - - - ✓ ✓ -
|
||||
T3 - - - - ✓ - -
|
||||
T4 - - - - - - -
|
||||
T5 - - - - - - ✓
|
||||
T6 - - - - - - -
|
||||
T7 - - - - - - -
|
||||
|
||||
✓ = has dependency
|
||||
- = no dependency
|
||||
```
|
||||
Reference in New Issue
Block a user