Milestone: build the bird club events page

What do you build in this milestone?

You build the events part of the Riverside Bird Club site: a list of four upcoming events, then filter buttons that show only walks or only talks. The assistant writes most of the code. Your job is the part an AI tool can't do for you: deciding what the page needs, asking for it in pieces, and checking every line before it stays.

The milestone pulls together the habits from the earlier lessons. A clear goal, your own code as context, limits on tools and style, and one small step per request. Then the checking habits: read the reply, test it in the Preview, compare it with what you asked for, and fix what is wrong. Nothing here is new. What is new is doing it all on one real page, in order, without a lesson telling you which habit comes next.

Why plan the pieces before the first request?

A whole events page in one request tempts the assistant to make big choices for you: a calendar library, a hero banner, sample events it made up. Send a vague request in the practice area and you will see exactly that reply. It looks impressive and contains almost nothing your club can use.

Spend two minutes listing the pieces first. For this page there are two: the event list, then the filter. Each piece should be small enough that you can read the whole reply in a minute or two and test it with a few clicks. The list is plain HTML and CSS. The filter adds a little JavaScript. If the filter goes wrong, you still have a working list to fall back on.

The order matters too. Build the thing that shows content first, then the thing that changes how it is shown. A filter with nothing to filter is impossible to test.

• Piece 1: the four events as a list, with dates, names and places.
• Piece 2: All, Walks and Talks buttons that hide the other events.
• Later, if you want: a sign-up link per event, or a past events section.

What goes in the first request?

Everything the assistant needs for the list, and nothing about the filter except that it comes later. That last part helps: it tells the assistant not to rush ahead and add buttons you haven't reviewed yet.

Type the event details yourself. The assistant can't know your club's dates, and a tool asked to “add some events” will invent them. Check the Prompt check view before you send: this lesson ticks goal, context, limits, a small step and which piece you are asking for.

Please add our upcoming events to my bird club page. First step: just the event list for now, nothing else yet. Here is my page so far:
<h1>Riverside Bird Club</h1>
<h2>Upcoming events</h2>
The events are: Dawn chorus walk, Saturday 9 May, 5:30, Mill Meadow. Nest box workshop, Wednesday 13 May, 19:00, Library hall. Swift survey, Sunday 7 June, 18:00, Old Bridge. Members' slide night, Thursday 18 June, 19:30, Library hall.
Plain HTML and CSS only, and keep my green colours.

How do you review the list reply?

Press **Use this code**, then read the Code tab from top to bottom. Start with what you can compare against your own notes. Are all four events there? Is every date, time and place exactly what you typed? AI tools sometimes reorder, merge or reword items without saying so, and a wrong date on a club page sends people to an empty meadow at dawn.

Then look at the markup. Each event is an <li> inside a <ul>, which is right for a list of similar items. Each date is in a <time> element with a datetime value such as 2026-05-09T05:30. Check those values too: the visible text says 9 May, so the machine-readable value must say the same day. Finally, check that the new CSS sits in your existing <style> block and that no outside stylesheet or script appeared.

Open the **Review** view. It compares the assistant's code with yours and shows every line you changed. After the list step it should be empty, because you haven't changed anything yet.

What changes in the second request?

The goal is new, and so is the context. This time the context is the list you already have, because the filter has to work with that exact markup. Say which events are walks and which are talks; the assistant can guess from the names, and guessing is how mistakes start. Add a limit about tools, and one about leaving the event details alone.

Real tools often keep the whole conversation, so you could say “now add a filter” and hope it remembers. Pasting the current code is safer. If you fixed something by hand after the last reply, the assistant only knows about your fix if you show it.

Next small change: add filter buttons above my event list so visitors can show only walks, only talks, or all events. The dawn chorus walk and the swift survey are walks; the workshop and the slide night are talks. Here is my list:
<ul id="events">
  <li><time datetime="2026-05-09T05:30">Saturday 9 May, 5:30</time> <strong>Dawn chorus walk</strong>, Mill Meadow</li>
  ...
</ul>
Plain JavaScript only, no libraries, and don't change the event details.

How do you test the filter properly?

Click every chip in the Preview, one after another. **All** shows four events. **Talks** shows the workshop and the slide night. Now press **Walks**: every event disappears. The reply said each chip shows only those events, and for one of them that is false.

Find the cause by reading. The script hides any list item whose data-kind doesn't equal the chip's data-filter. The list items say walk. The Walks chip says walks. One letter, and no error anywhere: the code runs fine and compares two strings that never match. This is the most common kind of AI bug, a small mismatch between two parts that each look correct alone.

Next, put the mouse away. Press Tab to move through the page. The chips are skipped, because they are <div> elements with a click handler. A keyboard user, or anyone using a switch device, can't filter the events at all. A <button type="button"> gets keyboard focus, Enter and Space, and the right role for screen readers, with no extra code.

Should you ask the assistant to fix these, or fix them yourself?

Both work. For two tiny, well-understood changes, editing the code yourself is quicker and keeps you in charge. You know exactly what changed, and the Review view shows your edits highlighted against the assistant's version.

Ask the assistant when you don't understand a problem yet, or when the fix touches many lines. If you do ask, describe what you saw, such as “the Walks button hides every event, I expected it to show the two walks”, and paste the current code. Then review the new reply as carefully as the first one.

What does a finished page look like?

Four events in date order, each with a correct <time> value. Three real buttons above the list that work by mouse, keyboard and touch. Each button shows the right events. No outside files, and no events that your club didn't plan. You can explain every line, because you asked for each piece and read it before keeping it.

Remember that the assistant on this page is pretend. It always answers the same kind of request with the same reply, so the checks are fair. A real AI tool would give you a slightly different page each time, maybe with different bugs, or none, or more. The process stays the same: small pieces, real details from you, and a careful read and test before anything stays on your site.

Field notes

• Plan the pieces first so the assistant doesn't make big choices for you.
• Type your own event details, because the assistant can't know your dates.
• Check every date, time and place in the reply against your notes.
• Test every filter button, then read the code to find why one fails.

Easy to get wrong

A big request gets a big reply full of choices you didn't make. Small pieces are quick to read and test, and a mistake in one piece doesn't hide inside another.

An AI tool has no idea when your club meets. If you leave gaps, it fills them with plausible fiction, and people turn up on the wrong day.

The All chip worked and the Walks chip did nothing. Bugs live in the cases you didn't try.

Questions people ask

Why does the Prompt check view list the pieces?

This milestone has two different requests, and the assistant needs to know which piece you want each time. Naming the piece is part of asking for one small step.

Could I use the assistant's code without changing it?

On this page, no: the filter reply has two real problems. On a real project, sometimes yes. You still read and test it first, because you can't know it is fine until you have checked.

Why a button and not a link for the filter?

A link takes you somewhere. A button does something on the current page. Filtering the list is an action, so <button type="button"> is the right element.

What if a real AI tool gives me a different filter?

Review it the same way. Check that every value matches the list, every chip is a real button, and every chip shows the right events.