Skip to main content

Prompt Templates

Prompt templates let you apply repeatable instructions to generated context bundles. They help turn file selection into a consistent LLM workflow.

What it does​

PastePrompt supports built-in templates for common review workflows and custom templates for your own process. A template can provide default instructions, review criteria, expected output format, severity focus, and workflow-specific context.

Templates are added to the generated bundle as user instructions. They do not call an LLM by themselves and do not guarantee the quality of model output.

Why it matters​

Auditors and reviewers often repeat the same instruction patterns: high-confidence-only review, diff review, sponsor fix validation, dependency analysis, or test coverage review. Writing those instructions from scratch each time is slow and inconsistent.

Templates help you:

  • Keep review instructions consistent.
  • Avoid forgetting important constraints.
  • Make prompt history more meaningful.
  • Rebuild the same audit workflow later.
  • Separate code context from review goals.

How to use it​

  1. Select files and metadata for the bundle.
  2. Open the prompt template picker.
  3. Choose a built-in template or a saved custom template.
  4. Edit the instructions for the current review.
  5. Add any issue-specific facts, assumptions, or constraints.
  6. Generate the context bundle.
  7. Review the final instructions before copy or export.

Built-in templates​

Built-in templates should cover common PastePrompt workflows such as security review, Git diff review, sponsor fix review, and security review passes.

Custom templates​

Custom templates are useful for team-specific report formats, recurring audit methodology, client review constraints, or model-specific phrasing. Keep templates factual and avoid instructions that ask the model to invent evidence.

Example templates​

Critical/High Confidence Only​

Focus only on high-confidence critical or high severity issues.
Verify each claim against the included code.
Do not report speculative issues.
For each candidate finding, include the affected file path, root cause, impact, realistic preconditions, and recommended fix.
If the evidence is insufficient, explain what code or tests would be needed.

Git Diff Review​

Review the included Git diff and related files.
Focus on behavioral regressions, security-sensitive changes, missing validation, broken assumptions, and test gaps.
Distinguish code facts from assumptions.
Do not comment on formatting unless it affects behavior or reviewability.
Review whether the included patch adequately addresses the original issue.
Use this structure:
1. Original issue summary.
2. Expected fix behavior.
3. Relevant changed files.
4. Remaining edge cases.
5. Verdict: fixed, partially fixed, not fixed, or needs more evidence.

Example workflow​

  1. Select the changed files for a sponsor fix.
  2. Include the Git diff against the original audit base.
  3. Apply the Sponsor Fix Review template.
  4. Paste the original issue summary into the instructions.
  5. Generate the bundle.
  6. Review model output manually before accepting any conclusion.

Limitations​

  • Templates are instructions, not enforcement.
  • Poorly scoped files can still produce weak output even with a strong template.
  • LLMs can miss bugs, overstate issues, or misread code.
  • Custom templates should not include secrets, license keys, or client-sensitive data unless you intend to include them in exported bundles.
  • Template availability may differ between Free, Founder, and Pro plans.