Just enough context to move

Before you start

• A working Codex or Claude Code session with access to your own project. Account, model and tool availability depend on the provider; INMC does not supply credits or access.
• One observed symptom, the expected result and a safe reproduction. Prefer mocked failures and test accounts; remove credentials and private customer data.
• The existing project instructions and test runner, if any. A natural-language prompt guides the model; keep the provider’s actual permission controls in place.

How to use it

1. Replace the placeholders in the prompt with one bug. If the task is already clear and trivial, proceed with an appropriate check instead of adding a mandatory planning step.
2. Ask for the five-line brief. Confirm the named paths were actually inspected and the proposed cause is supported or explicitly unverified.
3. Review the proposed check: setup, action and pass condition. First establish the reported failure in a safe test or mark it NOT RUN; do not confuse a proposed check with a result.
4. Authorize the narrow fix when the scope is clear. Run the relevant check again and inspect the actual output, including one retry or boundary case. Keep unrelated refactors out.
5. Save the result and unresolved cases. If capacity is low, stop at a useful checkpoint and continue later. This workflow promises neither a fixed usage reduction nor a number of prompts remaining.

ILLUSTRATIVE EXAMPLE

Make it concrete.

Authored example, not a live model run: in a demo project, a sign-in button keeps spinning when a mocked request rejects. It should show an error and enable retry. Supply this symptom plus the project path. The brief should locate the real loading-state handler and its existing test, or mark them UNVERIFIED. Proposed check: reject the mock once, submit, observe an error and an enabled button; submit again and confirm the handler accepts a retry. Do not use real passwords or infer that a mock proves production authentication.

Expected output

• A five-line brief naming the objective, observed evidence, inspected paths, unknowns and one proposed check. A possible cause such as a missing loading-state reset remains UNVERIFIED until the code supports it.
• For the demo: setup = reject a mock request once; action = submit, then retry; pass = error is visible, loading ends and retry is accepted. These are expected conditions, not claimed results.
• A result record with status PASS, FAIL or NOT RUN, actual command or manual steps, observed output and remaining limits. Example before access: “NOT RUN; test runner and actual file paths still need inspection.”

Check the result

• Actual inspected paths replace guesses, and no unsupported root cause is stated as fact.
• The failure is reproducible or clearly NOT RUN. A test command comes from the project, not an invented package script.
• After an authorized fix, both the rejection and retry behavior are checked; a mock is labeled and live account behavior remains unverified unless separately tested.
• No unrelated files, production deployment, credentials or permissions change as part of the brief.

If the result is off

• The agent proposes a whole rewrite: restate the one symptom and ask for the smallest affected path and acceptance check.
• There is no test runner: request a safe manual check with setup/action/pass conditions. Mark it NOT RUN until someone performs it; do not install a new framework automatically.
• The first reproduction does not fail: preserve the observation, check the fixture/environment and ask for one missing detail. Do not claim a fix or force a failing result.
• The mock passes but the real sign-in still fails: treat production as a separate unverified path. Inspect the actual error with approved access; never paste passwords or session tokens.
• The model ignores a boundary: use the tool’s permission controls and stop the task. Prompt wording is not a sandbox.