Turn a bug report into ranked hypotheses, a minimal reproduction, and diagnostics that distinguish causes before proposing a fix.
No public result for version 1 yet
Version 1 · 4 variables · 4 required
Fill in the values below — the customized prompt updates as you type. marks a required value.
Runtime, framework versions, deployment context, and relevant recent changes. Default: Python 3.12; a checkout service; the percentage-discount helper changed yesterday.
A concrete input with expected and actual behavior, including frequency. Default: A 15% discount on a price of 100 should return 85, but the helper returns 15.
Relevant source code, stack trace, or sanitized logs. Default: def discounted_price(price, percent): return price * percent / 100
Checks already performed and their observed results. Default: Confirmed the caller passes price=100 and percent=15. No other diagnostics performed.
Help investigate this software bug using only the evidence supplied.
Environment and recent changes:
Python 3.12; a checkout service; the percentage-discount helper changed yesterday.
Expected versus observed behavior:
A 15% discount on a price of 100 should return 85, but the helper returns 15.
Relevant code, logs, or stack trace:
def discounted_price(price, percent):
return price * percent / 100
Attempts already made:
Confirmed the caller passes price=100 and percent=15. No other diagnostics performed.
Produce:
1. A concise bug summary, separating observed facts, assumptions, and missing information.
2. Up to four plausible causes, ranked by how well the evidence supports them. For each, give supporting evidence, contrary evidence, and one observation that would distinguish it from the alternatives. Do not assign invented probabilities.
3. The smallest reproduction procedure supported by the inputs, with required setup, exact actions, and an observable failure condition. Mark unverified steps.
4. An ordered diagnostic plan, starting with cheap, non-destructive checks. State what to inspect or instrument, the expected observation under each hypothesis, and what the result would imply. Use exact commands only when the environment supports them; avoid logging credentials or personal data.
5. A focused fix candidate only if the evidence justifies one, plus a regression test with expected behavior. Otherwise request the single most useful missing result.
Do not label a root cause confirmed or a fix successful without corresponding evidence. Keep unrelated refactoring out of the proposal. End with a short record of what remains unverified.No public examples yet for version 1
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Curated prompt only. No example output or model test is attached; model compatibility has not been verified. Default inputs are illustrative practice material; replace them with your own facts and context.
Reports go to moderators and are never shown publicly.
No public results yet
Break a dependency replacement into reviewable stages with compatibility checks, exit criteria and realistic rollback limits.
No public results yet
Define realistic traffic, workload data, measurements and stopping rules for an authorized performance test.
No public results yet
Find source-visible labeling, semantics and keyboard risks, while separating code findings from checks that require a browser.
No public results yet
Map feature assets, trust boundaries and data flows to concrete threats, existing controls and targeted verification tasks.
No public results yet
Turn an API contract into a small client design that handles retryable failures, deadlines and idempotency deliberately.
No public results yet
Interpret supplied plan evidence and prioritize query or index experiments without inventing costs or speedups.
Oldest first · one level of replies
Sign in to join the discussion. Share what you learned or made with this prompt.
No comments yet
Be the first to share how this prompt worked for you.