augmented-lean-delivery

Reviews technical proposals and architectural decisions against 30 complexity dimensions. Use when user proposes technical solutions, designs systems, or evaluates architectural choices. Questions necessity of scale, consistency, resilience, and other complexity drivers. Pushes for simplest viable approach. Use when: - User proposes specific technologies (Kafka, microservices, event sourcing, etc.) - Designing new systems or features - Evaluating architectural trade-offs - Someone says "we need" followed by complex infrastructure Do NOT use when: - Simple feature implementation (use hamburger-method or story-splitting instead) - Work is already planned and simple - User asks "how to" implement something specific (use micro-steps-coach instead)

Applies the Hamburger Method to slice features into vertical deliverable pieces. Use when user asks how to slice work, break down features into layers, or wants to deliver incrementally. Helps generate 4-5 options per layer and compose minimal vertical slices. Use when: - Feature feels large but not obviously splittable with story-splitting heuristics - User asks "how to slice" or "how to deliver incrementally" - Need to generate multiple implementation options - Want to compose end-to-end vertical slices Do NOT use when: - Story has obvious "and", "or", "manage" indicators (use story-splitting instead) - User is asking HOW to implement (use micro-steps-coach instead) - Feature is already small (< 1 day work)

Breaks down ANY work into 1-3 hour micro-steps with zero downtime. Use for large refactorings, technical improvements, debugging, research, migrations, or any work that feels too big or risky. Automatically applies expand-contract pattern for risky changes. Forces smallest safe increments for all work types. Use when: - Work feels too big or risky (refactoring, migrations, performance fixes) - Database schema changes, API changes, service replacements - User asks "how do I implement" after deciding what to build - Work will take more than 1 day Do NOT use when: - User is still deciding WHAT to build (use story-splitting or hamburger-method first) - Work is already small (< 3 hours) - User asks for architectural review (use complexity-review instead)

Expert at detecting stories that are too big and applying splitting heuristics. Use when user describes work that seems large, mentions multiple features in one story, or needs help breaking down requirements. Detects linguistic red flags (and, or, manage, handle) and suggests concrete splitting strategies. Use when: - Story has obvious red flags: "and", "or", "manage", "handle", "including" - User describes multiple features bundled together - Story feels vague or too large - User asks "how to split this story" Do NOT use when: - Story is already small and focused (< 1 day work) - Feature needs layered analysis without obvious split points (use hamburger-method instead) - User asks HOW to implement (use micro-steps-coach instead)