Technology & Programming

Code comprehensionExplain unfamiliar code

Purpose

Helps you produce a walkthrough of the supplied code covering inputs, outputs, state changes, control flow, and external dependencies without assuming missing files.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a walkthrough of the supplied code covering inputs, outputs, state changes, control flow, and external dependencies without assuming missing files. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Identify a function that reads a file, transforms rows, and writes a result.

Improve the result

Review the result against this specific requirement: a walkthrough of the supplied code covering inputs, outputs, state changes, control flow, and external dependencies without assuming missing files. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Missing files and runtime behavior cannot be inferred with certainty. Confirm language and dependency versions before relying on the explanation.

Code comprehensionMap a call chain

Purpose

Helps you produce a call-chain outline from the supplied entry point to its observable result, marking dynamic or unavailable calls as unresolved.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a call-chain outline from the supplied entry point to its observable result, marking dynamic or unavailable calls as unresolved. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Trace route handler → service → repository and mark an unavailable external call.

Improve the result

Review the result against this specific requirement: a call-chain outline from the supplied entry point to its observable result, marking dynamic or unavailable calls as unresolved. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Missing files and runtime behavior cannot be inferred with certainty. Confirm language and dependency versions before relying on the explanation.

Code comprehensionExplain a regular expression

Purpose

Helps you produce a token-by-token explanation of the supplied regular expression, including flags, matching examples, nonmatches, and engine-dependent behavior.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a token-by-token explanation of the supplied regular expression, including flags, matching examples, nonmatches, and engine-dependent behavior. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Explain why an anchored digit pattern rejects trailing letters.

Improve the result

Review the result against this specific requirement: a token-by-token explanation of the supplied regular expression, including flags, matching examples, nonmatches, and engine-dependent behavior. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Missing files and runtime behavior cannot be inferred with certainty. Confirm language and dependency versions before relying on the explanation.

Code comprehensionTrace variable state

Purpose

Helps you produce a trace table for the supplied code and input showing each important variable change, branch decision, and final output.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a trace table for the supplied code and input showing each important variable change, branch decision, and final output. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Show a counter before and after each loop iteration, including zero iterations.

Improve the result

Review the result against this specific requirement: a trace table for the supplied code and input showing each important variable change, branch decision, and final output. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Missing files and runtime behavior cannot be inferred with certainty. Confirm language and dependency versions before relying on the explanation.

Code comprehensionUnderstand asynchronous behavior

Purpose

Helps you produce an explanation of ordering, waiting, cancellation, and error propagation in the supplied asynchronous code, distinguishing guaranteed order from scheduler-dependent order.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an explanation of ordering, waiting, cancellation, and error propagation in the supplied asynchronous code, distinguishing guaranteed order from scheduler-dependent order. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Separate awaited operations from tasks that may complete in either order.

Improve the result

Review the result against this specific requirement: an explanation of ordering, waiting, cancellation, and error propagation in the supplied asynchronous code, distinguishing guaranteed order from scheduler-dependent order. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Missing files and runtime behavior cannot be inferred with certainty. Confirm language and dependency versions before relying on the explanation.

Code comprehensionCompare two implementations

Purpose

Helps you produce a comparison of behavior, complexity, readability, and failure cases for the two supplied implementations using identical example inputs.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a comparison of behavior, complexity, readability, and failure cases for the two supplied implementations using identical example inputs. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Use the same empty and duplicate-containing inputs for both implementations.

Improve the result

Review the result against this specific requirement: a comparison of behavior, complexity, readability, and failure cases for the two supplied implementations using identical example inputs. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Missing files and runtime behavior cannot be inferred with certainty. Confirm language and dependency versions before relying on the explanation.

Code comprehensionExplain a SQL query

Purpose

Helps you produce a clause-by-clause explanation of the query, including join cardinality, filtering stages, grouping, null behavior, and potential duplicate rows.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a clause-by-clause explanation of the query, including join cardinality, filtering stages, grouping, null behavior, and potential duplicate rows. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Explain how a one-to-many join can multiply rows before aggregation.

Improve the result

Review the result against this specific requirement: a clause-by-clause explanation of the query, including join cardinality, filtering stages, grouping, null behavior, and potential duplicate rows. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Missing files and runtime behavior cannot be inferred with certainty. Confirm language and dependency versions before relying on the explanation.

Code comprehensionDecode a type signature

Purpose

Helps you produce an explanation of the supplied type signature with valid and invalid examples, generic constraints, and runtime guarantees it does not provide.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an explanation of the supplied type signature with valid and invalid examples, generic constraints, and runtime guarantees it does not provide. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Distinguish a compile-time string type from runtime validation of external input.

Improve the result

Review the result against this specific requirement: an explanation of the supplied type signature with valid and invalid examples, generic constraints, and runtime guarantees it does not provide. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Missing files and runtime behavior cannot be inferred with certainty. Confirm language and dependency versions before relying on the explanation.

Code comprehensionMap configuration precedence

Purpose

Helps you produce a precedence map for the supplied configuration sources showing defaults, overrides, environment-specific values, and unresolved conflicts.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a precedence map for the supplied configuration sources showing defaults, overrides, environment-specific values, and unresolved conflicts. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Show an environment variable overriding a default only if the supplied loader does so.

Improve the result

Review the result against this specific requirement: a precedence map for the supplied configuration sources showing defaults, overrides, environment-specific values, and unresolved conflicts. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Missing files and runtime behavior cannot be inferred with certainty. Confirm language and dependency versions before relying on the explanation.

Code comprehensionExplain an algorithm's tradeoffs

Purpose

Helps you produce an analysis of the supplied algorithm's time and space complexity, assumptions, worst cases, and suitable input sizes.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an analysis of the supplied algorithm's time and space complexity, assumptions, worst cases, and suitable input sizes. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: State that sorting dominates a linear scan when the actual implementation sorts first.

Improve the result

Review the result against this specific requirement: an analysis of the supplied algorithm's time and space complexity, assumptions, worst cases, and suitable input sizes. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Missing files and runtime behavior cannot be inferred with certainty. Confirm language and dependency versions before relying on the explanation.

Debugging and diagnosisTriage an error message

Purpose

Helps you produce a ranked hypothesis list from the exact error and context, with a minimal diagnostic check for each and no invented root cause.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a ranked hypothesis list from the exact error and context, with a minimal diagnostic check for each and no invented root cause. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Test a missing configuration value before claiming a network outage.

Improve the result

Review the result against this specific requirement: a ranked hypothesis list from the exact error and context, with a minimal diagnostic check for each and no invented root cause. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A plausible diagnosis is a hypothesis until reproduced. Test changes in an isolated environment and preserve the failing case.

Debugging and diagnosisReduce a bug reproduction

Purpose

Helps you produce a minimal reproducible example preserving the reported failure while removing unrelated code, with explicit expected and actual behavior.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a minimal reproducible example preserving the reported failure while removing unrelated code, with explicit expected and actual behavior. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Retain the failing input and remove unrelated UI code from the reproduction.

Improve the result

Review the result against this specific requirement: a minimal reproducible example preserving the reported failure while removing unrelated code, with explicit expected and actual behavior. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A plausible diagnosis is a hypothesis until reproduced. Test changes in an isolated environment and preserve the failing case.

Debugging and diagnosisFind an off-by-one error

Purpose

Helps you produce a boundary review of the supplied loop or range logic using empty, single-item, first-item, and last-item cases.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a boundary review of the supplied loop or range logic using empty, single-item, first-item, and last-item cases. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Check whether index equal to array length is incorrectly treated as valid.

Improve the result

Review the result against this specific requirement: a boundary review of the supplied loop or range logic using empty, single-item, first-item, and last-item cases. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A plausible diagnosis is a hypothesis until reproduced. Test changes in an isolated environment and preserve the failing case.

