Write a pull request description

Create a PR description that helps reviewers understand the change, how to test it and what to watch for.

LLazyPrompt(@lazyprompt)CodingGenerateWorks with any model
Prompt template
Write a pull request description for reviewers.

Change summary or diff:
{{changes}}

Problem being solved (and link): {{problem}}
Type of change: {{type}}
How I tested it: {{testing}}
Known limitations or follow-ups: {{followups}}

Use this structure, in Markdown:
## Summary
Two or three sentences: what changed and why, written for someone with no prior context.
## Changes
A short bullet list grouped by area. Mention anything surprising.
## How to review
Where to start, which files carry the real logic, and which are mechanical (renames, generated code).
## Testing
What was run, plus step-by-step manual verification a reviewer can repeat.
## Risks and rollout
Impact on existing behavior, migrations, config or feature flags needed, and how to roll back.
## Screenshots or output
Leave a placeholder only if the change is visible.

Keep it concise and skimmable. Do not invent test results: if my testing notes are thin, list what is still unverified under Testing. Do not repeat the diff line by line.
Example output
## Summary Search on large accounts took 3-8 seconds because every query loaded all documents before filtering. This PR moves filtering into the database query and adds an index, bringing the typical query under 200 ms. Fixes #1204. ## Changes - `search/query.ts`: filters and pagination now happen in SQL - `migrations/0042_search_index.sql`: adds a composite index on `(account_id, updated_at)` - `search/query.test.ts`: tests for filters, empty results and pagination ## How to review Start with `search/query.ts`; the migration is one statement; the test file is the quickest way to see the new behavior. ## Testing - Unit tests pass. - Manual: open an account with more than 50k documents and search "invoice"; results should appear in under half a second. - Not yet verified: behavior under concurrent imports. ## Risks and rollout The migration builds an index on a large table; run it during low traffic. Roll back by reverting the PR and dropping the index. Follow-up: cache invalidation after bulk import is still manual.

Why it works

Giving the model a fixed structure and a how-to-review section saves reviewers time. The rule against inventing test results keeps the description honest.

Licensed CC0 (public domain) Version 1 · history