Documentation

What lands on a student's repository.

Every push to a Coder in 90 assignment repo runs the autograder. What it posts back depends on whether the tests passed, and on whether there is a pull request to post it to.

When tests fail

The student gets the score and an explanation of the failure, written against the test output and grounded in the class's own course notes. It is a tutor's explanation, not a stack trace: what the test was checking, why it did not hold, and where to look.

A run that crashed before it could grade anything is not a grade. It is reported as a broken run, with the cause, and no mark is written.

When tests pass

Passing work gets a code review. The autograder reads the diff between the starter it gave the student and the commit they pushed, and comments on what the tests cannot see: correctness the suite does not cover, efficiency, maintainability and security. Where there is a pull request the comments are anchored to the lines they are about; where there is not, the review is posted on the commit.

It is written for a learner rather than a colleague. It says why something matters instead of only what to change, and it skips style nits entirely. Three findings is a full review, and none is a legitimate answer: inventing something to say teaches a student to distrust the reviewer.

It reviews the student's own work, not the starter template. It is written in the class's language. And it is advice, never a mark: the grade is the test suite's, and a review changes no score.

Asking for a review

Comment this on a pull request, or on an issue we opened on the repository: 

/cin90 review

It has to be the first thing on the first line. Trailing words are fine. The command answers whether or not it can act: if the latest run is still failing, or there is no graded run yet, or this commit already has a review, it says so rather than going quiet.

A comment written directly on a commit is a different thing to GitHub and does not reach us. If your work has neither a pull request nor an open issue from us, there is nowhere to type the command — the automatic review still arrives on every passing push.

Who can run it: the class's instructor, co-instructors and TAs, always. Students cannot by default — each ask is an AI call on the instructor's plan, and a comment box is one keystroke from a loop. An instructor can turn it on for their class in the class settings; a student's ask then works on their own repository only, and still stops after five reviews on one assignment where a teacher's does not.

The namespace matters: a repo can run other review bots alongside ours, and /cin90 is what reaches us.

For instructors

Reviews are on by default and included in your plan. A busy branch stops reviewing itself after five reviewed commits, so a student pushing twenty times does not spend twenty reviews; your own /cin90 review overrides that ceiling, and a student's does not.

Students cannot run the command until you let them. It is a per-class setting, off by default, in your class settings. Turning it off does not take away the automatic review on every passing run.

If your class is set to approve AI feedback before it is published, branch reviews are not written at all — the approval queue is built around failure explanations, and a review has nowhere to be read before it goes out. Turn approval off to enable them.

Classes on their own AI provider key do not get branch reviews yet.

What it is not

It is not an anti-cheat boundary, and it is not a second grader. The review reads code a student controls, so treat it as advice a reader can weigh, the same as any reviewer's. The mark comes from the tests.

Setting up a class? Move a course off GitHub Classroom, or see plans and pricing.