Use Bwat
Common workflows
Short, adaptable prompt recipes for the work developers hand to Bwat every day.
On this page
Understand an unfamiliar codebase
Start broad, confirm the map, then trace one real path through the system. This gives Bwat a useful direction without asking it to read the entire repository at once.
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.
Now trace sign-in from the first user action to the final session check. Call out the boundary between the client and server.
Fix a bug
Give Bwat the symptom, reproduction steps, and the expected behavior. Ask it to reproduce before editing so the fix is anchored to an observed failure.
The save button stays disabled after a user removes an optional image. Reproduce it, trace the state that controls the button, identify the root cause, implement the smallest durable fix, and run the relevant tests.
Build a feature
Describe the outcome and constraints, not a guessed file list. For a larger change, start in Plan mode so you can review the approach before anything is written.
Add saved filters to the orders page. A signed-in user can name, apply, rename, and delete a filter. Reuse the existing dialog and form patterns. Plan the data flow first, then implement it and verify the production build.
Write or repair tests
Find the public behavior in InvoiceCalculator that lacks coverage. Add focused tests in the existing style, including boundary and failure cases. Run only that test group first and explain what each new case protects.
Ask for behavior, not a target percentage. Coverage can rise while important failure paths remain untested.
Refactor safely
Refactor the notification dispatch code to remove the duplicated provider switch. Preserve public behavior and current error handling. Add a characterization test first, make the change in small steps, then run the full notification test suite.
Review current changes
A useful review asks for failures and regressions, not a summary of the diff. Tell Bwat what baseline to compare against and what risk matters most.
Review my current diff against main. Look for correctness bugs, regressions, missing validation, unsafe data handling, and tests that do not prove their claims. Report only actionable findings, ordered by severity, with file and line references.
Work with Git
Summarize my uncommitted changes and flag anything that looks accidental. Write a commit message from the staged diff. Do not stage anything else. Help me resolve this merge conflict while preserving both intended behaviors.
Read the final diff before you commit or push. Version control makes changes recoverable; it does not make an unchecked change correct.