From harness-engineering
Determine optimal implementation order based on dependencies, risks, and feature flags. Use when planning sprint execution order, sequencing tasks with dependencies, or deciding what to build first. Do NOT use for estimating complexity (use estimation-poker or similar).
npx claudepluginhub toru-oizumi/claude-harness-engineering --plugin harness-engineeringThis skill uses the workspace's default tool permissions.
Determine the optimal implementation order for a set of issues/features based on dependency analysis, risk assessment, and feature flag requirements.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Determine the optimal implementation order for a set of issues/features based on dependency analysis, risk assessment, and feature flag requirements.
"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 |
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.
## 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)
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.
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
Identify the longest dependency chain:
Critical Path = Feature Flag → Highest Risk → ... → Final Integration
Issues NOT on critical path can be parallelized.
## 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
| 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 |
pre-task-diagnostic — Individual issue analysisflow-parallel — Parallel implementation executionSee gotchas.md in this directory for known pitfalls and recurring mistakes when using this skill.