---
title: "Prompt templates"
description: "Copy-paste starting points for bugs, features, tests, refactors, upgrades, and investigations."
canonical_url: "https://hoplite.sh/docs/prompt-templates"
markdown_url: "https://hoplite.sh/docs/prompt-templates.md"
---

# Prompt templates
URL: /docs/prompt-templates
LLM index: /llms.txt
Description: Copy-paste starting points for bugs, features, tests, refactors, upgrades, and investigations.
Related: /docs/prompting, /docs/delegate, /docs/agent/instructions

# Prompt templates

Paste one of these into the composer and replace the `<placeholders>`. Each template states a goal, constraints, and how the agent should verify the result — the anatomy covered in [Write effective instructions](/docs/prompting). Project-wide conventions belong in [instructions](/docs/agent/instructions), not in every prompt.

## Fix a bug

Use when you can describe the symptom and roughly reproduce it.

```text title="template"
Fix: <one-line symptom>.
Repro: <steps, failing request, or the failing test>.
Expected: <the correct behavior>.
Start by writing a failing test that captures the bug, then fix it.
Run the test suite and confirm everything passes.
Don't change unrelated code.
```

## Build a feature

Use when the feature has a clear user-facing behavior you can check in a running app.

```text title="template"
Add <feature> to <area of the app>.
Users should be able to <core interaction>.
Follow the existing patterns in <directory or a similar feature>.
Constraints: <what not to touch, libraries or design rules to respect>.
Add tests for <the key behaviors>.
Start a preview and verify the flow end to end in the browser.
```

## Add test coverage

Use when a module works but nothing proves it.

```text title="template"
Add tests for <module or feature>.
Cover: <behavior 1>, <behavior 2>, <edge case>.
Match the style and helpers of the existing tests in <test directory>.
Don't change production code unless a test exposes a real bug —
and if it does, report it before fixing it.
Run the full suite and summarize what's covered now.
```

## Refactor safely

Use when you want structure to change and behavior to stay identical.

```text title="template"
Refactor <target> to <goal, e.g. extract the duplicated retry logic
into one implementation>.
Behavior must not change.
Run the test suite before you start and after each meaningful step.
If <target> isn't well covered by tests, add coverage first.
Keep the diff inside <boundary> — no drive-by changes.
```

## Upgrade a dependency

Use for version bumps where the risk is subtle breakage, not the code change itself.

```text title="template"
Upgrade <package> from <current version> to <target version>.
Apply any code changes the new version requires.
Run the test suite and fix what the upgrade broke.
Start a preview and click through <critical flow> in the browser
to confirm nothing regressed.
List any behavior changes or remaining risks in your summary.
```

## Investigate an issue

Use when you want a diagnosis before any change — the output is a report, not a diff.

```text title="template"
Investigate: <symptom, question, or failing CI run>.
Don't change any code yet.
Start from <files, logs, or the failing check>.
Report back: the root cause, the affected code paths, and a
proposed fix with rough scope. I'll review before you implement.
```

<Callout type="tip" title="Then pipeline the follow-ups">
You don't have to wait for the run to finish. Queue "now open a PR with `/pr`" or the next step right away — queued messages apply in order when the current run completes. See [What to delegate](/docs/delegate).
</Callout>

## Sitemap

See the full [sitemap](/docs/sitemap.md) for all pages.
Well-known sitemap: [/docs/.well-known/sitemap.md](/docs/.well-known/sitemap.md).