| name | ito-fix |
| description | Start a fix-oriented Ito change proposal with fix-biased intake and schema recommendations. |
Use this when the user frames the work as a fix, regression, correction, or supporting platform/tooling/infrastructure change that should be handled like a fix.
If the user already provided a change ID, skip to Step 5 (Continue with ito-proposal) — the change already exists.
Goal
Drive proposal creation through a fix-oriented intake lane without locking the user into a specific schema.
Steps
- Start with
ito-proposal-intake.
- Bias the intake toward fix questions:
- What is broken?
- What is the expected behavior?
- Is there a reproduction or regression signal?
- How bounded is the blast radius?
- Recommend a schema:
minimalist for bounded fixes and small supporting platform or infrastructure changes
tdd for regression-oriented changes where test-first work is safest
spec-driven if the fix turns out to be broad, architectural, or still ambiguous
event-driven if the change is centered on event or message workflow behavior
- If intake concludes no proposal is needed, say so and stop.
- If the work is ready for a proposal, continue with
ito-proposal using the intake summary as the shared understanding.
- If the request turns into a new capability or open-ended design discussion, switch to
ito-feature or ito-brainstorming.
Important
ito-fix is an opinionated front door, not a separate schema.
- The user may still override the recommended schema or continue through the neutral
ito-proposal lane.