Debugging and diagnosisDiagnose a null-value failure

Purpose

Helps you produce a data-flow review tracing where null or missing values enter, where assumptions fail, and how to handle absence explicitly.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a data-flow review tracing where null or missing values enter, where assumptions fail, and how to handle absence explicitly. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Trace an optional field from parsing to the dereference that assumes it exists.

Improve the result

Review the result against this specific requirement: a data-flow review tracing where null or missing values enter, where assumptions fail, and how to handle absence explicitly. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A plausible diagnosis is a hypothesis until reproduced. Test changes in an isolated environment and preserve the failing case.

Debugging and diagnosisInvestigate a race condition

Purpose

Helps you produce a possible interleaving timeline for the supplied concurrent code, identifying shared state and a reproducible synchronization test.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a possible interleaving timeline for the supplied concurrent code, identifying shared state and a reproducible synchronization test. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Show two workers reading the same old balance before either writes.

Improve the result

Review the result against this specific requirement: a possible interleaving timeline for the supplied concurrent code, identifying shared state and a reproducible synchronization test. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A plausible diagnosis is a hypothesis until reproduced. Test changes in an isolated environment and preserve the failing case.

Debugging and diagnosisDiagnose a memory leak

Purpose

Helps you produce a hypothesis-driven investigation plan using object lifetimes, retained references, and measurements, distinguishing leaks from expected caching.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a hypothesis-driven investigation plan using object lifetimes, retained references, and measurements, distinguishing leaks from expected caching. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Compare retained object counts after repeated operations and garbage collection.

Improve the result

Review the result against this specific requirement: a hypothesis-driven investigation plan using object lifetimes, retained references, and measurements, distinguishing leaks from expected caching. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A plausible diagnosis is a hypothesis until reproduced. Test changes in an isolated environment and preserve the failing case.

Debugging and diagnosisTrace a slow request

Purpose

Helps you produce a latency investigation plan that separates client, network, application, database, and downstream time before recommending optimization.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a latency investigation plan that separates client, network, application, database, and downstream time before recommending optimization. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Measure database time separately from serialization before optimizing the query.

Improve the result

Review the result against this specific requirement: a latency investigation plan that separates client, network, application, database, and downstream time before recommending optimization. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A plausible diagnosis is a hypothesis until reproduced. Test changes in an isolated environment and preserve the failing case.

Debugging and diagnosisInvestigate a flaky test

Purpose

Helps you produce a diagnostic plan for the supplied flaky test covering time, randomness, shared state, external services, and order dependence.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a diagnostic plan for the supplied flaky test covering time, randomness, shared state, external services, and order dependence. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Check whether the test depends on today's date or another test's state.

Improve the result

Review the result against this specific requirement: a diagnostic plan for the supplied flaky test covering time, randomness, shared state, external services, and order dependence. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A plausible diagnosis is a hypothesis until reproduced. Test changes in an isolated environment and preserve the failing case.

Debugging and diagnosisCompare working and failing environments

Purpose

Helps you produce a structured comparison of supplied environment details, highlighting version, configuration, locale, permission, and dependency differences relevant to the failure.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a structured comparison of supplied environment details, highlighting version, configuration, locale, permission, and dependency differences relevant to the failure. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Compare runtime versions and case-sensitive file paths between the two systems.

Improve the result

Review the result against this specific requirement: a structured comparison of supplied environment details, highlighting version, configuration, locale, permission, and dependency differences relevant to the failure. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A plausible diagnosis is a hypothesis until reproduced. Test changes in an isolated environment and preserve the failing case.

Debugging and diagnosisPropose a minimal bug fix

Purpose

Helps you produce a focused patch for the demonstrated defect, an explanation of behavior change, and regression checks without unrelated refactoring.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a focused patch for the demonstrated defect, an explanation of behavior change, and regression checks without unrelated refactoring. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Change the incorrect boundary condition and add a test for the last valid index.

Improve the result

Review the result against this specific requirement: a focused patch for the demonstrated defect, an explanation of behavior change, and regression checks without unrelated refactoring. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A plausible diagnosis is a hypothesis until reproduced. Test changes in an isolated environment and preserve the failing case.

Testing and qualityDesign behavior-focused unit tests

Purpose

Helps you produce unit-test cases for the supplied contract covering normal behavior, boundaries, invalid inputs, and observable outputs rather than implementation details.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare unit-test cases for the supplied contract covering normal behavior, boundaries, invalid inputs, and observable outputs rather than implementation details. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Assert the returned result and error behavior rather than a private helper call.

Improve the result

Review the result against this specific requirement: unit-test cases for the supplied contract covering normal behavior, boundaries, invalid inputs, and observable outputs rather than implementation details. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Generated tests may miss defects. Test code is not a passing test result; execution needs an appropriate runtime or available tools.

Testing and qualityCreate an integration test plan

Purpose

Helps you produce an integration test plan for the named components, specifying real boundaries, fixtures, cleanup, failure injection, and expected evidence.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an integration test plan for the named components, specifying real boundaries, fixtures, cleanup, failure injection, and expected evidence. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Verify a real database transaction rolls back when the second write fails.

Improve the result

Review the result against this specific requirement: an integration test plan for the named components, specifying real boundaries, fixtures, cleanup, failure injection, and expected evidence. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Generated tests may miss defects. Test code is not a passing test result; execution needs an appropriate runtime or available tools.

Testing and qualityGenerate edge-case test data

Purpose

Helps you produce synthetic test inputs for the stated schema covering missing values, Unicode, extremes, duplicates, and invalid types without real personal data.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare synthetic test inputs for the stated schema covering missing values, Unicode, extremes, duplicates, and invalid types without real personal data. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Include an empty name, accented text, maximum length, and invalid numeric input.

Improve the result

Review the result against this specific requirement: synthetic test inputs for the stated schema covering missing values, Unicode, extremes, duplicates, and invalid types without real personal data. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Generated tests may miss defects. Test code is not a passing test result; execution needs an appropriate runtime or available tools.

Testing and qualityReview test assertions

Purpose

Helps you produce an audit of the supplied tests for weak assertions, false positives, untested branches, and dependence on incidental implementation.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an audit of the supplied tests for weak assertions, false positives, untested branches, and dependence on incidental implementation. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Replace an assertion that only checks truthiness with the expected returned value.

Improve the result

Review the result against this specific requirement: an audit of the supplied tests for weak assertions, false positives, untested branches, and dependence on incidental implementation. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Generated tests may miss defects. Test code is not a passing test result; execution needs an appropriate runtime or available tools.

Testing and qualityDefine property-based invariants

Purpose

Helps you produce properties that should hold for the supplied function across many inputs, with counterexample ideas and domain constraints.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare properties that should hold for the supplied function across many inputs, with counterexample ideas and domain constraints. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Sorting should preserve the input multiset and produce nondecreasing order.

Improve the result

Review the result against this specific requirement: properties that should hold for the supplied function across many inputs, with counterexample ideas and domain constraints. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Generated tests may miss defects. Test code is not a passing test result; execution needs an appropriate runtime or available tools.

Testing and qualityPlan accessibility testing

Purpose

Helps you produce a practical accessibility test checklist for the supplied interface covering keyboard use, labels, focus, contrast, and screen-reader announcements.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a practical accessibility test checklist for the supplied interface covering keyboard use, labels, focus, contrast, and screen-reader announcements. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Tab to every control, trigger it by keyboard, and confirm visible focus.

Improve the result

Review the result against this specific requirement: a practical accessibility test checklist for the supplied interface covering keyboard use, labels, focus, contrast, and screen-reader announcements. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Generated tests may miss defects. Test code is not a passing test result; execution needs an appropriate runtime or available tools.

Testing and qualityTest a migration safely

Purpose

