delivery-methodologylisted

# delivery-methodology — ship bounded work without preserving two systems Read the repo's `AGENTS.md` (else `CLAUDE.md`) and any linked delivery/testing guide first. Repo rules may be stricter. This skill supplies the generic method when a repo has no equivalent. ## Startup operating principle Optimize for the smallest simple change that gives real users value and yields useful product evidence. Treat complexity as a cost: abstraction, compatibility machinery, enterprise hardening, and exhaustive hypothetical edge-case support need a present requirement or credible failure path. Preserve hard correctness, security/privacy, data-loss, migration, and protocol invariants. Otherwise ship a reversible useful boundary, validate the real user journey, and expand from evidence rather than imagination. ## Choose the topology Use a **direct task branch** for a complete change that can safely ship in one bounded PR. It starts from the target base and the PR targets that base. Use a **controlled lift branch** for foundational work whose partial state is unshippable or whose clean implementation replaces a system across coordinated slices. Record the choice and why before implementation. Feature flags are a rollout tool, not the default slicing strategy. Use one only around a clean, bounded activation seam. Prefer a lift when a flag would require broad branching, dual writes, duplicated state, compatibility shims, or two authoritative systems. ## Controlled lift - One Project Roo