decompose-gates

Decompose complex tasks into independently verifiable pieces with explicit pass/fail gates.

1.6k|141|Updated Dec 16, 2025
One-click install
npx skills add https://github.com/happier-dev/happier --skill decompose-gates
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: decompose-gates
Source: https://github.com/happier-dev/happier/tree/main/skills/decompose-gates
Command: npx skills add https://github.com/happier-dev/happier --skill decompose-gates

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Large or multi-part engineering tasks often fail as monolithic changes where something works but you cannot say which part, and something fails but you cannot say where. This Skill turns hard tasks into pieces that each pass or fail on their own, ordered so the riskiest assumption is tested first.

Core Features & Use Cases

  • Verification-boundary splitting: Breaks work along independent pass/fail checks rather than implementation convenience, with each piece stated as a falsifiable claim plus its deciding test.
  • Risk-weighted ordering: Names the highest-risk spots (silent failures, irreversible steps) and sequences work by information yield so shared assumptions are validated first.
  • Lane briefs for subagents: Produces self-contained restart briefs with gates, dependency contracts, exact paths, success criteria, and stop conditions for delegating work to subagents or Codex.
  • Use Case: When planning a corridor-sized refactor or writing lane briefs for parallel agents, use this Skill to produce a plan where every piece has a concrete check and integration risks are surfaced at the interfaces.

Quick Start

Ask the agent to decompose your large task into independently checkable pieces with explicit verification gates and risk-weighted ordering.

Frequently Asked Questions about decompose-gates

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I break a large coding task into verifiable pieces?

Split along verification boundaries rather than implementation convenience: each piece must have its own pass/fail check that does not depend on other pieces being correct. State each piece as a falsifiable claim with a concrete deciding test, such as a test slice, log observation, or measurement.

How to write lane briefs for subagents or Codex?

Each lane brief should be a sufficient restart brief on its own, carrying its gate (falsifiable claim plus check), exact paths and symbols, observed evidence, in-scope and out-of-scope surfaces, success criteria, required validation, and stop/fallback conditions. A fresh agent must be able to continue from the brief and on-disk report alone.

When should I order task pieces by risk instead of dependency?

Order by information yield: test first the smallest shared assumption whose failure would invalidate repeated downstream units. Skip the ramp when prior evidence or a deterministic tool already proves the unit shape, and keep independent work moving in parallel.

What are the limitations of fine-grained task decomposition?

Pieces that are too small to fail meaningfully create overhead; micro-slicing such as one-boolean extractions can grow the god-files it was meant to shrink. Each piece should own a whole responsibility end to end, including analysis, change, tests, and validation.

How does this handle compatibility-sensitive migrations?

For compatibility work, decompose the transition into independently falsifiable prepare/read, activate/write, migrate/backfill, mixed-version or rollback, and contract/removal claims only where those phases are reachable. Each claim names its exact released baseline and old/new producer-consumer direction.