|
| 1 | +--- |
| 2 | +name: codex-bug |
| 3 | +description: Diagnose GitHub bug reports in openai/codex. Use when given a GitHub issue URL from openai/codex and asked to decide next steps such as verifying against the repo, requesting more info, or explaining why it is not a bug; follow any additional user-provided instructions. |
| 4 | +--- |
| 5 | + |
| 6 | +# Codex Bug |
| 7 | + |
| 8 | +## Overview |
| 9 | + |
| 10 | +Diagnose a Codex GitHub bug report and decide the next action: verify against sources, request more info, or explain why it is not a bug. |
| 11 | + |
| 12 | +## Workflow |
| 13 | + |
| 14 | +1. Confirm the input |
| 15 | + |
| 16 | +- Require a GitHub issue URL that points to `github.com/openai/codex/issues/…`. |
| 17 | +- If the URL is missing or not in the right repo, ask the user for the correct link. |
| 18 | + |
| 19 | +2. Network access |
| 20 | + |
| 21 | +- Always access the issue over the network immediately, even if you think access is blocked or unavailable. |
| 22 | +- Prefer the GitHub API over HTML pages because the HTML is noisy: |
| 23 | + - Issue: `https://api.github.com/repos/openai/codex/issues/<number>` |
| 24 | + - Comments: `https://api.github.com/repos/openai/codex/issues/<number>/comments` |
| 25 | +- If the environment requires explicit approval, request it on demand via the tool and continue without additional user prompting. |
| 26 | +- Only if the network attempt fails after requesting approval, explain what you can do offline (e.g., draft a response template) and ask how to proceed. |
| 27 | + |
| 28 | +3. Read the issue |
| 29 | + |
| 30 | +- Use the GitHub API responses (issue + comments) as the source of truth rather than scraping the HTML issue page. |
| 31 | +- Extract: title, body, repro steps, expected vs actual, environment, logs, and any attachments. |
| 32 | +- Note whether the report already includes logs or session details. |
| 33 | +- If the report includes a thread ID, mention it in the summary and use it to look up the logs and session details if you have access to them. |
| 34 | + |
| 35 | +4. Summarize the bug before investigating |
| 36 | + |
| 37 | +- Before inspecting code, docs, or logs in depth, write a short summary of the report in your own words. |
| 38 | +- Include the reported behavior, expected behavior, repro steps, environment, and what evidence is already attached or missing. |
| 39 | + |
| 40 | +5. Decide the course of action |
| 41 | + |
| 42 | +- **Verify with sources** when the report is specific and likely reproducible. Inspect relevant Codex files (or mention the files to inspect if access is unavailable). |
| 43 | +- **Request more information** when the report is vague, missing repro steps, or lacks logs/environment. |
| 44 | +- **Explain not a bug** when the report contradicts current behavior or documented constraints (cite the evidence from the issue and any local sources you checked). |
| 45 | + |
| 46 | +6. Respond |
| 47 | + |
| 48 | +- Provide a concise report of your findings and next steps. |
0 commit comments