Helps you produce a migration test plan using a disposable copy, preconditions, data-integrity assertions, failure recovery, and rollback verification.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a migration test plan using a disposable copy, preconditions, data-integrity assertions, failure recovery, and rollback verification. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Compare record counts and constraints before and after a disposable migration.

Improve the result

Review the result against this specific requirement: a migration test plan using a disposable copy, preconditions, data-integrity assertions, failure recovery, and rollback verification. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Generated tests may miss defects. Test code is not a passing test result; execution needs an appropriate runtime or available tools.

Testing and qualityDesign a performance benchmark

Purpose

Helps you produce a benchmark design stating workload, warm-up, measurement method, variance, baseline, and conditions that make comparisons invalid.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a benchmark design stating workload, warm-up, measurement method, variance, baseline, and conditions that make comparisons invalid. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Run the same workload repeatedly and report spread rather than one best time.

Improve the result

Review the result against this specific requirement: a benchmark design stating workload, warm-up, measurement method, variance, baseline, and conditions that make comparisons invalid. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Generated tests may miss defects. Test code is not a passing test result; execution needs an appropriate runtime or available tools.

Testing and qualityBuild a regression checklist

Purpose

Helps you produce a risk-based regression checklist from the supplied change, distinguishing affected workflows, preserved behavior, and checks not yet executed.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a risk-based regression checklist from the supplied change, distinguishing affected workflows, preserved behavior, and checks not yet executed. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: For a search change, check empty queries, filters, and existing navigation.

Improve the result

Review the result against this specific requirement: a risk-based regression checklist from the supplied change, distinguishing affected workflows, preserved behavior, and checks not yet executed. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Generated tests may miss defects. Test code is not a passing test result; execution needs an appropriate runtime or available tools.

Testing and qualityInterpret test failures honestly

Purpose

Helps you produce a failure summary separating confirmed failures, environmental problems, skipped tests, and untested assumptions with reproducible evidence.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a failure summary separating confirmed failures, environmental problems, skipped tests, and untested assumptions with reproducible evidence. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Report skipped browser tests as untested, not passed.

Improve the result

Review the result against this specific requirement: a failure summary separating confirmed failures, environmental problems, skipped tests, and untested assumptions with reproducible evidence. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Generated tests may miss defects. Test code is not a passing test result; execution needs an appropriate runtime or available tools.

Web interfacesBuild a semantic HTML form

Purpose

Helps you produce a semantic form for the stated fields with explicit labels, helpful validation messages, keyboard access, and no invented submission backend.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a semantic form for the stated fields with explicit labels, helpful validation messages, keyboard access, and no invented submission backend. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Associate each label with its input and place error text beside the field.

Improve the result

Review the result against this specific requirement: a semantic form for the stated fields with explicit labels, helpful validation messages, keyboard access, and no invented submission backend. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Browser behavior, accessibility, and responsiveness require testing in actual target browsers and devices. Generated markup alone proves none of these.

Web interfacesFix a responsive overflow

Purpose

Helps you produce a diagnosis and minimal CSS correction for the supplied overflow, preserving content at narrow widths and explaining how to verify it.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a diagnosis and minimal CSS correction for the supplied overflow, preserving content at narrow widths and explaining how to verify it. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Fix an inflexible grid column rather than hiding horizontal overflow globally.

Improve the result

Review the result against this specific requirement: a diagnosis and minimal CSS correction for the supplied overflow, preserving content at narrow widths and explaining how to verify it. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Browser behavior, accessibility, and responsiveness require testing in actual target browsers and devices. Generated markup alone proves none of these.

Web interfacesCreate an accessible modal

Purpose

Helps you produce a modal implementation plan covering initial focus, focus containment, Escape dismissal, accessible naming, and focus restoration.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a modal implementation plan covering initial focus, focus containment, Escape dismissal, accessible naming, and focus restoration. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Return focus to the opener after closing the dialog with Escape.

Improve the result

Review the result against this specific requirement: a modal implementation plan covering initial focus, focus containment, Escape dismissal, accessible naming, and focus restoration. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Browser behavior, accessibility, and responsiveness require testing in actual target browsers and devices. Generated markup alone proves none of these.

Web interfacesImplement client-side filtering

Purpose

Helps you produce filtering logic for the supplied records that combines search and selected filters, handles empty results, and preserves keyboard usability.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare filtering logic for the supplied records that combines search and selected filters, handles empty results, and preserves keyboard usability. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Search results must satisfy both the text query and selected category.

Improve the result

Review the result against this specific requirement: filtering logic for the supplied records that combines search and selected filters, handles empty results, and preserves keyboard usability. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Browser behavior, accessibility, and responsiveness require testing in actual target browsers and devices. Generated markup alone proves none of these.

Web interfacesDesign loading and error states

Purpose

Helps you produce interface states for the described request covering initial, loading, empty, success, partial failure, retry, and cancellation.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare interface states for the described request covering initial, loading, empty, success, partial failure, retry, and cancellation. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: A failed refresh preserves existing data and offers a clear retry action.

Improve the result

Review the result against this specific requirement: interface states for the described request covering initial, loading, empty, success, partial failure, retry, and cancellation. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Browser behavior, accessibility, and responsiveness require testing in actual target browsers and devices. Generated markup alone proves none of these.

Web interfacesAudit frontend performance

Purpose

Helps you produce a prioritized frontend performance review based on supplied measurements, distinguishing render, network, script, and image costs before suggesting changes.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a prioritized frontend performance review based on supplied measurements, distinguishing render, network, script, and image costs before suggesting changes. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Prioritize a measured oversized image before speculative framework changes.

Improve the result

Review the result against this specific requirement: a prioritized frontend performance review based on supplied measurements, distinguishing render, network, script, and image costs before suggesting changes. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Browser behavior, accessibility, and responsiveness require testing in actual target browsers and devices. Generated markup alone proves none of these.

Web interfacesBuild a clipboard interaction

Purpose

Helps you produce a copy-to-clipboard interaction with explicit user action, success feedback, failure handling, and a manual-copy fallback.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a copy-to-clipboard interaction with explicit user action, success feedback, failure handling, and a manual-copy fallback. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Show Copied only after clipboard success; otherwise select text for manual copying.

Improve the result

Review the result against this specific requirement: a copy-to-clipboard interaction with explicit user action, success feedback, failure handling, and a manual-copy fallback. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Browser behavior, accessibility, and responsiveness require testing in actual target browsers and devices. Generated markup alone proves none of these.

Web interfacesReview browser storage use

Purpose

Helps you produce a review of the supplied storage design covering persistence, expiration, quota failure, privacy, and behavior when storage is unavailable.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a review of the supplied storage design covering persistence, expiration, quota failure, privacy, and behavior when storage is unavailable. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Handle a storage exception without preventing the page from loading.

Improve the result

Review the result against this specific requirement: a review of the supplied storage design covering persistence, expiration, quota failure, privacy, and behavior when storage is unavailable. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Browser behavior, accessibility, and responsiveness require testing in actual target browsers and devices. Generated markup alone proves none of these.

Web interfacesPlan internationalized UI text

Purpose

Helps you produce an internationalization plan for the supplied interface covering message keys, pluralization, dates, number formats, text expansion, and fallback behavior.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an internationalization plan for the supplied interface covering message keys, pluralization, dates, number formats, text expansion, and fallback behavior. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Use locale-aware plural forms rather than concatenating a number with a fixed noun.

Improve the result

Review the result against this specific requirement: an internationalization plan for the supplied interface covering message keys, pluralization, dates, number formats, text expansion, and fallback behavior. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Browser behavior, accessibility, and responsiveness require testing in actual target browsers and devices. Generated markup alone proves none of these.

Web interfacesImprove page metadata

Purpose

