implementation-sequencer

Implementation Sequencer Skill

Determine the optimal implementation order for a set of issues/features based on dependency analysis, risk assessment, and feature flag requirements.

Design Philosophy

"Feature Flags are not the last step—they are the first."

Anti-Pattern	Problem
Feature Flag setup last	In-progress UI exposed to production users
Misunderstanding dependency direction	"A→B" may actually be "B→A"
Deferring high-risk items	Delayed feedback, increased rework

When to Use

• After story points are determined
• After requirements are defined
• Before sprint planning or backlog refinement
• When multiple issues need sequencing

Input Requirements

1. Issue list with issue ID/name, estimated points, initial risk assessment
2. Feature context: Is A/B testing required? Are there existing feature flags?

Sequencing Process

Step 1: Dependency Graph Construction

Identify ALL dependencies between issues:

Dependency Types:
  1. Feature Flag: Feature → A/B Config
  2. UI Hierarchy: Child screen → Parent screen
  3. Data: Display → Data source
  4. Prerequisite: Feature B → Feature A completion

Critical Question: "What is needed to hide this feature in production?" If the answer is "Feature Flag", then Feature Flag is a dependency for ALL features.

Output Format

## Step 1: Dependency Graph

### Feature Flag Dependencies
| Issue | Requires Feature Flag | Flag Name |
|-------|----------------------|-----------|

### Inter-Issue Dependencies
[Issue A] ──depends on──► [Issue B]

### Dependency Matrix
|   | A1 | A2 | A3 |
|---|----|----|-----|
| A1 | -  |    | ✓  |
✓ = depends on (row depends on column)

Step 2: Feature Flag Positioning

Rule: If A/B testing is required, Feature Flag setup comes FIRST.

Scenario	Feature Flag Position
A/B test required	1st (before all features)
No A/B test	Not needed or optional

Why: Add with default false → invisible to production users. During dev, only developers override to enable. After completion, gradually increase % for rollout.

Step 3: Risk-Based Ordering

Within dependency constraints, prioritize by risk:

Priority	Criteria	Rationale
1	Highest Risk + Critical Path	Early feedback, minimize rework
2	Medium Risk	Start when dependencies complete
3	Low Risk	Can parallelize

Risk Factors: Technical uncertainty, specification ambiguity, integration complexity, performance concerns

Step 4: Critical Path Identification

Identify the longest dependency chain:

Critical Path = Feature Flag → Highest Risk → ... → Final Integration

Issues NOT on critical path can be parallelized.

Step 5: Final Sequence

Output Format

## Step 5: Final Implementation Sequence

| Order | Issue | Rationale | Parallel? |
|-------|-------|-----------|-----------|
| 1 | A5 A/B Config | Prerequisite for all (default:false) | No |
| 2 | A3 Core Feature | Highest risk + on CP | No |
| 3 | A1 UI Feature | Low risk | Yes (with A2) |

### Visualization
Week 1          Week 2
──────────────────────
[A5]──►[A3]────►[A4]
        │
        └──[A1]
        └──[A2]

### Implementation Checkpoints
- [ ] After A5: Verify flags work in dev environment
- [ ] After high-risk: Demo to stakeholders

Common Anti-Patterns

Anti-Pattern	Problem	Solution
Feature Flag last	In-progress UI exposed to production	Feature Flag First
Low risk first	High-risk rework hits late in cycle	Risk-first ordering
Missing dependencies	Rework, blocking	Create dependency matrix
All sequential	Inefficient	Identify parallelizable issues

Related Skills

• pre-task-diagnostic — Individual issue analysis
• flow-parallel — Parallel implementation execution

Gotchas

See gotchas.md in this directory for known pitfalls and recurring mistakes when using this skill.