How to use AI to investigate a bug

Replace bracketed values before sending the prompt. Give the assistant the relevant public files from the exact target release; use synthetic examples and keep credentials, private campaigns and proprietary material out of its context.

What you will build

Investigate one observable failure, such as a token moving back after a rejected edit. Distinguish a server conflict, a permission denial and a rendering problem rather than treating them as the same symptom.

Context to give the assistant

• Installed host/package versions, browser/OS and a minimal reproduction with synthetic data.

• Expected versus observed behavior and redacted error.code, network status and timestamps.

• docs/en/code-map.md, architecture.md and the owning domain’s service and tests.

Step by step

1. Reproduce in an isolated installation and record the smallest sequence that fails.

2. Ask for hypotheses and evidence to distinguish them before requesting a patch.

3. Trace the entry point through transport, service validation, persistence and presentation.

4. Change the owning layer and verify the original case plus the relevant permission/conflict boundary.

Copy and adapt this prompt

Repository: [local checkout or public repository]
Target host release: [installed/requested version; preserve it]
Task scope and authorization: [what may be changed/published]

Investigate this bug: [minimal steps, expected result, observed result]. Target release: [version].
Read AGENTS.md, inspect git status and preserve pending work. Use the code map to locate the owning domain.
Reproduce using synthetic data and separate request IDs/revisions, transport results and rendered state. Inspect error.code instead of translated text.
Show the evidence for the cause before implementing the smallest fix. Keep rules/authorization in services and notifications after commit.
Do not force success by refreshing an expected revision silently, suppressing errors, removing assertions or bypassing permissions.
Run focused validation and report commands, outputs and any remaining uncertainty. Do not publish logs, credentials or campaign data.

Inspect the actual files and supported APIs before proposing code. Do not invent commands, fields, endpoints or package capabilities.
Use disposable test data and installation-local tools/caches. Explain any unsupported requirement and validate the result with the project’s real tools.
Deliver concrete files or editor steps, the checks performed and any unresolved limits.

How to validate

• Confirm the original reproduction now behaves as expected.

• Test the denied/expired/stale case relevant to the cause, rather than only the successful GM path.

• Review the diff for unrelated changes, data writes and weakened assertions.

Ready when

The failure has a demonstrated cause, a focused correction and evidence that the original case and its relevant boundaries work.

Continue with the module reference, public API and testing guide.