Shaping

This is a structured methodology for working through problem and solution design with a user before writing code. It gives you a specific notation system (R for requirements, A/B/C for competing solution shapes, C1/C2 for parts within a shape) and enforces fit checks as decision matrices to compare options. The most interesting bit is the multi-level consistency rule: changes at any abstraction level must ripple up and down through your shaping doc, slices doc, and implementation plans. It's opinionated about chunking (never more than 9 top-level requirements) and phase transitions (you can't slice until you've breadboarded). Use this when you need disciplined exploration of a problem space rather than jumping straight to implementation.