Why Acceptance Criteria Matters
When you provide acceptance criteria in your issue, Cyrus treats it as a checklist to verify its own work. After completing the initial implementation, Cyrus will specifically check each acceptance criterion and loop up to 3 times if necessary to ensure it achieved your goal. This self-verification behavior means:- Better results without back-and-forth: You don’t have to correct Cyrus 5 times if you clearly define what “done” looks like upfront
- Higher token usage: Cyrus may use more tokens than running Claude Code locally because it’s actively verifying and iterating on its work (typically 3-5x more depending on task complexity)
- More autonomous operation: The clearer your acceptance criteria, the more confidently Cyrus can validate its work without asking you questions
Click this link to populate a new Linear issue with the contents seen below. Switch your active Linear workspace, and click again if it takes you to the wrong workspace.
- “what is the bigger picture outcome you’re hoping to drive”, this is important context
- frame what is the model supposed to be doing to help you achieve that, this is the objective in a bit more detail
- acceptance criteria: think to the end of the process, how would you validate its work? should there be at least 3 results it generates? what is something else in the world you can liken the standards you have to? (help it understand what quality / depth is acceptable). in what format / artifact would you like the results? You can even ask it to post a Linear comment as the ‘artifact’, which will have markdown you can copy-paste.
- “process notes”: this is something like: what overarching process would I myself follow to get to my goal, if I’m opinionated or experienced in that.
- references as links or filepaths, or any form of references, ones that it should definitely read or incorporate. Or else, based on web research from these 4 sources, etc.