Rendered documentation

Prompt Pattern Matrix

Use this matrix to decide which research control belongs in which asset. The matrix is intentionally practical: it maps prompt engineering research into rev…

Use this matrix to decide which research control belongs in which asset. The matrix is intentionally practical: it maps prompt-engineering research into reviewable behaviours.

PatternBest forBehaviour requiredEvidence expectedFailure it prevents
Chain-of-Thought summaryComplex reasoning, planning, auditsConcise public rationale and assumptionsDecision summary, assumption list, evidence tableFluent final answers with no visible reasoning artefacts
Tree-of-ThoughtsArchitecture, UI strategy, remediation choicesCompare multiple candidate branchesRejected branch, selected branch, trade-offAnchoring on first plausible solution
ReActCoding, debugging, UI review, repository inspectionObserve → act → observe loopFiles inspected, commands run, screenshots, logsHallucinated environment state
Least-to-MostLarge implementation tasksDecompose into ordered subproblemsSubtask checklist with statusBig-bang changes and hidden scope creep
Self-ConsistencyVerification and release claimsCross-check independent evidence routesSource + command + behaviour + docs comparisonTrusting one lucky passing signal
ReflexionFailed tests, debugging, remediationTurn failed feedback into a correction noteFailure log and second attempt rationaleRepeating the same error after feedback
System 2 forcingHigh-risk review and final answerSlow checklist, uncertainty labels, premortemPremortem, risk list, final statusCompletion bias and premature closure
TraceabilityContracts, release, complianceMap every claim to a requirement and verifierRequirement → artefact → evidence → statusUnsupported acceptance and hallucinated features

Minimum pattern stack by task

  1. Any coding task: ReAct + Least-to-Most + Traceability.
  2. Bug fix: ReAct + Reflexion + Self-Consistency + Traceability.
  3. UI review: ReAct + Self-Consistency + Traceability + System 2 forcing.
  4. Accessibility remediation: ReAct + Traceability + Self-Consistency + Standards mapping.
  5. Architecture or refactor: Tree-of-Thoughts + Least-to-Most + Premortem + Traceability.
  6. Release claim: Self-Consistency + Traceability + System 2 forcing + Premortem.
  7. Security or privacy: Premortem + Traceability + ReAct + Self-Consistency.
  8. Documentation truthfulness: ReAct + Traceability + Self-Consistency.
  9. Template writing: Chain-of-Thought summary + Tree-of-Thoughts + Traceability.
  10. Final merge gate: All controls, with extra weight on evidence and rejection clauses.

Required phrasing standard

Use evidence-facing phrasing:

  • Good: “I inspected path, ran command, observed result, and the remaining unverified area is x. Final status: partially verified.”
  • Bad: “I reasoned through it and everything should work.”

Use branch-aware phrasing:

  • Good: “I considered A and B. A was rejected because it changes shared behaviour. B was selected because it satisfies the requirement with lower regression risk.”
  • Bad: “I picked the simplest approach.”

Use traceability phrasing:

  • Good: “Requirement → file → command/manual check → status.”
  • Bad: “Feature complete.”