Prompt library

Map this repository for a new contributor. Identify the runtime entry points,
major modules, data stores, and the commands used to test and build it.
Cite the files behind each conclusion. Keep the answer concise.

Trace [user action or request] from its first entry point to the final result.
Show the client/server boundary, important state changes, and error handling.
Do not edit anything. Cite the relevant files and symbols.

@path/to/file Explain what this code does, why it exists, and how it fits
into the surrounding system. Then give me the three assumptions I should verify
before changing it. Use plain language but keep the technical details accurate.

[Describe the symptom.] Expected: [expected behavior].
Reproduce it using [steps or command], trace the root cause, and explain it
before editing. Implement the smallest durable fix, add a regression test,
and run [relevant check]. Keep unrelated code unchanged.

Diagnose [problem] without changing files. Reproduce the failure, identify
the root cause with file and line references, and separate confirmed facts from
hypotheses. End with the smallest safe fix and the test that would prove it.

Add [user-visible capability]. Users should be able to [acceptance criteria].
Preserve [API, compatibility, or design constraint]. Study the existing patterns
and propose a plan before editing. After approval, implement it, add tests for
[important cases], and run [build or test command].

Add [small capability] to @path/to/starting-file. Follow the existing
[component/API/test] pattern, keep the public behavior unchanged elsewhere,
and verify it with [focused command]. Show me the final diff summary.

Find the important public behavior in [module] that lacks coverage. Add
focused tests in the existing style for the normal case, boundary case, and
most likely failure. Do not change production behavior merely to make testing
easier. Run the smallest relevant test group and explain what each case proves.

Refactor [area] to [desired structural outcome]. Preserve the public API,
error behavior, and observable output. Add a characterization test first if the
behavior is not already protected. Make focused changes, run [checks], and call
out any remaining risk instead of hiding it.

Review my current changes against [main or another baseline]. Look for
correctness bugs, regressions, unsafe data handling, performance problems, and
tests that do not prove their claims. Report only actionable findings, ordered
by severity, with file and line references. Do not edit files.

Review the staged diff as if you were the maintainer. Flag anything accidental,
missing, or risky. Check that the tests cover the changed behavior. If it is ready,
say so plainly and draft a concise commit message. Do not stage or commit files.

Improve @path/to/component for [user and goal]. Preserve [design system or
existing interaction], handle loading/empty/error states, and make the layout
work on narrow and wide screens. Inspect the rendered result, test the important
interaction, and run the production build.

Summarize this work for a fresh Bwat session in five sections: goal, current
state, decisions already made, important files, and the next verification step.
Include unresolved questions. Leave out the conversational history.