Prompts Resources

Choosing and checking a resource

A prompt is an input to a language model, not a program that supplies its own facts. Choose a listing by the task and inspect its complete text before use. The examples discussed below concern architecture decisions, SQL review, event design, incident review and TypeScript migration. Each needs different evidence and a different human owner; a polished answer from one cannot replace the others.

Before pasting anything into a model, write down the question you need answered and the decision that will follow. Gather only the relevant, current source material. Mark which statements are verified, which are assumptions and which are unknown. If a required fact is missing, ask the responsible person or system rather than asking a model to fill the gap with a plausible guess.

For an architecture decision record, supply the actual problem, constraints, credible alternatives and criteria. Ask the draft to preserve unknown costs and unverified approvals as questions. The person who owns the decision must accept it. A generated recommendation is not an approval, and an ADR outline does not demonstrate that implementation follows the chosen design.

For SQL review, identify the database engine and version, intended result, sanitized schema, representative values and plan evidence. Keep estimated plan cost separate from elapsed time. A suggested index has storage and write consequences. Measure a candidate with representative data and protect production from statements that execute or mutate records. A prompt cannot connect to the database or measure a query on your behalf.

For event architecture, name producers, consumers, transaction boundaries, ordering requirements and user-visible completion states. Explain how retries, duplicates, stale events and failed side effects are handled. Terms such as exactly once need a specific system-level definition. A prompt can surface these questions but cannot create durable idempotency, an outbox publisher or broker configuration.

For an incident review, give a timestamped evidence timeline and separate observation from hypothesis. Include timezone, impact source and known telemetry gaps. Ask the model to keep cause unknown when sources do not establish it. Verify any calculated duration against agreed start and end criteria; arithmetic cannot determine when users first experienced impact or when service was restored.

For a TypeScript migration, describe the installed compiler, current options, callers and runtime input contract. Types do not validate data arriving over a network. Check public declarations and old accepted inputs before narrowing a type. A prompt that asks to remove every any cannot prove compatibility or preserve behavior automatically.

Use synthetic examples when testing a prompt. State expected outcomes before generating, including an invalid and a boundary case. Compare the response with those outcomes and inspect each material factual statement against its source. A model may omit an important limitation even when the answer reads smoothly. Save the input version, provider settings and reviewed result if the output informs a consequential change.

Do not include credentials, customer records, confidential incidents or private source code unless the selected provider and organizational process permit that data. Review provider retention and training settings rather than assuming that a prompt is private. Remove identifiers from examples and verify that redaction does not erase information needed to reason about the problem.

Treat output as a draft. A technical owner should validate framework behavior, database plans, reliability constraints and API contracts. Security, privacy or legal questions may need their designated reviewers. The prompt author is not an expert credential, and a generated answer is not independent verification. Keep the final approval with the person responsible for the system.

When an answer invents a fact, identify the exact sentence and its unsupported assumption. Correct the input with a source or mark the fact unknown, then regenerate only if useful. Do not patch an error by adding a more forceful instruction while leaving the missing evidence unresolved. Retain the failed example when it reveals a reusable limitation.

Compare alternatives fairly. Ask the model to state why an option meets each supplied criterion and what evidence is missing. Request material costs, failure modes and operational work along with benefits. If the output ranks choices without using the supplied criteria, disregard the ranking and make the comparison explicit before relying on it.

Check that prompt instructions do not conflict with the task or with the system that will receive them. A generic request for a concise answer can hide necessary uncertainty; a request for exhaustive detail can produce filler. Tune the instruction to the actual deliverable, then review clarity, evidence and the action the reader should take.

If a listing refers to a package, tool, expert persona or automated capability, inspect whether the downloaded files actually supply it. The entries discussed in this guide are AI-generated text templates; they do not bundle an optimizer, queue implementation, incident data source, compiler migration tool or decision approval system. Compatibility labels indicate intended use, not a test result.

Keep redistribution terms distinct from the terms of named software. The SimplyUtils AI-generated template terms have not been verified. A link to official documentation provides context for a factual claim but does not license copied material. Check upstream source and rights before republishing code, examples, tables or substantial prose.

For a useful failure report, provide the resource URL, prompt version, redacted input, expected behavior and the exact unsupported or missing output. Include the model/provider only when relevant and safe to share. Never attach a token or production transcript. A small reproducible case helps improve the guide without exposing private material.

After an output leads to a code or policy change, use the normal review and test process for that change. Record what was actually measured, what remains uncertain and who accepted the result. Revisit the prompt when the referenced framework, database or organizational process changes. A past useful response does not establish current correctness.

Search by a concrete task phrase and clear filters when no entries appear. Read the full description and guide before downloading; title similarity alone is not evidence that two resources are interchangeable. This directory helps discover text examples. It does not execute, install, benchmark or verify a generated response.

The goal of a good prompt is to make the evidence and open questions easier to inspect. It should narrow the task, preserve uncertainty and make review practical. It should not manufacture credentials, results or certainty. Keep decisions and system changes accountable to people who can inspect the underlying sources and consequences.

• Architecture Source Review Prompt - An architecture-review prompt with an original finite-number example and source-checking limits. It cannot guarantee factual accuracy.
• ADR Writing Prompt Guide - AI-generated prompt guide for drafting decision records from supplied evidence; approval remains with the decision owner.
• Incident Review Prompt Guide - AI-generated prompt guide for evidence-based incident timelines; it cannot establish root cause or recovery.
• SQL Plan Review Prompt Guide - AI-generated prompt guide for query semantics and plan evidence; it does not connect to or benchmark a database.
• TypeScript Migration Prompt Guide - AI-generated prompt guide for boundary contracts and compiler review; it cannot prove runtime safety.
• Event Design Prompt Guide - AI-generated prompt guide for event requirements and failure cases; it does not implement a broker or outbox.