Help me start the right Developers workflow.
Task to use: Debug an Issue: start from error message and reproduction steps.
Paste current work: Need likely causes, questions to ask, reproduction plan, and commands to verify. Do not suggest random rewrites. In debugging plan work, the rough note has to lead because role-level advice would flatten the situation. A reviewer needs those notes kept separate from assumptions. Carry the source note into a debugging plan. For debugging plan work, paste the source as bullets, constraints, and audience notes so the model has enough shape for a technical checklist with hypotheses, steps, risks, and verification commands..
Audience and constraints: Software developers using ChatGPT for review, tests, documentation, debugging, and learning..
Who checks it: Let a human checker decide whether a debugging plan reflects the source note or needs another pass before it reaches a code reviewer, teammate, maintainer, or future self..
Before writing, ask for anything missing that would change the debug an issue: start from error message and reproduction steps output.
Return: The output should be easy to copy, but harder to misuse: every risky claim needs a visible check and a clear owner before reuse.
Stop if: Restart the prompt if it adds citations, policies, credentials, or outcomes outside the source notes.
After the first answer
Save what came back, what needs fixing, and the next prompt change before moving to another task.
0No role notes yet
Run the prompt once, check the answer, then save the problem and next try here.
Nothing saved yet
Where ChatGPT helps this role
Turn rough notes into a reviewable asset for a code reviewer, teammate, maintainer, or future self.
Convert a recurring developers workflow into a reusable prompt sequence.
Ask ChatGPT for clarifying questions before committing to tone, format, or evidence.
Create a quick version for routine work and a deeper version for high-stakes work.
Review an existing answer against privacy, accuracy, and role-specific constraints.
Rewrite output for a different audience without changing the underlying facts.
Build a checklist that makes the human review faster and less subjective.
Main Risks
AI-assisted code must be reviewed, tested, and adapted to the actual codebase.
A broad prompt can hide missing source material, so developers should name the exact evidence before asking for output.
Over-polished wording can make weak assumptions look finished; every page links the prompt to a review step.
Copying the same prompt across tasks weakens results because developers need different inputs for planning, review, outreach, and explanation work.
Recommended Workflow
Pick the task page that matches the work to finish, not just the closest job title.
Prepare the source notes, audience, constraints, and forbidden assumptions before copying a prompt.
Run the prompt once for structure, then run a review prompt against facts, tone, and missing context.
Save the final prompt with the human review checklist so the workflow can be reused without becoming automatic.
Choose the first task by situation
Start with Debug an issue when the user has source notes but does not yet know the right output structure, then move to Review code or Write unit tests only after the audience and review owner are clear.
Choose by situation
Choose Debug an issue when the main problem is shaping raw context into something a code reviewer, teammate, maintainer, or future self can inspect.
Choose Review code when the user already has a first version and needs the next artifact in the same developers loop.
Choose Write unit tests when the risk is quality control, review consistency, or a clearer handoff to another person.
Open the role guide when the user cannot name the task yet and needs to decide whether to create, revise, review, or sanitize context first.
Avoid starting with
Do not start from a broad role prompt when the user already knows the concrete task.
Do not start from a writing prompt when the missing piece is source material or named human check.
Do not reuse a developers prompt across unrelated tasks without changing inputs, constraints, and review checks.
Developers pages are organized by the choice a person is trying to make, not by a generic prompt collection. The role page should help the user pick the first useful task, then the task page should carry the details: source material, variable fill, example, stronger prompt, and human review boundary.
Pick the workflow by the work in front of you
Debug an issue
Use when the next useful output is a debugging plan and the answer needs a technical checklist with hypotheses, steps, risks, and verification commands.
Debug an issue needs error message, reproduction steps, recent changes, environment, and expected behavior; the check focuses on debugging plan quality, reproduction steps and error evidence, and codebase verification, not a generic writing pass.
Review code
Use when the next useful output is a code review checklist and the answer needs a technical checklist with hypotheses, steps, risks, and verification commands.
Review code needs diff summary, affected files, risk areas, tests, and intended behavior; the check focuses on code review checklist quality, behavior risk and diff hotspots, and codebase verification, not a generic writing pass.
Write unit tests
Use when the next useful output is unit test cases and the answer needs a technical checklist with hypotheses, steps, risks, and verification commands.
Write unit tests needs function behavior, edge cases, inputs, outputs, and existing test style; the check focuses on unit test cases quality, edge cases and assertions, and codebase verification, not a generic writing pass.
Write documentation
Use when the next useful output is developer documentation and the answer needs developer documentation arranged as a working version, check questions, and next steps.
Write documentation needs feature behavior, audience, setup steps, examples, and known limitations; the check focuses on developer documentation quality, reader task and setup path, and codebase verification, not a generic writing pass.
Plan refactoring
Use when the next useful output is a refactoring plan and the answer needs a technical checklist with hypotheses, steps, risks, and verification commands.
Plan refactoring needs current code shape, pain points, behavior to preserve, tests, and migration risk; the check focuses on refactoring plan quality, behavior preservation and coupling removal, and codebase verification, not a generic writing pass.
Sketch API integration
Use when the next useful output is an API integration plan and the answer needs a technical checklist with hypotheses, steps, risks, and verification commands.
Sketch API integration needs API docs, auth model, endpoints, data shape, errors, and rate limits; the check focuses on API integration plan quality, auth flow and endpoint contract, and codebase verification, not a generic writing pass.
Explain regex
Use when the next useful output is a plain-language regex explanation and the answer needs a technical checklist with hypotheses, steps, risks, and verification commands.
Explain regex needs target pattern, sample matches, sample non-matches, escaping rules, and test cases; the check focuses on plain-language regex explanation quality, pattern tokens and sample matches, and codebase verification, not a generic writing pass.
Build learning roadmaps
Use when the next useful output is a learning roadmap and the answer needs a sequenced plan with stages, owners, timing, and choice checkpoints.
Build learning roadmaps needs current skill level, target outcome, time budget, projects, and feedback loop; the check focuses on learning roadmap quality, skill baseline and project ladder, and codebase verification, not a generic writing pass.
Use this when debugging plan has real source material but still needs review. The page turns error message, reproduction steps, recent changes, environment, and expected behavior into a debugging plan and shows what to keep, question, revise, or discard.
Turn error message, reproduction steps, recent changes, environment, and expected behavior into a debugging plan for a code reviewer, teammate, maintainer, or future self.
Bring first
Need likely causes, questions to ask, reproduction plan, and commands to verify. Do not suggest random rewrites. In debugging plan work, the rough note has to lead because role-level advice would flatten the situation. A reviewer needs those notes kept separate from assumptions. Carry the source note into a debugging plan. For debugging plan work, paste the source as bullets, constraints, and audience notes so the model has enough shape for a technical checklist with hypotheses, steps, risks, and verification commands.
Reject if
Restart the prompt if it adds citations, policies, credentials, or outcomes outside the source notes.
Turn diff summary, affected files, risk areas, tests, and intended behavior into a code review checklist with a worked input, a copyable run, and a second pass for weak sections. The reviewer checks code review checklist quality, behavior risk and diff hotspots before reuse.
Turn diff summary, affected files, risk areas, tests, and intended behavior into a code review checklist for a code reviewer, teammate, maintainer, or future self.
Bring first
Need review checklist for security, redirects, edge cases, tests, naming, and rollback risk. Include questions for reviewer. Examples for code review checklist work help only when they keep the source note visible while shaping review checklist mapped to changed files. The response should leave the source trail easy to inspect. In code review checklist work, the supplied note becomes the base for a code review checklist. A usable starting note for code review checklist work includes what is known, what is uncertain, and what the reviewer must verify.
Reject if
Send it back for revision if it skips examples that sound plausible but cannot be tied back to the user's source.
Start with this material: function behavior, edge cases, inputs, outputs, and existing test style. Use the unit test cases workflow to create unit test cases, keep test case table with edge conditions visible, add reject rules, and show a code reviewer, teammate, maintainer, or future self what to check next.
Turn function behavior, edge cases, inputs, outputs, and existing test style into unit test cases for a code reviewer, teammate, maintainer, or future self.
Bring first
Need test cases, names, assertions, and edge cases. Existing tests use Vitest. Avoid testing implementation details. Phrase shopping fails for unit test cases work because the note should become test case table with edge conditions. The user's note should stay readable after the answer is organized. This unit test cases work run should turn that note into unit test cases. For unit test cases work, paste the source as bullets, constraints, and audience notes so the model has enough shape for a technical checklist with hypotheses, steps, risks, and verification commands.
Reject if
Reject the answer if it invents facts, numbers, policy claims, citations, credentials, or examples that were not in the notes.
Turn feature behavior, audience, setup steps, examples, and known limitations into developer documentation with a worked input, a copyable run, and a second pass for weak sections. The reviewer checks developer documentation quality, reader task and setup path before reuse.
Turn feature behavior, audience, setup steps, examples, and known limitations into developer documentation for a code reviewer, teammate, maintainer, or future self.
Bring first
Need overview, setup steps, retry timing, example payload, error cases, limitations, and support troubleshooting notes. Examples for developer documentation work help only when they keep the source note visible while shaping doc outline with example and limitation blocks. The response should leave the source trail easy to inspect. In developer documentation work, the supplied note becomes the base for developer documentation. A usable starting note for developer documentation work includes what is known, what is uncertain, and what the reviewer must verify.
Reject if
Send it back for revision if it skips examples that sound plausible but cannot be tied back to the user's source.
Use this workflow when the refactoring plan job starts with current code shape, pain points, behavior to preserve, tests and needs a clear output shape. The result can be checked before it reaches a code reviewer, teammate, maintainer, or future self.
Turn current code shape, pain points, behavior to preserve, tests, and migration risk into a refactoring plan for a code reviewer, teammate, maintainer, or future self.
Bring first
Need refactor plan, preserved behavior, test coverage, file moves, migration steps, risks, and verification commands. In refactoring plan work, the rough note has to lead because role-level advice would flatten the situation. A working result should keep source, limit, and reviewer together. Carry the source note into a refactoring plan. For refactoring plan work, paste the source as bullets, constraints, and audience notes so the model has enough shape for a technical checklist with hypotheses, steps, risks, and verification commands.
Reject if
Restart the prompt if it adds citations, policies, credentials, or outcomes outside the source notes.
The API integration plan prompt path asks for API docs, auth model, endpoints, data shape, errors, and rate, creates an API integration plan, and marks what still needs a person. It is meant for a code reviewer, teammate, maintainer, or future self, not for one-click publishing.
Turn API docs, auth model, endpoints, data shape, errors, and rate limits into an API integration plan for a code reviewer, teammate, maintainer, or future self.
Bring first
Need integration plan from docs, endpoints, auth flow, data mapping, error handling, webhook validation, and tests. Developers need more than broad ChatGPT advice here; the answer has to work against the actual note and reviewer. A safer first pass should expose the factual base. a code reviewer, teammate, maintainer, or future self should still see the note while an API integration plan is being built. Sketch API Integration works better when the context is in named fields, because each variable can be checked before copying.
Reject if
Stop before sharing if it cannot show support, numbers, or authority that the user did not provide.
The regex prompt path asks for target pattern, sample matches, sample non-matches, escaping rules, and test, creates a plain-language regex explanation, and marks what still needs a person. It is meant for a code reviewer, teammate, maintainer, or future self, not for one-click publishing.
Turn target pattern, sample matches, sample non-matches, escaping rules, and test cases into a plain-language regex explanation for a code reviewer, teammate, maintainer, or future self.
Bring first
Need regex explanation, pattern, sample matches, sample non-matches, edge cases, and test cases. Avoid catastrophic backtracking. Developers need more than broad ChatGPT advice here; the answer has to work against the actual note and reviewer. A safer first pass should expose the factual base. a code reviewer, teammate, maintainer, or future self should still see the note while a plain-language regex explanation is being built. Explain Regex works better when the context is in named fields, because each variable can be checked before copying.
Reject if
Stop before sharing if it cannot show support, numbers, or authority that the user did not provide.
Developers can move from current skill level, target outcome, time budget, projects, and feedback to a learning roadmap without treating the first answer as finished. The workflow adds a messy-note example, answer checks, and a follow-up prompt for learning roadmap quality, skill baseline and project ladder.
Turn current skill level, target outcome, time budget, projects, and feedback loop into a learning roadmap for a code reviewer, teammate, maintainer, or future self.
Bring first
Need weekly plan, projects, reading, practice tasks, checkpoints, feedback sources, and what to skip. 5 hours per week. roadmap with practice project and feedback loop would be weak without the source details, so the evidence has to stay attached. A reviewable answer should keep the original constraint in the open. Developers should use the note as the base for a learning roadmap. Before developers run this, separate facts, preferences, and limits so the finished answer does not hide assumptions.
Reject if
Do not use the answer if it hides unsupported claims about actual error output, code behavior, and passing verification or treats uncertainty as fact.