eko24ive/pi-config/bug-reporter

Bug Reporter

Create a review-ready bug report from the information and evidence already available in the conversation and workspace.

Authority

Report composition does not authorize evidence capture, file writes, publication, destination-specific metadata, or fixing the bug. Those require explicit instructions.

Workflow

1. Collect available facts. Extract the affected location, actual and expected behavior, reproduction steps, environment, display/device details, and existing evidence.
2. Respect the source of truth. Follow applicable user/project report conventions. Include severity only when required, requested, or supported; use project policy first and references/severity-guide.md only as a fallback.
3. Clarify only material gaps. Ask when missing information prevents a useful report or impact assessment. Otherwise omit unsupported optional fields or list a material limitation.
4. Inspect existing evidence. Use screenshots, videos, logs, traces, network details, and prior observations already available. Distinguish observed facts, reporter claims, and technical hypotheses.
5. Investigate lightly when useful. If the relevant codebase is available and technical notes would materially improve the report, locate likely implementation points using repository-preferred navigation tools. Include only grounded, relevant files and do not turn reporting into full root-cause analysis.
6. Compose the report. Follow an explicitly requested or project-required format. Otherwise use references/template.md.

Rules

• Write a specific title beginning with the affected feature or location.
• Preserve exact relevant errors, status codes, request names, device details, and versions when known.
• Never invent steps, logs, stack traces, user data, routes, files, or causes.
• Keep observed behavior separate from suspected cause; omit unsupported hypotheses.
• Mark reproduced only when the relevant steps were witnessed and the claimed result observed. An endpoint artifact alone does not establish the sequence.
• Scope reproduction, frequency, environment, and display claims to observed or explicitly reported targets and attempts. Do not generalize.
• Reference artifacts where they currently exist; do not rename or relocate them.
• Include sections only when supported by available facts or required by applicable guidance.

Output

Follow applicable user/project output guidance. Otherwise return the completed Markdown report in chat, optionally preceded by one short uncertainty note.

References

• references/template.md — destination-neutral default structure.
• references/severity-guide.md — generic fallback when no project severity policy exists.