The bakery, the team and the client are invented. Everything else is the real shape — the same files, in the same places, filled in the way a team that had done the work would fill them.

Open the example repository

Read it, do not copy it. A proposal about a bakery from a team whose client is a clinic is a returned proposal, and it is obvious from the first paragraph.

What to look at, and why

The proposal

docs/proposal.md — eight sections, nothing else. Notice how short it is, and that section 2 names a number: about four orders a week. Section 3 names how that number will be counted from now on. A proposal with no number in it has nothing to be right or wrong about.

The same thing, published

isom472-fall2026.github.io/example-team/docs/ — the page students present from. It is plain on purpose: it is checked only that it opens, not on how it looks.

The front page

README.md — who holds which role, who leads which phase, what is due next, and the links to the page and the board. It is the first thing anyone opening the repository sees, and it is kept current.

The team agreement

docs/team-agreement.md — signed by everyone, with the clause that matters: what the team does when a member goes quiet, agreed while everyone is still friendly.

Two stories

The issues — each one is as a … I want … so that … followed by acceptance criteria a teammate can check by doing them. None of them says “works properly”.

One pull request, reviewed and merged

Pull request #3 — the whole loop in one page. What changed and why, Closes #2 so the issue closed itself on merge, and the AI-Assisted line naming the tool, what it produced, and what the student changed. Read the review comment: it says what was checked, not “looks good”.

One thing this example does not show. It was written by one person, so the review is a comment and the author merged it. In your repository the reviewer approves, and the reviewer merges — never the person who wrote the code.

How to use it this week