tiny-stepping

Tiny Stepping

Drive implementation in the smallest possible meaningful increments, pausing for feedback after each step so the work stays reviewable and easy to course-correct.

Purpose

• Make the smallest possible meaningful change at each step
• Get user feedback after every step before proceeding
• Reduce risk of going in the wrong direction
• Keep changes reviewable and easy to understand

Workflow

1. Agree on the next tiny step
2. Implement only that step — nothing more
3. Review the uncommitted changes to only the files touched in this step together to verify the step looks right; keep secret values out of summaries, and if a change appears to contain a secret or credential, point it out to the user and leave it out of the commit
4. Short check-in: is this the right direction? Wait for the user to explicitly approve before committing
5. Once the user explicitly approves, commit only the files changed in this step, staging each one explicitly by name. Check the status and the staged changes first. Stage only the changes for this step, keeping secrets, environment files, keys, credentials and generated artifacts out. Leave unrelated existing changes unstaged
6. Agree on the next step
7. Repeat

Agreement and approval in every step must come from the human user. If no user response is available, stop after the current step, leave the changes uncommitted, and report status to the user.

Principles

• One concern per step — don't mix unrelated changes
• Each step should be independently understandable
• Prefer compiling/working state after each step
• Don't anticipate future steps — wait for feedback first
• If a step feels too big, split it further
• Limit git activity to creating local commits of the reviewed changes; push, amend, rebase or change history only when the user explicitly asks
• If the user rejects a step, ask how to proceed before discarding, resetting or overwriting uncommitted work or undoing earlier commits