Core concepts
Get reliable results.
Seven habits that make Flash’s work more accurate and easier to check.
1. Give Flash the right context
Run /init, confirm the board and select the exact parts fitted. Keep FLASH.md short: only the rules Flash cannot work out from the code.
2. Ask for something concrete and checkable
Name the files or component, the expected behaviour and how you will know it is done. A check Flash can run itself is the most reliable finish line.
Fix the sensor timeout in @src/sensor.c using the part's timing requirements. Done means: the board prints "imu ready" within 2 s of reset and no watchdog reset appears in 30 s of output.3. Plan broad changes first
Use Plan to explore and agree an approach, then Normal to implement it. Skip planning for small, clear fixes. Use Debug when you need evidence from the board. See Agent modes.
4. Protect what you are debugging
A reset or reflash can erase the fault you want to see. Say so in the request, for example “attach without resetting” or “do not reflash”. Build with debug symbols when you plan to inspect variables.
5. Keep conversations focused
One task per conversation. Use /clear between unrelated tasks and /compact for long ones. If Flash drifts, press Esc and correct it.
6. Read what Flash asks to do
Check the command, file or device before approving, and choose the narrowest answer. See Tool approvals.
7. Save configuration on purpose
/config set changes a value for this session only; /config save keeps it for the project. Check where a value comes from before saving it.
/config explain/config saveExample requests
The same habits applied to three common tasks. Adapt the part, board and numbers to your project.
Inspect the existing test setup. Add a focused test for the sensor timeout path using the project's conventions, and say which parts still need the board.Plan the move from the ESP32 to the ESP32-S3. List only what differs: pins, peripherals, SDK APIs and build settings. Do not change any files yet.Measure the sensor loop latency over 1,000 reads and report the baseline. Propose one change, then repeat the same measurement and compare.