Prompt Engineering Guide for Daily Work

Operational prompting patterns for daily work with explicit evidence boundaries, verification, and fail-closed behavior.

Purpose

This guide converts daily prompting from a single generic request into a controlled workflow. It separates source-bound work, public-source verification, and final-answer checks so the prompt, files, tools, and verification rules match the task.

When to use this

Use this section to decide whether this workflow is the right fit before you configure prompts, policies, or reference material.

Use case
The task depends on provided material
Use this when the answer must stay inside files, notes, logs, screenshots, threads, code, or excerpts supplied in the current task.
Use case
The task needs current or public facts
Use this when the answer depends on external facts, official documentation, public sources, citations, or web verification.
Use case
The input is long or easy to skip
Use this when the assistant must explicitly read, scan, and report coverage for long documents, repositories, threads, or multi-file inputs.
Use case
The output needs stricter final checks
Use this when the answer must avoid unsupported agreement, weak evidence, terminology drift, or unreported uncertainty.

Decision guide

Choose the daily-work prompt setup

Select the evidence boundary first. Then open the matching prompt stack or final-check workflow.

Option 1 · Provided material only
Work only from provided material
Use this when the answer must be grounded only in supplied files, logs, screenshots, code, notes, or pasted material.
Evidence boundary: Provided material only; no external lookup, memory-based claims, or inferred project state.
Best for: Summaries, extraction, classification, file review, repository review, and artifact-bound answers.
Use when: The task is about material supplied in the current request.
Open ready-made stacks
Option 2 · Public-source verification
Verify public claims before answering
Use this when the answer depends on current, external, official, or public facts that must be checked and cited.
Evidence boundary: Authoritative public sources plus any supplied material that is explicitly allowed.
Best for: Current facts, official documentation, product behavior, standards, citations, and public-source claim checks.
Use when: The task cannot be answered safely from provided material alone.
Open ready-made stacks
Option 3 · Final checks
Run final answer checks
Use this before sending an answer when the draft needs evidence, terminology, uncertainty, and unsupported-agreement checks.
Evidence boundary: The already selected evidence boundary remains active; final checks do not add new sources by default.
Best for: Reducing automatic agreement, unsupported conclusions, wording drift, and missing confidence reporting.
Use when: The draft answer exists but needs an acceptance check before reuse, publication, or delivery.
Open ready-made stacks

Workflow assets

Required workflow assets

Open the prompts, policies, and reference pages needed to run this workflow correctly.

Optional prompt
Read all provided artifacts first
Use when a daily-work task depends on supplied files, logs, screenshots, documents, code, or pasted material.
Type: Prompt component
Belongs in: Runtime prompt layer
Open prompt
Optional prompt
Deep search
Use when the answer depends on public or current information and needs source retrieval before answering.
Type: Prompt component
Belongs in: Runtime prompt layer
Open prompt
Optional prompt
Confidence score
Use when the answer needs an explicit evidence-based confidence line before acceptance.
Type: Prompt component
Belongs in: Verification layer
Open prompt
Optional policy
Facts-only: artifacts only
Use when the answer must stay inside provided material only.
Type: Evidence-boundary policy
Controls: Provided-material boundary, no external sources, and missing-evidence handling.
Read policy
Optional policy
Facts-only: authoritative sources required
Use when public claims require authoritative cited sources.
Type: Evidence-boundary policy
Controls: Public-source verification, citation requirements, and fail-closed handling.
Read policy

Implementation procedure

Step-by-step implementation procedure

Follow the workflow in order. Each step gives one action and one verification check before continuing.

  1. Runtime prompt layer

    Define the task and evidence boundary

    State whether the answer must use provided material only, public-source verification, or final-answer checks.

    Action
    Choose one boundary before selecting a prompt stack.
    Verify
    The selected boundary matches the task.

  2. Reference layer

    Attach or name the allowed sources

    Provide the files, excerpts, logs, code, URLs, or official sources the workflow is allowed to use.

    Action
    Mark unavailable sources as missing instead of letting the assistant infer them.
    Verify
    The answer source is explicit.

  3. Runtime prompt layer

    Open the matching stack or component

    Use the files-only, web-verified, or final-check setup that matches the selected boundary.

    Action
    Add only the components required for the current task.
    Verify
    The prompt does not combine incompatible evidence rules.

  4. Verification layer

    Check the answer before use

    Review source alignment, unsupported claims, skipped material, uncertainty, and confidence reporting.

    Action
    Revise or fail closed when evidence is missing or the answer exceeds the selected boundary.
    Verify
    The output can be traced to allowed evidence or reports the gap.

Verification checklist

Use this checklist before accepting the output, publishing it, or using it as evidence for a downstream workflow.

Evidence boundary
The answer uses only the allowed evidence
Provided-material workflows do not add public facts; public-source workflows cite authoritative sources; final checks do not change the active evidence boundary.
Coverage
Long or multi-file inputs include coverage disclosure
The output states what was inspected, what was not inspected, and where evidence came from when the task depends on broad input coverage.
Tool use
Tool behavior is declared instead of assumed
Browsing, connectors, code execution, and document analysis are treated as product- and runtime-dependent.
Output discipline
Unsupported claims and agreement are checked
The final answer does not confirm unsupported user claims, invent evidence, or hide uncertainty.

Next step