Helps you produce page metadata and semantic heading suggestions grounded in the actual content, with canonical and indexing decisions that avoid misleading claims.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare page metadata and semantic heading suggestions grounded in the actual content, with canonical and indexing decisions that avoid misleading claims. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Write a unique description reflecting the page's actual free resource.

Improve the result

Review the result against this specific requirement: page metadata and semantic heading suggestions grounded in the actual content, with canonical and indexing decisions that avoid misleading claims. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Browser behavior, accessibility, and responsiveness require testing in actual target browsers and devices. Generated markup alone proves none of these.

Data and databasesDesign a relational schema

Purpose

Helps you produce a relational schema for the stated entities with keys, relationships, constraints, and examples of invalid states the design prevents.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a relational schema for the stated entities with keys, relationships, constraints, and examples of invalid states the design prevents. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: A foreign key prevents an order from referring to a nonexistent customer.

Improve the result

Review the result against this specific requirement: a relational schema for the stated entities with keys, relationships, constraints, and examples of invalid states the design prevents. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Queries and migrations can alter or lose data. Review against the actual database engine and test on a disposable copy before production use.

Data and databasesWrite a parameterized query

Purpose

Helps you produce a parameterized query for the requested operation using the specified driver, separating values from SQL structure and handling empty results.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a parameterized query for the requested operation using the specified driver, separating values from SQL structure and handling empty results. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Bind a user-supplied value instead of inserting it into SQL text.

Improve the result

Review the result against this specific requirement: a parameterized query for the requested operation using the specified driver, separating values from SQL structure and handling empty results. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Queries and migrations can alter or lose data. Review against the actual database engine and test on a disposable copy before production use.

Data and databasesInvestigate duplicate records

Purpose

Helps you produce a read-only analysis plan identifying duplicate definitions, likely causes, and reconciliation options before proposing any deletion.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a read-only analysis plan identifying duplicate definitions, likely causes, and reconciliation options before proposing any deletion. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Distinguish repeated email addresses from truly duplicate customer records.

Improve the result

Review the result against this specific requirement: a read-only analysis plan identifying duplicate definitions, likely causes, and reconciliation options before proposing any deletion. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Queries and migrations can alter or lose data. Review against the actual database engine and test on a disposable copy before production use.

Data and databasesPlan a schema migration

Purpose

Helps you produce an incremental schema migration design covering compatibility between old and new code, backfill, validation, and rollback limits.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an incremental schema migration design covering compatibility between old and new code, backfill, validation, and rollback limits. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Add a nullable field, backfill it, validate, then tighten the constraint.

Improve the result

Review the result against this specific requirement: an incremental schema migration design covering compatibility between old and new code, backfill, validation, and rollback limits. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Queries and migrations can alter or lose data. Review against the actual database engine and test on a disposable copy before production use.

Data and databasesReview an index strategy

Purpose

Helps you produce an index recommendation based on supplied queries and execution plans, including write overhead and evidence needed before adding indexes.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an index recommendation based on supplied queries and execution plans, including write overhead and evidence needed before adding indexes. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: An index on a filter column needs query-plan evidence and write-cost consideration.

Improve the result

Review the result against this specific requirement: an index recommendation based on supplied queries and execution plans, including write overhead and evidence needed before adding indexes. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Queries and migrations can alter or lose data. Review against the actual database engine and test on a disposable copy before production use.

Data and databasesValidate a JSON payload

Purpose

Helps you produce a validation specification for the supplied JSON contract covering required fields, types, ranges, unknown fields, and actionable error messages.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a validation specification for the supplied JSON contract covering required fields, types, ranges, unknown fields, and actionable error messages. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Reject a negative quantity with a field-specific error instead of silently coercing it.

Improve the result

Review the result against this specific requirement: a validation specification for the supplied JSON contract covering required fields, types, ranges, unknown fields, and actionable error messages. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Queries and migrations can alter or lose data. Review against the actual database engine and test on a disposable copy before production use.

Data and databasesClean a CSV reproducibly

Purpose

Helps you produce a documented CSV-cleaning script that preserves the original, reports changed rows, defines missing-value handling, and validates output counts.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a documented CSV-cleaning script that preserves the original, reports changed rows, defines missing-value handling, and validates output counts. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Report ten normalized rows and two rejected rows while preserving the source CSV.

Improve the result

Review the result against this specific requirement: a documented CSV-cleaning script that preserves the original, reports changed rows, defines missing-value handling, and validates output counts. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Queries and migrations can alter or lose data. Review against the actual database engine and test on a disposable copy before production use.

Data and databasesHandle time zones correctly

Purpose

Helps you produce a design for storing and displaying the supplied timestamps that distinguishes instants, local dates, time zones, and daylight-saving ambiguity.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a design for storing and displaying the supplied timestamps that distinguishes instants, local dates, time zones, and daylight-saving ambiguity. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Store an event instant separately from its display time zone.

Improve the result

Review the result against this specific requirement: a design for storing and displaying the supplied timestamps that distinguishes instants, local dates, time zones, and daylight-saving ambiguity. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Queries and migrations can alter or lose data. Review against the actual database engine and test on a disposable copy before production use.

Data and databasesReconcile two datasets

Purpose

Helps you produce a reconciliation procedure using the supplied matching keys, reporting unmatched and conflicting records without silently choosing a winner.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a reconciliation procedure using the supplied matching keys, reporting unmatched and conflicting records without silently choosing a winner. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: List records with matching IDs but conflicting amounts for human resolution.

Improve the result

Review the result against this specific requirement: a reconciliation procedure using the supplied matching keys, reporting unmatched and conflicting records without silently choosing a winner. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Queries and migrations can alter or lose data. Review against the actual database engine and test on a disposable copy before production use.

Data and databasesDefine data retention behavior

Purpose

Helps you produce a technical retention design from the supplied policy covering active records, backups, deletion evidence, and exceptions without inventing legal requirements.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a technical retention design from the supplied policy covering active records, backups, deletion evidence, and exceptions without inventing legal requirements. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Explain whether backups retain deleted records and when their retention expires.

Improve the result

Review the result against this specific requirement: a technical retention design from the supplied policy covering active records, backups, deletion evidence, and exceptions without inventing legal requirements. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Queries and migrations can alter or lose data. Review against the actual database engine and test on a disposable copy before production use.

APIs and integrationsDesign an API contract

Purpose

Helps you produce an API contract for the stated operation with request and response examples, validation, error codes, authorization assumptions, and versioning considerations.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an API contract for the stated operation with request and response examples, validation, error codes, authorization assumptions, and versioning considerations. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Document a validation error separately from an authentication error.

Improve the result

Review the result against this specific requirement: an API contract for the stated operation with request and response examples, validation, error codes, authorization assumptions, and versioning considerations. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Provider contracts and permissions can change. Use current official documentation; this prompt does not connect accounts or execute requests automatically.

APIs and integrationsHandle paginated responses

Purpose

Helps you produce a pagination strategy for the supplied API contract that avoids missing or duplicating records and handles changing datasets and termination.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a pagination strategy for the supplied API contract that avoids missing or duplicating records and handles changing datasets and termination. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Follow the returned cursor until the API's documented end condition.

Improve the result

Review the result against this specific requirement: a pagination strategy for the supplied API contract that avoids missing or duplicating records and handles changing datasets and termination. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Provider contracts and permissions can change. Use current official documentation; this prompt does not connect accounts or execute requests automatically.

APIs and integrationsDesign retry behavior

Purpose

Helps you produce a retry policy distinguishing transient from permanent failures, respecting rate limits, using bounded backoff, and avoiding duplicate side effects.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a retry policy distinguishing transient from permanent failures, respecting rate limits, using bounded backoff, and avoiding duplicate side effects. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Retry a transient failure with bounded delay but do not retry a permanent validation error.

Improve the result

