Prompt Pattern Checker

Review rules

• Manual step-by-step reasoning instructionReview

  Current reasoning models usually do their own internal reasoning. Asking them to think, reason, or solve step by step can add noise when what you really need is a clear answer or a specific verification check.

  Try instead: Ask for the result plus the evidence you need to trust it: assumptions, checks performed, caveats, or a short rationale.

  May be fine when: Useful for teaching, worked examples, proofs, math tutoring, or any task where the step sequence is the deliverable.

• "Take a deep breath" prompting trickReview

  This was a popular trick for older models. It is not a reliable control for modern reasoning depth.

  Try instead: State the actual quality bar: the decision criteria, verification target, or level of care needed.

  May be fine when: Fine as tone in a casual chat, but it should not be treated as the part that improves the answer.

• Request for hidden chain-of-thoughtReview

  Modern reasoning guidance favors concise answers, assumptions, and summaries over exposing hidden chain-of-thought. Full private reasoning transcripts are not the same thing as useful evidence.

  Try instead: Ask for a concise rationale, assumptions, uncertainty, or the checks that were performed.

  May be fine when: A visible worked solution is appropriate for tutoring or proofs when the reasoning itself is the thing being taught.

• Plan gate before ordinary workReview

  A plan gate is useful for risky multi-file or high-impact work. As a default for small tasks, it can turn a simple request into unnecessary ceremony.

  Try instead: For small tasks, give the goal, boundaries, and verification path. For risky work, explicitly ask for read-only planning and approval before edits.

  May be fine when: Appropriate for architecture, security, billing, data migration, legal, or other work where approval before action matters.

• Reasoning effort written into prompt textAPI setting

  Reasoning depth is a model or API setting on platforms that expose it. Writing "Reasoning Effort Level: HIGH" inside the prompt body does not set that control.

  Try instead: Set the provider parameter or GUI effort control when available. Use prompt text for the task, constraints, and output requirements.

  May be fine when: Reasonable in internal documentation when you are describing which API setting to use, not when pasted as the prompt body.

• Invented-expertise persona boilerplateReview

  Long persona setup often adds length without adding much control. Models respond more reliably to audience, task, format, examples, and constraints.

  Try instead: Keep role context only when it changes the work. Replace status claims with concrete requirements.

  May be fine when: A short role can help when it supplies real domain context, such as "act as a tax reviewer" for a tax-specific review.

• Forced numeric self-scoringReview

  A model scoring its own answer from 1 to 10 is not a strong verification method. It can create a false sense of precision.

  Try instead: Ask for a check against named criteria, edge cases, tests, or source evidence.

  May be fine when: Numeric ratings can be useful for subjective triage if the rating is not treated as proof.

• "On a scale of X to Y" framingReview

  Arbitrary rating scales are easy to produce and hard to calibrate.

  Try instead: Ask for categories tied to observable criteria: low/medium/high risk, reversible/not reversible, source-backed/unsupported.

  May be fine when: A scale can work when you define each point clearly and use it for rough sorting, not final judgment.

• Requested numeric confidence scoreReview

  A model-reported confidence number is not a reliable calibration signal by itself.

  Try instead: Ask what the model is unsure about, what evidence is missing, and what would change the answer.

  May be fine when: Useful only as a rough internal triage field when paired with reasons and missing-evidence notes.

• Hand-scripted self-reflection ritualReview

  Evaluate, critique, revise, and re-score loops can make prompts longer without adding a concrete quality bar.

  Try instead: Give the model the criteria that matter and ask it to check the final answer against those criteria.

  May be fine when: Can be useful for writing workshops or educational settings where the reflection process is the output.

• "Explain like I am five" shortcutReview

  ELI5 is a rough proxy for calibration. It can remove useful detail when the learner is not actually a child.

  Try instead: State your real background and what the explanation should help you do.

  May be fine when: Fine when you truly want a child-level analogy or a first-pass simplification.

• Prefilled response trick for formattingFormat risk

  Ending the prompt with "Here is the JSON:" or similar is a brittle way to force a format when many platforms now provide schema or structured-output features.

  Try instead: Use the provider structured-output, JSON schema, or tool-calling feature when available. Put extraction rules in the prompt and the schema in the request.

  May be fine when: Sometimes acceptable in a plain chat UI with no schema control, but validate the output before using it.

• Shouted emphasisReview

  All-caps emphasis can make prompts brittle and overbearing. Clear hierarchy and precise conditions usually work better.

  Try instead: Use normal sentence case and state the trigger condition directly.

  May be fine when: One short warning may be fine in a long operational prompt, especially when it protects a real safety or data-loss boundary.

• Large set of examplesReview

  Examples are powerful, but large similar sets can teach accidental patterns. A smaller, varied set is usually easier to audit.

  Try instead: Start with 1-3 strong examples. Add more only when they cover genuinely different cases.

  May be fine when: Useful for classification, extraction, or style transfer when each example covers a real edge case.