This skill should be used when "breaking down tasks", "creating task table", "parallel tracks", "shippable increments", or planning implementation work in a design. Covers deployment coupling, parallel track identification, task consolidation, and the task table format. Do not use for ticket creation (see /forge:start-task).
From forgenpx claudepluginhub flox/forge-plugin --plugin forgeThis skill uses the workspace's default tool permissions.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Details PluginEval's skill quality evaluation: 3 layers (static, LLM judge), 10 dimensions, rubrics, formulas, anti-patterns, badges. Use to interpret scores, improve triggering, calibrate thresholds.
Standard approach for breaking work into independently reviewable, shippable, and parallelizable tasks.
For each affected component, determine:
| Factor | Question |
|---|---|
| Release cadence | How often does this ship? |
| Integration points | What boundaries are crossed? |
| Shared state | API contracts, shared types? |
Shipping order based on coupling:
Analyze work to find parallelizable streams:
| Dependency Type | Parallelization |
|---|---|
| Different components, no shared contracts | Fully parallel |
| Same component, independent modules | Parallel with coordination |
| Shared API contract | Producer first, then consumer |
| Shared data | Sequential (ordering matters) |
Output format:
- Track A: Backend service implementation
- Track B: CLI/UI consumer (behind flag)
- Track C: Test infrastructure
- Sync point: Integration tests validate all tracks
Each task should be:
| Criterion | Meaning |
|---|---|
| Independently mergeable | Doesn't break main |
| Small PRs | Target 200-400 lines for easier review |
| Complete | Has tests, passes CI |
| Flagged if needed | Incomplete user-facing work behind flag |
| Testable | Can be meaningfully verified on its own |
Prefer S/M tasks; break L tasks into smaller pieces.
Consolidate S-sized tasks within the same component.
Multiple trivial tasks (S-sized, ~20 lines each) to the same component should be grouped into a single ticket/PR. The overhead of reviewing and managing multiple tiny PRs exceeds the benefit of granular separation.
| Scenario | Approach |
|---|---|
| 3 S-sized tasks, same component | Consolidate into 1 ticket |
| 2 S-sized + 1 M-sized, same component | Consider consolidating |
| S-sized tasks, different components | Keep separate |
| M or L-sized tasks | Keep separate for focused review |
Example anti-pattern:
T1: Update landing page banner (S)
T2: Remove sign-up button (S)
T3: Update install instructions (S)
Three separate tickets for trivially small changes to the same component creates unnecessary overhead.
Better approach:
T1: Update pages for open access (M)
- Update landing page banner
- Remove sign-up button
- Update install instructions
One focused ticket covering all related changes.
When to keep tasks separate despite small size:
Don't break tasks into pieces that can't be independently tested.
The test for "should I split this?" is: can each piece be meaningfully verified on its own?
If splitting creates work that can only be tested by completing the next task, keep them together.
Example anti-pattern (UI):
Problem: A dialog component that isn't shown anywhere is untestable. The real test is visual verification in the browser — you can't see it unless it's integrated.
Better approach:
Exceptions to keeping tasks together:
| Task | Type | Component | Size | Track | Depends On | Ticket |
|------|------|-----------|------|-------|------------|--------|
| ... | Prep/Feature | ... | S/M/L | A/B/C | ... | TBD |
| Type | Purpose |
|---|---|
| Prep | Preparatory work (refactor, cleanup) — do first |
| Feature | Core feature implementation |
| Size | Approximate |
|---|---|
| S | ~20-50 lines |
| M | ~100-300 lines |
| L | ~400+ lines (consider splitting) |
Watch for these warning signs:
| Threshold | Warning |
|---|---|
| > 10 tasks | Consider splitting into multiple slices |
| > 3 L-sized tasks | High complexity warning |
| > 4 affected components | Cross-cutting complexity |
If thresholds exceeded, consider whether scope should be reduced.