Review the result against this specific requirement: a retry policy distinguishing transient from permanent failures, respecting rate limits, using bounded backoff, and avoiding duplicate side effects. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Provider contracts and permissions can change. Use current official documentation; this prompt does not connect accounts or execute requests automatically.

APIs and integrationsMake a request idempotent

Purpose

Helps you produce an idempotency design for the supplied operation with key scope, persistence, concurrent requests, expiry, and conflict handling.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an idempotency design for the supplied operation with key scope, persistence, concurrent requests, expiry, and conflict handling. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: A repeated payment request with the same key returns the original outcome.

Improve the result

Review the result against this specific requirement: an idempotency design for the supplied operation with key scope, persistence, concurrent requests, expiry, and conflict handling. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Provider contracts and permissions can change. Use current official documentation; this prompt does not connect accounts or execute requests automatically.

APIs and integrationsValidate webhook delivery

Purpose

Helps you produce a webhook-receiver design covering documented signature verification, timestamp tolerance, replay handling, durable acknowledgment, and safe logging.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a webhook-receiver design covering documented signature verification, timestamp tolerance, replay handling, durable acknowledgment, and safe logging. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Verify signature over the documented raw body before accepting the webhook.

Improve the result

Review the result against this specific requirement: a webhook-receiver design covering documented signature verification, timestamp tolerance, replay handling, durable acknowledgment, and safe logging. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Provider contracts and permissions can change. Use current official documentation; this prompt does not connect accounts or execute requests automatically.

APIs and integrationsMap fields between systems

Purpose

Helps you produce a field-mapping table for the two supplied schemas showing conversions, required fields, lossy transformations, and unresolved business rules.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a field-mapping table for the two supplied schemas showing conversions, required fields, lossy transformations, and unresolved business rules. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Mark cents-to-decimal currency conversion and its rounding rule explicitly.

Improve the result

Review the result against this specific requirement: a field-mapping table for the two supplied schemas showing conversions, required fields, lossy transformations, and unresolved business rules. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Provider contracts and permissions can change. Use current official documentation; this prompt does not connect accounts or execute requests automatically.

APIs and integrationsPlan OAuth integration boundaries

Purpose

Helps you produce an integration checklist based on the supplied provider documentation covering scopes, redirects, token storage, refresh, revocation, and user consent.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an integration checklist based on the supplied provider documentation covering scopes, redirects, token storage, refresh, revocation, and user consent. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Request only required scopes and never place tokens in URLs or logs.

Improve the result

Review the result against this specific requirement: an integration checklist based on the supplied provider documentation covering scopes, redirects, token storage, refresh, revocation, and user consent. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Provider contracts and permissions can change. Use current official documentation; this prompt does not connect accounts or execute requests automatically.

APIs and integrationsHandle API version changes

Purpose

Helps you produce a compatibility review of the supplied old and new API contracts identifying breaking changes, migration steps, and contract tests.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a compatibility review of the supplied old and new API contracts identifying breaking changes, migration steps, and contract tests. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Flag a renamed required response field and add a compatibility test.

Improve the result

Review the result against this specific requirement: a compatibility review of the supplied old and new API contracts identifying breaking changes, migration steps, and contract tests. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Provider contracts and permissions can change. Use current official documentation; this prompt does not connect accounts or execute requests automatically.

APIs and integrationsDesign an offline sync policy

Purpose

Helps you produce a synchronization design for the stated offline workflow covering conflict detection, ordering, retries, deletion markers, and user-visible resolution.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a synchronization design for the stated offline workflow covering conflict detection, ordering, retries, deletion markers, and user-visible resolution. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Detect two edits to the same record rather than silently overwriting one.

Improve the result

Review the result against this specific requirement: a synchronization design for the stated offline workflow covering conflict detection, ordering, retries, deletion markers, and user-visible resolution. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Provider contracts and permissions can change. Use current official documentation; this prompt does not connect accounts or execute requests automatically.

APIs and integrationsDiagnose an integration mismatch

Purpose

Helps you produce a comparison of sanitized request, response, and documented contract that separates authentication, format, timing, and semantic mismatches.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a comparison of sanitized request, response, and documented contract that separates authentication, format, timing, and semantic mismatches. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Compare the actual Content-Type and body shape with the documented contract.

Improve the result

Review the result against this specific requirement: a comparison of sanitized request, response, and documented contract that separates authentication, format, timing, and semantic mismatches. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Provider contracts and permissions can change. Use current official documentation; this prompt does not connect accounts or execute requests automatically.

Architecture and maintainabilityChoose a simple architecture

Purpose

Helps you produce two proportionate architecture options for the stated workload, with operational cost, failure modes, and reasons to avoid unnecessary components.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare two proportionate architecture options for the stated workload, with operational cost, failure modes, and reasons to avoid unnecessary components. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Compare a static site with a small server only when the feature needs server state.

Improve the result

Review the result against this specific requirement: two proportionate architecture options for the stated workload, with operational cost, failure modes, and reasons to avoid unnecessary components. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Architecture recommendations depend on actual workload and operating constraints. Validate assumptions with measurements rather than treating estimates as guarantees.

Architecture and maintainabilityDefine component boundaries

Purpose

Helps you produce a component boundary proposal separating responsibilities, interfaces, ownership of state, and dependency direction for the supplied system.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a component boundary proposal separating responsibilities, interfaces, ownership of state, and dependency direction for the supplied system. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Keep payment state ownership in one component and expose a clear interface.

Improve the result

Review the result against this specific requirement: a component boundary proposal separating responsibilities, interfaces, ownership of state, and dependency direction for the supplied system. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Architecture recommendations depend on actual workload and operating constraints. Validate assumptions with measurements rather than treating estimates as guarantees.

Architecture and maintainabilityPlan incremental refactoring

Purpose

Helps you produce a sequence of small refactoring steps preserving observable behavior, with characterization checks and safe stopping points after each step.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a sequence of small refactoring steps preserving observable behavior, with characterization checks and safe stopping points after each step. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Extract one pure function, verify behavior, then proceed to the next step.

Improve the result

Review the result against this specific requirement: a sequence of small refactoring steps preserving observable behavior, with characterization checks and safe stopping points after each step. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Architecture recommendations depend on actual workload and operating constraints. Validate assumptions with measurements rather than treating estimates as guarantees.

Architecture and maintainabilityReview dependency coupling

Purpose

Helps you produce a coupling review of the supplied modules identifying cycles, hidden shared state, and the smallest useful interface improvements.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a coupling review of the supplied modules identifying cycles, hidden shared state, and the smallest useful interface improvements. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Replace a circular module dependency with an explicit shared interface.

Improve the result

Review the result against this specific requirement: a coupling review of the supplied modules identifying cycles, hidden shared state, and the smallest useful interface improvements. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Architecture recommendations depend on actual workload and operating constraints. Validate assumptions with measurements rather than treating estimates as guarantees.

Architecture and maintainabilityDesign cache invalidation

Purpose

Helps you produce a cache design specifying keys, freshness requirements, invalidation triggers, stale-data behavior, and failure handling for the stated workload.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a cache design specifying keys, freshness requirements, invalidation triggers, stale-data behavior, and failure handling for the stated workload. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Invalidate a cached product record when its price changes, with defined stale behavior.

Improve the result

Review the result against this specific requirement: a cache design specifying keys, freshness requirements, invalidation triggers, stale-data behavior, and failure handling for the stated workload. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Architecture recommendations depend on actual workload and operating constraints. Validate assumptions with measurements rather than treating estimates as guarantees.

Architecture and maintainabilityEvaluate a queue design

Purpose

Helps you produce a queue design review covering delivery semantics, retries, poison messages, ordering, backpressure, and observability without claiming exactly-once execution casually.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a queue design review covering delivery semantics, retries, poison messages, ordering, backpressure, and observability without claiming exactly-once execution casually. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: A failed message reaches a bounded retry limit and an inspectable dead-letter queue.

