Prompt library
Ready-made prompts for common jobs, grouped by where you are in the work. Copy one, replace the parts in angle brackets, and send it. Each prompt is written so the agent knows what “done” means and how to check it.
Prompts you use often are worth saving as a custom command or skill, so you can run them as /name with arguments.
Find your way around
| Goal | Prompt |
|---|---|
| First look at a repository | Walk me through this repository: what it does, how it is laid out, how to build and test it, and which folders I can ignore. |
| Follow one request end to end | A user submits the signup form. Trace that request through the code to the database write, naming each file and function on the way. |
| Find where a behavior lives | Where do we decide whether <a user can export reports>? Show me the check and everything that calls it. |
| Judge the impact of a change | If I removed <the legacyAuth module>, what would stop compiling or behave differently? List callers and tests. |
| Learn the history of a file | Read the git log for <src/billing/invoice.ts> and tell me why it looks the way it does today. Mention the commits that mattered. |
| Read an unfamiliar language | I mostly write Python. Explain <cmd/server/main.go> line by line where Go does something a Python developer would not expect. |
| Write the findings down | Turn what you just explained into a section of SYNTIC.md so future sessions start with it. |
Plan
| Goal | Prompt |
|---|---|
| Plan before touching code | /plan Add rate limiting to the public API. Look at how middleware is wired today, propose an approach, list the files you would change and the tests you would add. Do not edit anything yet. |
| Compare options | Give me two ways to cache <product lookups>: one in-process, one shared. For each, the code changes, the failure modes and how we would test it. Recommend one. |
| Interview me first | Before you start on <the export feature>, ask me the questions you need answered to do it well, one at a time. Then write a short spec to SPEC.md. |
| Break a big job down | This migration touches every service. Split it into steps that each leave the build green, and say which ones can run in parallel. |
| A long, careful plan | /ultraplan Move session storage from files to SQLite without losing existing sessions. |
Build
| Goal | Prompt |
|---|---|
| Add a feature with tests | Add a --dry-run flag to the import command: print what would change, write nothing. Add tests for both modes and run them. |
| Follow an existing pattern | Add a <DELETE /teams/:id> endpoint. Copy how the other team endpoints handle auth, validation and errors. |
| Build from a screenshot | Paste a mockup with Ctrl+V, then: Build this settings panel with our existing form components. Match spacing and labels. |
| Script a chore | Write a script in scripts/ that finds images over 500 KB in public/ and prints their paths and sizes. Run it once to show me the output. |
| Keep going until it works | /goal the new parser passes every case in tests/fixtures/ and the linter is clean |
Fix
| Goal | Prompt |
|---|---|
| Fix a failing test | npm test -- auth fails on the refresh-token case. Find the cause and fix the code, not the test. |
| Work from a stack trace | Paste the trace, then: What is the root cause, and what is the smallest change that fixes it? Show me before you edit. |
| Reproduce first | Users say search returns duplicates after an edit. Write a failing test that shows it, then fix it. |
| Fix a flaky test | <test_upload_resume> fails about one run in ten. Run it in a loop, find the race, fix it, then run it 50 times to prove it. |
| Clear a build after an upgrade | I bumped <the HTTP client> to the next major version. Fix whatever breaks, and list any behavior changes I should know about. |
Improve
| Goal | Prompt |
|---|---|
| Refactor safely | Split OrderService into a reader and a writer. Keep the public API the same and run the tests after each step. |
| Remove dead code | Find exported functions in src/ that nothing calls. Show me the list before deleting anything. |
| Speed something up | The /reports endpoint takes 4 seconds. Profile it, find the slow part, and propose a fix with numbers before and after. |
| Raise test coverage | Cover parseDuration with table-driven tests, including empty input, negative values and overflow. |
| Clean up a diff | /simplify |
Review and ship
| Goal | Prompt |
|---|---|
| Review your own changes | /code-review high |
| A deep review before a release | /ultrareview |
| Check for security problems | /security-review |
| Review a pull request | /review 482 |
| Write the commit | /commit |
| Commit, push and open a PR | /commit-push-pr mention that this closes #311 |
| Answer review comments | /pr-comments, then: Address each comment. Where you disagree, explain why in a reply draft instead of changing code. |
| Fix a red pull request | /autofix-pr 482 |
Document
| Goal | Prompt |
|---|---|
| Explain a module to newcomers | Write docs/architecture/queue.md explaining how the job queue works, with a sequence of what happens when a job fails. |
| Keep docs in step with code | Compare README.md with what the CLI actually accepts today. Fix every flag or example that is out of date. |
| Onboard a teammate | /team-onboarding backend engineer |
| Changelog from history | Summarize the commits since tag v2.3.0 as a changelog, grouped by feature, fix and breaking change. |
Work in parallel
| Goal | Prompt |
|---|---|
| Fan out over many files | /batch Replace every use of the old logger with the new one, one package per agent. |
| Research in the background | Use a background agent to find every place we parse dates, and tell me when it is done. I will keep working here. |
| A side question | /btw what does the --frozen-lockfile flag do again? |
| Several reviewers at once | Start three reviewers on this branch: one for correctness, one for performance, one for API design. Merge their findings. |
What makes these work
- They state the finish line. “Tests pass”, “show me the list first”, “run it 50 times”. The agent stops when the line is reached, not when it runs out of ideas.
- They name a check. A test command, a linter, a measurement. Work the agent can verify is work it gets right more often.
- They point at real places. A file path or function name saves a search and keeps the context small.
- They say what not to touch. “Fix the code, not the test.” “Do not edit anything yet.” Constraints prevent the shortcuts you would reject in review.
See Best practices for the habits behind these prompts, and Common workflows for the built-in commands they use.