vouch

instead of writing a CLI dynamically, how about we ship one with this repo? this is required for putting vouch on homebrew, xref https://github.com/Homebrew/homebrew-core/pull/269267#discussion_r2852092812 xref #26 WDYT of this approach @mitchellh? verified it works locally by running . added a test for as well but didn't test this yet

A good point was brought up when we were thinking through implementing the vouch system for the OpenCode repo (we see a lot of AI slop, especially in issues) and someone in https://github.com/anomalyco/opencode/pull/12640#issuecomment-3865765666 brought up the thought of if someone changes their username they would be able to get around being . A bad user (that wants to spam) might change their username to get around being "banned/denounced" from a repo. I think a way to solve this would be to have in the file would be to include the userid of the user as well so that: would become The only caveat to this is since this isn't Github specific (and I don't have experience with other providers like Gitlab) I can't confirm if this is a reliable way to attain user-ids.

This adds the ability to customize the response used for unvouched users when closing pull requests or issues. For both and , the argument allows the ability to supply an optional template for use. This template follows the expansion rules as defined in Nushell's . The default messages for both of these have been moved to a new sub-directory and are now templates themselves, serving as an example for both how to template and also the arguments available (although they have also been documented). has also been added as an argument for the respective workflows. Closes #50.