Prompt engineering for product systems

Use before writing a long prompt or selecting a model.

You are helping [TEAM] make [DECISION] for [AUDIENCE]. The decision matters because [CONSEQUENCE]. Your job is to [ACTION]. Use [APPROVED CONTEXT]. Return [OUTPUT SHAPE] with [LENGTH OR DETAIL]. If the context is insufficient, list what is missing instead of guessing.

Output: A reusable job contract with clear missing-context behavior.

Guardrails: Name the decision before the task · Do not guess when context is missing

Use when factual accuracy, attribution, or decision quality matters.

Use only the approved context below. Separate the response into: Known, Inferred, Missing, and Recommended next step. Quote or link only evidence present in the context. If two sources conflict, show the conflict and do not silently choose a winner.

Approved context:
[PASTE SOURCES]
Question or decision:
[PASTE QUESTION]

Output: An attributable answer that separates evidence from inference.

Guardrails: No invented citations · Conflicts remain visible · Unknowns are explicit

Use when consistency matters more than a one-off answer.

Follow the output pattern shown in the examples. Preserve the same headings, level of detail, and decision labels. Do not copy facts from the examples into the new answer.

Example 1 input:
[INPUT]
Example 1 output:
[OUTPUT]

Example 2 input:
[INPUT]
Example 2 output:
[OUTPUT]

New input:
[INPUT]

Return only the requested output shape and flag any missing field.

Output: A consistent output that follows the demonstrated contract.

Guardrails: Examples teach structure, not facts · Missing fields are not filled with guesses

Use for complex work that needs a reliable sequence without exposing hidden reasoning.

Break this task into a short sequence of observable checks. For each check, state the input needed, the expected artifact, and the pass/fail rule. Then produce the final answer using only artifacts that pass. Do not provide private chain-of-thought; provide concise rationale, evidence, and the checks a reviewer can reproduce.

Task:
[PASTE TASK]
Constraints:
[PASTE CONSTRAINTS]

Output: A final answer backed by reproducible checks.

Guardrails: Use observable checks instead of hidden reasoning · Stop when a required check fails

Use before connecting a prompt to tools, customer data, budgets, or production systems.

You may suggest options and draft artifacts. You may read only [APPROVED SOURCES]. You may call [READ-ONLY TOOLS]. You may not publish, spend budget, contact a customer, change production systems, or execute a write action without explicit approval from [ROLE]. When a request exceeds the boundary, explain why, return a safe draft, and identify the approver.

Output: A clear read, draft, write, and escalation policy.

Guardrails: Default to least privilege · Separate draft from execute · Escalate ambiguous authority

Use when a prompt is ready to be tested across representative and adversarial cases.

Create a compact evaluation plan for this prompt or agent. Include five representative inputs, two edge cases, one missing-context case, and one prompt-injection or unsafe request. Define expected behavior, unacceptable behavior, reviewer rubric, telemetry, and recovery action. Recommend which failures block release and which become monitored follow-ups.

Prompt or workflow:
[PASTE PROMPT]
Tools and data:
[PASTE TOOLS AND DATA]

Output: A release gate with test cases, rubric, telemetry, and recovery.

Guardrails: Test unsafe and ambiguous inputs · Evaluate observable behavior, not hidden reasoning

Use when a generic prompt needs to become a reusable PodLabsTech playbook.

Adapt the prompt below for [SERVICE]. Preserve the decision it supports, then add the service-specific inputs, vocabulary, risks, output schema, human review, and success metric. Return: purpose, when to use, required context, prompt template with variables, example input, expected output, failure modes, and evaluation checklist.

Base prompt:
[PASTE PROMPT]
Service context:
[PASTE SERVICE CONTEXT]

Output: A service-ready prompt playbook.

Guardrails: Keep the original decision visible · Do not add unsupported claims or capabilities