In week one you added one file to the class roster and it went in through a pull request. That was the smallest possible change, in a shared repository, with the computer refusing to let anyone skip the review. From here on the change is a feature, the repository is yours, and nobody enforces the rule but you. The steps are the same.

1. Start from a ticket

A ticket is a GitHub issue: a short story about who wants what and why, and under it a definition of done, a few sentences that say when the feature is finished. In the class repo the tickets are already in the Issues tab. For your own project you write them: one issue per feature, three to five checkable sentences each.

Read the ticket before you touch anything. It is what your reviewer will hold the change against.

2. Branch first

Never build on main. In the bottom-left corner of the Codespace, click main, choose Create new branch, type posts-form, and press Enter. The corner now reads posts-form, and everything you commit from here goes on that branch. (Source Control's ... menu has the same thing under Branch, Create Branch.)

The name describes the change. If you forget and commit on main, nothing is lost: make the branch now the same way, and your commit comes with it.

3. Build it, with tests

Before the prompt, one line in AGENTS.md, the file your agent reads before it does anything. It already says that every sentence of a definition of done gets a test, and it points at the code rules; the agent already knows how to read a GitHub issue. Add the one thing nobody said, at the end of the Rules list:

- After changing any code, run the tests and report the result before saying you are done.

Then the prompt can be short, because the file carries the rest:

Read issue #1 and build it.

Watch what happens that you did not ask for: the agent reads the ticket, writes one named test per sentence, runs them and reports. That is what the file is for. Anything you would otherwise type into every prompt belongs there instead.

Then check it yourself, twice: use the page in the browser, and run the tests:

bin/rails test

Open the test file and read the test names against the ticket. One per sentence? A sentence with no test is a sentence nobody checked.

4. Commit and publish

In Source Control, stage the changes and commit with a message that says what changed, so that someone reading the history later knows without opening the diff. "Add the new post form and create action, with tests" is a message. "done" and "tried again" are not.

Then Publish Branch. Your branch is now on GitHub; main is untouched.

5. Open the pull request

On your repo's GitHub page a banner offers Compare & pull request. Click it. The title is the ticket's title. In the body, write closes #1 (the issue number), so merging the PR closes the ticket, and a sentence on what you did. Create pull request.

A pull request is a request to change main. Nothing has changed yet.

6. Invite your reviewer

Your copy of the repo is private, so only a collaborator can review it. On the repo page: Settings, Collaborators, Add people, your partner's GitHub username, Add. They accept from the email GitHub sends, or at github.com/notifications.

7. Review someone else's

Open their pull request. Read the issue it closes, then click Files changed and read the diff. If you are sitting next to them, run the tests on their machine:

bin/rails test

Then answer five questions:

  1. Does the change do what the issue says? Read the issue, then the diff.
  2. Does the commit message tell you what changed without opening the diff?
  3. Does it follow the pattern? The right actions in the right controller, the form posts to the resource's path, create redirects.
  4. Is there a test for every sentence in the issue, and do they pass when you run them?
  5. Would you merge it? If not, what would you ask for?

The first, second and fifth are week one's three questions. They never change. The third and fourth are new because the change is code now, built against a pattern and a ticket.

Leave at least one comment on a line: hover over a line in the diff, click the blue +, write it, Add single comment. Then Review changes. If all five answers are yes, Approve. If not, Request changes and say which question failed. Submit review.

8. Merge

When your reviewer approves, Merge pull request, Confirm merge, Delete branch. The feature is on main, and the issue it closed is closed.

The merge button worked before anyone reviewed. On a personal repo, GitHub does not stop you. The rule held because you held it. On a team, the repository is set up so the computer holds it too, which is what the roster did in week one.

If you requested changes

The author fixes it on the same branch, commits, and syncs. The pull request updates on its own. Review again. That loop, change, review, change, merge, is the part of this course that carries the furthest, and the one an agent cannot do for you: someone who did not write the code has to read it.