Begin with the user’s task
Describe what someone is trying to do, what they expect and what actually happens. A bug report needs steps, an environment and an approximate time.
Separate observations from explanations. “The button does not submit the form” is an observation; “the database is broken” is a hypothesis that still needs checking.
Collect setup instructions
Provide the repository, runtime versions, dependency installation and startup procedure. List supporting services such as a database, job queue, email service or external API.
Describe differences between local development, a test environment and production. A problem that appears in only one environment is useful diagnostic information.
Share access appropriately
Agree first on the minimum permissions and who can provide them. Passwords, API keys and personal data do not belong in a public brief or a routine task description.
Use test data where possible. If real data is necessary, define permitted actions and verification separately.
Identify important neighbouring workflows
A change to pricing, an order status or access rules may affect several screens and background operations. Name the workflows that must keep working.
Existing tests, sample inputs and outputs and explanations of business rules are useful. Unaligned expectations often look like a technical fault.
Agree on release rules
Who accepts the result, who deploys it and how is it checked afterwards? Significant changes need an agreed recovery option.
If the cause is still unknown, the first stage may deliver diagnosis and a plan. That needs to be explicit in the scope.