Improve the result

Review the result against this specific requirement: a queue design review covering delivery semantics, retries, poison messages, ordering, backpressure, and observability without claiming exactly-once execution casually. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Architecture recommendations depend on actual workload and operating constraints. Validate assumptions with measurements rather than treating estimates as guarantees.

Architecture and maintainabilityWrite an architecture decision record

Purpose

Helps you produce a decision record grounded in the supplied context with options, constraints, chosen tradeoff, consequences, and a future reconsideration trigger.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a decision record grounded in the supplied context with options, constraints, chosen tradeoff, consequences, and a future reconsideration trigger. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Record why the simpler option meets current load and when to reconsider.

Improve the result

Review the result against this specific requirement: a decision record grounded in the supplied context with options, constraints, chosen tradeoff, consequences, and a future reconsideration trigger. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Architecture recommendations depend on actual workload and operating constraints. Validate assumptions with measurements rather than treating estimates as guarantees.

Architecture and maintainabilityPlan graceful degradation

Purpose

Helps you produce a degradation plan for the named dependency failure specifying essential behavior, disabled features, user messaging, and recovery criteria.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a degradation plan for the named dependency failure specifying essential behavior, disabled features, user messaging, and recovery criteria. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: If recommendations fail, preserve core browsing and explain temporary unavailability.

Improve the result

Review the result against this specific requirement: a degradation plan for the named dependency failure specifying essential behavior, disabled features, user messaging, and recovery criteria. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Architecture recommendations depend on actual workload and operating constraints. Validate assumptions with measurements rather than treating estimates as guarantees.

Architecture and maintainabilityReview configuration design

Purpose

Helps you produce a configuration design that separates safe defaults, environment settings, secrets, validation, and changes requiring restart.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a configuration design that separates safe defaults, environment settings, secrets, validation, and changes requiring restart. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Reject invalid required configuration at startup rather than failing mid-request.

Improve the result

Review the result against this specific requirement: a configuration design that separates safe defaults, environment settings, secrets, validation, and changes requiring restart. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Architecture recommendations depend on actual workload and operating constraints. Validate assumptions with measurements rather than treating estimates as guarantees.

Architecture and maintainabilityEstimate capacity with assumptions

Purpose

Helps you produce a rough capacity model from supplied traffic and resource measurements, showing assumptions, bottlenecks, uncertainty, and what must be load-tested.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a rough capacity model from supplied traffic and resource measurements, showing assumptions, bottlenecks, uncertainty, and what must be load-tested. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Show how doubled request volume affects the measured bottleneck under stated assumptions.

Improve the result

Review the result against this specific requirement: a rough capacity model from supplied traffic and resource measurements, showing assumptions, bottlenecks, uncertainty, and what must be load-tested. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Architecture recommendations depend on actual workload and operating constraints. Validate assumptions with measurements rather than treating estimates as guarantees.

Defensive security and privacyReview input validation

Purpose

Helps you produce a defensive review of the supplied input boundary identifying trusted versus untrusted data, validation rules, encoding, and rejection behavior.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a defensive review of the supplied input boundary identifying trusted versus untrusted data, validation rules, encoding, and rejection behavior. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Validate length and type before processing and encode output for its destination.

Improve the result

Review the result against this specific requirement: a defensive review of the supplied input boundary identifying trusted versus untrusted data, validation rules, encoding, and rejection behavior. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

This is a defensive review, not a security certification or legal opinion. Use sanitized inputs and validate controls with authorized tests.

Defensive security and privacyCheck authorization boundaries

Purpose

Helps you produce an authorization test matrix for the supplied roles and resources covering allowed access, denied access, and cross-user isolation.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an authorization test matrix for the supplied roles and resources covering allowed access, denied access, and cross-user isolation. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: A user may read their own record but must be denied another user's record.

Improve the result

Review the result against this specific requirement: an authorization test matrix for the supplied roles and resources covering allowed access, denied access, and cross-user isolation. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

This is a defensive review, not a security certification or legal opinion. Use sanitized inputs and validate controls with authorized tests.

Defensive security and privacyReview secret handling

Purpose

Helps you produce a review of the described secret lifecycle covering storage, access, rotation, logging, and revocation without requesting actual secret values.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a review of the described secret lifecycle covering storage, access, rotation, logging, and revocation without requesting actual secret values. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Describe rotation using a secret identifier, never by pasting the secret.

Improve the result

Review the result against this specific requirement: a review of the described secret lifecycle covering storage, access, rotation, logging, and revocation without requesting actual secret values. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

This is a defensive review, not a security certification or legal opinion. Use sanitized inputs and validate controls with authorized tests.

Defensive security and privacyCreate a threat model

Purpose

Helps you produce a bounded threat model for the supplied system identifying assets, trust boundaries, plausible misuse, mitigations, and residual risks.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a bounded threat model for the supplied system identifying assets, trust boundaries, plausible misuse, mitigations, and residual risks. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Treat uploaded documents as untrusted input crossing a defined boundary.

Improve the result

Review the result against this specific requirement: a bounded threat model for the supplied system identifying assets, trust boundaries, plausible misuse, mitigations, and residual risks. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

This is a defensive review, not a security certification or legal opinion. Use sanitized inputs and validate controls with authorized tests.

Defensive security and privacyMinimize collected data

Purpose

Helps you produce a data-minimization review of the supplied feature separating required data from optional data and proposing retention and access limits.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a data-minimization review of the supplied feature separating required data from optional data and proposing retention and access limits. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Remove date of birth when the feature only needs an age-range choice.

Improve the result

Review the result against this specific requirement: a data-minimization review of the supplied feature separating required data from optional data and proposing retention and access limits. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

This is a defensive review, not a security certification or legal opinion. Use sanitized inputs and validate controls with authorized tests.

Defensive security and privacyReview logging privacy

Purpose

Helps you produce a logging-field audit identifying sensitive values, useful diagnostic alternatives, redaction needs, and access restrictions.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a logging-field audit identifying sensitive values, useful diagnostic alternatives, redaction needs, and access restrictions. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Log a request identifier instead of a full authentication header.

Improve the result

Review the result against this specific requirement: a logging-field audit identifying sensitive values, useful diagnostic alternatives, redaction needs, and access restrictions. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

This is a defensive review, not a security certification or legal opinion. Use sanitized inputs and validate controls with authorized tests.

Defensive security and privacyPlan secure file uploads

Purpose

Helps you produce a defensive upload design covering allowed types, size limits, storage isolation, filename handling, scanning options, and download authorization.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a defensive upload design covering allowed types, size limits, storage isolation, filename handling, scanning options, and download authorization. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Store uploads outside executable paths and authorize each private download.

Improve the result

Review the result against this specific requirement: a defensive upload design covering allowed types, size limits, storage isolation, filename handling, scanning options, and download authorization. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

This is a defensive review, not a security certification or legal opinion. Use sanitized inputs and validate controls with authorized tests.

Defensive security and privacyReview dependency risk

Purpose

Helps you produce a review of supplied dependency inventory and advisories distinguishing affected versions, reachable functionality, remediation, and unverified exposure.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a review of supplied dependency inventory and advisories distinguishing affected versions, reachable functionality, remediation, and unverified exposure. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Match the installed version to an advisory before declaring the system affected.

Improve the result

Review the result against this specific requirement: a review of supplied dependency inventory and advisories distinguishing affected versions, reachable functionality, remediation, and unverified exposure. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

This is a defensive review, not a security certification or legal opinion. Use sanitized inputs and validate controls with authorized tests.

Defensive security and privacyPrepare a security incident checklist

Purpose

