Better prompts for your AI coding tools

Have Cascade draft a short plan first, naming the modules it will create, then execute it. Goal: a {{language}} REST service over {{database}} exposing /api/{{resource}}. Handlers: create, fetch a single record, PATCH updates, delete, and a listing route accepting page, limit (never above 100), and sort. A body failing validation gets a 400 whose payload is an array of per-field messages; an unrecognized id gets 404; inserting a duplicate into a unique column gets 409. Every query must go through this repo's ORM or prepared statements; SQL assembled from strings is banned. Include a schema migration plus a seeder inserting sample rows. In the editor terminal, run the integration suite until it passes; required cases: complete CRUD flow, malformed body, id that matches no row, and a page request beyond the final page. Finish with the created-file list and the command that boots the server locally.

Working with Copilot Edits file by file inside VS Code: begin by opening src and mirroring its existing layout. Step 1: a route module in {{language}} declaring five operations for {{resource}}: collection GET paged by a cursor token plus a limit count, single-record GET, POST, PATCH, DELETE. Step 2: a service module holding business rules, and a repository that talks to {{database}} only through bound parameters or the ORM this project already ships; concatenated SQL strings are forbidden. Step 3: register the router inside the application entry file. Behavior contract: schema-check incoming JSON and reply 400 naming which fields failed, 404 when an id matches nothing, 409 for uniqueness conflicts. Step 4: integration tests for one successful round trip, one schema-violating payload, one lookup of an absent record. Run the project's test command and report each added or modified file.

Build a dashboard page in this codebase's existing frontend stack that surfaces {{resource}} metrics. Layout: a stat row with four summary cards (total, active, created this week, error count), a time-series chart of {{resource}} activity over the last 30 days, and a sortable table of the 20 most recent records with status badges. Fetch data through a typed client module rather than inline fetch calls, and handle three states per widget: loading skeleton, empty dataset with a short explanation, and fetch failure with a retry button. Keep the chart dependency-light; use whatever charting library is already installed before adding one. Make the grid collapse to a single column below tablet width. Add a component test for the table's sort behavior and the empty state. Run the dev build and the tests, then summarize the components you added and where they mount.

Build a dashboard UI in this project using {{language}} and the existing component conventions. Layout: a fixed sidebar with nav links, a top bar with a date-range picker, and a main grid of four stat cards above two charts and a recent-activity table. Fetch data through a single useDashboardData hook so widgets stay decoupled from the API layer. Every widget needs three states: skeleton while loading, an inline retry on fetch failure, and a zero-data message that tells the user what action creates data. The table should sort by column header and paginate client-side up to 500 rows. Keep the grid responsive: cards collapse to one column below 768px and charts stay legible at 320px wide. When done, run the dev server, confirm no console errors, and list the components you added with their file paths.

Build a dashboard page in this codebase that summarizes {{resource}} activity. Use the component library and styling approach already in the project; check package.json before picking anything new. Layout: a four-stat summary row, a line chart of {{resource}} over the last 30 days, and a recent-items table with column sorting and a date-range filter. Fetch data through the existing API client with loading skeletons per section, so one slow request does not blank the page. Handle the empty account case with a short explainer instead of a zeroed chart, and show a retry button on fetch errors. Keep chart logic in its own component and type the API response instead of using any. Verify by running the dev server and the type checker, then list the components you added.