ChatGPT Dots Workflow: From Feedback to a Reviewed PR

1. Define one issue and the expected result

Provide the feedback thread or bug report, the repository, the affected behavior, and a concrete acceptance check. Ask the dot to summarize the issue and any missing reproduction details before it changes code. Avoid a vague request to “fix everything.”

2. Give the minimum access the task needs

Connect the relevant app or repository only if you want the dot to use it. Say which files or area are in scope and whether it may edit code or only investigate. For local files, distinguish your computer from the dot’s cloud computer.

3. Set a review boundary

Ask for a small, dedicated branch and a draft pull request. Specify whether committing and pushing are allowed. Keep merging and deployment as separate decisions. Review your approval and control settings before starting.

4. Ask for reproducible evidence

Have the dot report what changed, commands run, their results, and any tests it could not run. Request regression coverage for the original issue and inspect the diff yourself. A passing build alone does not establish that the reported bug is fixed.

5. Review the handoff

Check the exact commit in the PR, the required CI results, screenshots for UI changes, and any remaining risks. Decide whether to request changes or merge only after you have reviewed the evidence.

Sample task brief

This is an editorial example, not a prompt published by OpenAI:

“Investigate the linked bug in this repository. Reproduce it, propose a small fix, and add a regression test. You may edit files and run tests. Show me the diff and results before committing, pushing, merging, or deploying.”

Change those permissions deliberately if you want the dot to take additional steps. For account access and work-limit questions, read pricing, availability, and limits.

Source example and limits

OpenAI’s announcement describes a developer turning feedback into tested fixes and pull requests. It does not publish a repository, a reproducible benchmark, or this five-step checklist. Read the separate official developer example for the source story and its evidence limits.

The intended outcome is a small, reviewable change with evidence tied to one reported issue. This checklist does not guarantee a correct patch, faster delivery, or access to a particular repository. A human maintainer remains responsible for the merge decision.