Helps you produce a defensive checklist for the stated incident covering evidence preservation, containment, access review, recovery, and communication responsibilities.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a defensive checklist for the stated incident covering evidence preservation, containment, access review, recovery, and communication responsibilities. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Preserve relevant logs before containment actions that could erase evidence.

Improve the result

Review the result against this specific requirement: a defensive checklist for the stated incident covering evidence preservation, containment, access review, recovery, and communication responsibilities. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

This is a defensive review, not a security certification or legal opinion. Use sanitized inputs and validate controls with authorized tests.

Defensive security and privacyReview privacy-sensitive exports

Purpose

Helps you produce an export review identifying personal fields, authorization checks, accidental extra rows, metadata exposure, and safe delivery requirements.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an export review identifying personal fields, authorization checks, accidental extra rows, metadata exposure, and safe delivery requirements. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Check tenant filtering so an export cannot include another customer's rows.

Improve the result

Review the result against this specific requirement: an export review identifying personal fields, authorization checks, accidental extra rows, metadata exposure, and safe delivery requirements. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

This is a defensive review, not a security certification or legal opinion. Use sanitized inputs and validate controls with authorized tests.

Operations and deploymentCreate a deployment checklist

Purpose

Helps you produce a deployment checklist for the supplied release including preflight checks, backup, staged rollout, health signals, and rollback criteria.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a deployment checklist for the supplied release including preflight checks, backup, staged rollout, health signals, and rollback criteria. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Require a healthy staged release before wider rollout and retain the previous version.

Improve the result

Review the result against this specific requirement: a deployment checklist for the supplied release including preflight checks, backup, staged rollout, health signals, and rollback criteria. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A written plan does not deploy, schedule, restore, or monitor anything. Execution requires authorized infrastructure access and verification of the actual result.

Operations and deploymentWrite a rollback plan

Purpose

Helps you produce a rollback plan distinguishing application, configuration, and data changes, with exact preconditions and cases where reversal loses information.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a rollback plan distinguishing application, configuration, and data changes, with exact preconditions and cases where reversal loses information. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Explain why reversing code cannot automatically undo a destructive data migration.

Improve the result

Review the result against this specific requirement: a rollback plan distinguishing application, configuration, and data changes, with exact preconditions and cases where reversal loses information. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A written plan does not deploy, schedule, restore, or monitor anything. Execution requires authorized infrastructure access and verification of the actual result.

Operations and deploymentReview a container build

Purpose

Helps you produce a review of the supplied container definition covering reproducibility, unnecessary layers, runtime privileges, secrets, and health behavior.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a review of the supplied container definition covering reproducibility, unnecessary layers, runtime privileges, secrets, and health behavior. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Use a limited runtime user and keep build credentials out of image layers.

Improve the result

Review the result against this specific requirement: a review of the supplied container definition covering reproducibility, unnecessary layers, runtime privileges, secrets, and health behavior. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A written plan does not deploy, schedule, restore, or monitor anything. Execution requires authorized infrastructure access and verification of the actual result.

Operations and deploymentDesign useful monitoring

Purpose

Helps you produce a monitoring plan connecting user-visible failures to metrics, logs, alerts, thresholds, ownership, and actionable response steps.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a monitoring plan connecting user-visible failures to metrics, logs, alerts, thresholds, ownership, and actionable response steps. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Alert on sustained user-facing errors with an owner and a response action.

Improve the result

Review the result against this specific requirement: a monitoring plan connecting user-visible failures to metrics, logs, alerts, thresholds, ownership, and actionable response steps. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A written plan does not deploy, schedule, restore, or monitor anything. Execution requires authorized infrastructure access and verification of the actual result.

Operations and deploymentReduce alert noise

Purpose

Helps you produce an analysis of supplied alert history separating actionable incidents from duplicates and proposing grouping, suppression, and escalation rules.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare an analysis of supplied alert history separating actionable incidents from duplicates and proposing grouping, suppression, and escalation rules. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Group repeated alerts for the same outage while preserving a recovery notification.

Improve the result

Review the result against this specific requirement: an analysis of supplied alert history separating actionable incidents from duplicates and proposing grouping, suppression, and escalation rules. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A written plan does not deploy, schedule, restore, or monitor anything. Execution requires authorized infrastructure access and verification of the actual result.

Operations and deploymentVerify backup restoration

Purpose

Helps you produce a restore-test procedure in an isolated environment with integrity checks, access validation, recovery timing, and documented gaps.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a restore-test procedure in an isolated environment with integrity checks, access validation, recovery timing, and documented gaps. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Restore to an isolated target and verify both data counts and usable access.

Improve the result

Review the result against this specific requirement: a restore-test procedure in an isolated environment with integrity checks, access validation, recovery timing, and documented gaps. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A written plan does not deploy, schedule, restore, or monitor anything. Execution requires authorized infrastructure access and verification of the actual result.

Operations and deploymentPlan a scheduled job safely

Purpose

Helps you produce a job design covering time zone, overlap prevention, idempotency, retries, missed runs, and completion evidence without claiming it is scheduled.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a job design covering time zone, overlap prevention, idempotency, retries, missed runs, and completion evidence without claiming it is scheduled. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Use a lock to prevent overlap and record success only after the work completes.

Improve the result

Review the result against this specific requirement: a job design covering time zone, overlap prevention, idempotency, retries, missed runs, and completion evidence without claiming it is scheduled. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A written plan does not deploy, schedule, restore, or monitor anything. Execution requires authorized infrastructure access and verification of the actual result.

Operations and deploymentAnalyze a production incident timeline

Purpose

Helps you produce a timeline from supplied logs separating observed events, inferred causes, missing evidence, and corrective actions without assigning unsupported blame.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a timeline from supplied logs separating observed events, inferred causes, missing evidence, and corrective actions without assigning unsupported blame. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Mark the first observed error time separately from the inferred start of the cause.

Improve the result

Review the result against this specific requirement: a timeline from supplied logs separating observed events, inferred causes, missing evidence, and corrective actions without assigning unsupported blame. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A written plan does not deploy, schedule, restore, or monitor anything. Execution requires authorized infrastructure access and verification of the actual result.

Operations and deploymentReview infrastructure changes

Purpose

Helps you produce a review of the supplied infrastructure diff identifying resource changes, access effects, cost implications, and rollback requirements.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a review of the supplied infrastructure diff identifying resource changes, access effects, cost implications, and rollback requirements. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Identify a permission expansion and its exact resource scope before applying it.

Improve the result

Review the result against this specific requirement: a review of the supplied infrastructure diff identifying resource changes, access effects, cost implications, and rollback requirements. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A written plan does not deploy, schedule, restore, or monitor anything. Execution requires authorized infrastructure access and verification of the actual result.

Operations and deploymentDesign a health endpoint

Purpose

Helps you produce a health-check contract distinguishing liveness and readiness, bounded dependency checks, safe diagnostic detail, and failure status behavior.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a health-check contract distinguishing liveness and readiness, bounded dependency checks, safe diagnostic detail, and failure status behavior. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Liveness remains healthy during a temporary dependency failure while readiness reflects impact.

Improve the result

Review the result against this specific requirement: a health-check contract distinguishing liveness and readiness, bounded dependency checks, safe diagnostic detail, and failure status behavior. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

A written plan does not deploy, schedule, restore, or monitor anything. Execution requires authorized infrastructure access and verification of the actual result.

Documentation and developer workflowWrite a setup guide from evidence

Purpose

Helps you produce a setup guide using only supplied verified commands and prerequisites, with expected outputs, troubleshooting, and explicit untested steps.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a setup guide using only supplied verified commands and prerequisites, with expected outputs, troubleshooting, and explicit untested steps. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Label an unexecuted install command as untested and include its expected result.

Improve the result

Review the result against this specific requirement: a setup guide using only supplied verified commands and prerequisites, with expected outputs, troubleshooting, and explicit untested steps. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Documentation can become stale and code review cannot prove correctness. Mark unexecuted commands and unverified behavior explicitly.

