# Just enough context to move

Turn a vague bug report into a small check you can run. Fix the behavior you can demonstrate before expanding the task.

Use in: Claude Code or Codex · one reproducible bug

Reviewed: 2026-10-27

## 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.

## Prompt to copy

Help me diagnose one reproducible bug before changing code.

Observed: [what happens]. Expected: [what should happen]. Reproduction: [smallest steps or mocked input]. Relevant project or files: [paths, if known]. Keep unchanged: [constraints].

Read the relevant project instructions and inspect the smallest useful set of files. Give me a five-line brief: objective, observed evidence, actual relevant paths, unknowns, and the smallest check that can reproduce this failure. Mark paths and causes UNVERIFIED until inspected; do not invent a test command.

For the check, list setup, action and observable pass condition. Include the reported failure and one retry or boundary case. Separate a mock result from a real account result. If you cannot run it, mark it NOT RUN and name what is missing.

Do not edit during this diagnostic step. Stop with the proposed scope and check. Once I authorize a fix, change only what the evidence supports, rerun the relevant check, and report the actual command/output or manual observation. Passing one test does not prove the whole product works. Do not publish or change credentials or permissions.

Before a long follow-up, check remaining plan capacity and reset time in INMC or the provider. An unavailable reading is unknown; tokens, plan capacity and API cost are different.

## A practical example

Illustrative scenario, not a measured case study.

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.

An INMC workflow for a specific bug, not a new trend or a fixed saving. Use a brief when the symptom or scope is unclear; routine clear tasks do not need a planning ritual. A prompt alone does not enforce permissions.

## Official reference

[Claude Code · Best practices](https://code.claude.com/docs/en/best-practices)

[OpenAI · Codex prompting](https://learn.chatgpt.com/docs/prompting)

[Back to the library](https://ineedmycredits.com/ideas)

Canonical HTML: https://ineedmycredits.com/ideas/context-before-code