| name | team-planning-guard |
| description | Use when reviewing task breakdowns, checking dependency ordering, optimizing task granularity, or deciding whether to proceed to implementation. |
Team Planning Guard
Core Principle
Task breakdown must be granular enough and dependency-ordered so each task can be independently verified.
When to Use
Use this skill when:
- Executing
/team-plan task review
- Checking task breakdown quality
- Checking dependency relationships
- Deciding whether tasks are ready for implementation
Do NOT use this skill when:
- Creating proposals (use
team-openspec-guard)
- Implementing code (use
team-implementation-guard)
Non-Negotiable Rules
- Do NOT proceed with tasks too large to verify — each task must be ≤ 1 hour
- Do NOT proceed with tasks lacking verification methods
- Do NOT proceed with unresolved dependencies (circular or missing)
- Do NOT proceed with unclosed blocking open questions
Task Quality Checklist
Granularity
Linkage
Dependencies
Verification
Execution Mode Recommendation
After analyzing the dependency graph, recommend an execution mode:
| Condition | Mode | Why |
|---|
| Total tasks ≤ 3 | Inline | Small scope, one context is enough |
| Tasks > 3, all sequential dependencies | Subagent | Isolate context per task, main agent coordinates |
| Tasks > 3, has independent tasks (no mutual dependencies) | Parallel | Independent tasks can run concurrently |
Parallel safety check — only recommend Parallel when:
- Independent tasks do NOT modify the same files
- Each independent task's verification does NOT depend on other tasks' output
Write the recommendation into the plan review output. /team-apply will read and follow it.
Dependency Matrix Format
| Task | Depends On | Depended By |
|------|------------|-------------|
| 1.1 Create data model | None | 1.2, 2.1 |
| 1.2 Implement DAO layer | 1.1 | 2.1, 2.2 |
| 2.1 Implement API layer | 1.1, 1.2 | 3.1 |
| 2.2 Implement business logic | 1.2 | 3.1 |
| 3.1 Integration tests | 2.1, 2.2 | None |
Check algorithm:
- For each task, list its dependencies
- For each task, list who depends on it
- Check no circular dependencies (trace dependency chain)
- Check no orphan tasks (neither depends nor is depended on)
ASCII dependency graph:
1.1 ──► 1.2 ──► 2.1 ──► 3.1
│
└─► 2.2 ──► 3.1
Task Template
- [ ] X.Y <Task title>
- Requirement: <requirement name or ID>
- Verification: `<command or manual scenario>`
- Estimate: <minutes>
- Depends on: <preceding task, if any>
Example:
## 1. Data Layer
- [ ] 1.1 Create User model with email verification fields
- Requirement: user-registration
- Verification: `pytest tests/models/test_user.py -v`
- Estimate: 30 min
- [ ] 1.2 Create password reset token model
- Requirement: password-reset
- Verification: `pytest tests/models/test_reset_token.py -v`
- Estimate: 25 min
- Depends on: 1.1
## 2. API Layer
- [ ] 2.1 Implement registration endpoint
- Requirement: user-registration
- Verification: `pytest tests/api/test_register.py -v`
- Estimate: 45 min
- Depends on: 1.1
- [ ] 2.2 Implement password reset flow
- Requirement: password-reset
- Verification: `pytest tests/api/test_password_reset.py -v`
- Estimate: 60 min
- Depends on: 1.2
## 3. Integration
- [ ] 3.1 End-to-end registration test
- Requirement: user-registration
- Verification: `pytest tests/e2e/test_registration_flow.py -v`
- Estimate: 30 min
- Depends on: 2.1
Risk Signals
STOP and ask before continuing when:
- Multiple tasks have circular dependencies
- Critical dependency missing (e.g., API contract not decided)
- Task breakdown too coarse (single task > 1 hour)
- Acceptance criteria can't map to specific tasks
- Deferred tasks > 30% with no clear follow-up plan
Common Mistakes
| Mistake | Fix |
|---|
| Task "Implement authentication" | Split into model, API, tests subtasks |
| Verification "works correctly" | Write specific command like pytest tests/auth/ |
| Dependencies not marked | Add "Depends on: Task X" in description |
| Basic tasks skipped | Ensure models, config, dependencies come first |
Bad Cases
When this skill fails, record in badCases/ directory:
- Input: what the user said
- Wrong output: what the AI did that it shouldn't have
- Expected output: what it should have done
- New rule needed: how to prevent recurrence
See badCases/ for case history.