Documentation and developer workflowCreate a concise pull-request description

Purpose

Helps you produce a pull-request description stating the concrete problem, resulting behavior, scope, validation evidence, and remaining limitations.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a pull-request description stating the concrete problem, resulting behavior, scope, validation evidence, and remaining limitations. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Describe the trigger, corrected behavior, and the specific test that passed.

Improve the result

Review the result against this specific requirement: a pull-request description stating the concrete problem, resulting behavior, scope, validation evidence, and remaining limitations. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Documentation can become stale and code review cannot prove correctness. Mark unexecuted commands and unverified behavior explicitly.

Documentation and developer workflowReview a code diff

Purpose

Helps you produce a prioritized review of the supplied diff focused on correctness, regressions, security, and maintainability, with exact evidence for each finding.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a prioritized review of the supplied diff focused on correctness, regressions, security, and maintainability, with exact evidence for each finding. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Tie a regression concern to the changed line and a concrete failing scenario.

Improve the result

Review the result against this specific requirement: a prioritized review of the supplied diff focused on correctness, regressions, security, and maintainability, with exact evidence for each finding. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Documentation can become stale and code review cannot prove correctness. Mark unexecuted commands and unverified behavior explicitly.

Documentation and developer workflowDocument a public function

Purpose

Helps you produce function documentation specifying parameters, return values, exceptions, side effects, and a realistic usage example consistent with the supplied code.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare function documentation specifying parameters, return values, exceptions, side effects, and a realistic usage example consistent with the supplied code. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Document whether the function mutates its input and how errors are returned.

Improve the result

Review the result against this specific requirement: function documentation specifying parameters, return values, exceptions, side effects, and a realistic usage example consistent with the supplied code. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Documentation can become stale and code review cannot prove correctness. Mark unexecuted commands and unverified behavior explicitly.

Documentation and developer workflowPrepare a bug report

Purpose

Helps you produce a reproducible bug report with environment, steps, expected behavior, actual behavior, minimal evidence, and impact without speculation presented as fact.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a reproducible bug report with environment, steps, expected behavior, actual behavior, minimal evidence, and impact without speculation presented as fact. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Include exact reproduction steps and sanitized error text, not an assumed cause.

Improve the result

Review the result against this specific requirement: a reproducible bug report with environment, steps, expected behavior, actual behavior, minimal evidence, and impact without speculation presented as fact. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Documentation can become stale and code review cannot prove correctness. Mark unexecuted commands and unverified behavior explicitly.

Documentation and developer workflowWrite a maintenance handoff

Purpose

Helps you produce a handoff documenting current behavior, important files, verified checks, known issues, operational dependencies, and the next safe action.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a handoff documenting current behavior, important files, verified checks, known issues, operational dependencies, and the next safe action. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Record the last verified version, open issue, and the next non-destructive check.

Improve the result

Review the result against this specific requirement: a handoff documenting current behavior, important files, verified checks, known issues, operational dependencies, and the next safe action. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Documentation can become stale and code review cannot prove correctness. Mark unexecuted commands and unverified behavior explicitly.

Documentation and developer workflowExplain a technical change to users

Purpose

Helps you produce a user-facing release note explaining the practical change, who is affected, required action, and known limitations without internal implementation clutter.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a user-facing release note explaining the practical change, who is affected, required action, and known limitations without internal implementation clutter. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Explain that saved filters now persist and whether users need to refresh.

Improve the result

Review the result against this specific requirement: a user-facing release note explaining the practical change, who is affected, required action, and known limitations without internal implementation clutter. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Documentation can become stale and code review cannot prove correctness. Mark unexecuted commands and unverified behavior explicitly.

Documentation and developer workflowCreate a troubleshooting decision tree

Purpose

Helps you produce a troubleshooting tree ordered by safe observable checks, with stop conditions, escalation evidence, and no destructive first steps.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a troubleshooting tree ordered by safe observable checks, with stop conditions, escalation evidence, and no destructive first steps. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Check service status before suggesting configuration changes or data deletion.

Improve the result

Review the result against this specific requirement: a troubleshooting tree ordered by safe observable checks, with stop conditions, escalation evidence, and no destructive first steps. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Documentation can become stale and code review cannot prove correctness. Mark unexecuted commands and unverified behavior explicitly.

Documentation and developer workflowAudit documentation drift

Purpose

Helps you produce a comparison of supplied documentation and code identifying outdated commands, renamed fields, missing behavior, and claims requiring runtime verification.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a comparison of supplied documentation and code identifying outdated commands, renamed fields, missing behavior, and claims requiring runtime verification. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Flag a documented command that no longer exists in the supplied package scripts.

Improve the result

Review the result against this specific requirement: a comparison of supplied documentation and code identifying outdated commands, renamed fields, missing behavior, and claims requiring runtime verification. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Documentation can become stale and code review cannot prove correctness. Mark unexecuted commands and unverified behavior explicitly.

Documentation and developer workflowCreate an onboarding code tour

Purpose

Helps you produce a newcomer-oriented tour of the supplied repository identifying entry points, core workflows, tests, configuration, and a safe first task.

How to use it

Replace both fields. Paste the relevant sanitized code, configuration, logs, measurements, or official documentation, including versions. Attach files only if uploads are available. Do not include secrets or private production data.

Your ready-to-copy prompt

Use this technical context: {{context}}
My goal and constraints: {{constraints}}

Prepare a newcomer-oriented tour of the supplied repository identifying entry points, core workflows, tests, configuration, and a safe first task. Ask for essential missing details before assuming them. Distinguish observed evidence from hypotheses. Keep proposed changes within scope. Label code, commands, and tests as unexecuted unless you actually run them with available authorized tools, and report the evidence of any execution.

Make it your own

Source material and context: Paste the relevant sanitized code or system details and exact versions here.
Goal, level, and constraints: State the desired behavior, target environment, and changes that are out of scope.

What a successful result should contain

Illustrative successful-result example: Start with the app entry point, follow one request, and locate its test.

Improve the result

Review the result against this specific requirement: a newcomer-oriented tour of the supplied repository identifying entry points, core workflows, tests, configuration, and a safe first task. Ask for a revision of any missing part, and compare claims with your supplied source.

Limits & checks

Documentation can become stale and code review cannot prove correctness. Mark unexecuted commands and unverified behavior explicitly.

Explore by task

Start here

Your prompt library

Purpose

How to use it

Your ready-to-copy prompt

Make it your own

What a successful result should contain

Improve the result

Limits & checks

Purpose

How to use it

Your ready-to-copy prompt

Make it your own

What a successful result should contain

Improve the result

Limits & checks

Purpose

How to use it

Your ready-to-copy prompt

Make it your own

What a successful result should contain

Improve the result

Limits & checks

Purpose

How to use it

Your ready-to-copy prompt

Make it your own

What a successful result should contain

Improve the result

Limits & checks

Purpose

How to use it

Your ready-to-copy prompt

Make it your own

What a successful result should contain

Improve the result

Limits & checks

Purpose

How to use it

Your ready-to-copy prompt

Make it your own

What a successful result should contain

Improve the result

Limits & checks

Purpose

How to use it

Your ready-to-copy prompt

Make it your own

What a successful result should contain

Improve the result

Limits & checks

Purpose

How to use it

Your ready-to-copy prompt

Make it your own

What a successful result should contain

Improve the result

Limits & checks

Purpose

How to use it

Your ready-to-copy prompt

Make it your own

What a successful result should contain

Improve the result

Limits & checks

Purpose

How to use it

Your ready-to-copy prompt

Make it your own

What a successful result should contain

Improve the result

Limits & checks

Purpose

How to use it

Your ready-to-copy prompt

Make it your own

What a successful result should contain

Improve the result