Help me solve this JavaScript task: [TASK]. The code, error output, or current implementation is [CURRENT CODE OR ERROR]. My runtime and project constraints are [ENVIRONMENT]. The expected behavior, input shape, and examples are [EXPECTED BEHAVIOR]. The relevant dependencies, style rules, and files I can change are [PROJECT CONSTRAINTS]. Work from the supplied code and facts. Do not invent APIs, package behavior, configuration, files, credentials, benchmark results, or test outcomes. If a library version, runtime behavior, or external API contract is uncertain, state the assumption and show how I can verify it. Prefer the smallest change that solves the stated problem and preserves existing public behavior. Produce the response in this order: 1. Diagnosis: explain the likely root cause or implementation approach in three to six plain-language bullets, distinguishing evidence from assumptions. 2. Solution: provide complete, runnable JavaScript or TypeScript for the changed function, module, or minimal file. Mark exactly where it belongs. Preserve the requested module system and asynchronous style. 3. Edge cases: explain how the code handles invalid input, empty values, boundary conditions, errors, concurrency or async failures, and cleanup where relevant. 4. Tests: provide three to six focused tests using [TEST FRAMEWORK], including the failing case, a normal case, and an edge case. Do not claim they passed. 5. Integration notes: list any imports, environment variables, migration steps, or behavior changes. Avoid broad refactors, obsolete syntax for my environment, hidden global state, and swallowing errors. Use parameter validation only where it improves the contract, and make error messages actionable. Before answering, self-check that identifiers are consistent, the example code parses in the stated runtime, and every behavior claimed is covered by supplied code or a proposed test. Ask up to three clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [TASK] | Describe the feature, bug, refactor, or coding question you need solved. | Fix a function that fetches paginated GitHub issues and returns only open issues with labels. |
| [CURRENT CODE OR ERROR] | Paste the smallest relevant code sample and the exact error or unexpected result. | async function issues(url) { const r = await fetch(url); return (await r.json()).filter(x => x.state = 'open'); } It returns closed issues too and fails when GitHub returns a non-200 response. |
| [ENVIRONMENT] | State the JavaScript runtime, version, framework, package manager, and browser or server context. | Node.js 22, ESM modules, built-in fetch, no TypeScript. |
| [EXPECTED BEHAVIOR] | Describe valid inputs, expected outputs, and one or two concrete examples. | Given an API URL, return an array of open issue objects. Throw an error containing status code for a 403 response. A pull request object in the response must be excluded. |
| [PROJECT CONSTRAINTS] | List dependencies, files you may change, code conventions, performance needs, and security constraints. | Can edit src/issues.js and test/issues.test.js. No new dependencies. Follow existing async/await style. The token is already supplied by the caller and must never be logged. |
| [TEST FRAMEWORK] | Name the test framework and any existing test pattern, such as Vitest, Jest, or Node test. | node:test with node:assert/strict; mock fetch by injecting it as a function argument. |
How to use
- Paste a minimal reproducible example, including the exact error text and the expected result.
- State the runtime version because module syntax, built-ins, and APIs differ across Node, browsers, and frameworks.
- Run the proposed tests locally and compare the changed behavior with your existing public contract.
- Follow up with: “Now return this as a minimal diff for src/issues.js and test/issues.test.js, with no unrelated formatting changes.”
Variations
Debug a bug
Use this when code works unexpectedly and you need a root-cause investigation.
Debug this JavaScript issue: [SYMPTOM]. Here is the minimal reproduction and exact output: [REPRODUCTION]. It runs in [ENVIRONMENT], and the expected behavior is [EXPECTED RESULT]. First rank the most likely causes and explain the evidence for each. Then provide the smallest corrected code change and three focused [TEST FRAMEWORK] tests. Do not assume hidden application state, package versions, or API responses that I have not supplied. Include one diagnostic log or breakpoint suggestion if the cause cannot be proven from the snippet. Check that the fix does not mask the error. Ask up to three questions only if required details are missing.
Code review
Use this when you want actionable review feedback on a pull request or function.
Review this JavaScript change for correctness, security, maintainability, and runtime behavior: [CODE CHANGE]. The intended behavior is [INTENT], the environment is [ENVIRONMENT], and relevant surrounding constraints are [CONTEXT]. Return findings ordered by severity, each with the affected code, failure scenario, and a specific fix. Then list test cases that would catch the highest-risk problems. Do not invent vulnerabilities or style rules; label uncertainty where context is missing. Do not rewrite the entire codebase unless a finding requires it. Self-check that each finding is tied to a concrete line or behavior. Ask up to three questions only if needed.
Build a utility
Use this when you need a small, well-specified function or module.
Implement a JavaScript utility that [UTILITY PURPOSE]. Its input and output contract is [INPUT OUTPUT EXAMPLES]. It will run in [ENVIRONMENT], and constraints are [CONSTRAINTS]. Provide a complete module with JSDoc for public parameters and returns, clear error behavior, and four [TEST FRAMEWORK] tests covering normal input, invalid input, empty input, and a boundary case. Explain algorithmic complexity only if it is relevant to the expected data size. Do not add dependencies or invent surrounding application code. Check that the exports match the stated module system. Ask up to three questions only if a required input is missing.
Tips
- Reduce a bug report to the smallest code path that still fails; unrelated framework code makes an AI diagnosis less reliable.
- Specify the runtime and module system because `require`, `import`, `fetch`, top-level await, and test mocking differ materially across environments.
- Ask for tests that demonstrate the prior failure and a boundary condition, then run them yourself; generated tests are a proposal, not evidence.
- For API-facing code, provide a sample success payload and error payload, and explicitly identify secrets that must not be logged or returned.
FAQ
Can ChatGPT write production JavaScript?
It can draft useful code, tests, and explanations, but you should run the code, inspect dependencies, and review security-sensitive behavior before deployment.
What should I paste with a JavaScript error?
Paste the exact error, the smallest relevant code, runtime and package versions, input that triggers it, and the expected result. Stack traces are often useful when they include your code path.
Should I ask AI to refactor a large JavaScript file?
Start with one behavior or module and preserve a testable baseline. Large refactors are safer when broken into small changes with tests after each change.