Running a project: from an interview to a PRD

Today we ran a whole project opening from start to finish: interview a client, write what they said into PROPOSAL.md, let an agent interview you to turn that into PRD.md, and put the rules the agent must follow in AGENTS.md. Two classmates gave lightning talks, one on a site they built by putting AI tools to work alongside each other, and one on where to go when you need design ideas. The habit worth keeping: write the plan down before any code, and hand the agent that plan.

The same steps work on <your-github-username>.github.io, on Mini Project 1, and on anything you build after this course. Written out with the exact clicks: Running a Project With an Agent.

1. Branch first, so the site you already have keeps working: "Create a new branch called redesign and switch to it. Do not change any files." Read the command it proposes, then approve it.
2. Write PROPOSAL.md yourself, five sentences, before AI sees anything.
3. Start a new chat, drag PROPOSAL.md in, and paste the interview prompt. Answer one question at a time.
4. Type write it, then read PRD.md and delete anything you did not actually decide. Commit both files.
5. Type /init and ask for AGENTS.md by name. Cut it down to about five rules and commit it.
6. Build: "Read PRD.md, then build the home page." Read what it wrote before you keep it.

We worked through step four on screen in class. Steps five and six are the ones to do on your own.

Start a new chat whenever the job changes. A 15-round interview followed by "now build it" in the same conversation brings back everything the interview ruled out.

Everything we made in class is in one public repository: OIM3690/crust-fund-bakery.

Open PROPOSAL.md, PRD.md and AGENTS.md first, then read index.html and styles.css beside them. You can see exactly what the agent was told and exactly what it produced from that, which is the part you cannot get from your own work yet. Your repository will hold the same files by the end of the week.

The live site is linked from the About box on the right of that page, which is where your own project link goes too. Click through to Order Online and Catering. Both say "Coming Soon", because the PRD put online ordering and payment on the Later list and asked for the pages to exist anyway.

On Thursday we will read that styles.css together.

Open the Chat view, pick Sonnet 5 (Babson) in the model picker, and set the role to Agent.

If the model is missing from the picker, look for a second dropdown beside it showing a session target such as Copilot or Claude, and set that to Local. A key you added yourself is a custom endpoint, and custom endpoints only run under Local. It looks like a broken key and it is not one. The full version is in Your Babson AI Key.

We interviewed a bakery owner near campus, played by ChatGPT, and the room supplied the questions. The first answer to almost every question was vague. Asked what she wanted from the site, she said she would like it to "feel easy and useful". Asked which sections the page needed, she said she was not sure.

That is the normal case, and it is the reason the interview exists.

There is a gap between what a client intends and what a page has to do, and closing it is your job.

What worked in the room:

• Ask who visits and what they should do, before anything about colors or fonts. Everything else follows from the answer.
• Push on a vague answer. "Can you be more specific?" produced more in one line than the original question did.
• Ask which sites they like, and why. "Clean, lots of white space, big photos" is something an agent can act on.

AI does not know your client, their business, or the street the shop is on. Whatever you do not tell it, it will invent.

🤖 AI tip: Ask your agent to interview you before it writes the PRD. A question you cannot answer is a decision you have not made yet.

You can practise the interview on a practice client before you sit down with a real one. A simulated client is for rehearsing questions and it never replaces the real conversation.

The bakery owner asked for online ordering with payment. The room worked out what that actually needs: a payment processor such as Stripe, a way to hold a cart, user accounts, somewhere to store all of it, and a real answer on privacy. None of that is a static page, and we have not covered any of it yet.

This will happen to you. Clients ask for what they want, and the technology decides what is cheap to build.

Agree to the goal and move the feature. Put a Later section in PRD.md, write the real feature down there, and ship a static stand-in now:

• A catering request becomes a mailto: link that opens the customer's email app.
• An order button becomes a phone number, or a link to whatever ordering service the client already pays for.
• Anything genuinely impossible becomes one honest sentence to the client about what version two will hold.

Write a rule into AGENTS.md for this too, so the agent does not quietly invent a backend:

If it needs a server, stop, tell me, and add it to Later in PRD.md.

• README.md is for people. It is the front page of your repository.
• PROPOSAL.md is yours, in your words, out of the conversation you had.
• PRD.md is what the agent writes from your proposal, and what you correct. It says who the page is for, what it contains, and what "done" looks like.
• AGENTS.md is the rules the agent reads on every request, without being told to. VS Code picks it up automatically at the top of the repository, and so does Codex.

AGENTS.md is the one most people skip, and it is the one that stops an agent adding React to a three-page site. Keep it to about five rules. A rule that says what to do instead of the thing you forbid holds up better than a flat prohibition.

One rule worth stealing: ask the agent to start every answer with your name. When it stops doing that, the conversation has grown too long and the agent has lost the thread, which is the moment to start a new chat.

One of the lightning talks was a set of places to look when you know something is wrong with your page and cannot name it:

• Awwwards for sites of the day and the year, sortable by category and by the technology behind them. You can submit your own.
• Supahero for hero sections only, which is the big block at the top of a page and the first thing anyone sees.
• 60fps.design for interactions and animations. Most of it is built for phone apps, so borrow the idea and work out the web version yourself.

Every one of them is now on the recommended reading page, along with the ones already there.

Find something you like, screenshot it, and hand the screenshot to your agent with a sentence about what you want from it. AI left alone will give you something competent and forgettable, usually with too many emoji.

The other lightning talk walked through a site its builder had deployed, with real content on it from real users. What is worth borrowing is the method.

The build used a pair of AI tools with different jobs: a chat app for thinking, naming features and drafting prompts, and a coding agent in the editor with access to the whole repository for making the changes. The prompts moved between them by hand.

The reason that helps is the same reason step three above says to start a new chat. One conversation carrying brainstorming, decisions and code at once gets cluttered, and the output gets worse. Splitting the thinking from the editing keeps each one short.

Some tools that came up, since several of you will meet them:

• Cursor is a fork of VS Code with AI built in. It is a reasonable choice and the gap between it and VS Code has mostly closed. This course uses VS Code because Babson provides the model access free.
• Vercel and Netlify deploy sites that need a server behind them, which is more than GitHub Pages does. You do not need either one yet.
• Firebase and Supabase are databases you can reach from a web page. We will get to that in the second half of the term, when the projects start needing to store things.

The talk named its own limitation. A site that depends on other people adding content is only as good as that content, and getting the first 100 entries in was harder than building the site.

Claim a slot on the lightning board.

Finish the workflow above in your <your-github-username>.github.io repo. That means PRD.md and AGENTS.md committed, and a home page built from the PRD that you have read.

In your oim3690 repository:

1. css/styles.css, linked from about-me.html, with the <style> block gone. The file name matters, letter for letter.
2. logs/wk04.md, with the same four prompts as every week.

Go through the CSS Essentials slides on your own and do the exercises on them. That is where CSS lives for this cohort now.

Mini Project 1: the deadline is 9/29. The times table in the spec is a suggested pace. By now you want the interview done and PROPOSAL.md in the project repository, and the same steps carry straight over.

On Thursday we will pick up CSS again.