Push to default branch
Use this when you want fresh questions every time a student pushes to their main branch. It's the simplest setup, and a good first choice.
Submission tag
Use this when you want to assess finished work once, when the student says they're done, rather than on every push. Ordinary pushes don't run it, and it costs one AI call per submission.
Milestone tags
Use this when a project is handed in over several stages, and each stage should get its own assessment. Each tag gets its own issue, PDF and instructor-repository folder, so earlier stages are kept when later ones arrive.
Separate workflow per phase
Use this when each stage of a project needs its own instructions for the AI, and each stage should be asked only about the work since the one before it. Each phase gets its own workflow file. This is the phase2 one.
Codebase context
Use this when the code being assessed builds on other code in the repository, and you want questions about how the pieces fit together. The AI is given your unchanged starter code and, when each milestone is assessed on its own, the student's earlier milestones as background. Every question is still about the code being assessed.
Ask about starter code
Use this when students build on substantial starter code, such as a "fill in the TODOs" template, and you want a few questions to check they understand the code they were given, not only the code they wrote.
Manual run overrides
Use this when you want to change a setting for a single run, such as a different number of questions or a different model, from the Run workflow form in the Actions tab, without editing the file.
Two sets of questions
Use this when one assignment needs more than one set of questions, each with its own instructions, such as a checkpoint part-way through a lab and a final review at the end, and you run each set by hand.
Preview the files
Use this when you want to check which files a run would assess, in a real repository, before any questions are generated: before the first assessed run, or after changing a pattern.
Same stack for every student
Use this when every student's repository should have its files chosen by the same rules, whatever a student adds to it. It suits an assignment whose starter template fixes the language and the folder layout.
Assignment brief as context
Use this when you want the questions to follow what the assignment asked for. GrillMyCode reads your brief, rubric or requirements from the repository and gives them to the AI along with the student's code.
Research or tracing questions
Use this when you want every question to send students to the documentation, or every question to be answered by running the code in their head. Research questions ask why a line is needed, what a library call does here, or what happens on an edge case. Tracing questions ask for the value a function returns, how many times a loop runs, or the order things happen in.
Capable model, lower reasoning
Use this when you want a more capable model than the default, but not the cost of the reasoning it does unless told otherwise. Some models reason at a high level by default, and on one 20-question run that reasoning was about nine-tenths of the output billed.
Private answer key
Use this when you want every student's questions with the answers, and a multiple-choice quiz for your LMS, in a private repository only instructors can see. Classroom 50 assignment repositories only.
Repository labels
Use this when you want to see, straight from your organization's repository list, which student repositories have questions. It needs the private answer key token.
Using the action's outputs
Use this when a later step in your workflow needs the results, for example to post the issue link somewhere else or keep a copy of the questions.
Every input, annotated
Use this when you want to see every setting in one place. Each input has a comment explaining it, and optional ones are commented out. Delete what you don't need.