Build a business dashboard or internal tool from an empty repository

Create the repository and the accounts

On GitHub, create a repository called northwind-ops and tick Add README. On Supabase, create two free projects: northwind-dev for building and northwind-live for real data. In ProPR, open Repositories, choose Add Repository, enter the repository name, and switch on Visual previews. Add the development database keys to your agent's environment variables in ProPR's agent settings. The live keys go into Vercel later and never into the repository.

The plan becomes issues

Every issue carries a checklist of what done means. A plan for this tool looks like this.

1. Set up the Next.js project with Tailwind, Supabase and sample dataDone when: the project builds, connects to the development database using keys from the environment, and a script fills it with fifty sample bookings.
2. Staff sign-in with emailDone when: a visitor sees only the sign-in screen; a staff list table holds the invited email addresses; a listed address signs in with a magic link; and every data read, mutation and export checks the list on the server and refuses anyone else. Tests cover two refusals: a visitor who is not signed in, and an account that signed in but is not on the staff list, which cannot read bookings or download the CSV.
3. Bookings table and add-booking formDone when: the table lists bookings with search by customer and item, the form adds a booking with validation, and both look right at desktop and tablet widths.
4. Overdue returns listDone when: bookings past their due date show in a separate list with days late, sorted most late first, and a count appears in the navigation.
5. Revenue-by-month chartDone when: a bar chart shows the last twelve months of revenue from completed bookings, with the total for the current month above it.
6. CSV downloadDone when: a date range picker and a download button produce a CSV that opens in a spreadsheet with one row per booking, and a test checks the column headers.

What you look at in each pull request

• The screenshot. Does the bookings table show the columns you asked for? Is the overdue list obvious?
• The summary against the checklist. The agent says what it built and tested. Compare it with the issue.
• The preview address. Vercel builds every pull request. Open it, sign in with a test email, add a booking, try the search.

For the sign-in pull request, ask a second model to look before you merge, and tell it the question: can an account that signed in but is not on the staff list reach any booking data or the export? Write /review with a model name as a comment and the review comes back as numbered findings; /fix applies the ones you keep. The second-model review playbook walks through it.

A new commit arrives on the same pull request with a fresh screenshot. When the last piece merges into the epic branch, ProPR tells you the epic is ready, and you merge it into main. Vercel deploys the tool.

How the tool grows

Every request from staff becomes an issue: "let me mark a booking returned from the overdue list", "email me each Monday's overdue list". A bigger change gets a plan. Hand an open-ended improvement to a goal, such as making every screen usable on a phone, and check its checkpoints on the draft pull request. Schedule an automation that reads the repository weekly and reports slow queries or missing tests; the scheduled report playbook shows one.