Planning Skills

work-triage, work-tracker, and writing-plans for structured execution

Fulcrum Opinion: Good planning is the difference between 2-hour tasks and 2-day tasks. The teams that ship fastest are the ones that spend time upfront defining done.

work-triage

The work-triage skill analyzes incoming requests to determine priority, route to appropriate agents, and create work items. It uses an urgency-impact matrix for P0-P3 prioritization and a decision tree for agent routing.

Priority Levels

Priority	Urgency	Impact	Example
P0	Critical	High	Production outage, security breach
P1	High	High	Major feature broken, data integrity issue
P2	Medium	Medium	New feature, enhancement, tech debt
P3	Low	Low	Nice-to-have, cosmetic, optimization

Agent Routing Decision Tree

Request Analysis
       │
       ├─► Security concern? ──────► @backend-engineer + @devops-engineer
       │
       ├─► UI/UX issue? ───────────► @frontend-engineer
       │
       ├─► Data model change? ─────► @database-engineer + @backend-engineer
       │
       ├─► Infrastructure? ────────► @devops-engineer
       │
       ├─► AI/ML feature? ─────────► @ai-engineer
       │
       ├─► Cross-cutting? ─────────► @tech-lead (coordination)
       │
       └─► Unclear scope? ─────────► @pm (requirements clarification)

Invocation

# Triage a new request
/work-triage "Users report slow page loads on the dashboard"

# Output includes:
# - Priority assignment (P0-P3)
# - Recommended agents
# - Initial scope assessment
# - Suggested next steps

work-tracker

The work-tracker skill provides Beads-powered work item management. It's the internal engine used by the Work Orchestrator for tracking progress, managing dependencies, and ensuring nothing falls through the cracks.

Work Item Lifecycle

┌──────────┐    ┌────────────┐    ┌─────────────┐    ┌──────────┐
│  QUEUED  │───►│ IN_PROGRESS│───►│ IN_REVIEW   │───►│  DONE    │
└──────────┘    └────────────┘    └─────────────┘    └──────────┘
     │               │                  │                  │
     │               │                  │                  │
     ▼               ▼                  ▼                  ▼
  blocked?       needs help?       changes req?       archived
     │               │                  │
     ▼               ▼                  ▼
 ┌──────────┐  ┌────────────┐    ┌─────────────┐
 │ BLOCKED  │  │   PAUSED   │    │ IN_PROGRESS │
 └──────────┘  └────────────┘    └─────────────┘

Key Capabilities

Git-synced persistence — Work items survive across sessions
Dependency tracking — Know what's blocking what
Progress visibility — Real-time status across all agents
History preservation — Full audit trail of decisions

Usage

# Create a work item
/work-tracker create "Implement OAuth flow" --priority P2 --assignee @backend-engineer

# Update status
/work-tracker update BEAD-42 --status in_review

# Check dependencies
/work-tracker deps BEAD-42

# View all active work
/work-tracker list --status active

Note: work-tracker is primarily used internally by the Work Orchestrator. You'll rarely invoke it directly—instead, it's called automatically when agents coordinate work.

writing-plans

The writing-plans skill creates detailed implementation plans before any code is touched. It transforms requirements into actionable, step-by-step execution guides with clear acceptance criteria.

Mandatory: Use writing-plans when you have a spec or requirements for a multi-step task, before touching code. Plans prevent scope creep, ensure nothing is forgotten, and enable parallel execution.

Plan Structure

# Implementation Plan: [Feature Name]

## Overview
Brief description and success criteria

## Prerequisites
- [ ] Dependencies resolved
- [ ] Environment configured
- [ ] Access permissions verified

## Implementation Steps

### Phase 1: Foundation
- [ ] Step 1.1: Create base structure
- [ ] Step 1.2: Set up interfaces
  - Acceptance: Tests pass, types compile

### Phase 2: Core Logic
- [ ] Step 2.1: Implement business logic
- [ ] Step 2.2: Add error handling
  - Acceptance: Edge cases covered

### Phase 3: Integration
- [ ] Step 3.1: Connect to existing systems
- [ ] Step 3.2: Update API contracts
  - Acceptance: Integration tests pass

## Verification Checklist
- [ ] All tests pass
- [ ] Documentation updated
- [ ] No regressions introduced

## Rollback Plan
Steps to revert if issues arise

Invocation

# Create a plan from requirements
/writing-plans "Implement multi-tenant data isolation"

# Create a plan from a GitHub issue
/writing-plans --from-issue #142

# Create a plan with specific scope
/writing-plans "Add caching layer" --scope "Redis integration only"

Plan-Driven Development Workflow

1. Requirements      ──► /brainstorming (clarify intent)
         │
2. Planning          ──► /writing-plans (create execution plan)
         │
3. Review            ──► Share plan with team/stakeholders
         │
4. Execution         ──► /executing-plans (follow plan step-by-step)
         │
5. Verification      ──► /verification-before-completion
         │
6. Completion        ──► PR or merge

Planning Best Practices

The 10-Minute Rule

If a task will take more than 10 minutes to implement, it deserves a plan. The time invested in planning is almost always less than the time lost to mid-implementation pivots and forgotten requirements.

Parallel Execution Opportunities

Good plans identify which steps can run in parallel. Look for:

Independent components with no shared state
Backend and frontend work that can proceed simultaneously
Test writing that can happen alongside implementation

# Parallel-aware plan structure
Phase 2 (parallel):
  ├── Task A: Backend API ──► @backend-engineer
  ├── Task B: Frontend UI ──► @frontend-engineer
  └── Task C: DB schema   ──► @database-engineer

Phase 3 (sequential, after Phase 2):
  └── Task D: Integration ──► @tech-lead

Pro tip: When creating plans, explicitly mark dependencies. "Task B depends on Task A" is clearer than assuming the order is obvious. This enables the Work Orchestrator to parallelize safely.