Review-first run
A practical debug an issue workflow for developers, with variable prompts, a messy-note example, quality checks, and next-step links. debug an issue treats debug log with reproduction and hypothesis rows as the asset to check, not as decorative output.
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 debug an issue, 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 debug an issue note into a debugging plan. For debug an issue, 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.
Ready-to-run path
Turn rough review code notes into a code review checklist; use the prompt, sample input, rejection rules, and review checklist together. review code review starts at the moment where code reviews can stay broad instead of naming file-level risks and test questions.
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 review code 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 review code, the supplied note becomes the base for a code review checklist. A usable review code input 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.
Ready-to-run path
Developers get a unit tests run sheet with real input, source checks, answer repair, and a handoff path for a code reviewer, teammate, maintainer, or future self. unit tests gives the user a concrete test case table with edge conditions to inspect, not just wording to polish.
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 in write unit tests fails because the note should become test case table with edge conditions. The user's note should stay readable after the answer is organized. This write unit tests run should turn that note into unit test cases. For write unit tests, 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.
Review-first run
Turn rough documentation notes into developer documentation; use the prompt, sample input, rejection rules, and review checklist together. documentation review starts at the moment where documentation can describe the happy path while examples and limitations stay thin.
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 write documentation 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 write documentation, the supplied note becomes the base for developer documentation. A usable write documentation input 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.
Ready-to-run path
Use this page when refactoring needs current code shape, pain points, behavior to preserve, tests, and migration risk, a clear output shape, and a review pass before sharing with a code reviewer, teammate, maintainer, or future self. refactoring treats refactor plan with behavior-preservation checks as the asset to check, not as decorative output.
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 plan refactoring, 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 plan refactoring note into a refactoring plan. For plan refactoring, 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.
Ready-to-run path
A focused prompt path for developers: gather context, create an API integration plan, repair weak answers, and save only the reusable parts. api integration needs a human pass that can replace polished filler with source-backed lines inside an API integration plan before the answer is reused.
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 proof, numbers, or authority that the user did not provide.
Review-first run
A focused prompt path for developers: gather context, create a plain-language regex explanation, repair weak answers, and save only the reusable parts. regex needs a human pass that can replace polished filler with source-backed lines inside a plain-language regex explanation before the answer is reused.
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 proof, numbers, or authority that the user did not provide.
Ready-to-run path
A prompt workbench for learning roadmaps, covering current skill level, target outcome, time budget, projects, and feedback loop, a sequenced plan with stages, owners, timing, and decision checkpoints, review checks, and follow-up fixes. learning roadmaps examples stay close to an engineering workflow where context, tests, and reproducibility matter, so the prompt has a real work setting.
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.