How to trigger reviews, the commands the bot understands, the config file, the GitHub Action, the API, and how visual QA works. Reference, not marketing.
Install the GitHub app and point a ShipGuarde project at a repo. No config files required to start.
Add the shipguarde label or comment @shipguarde run. Reviews are opt-in; nothing runs until you ask.
A status check, inline comments, and a sticky summary land on the PR with one clear ruling.
A run is never started by the mere existence of a PR. It starts only when you ask, one of three ways. Any comment that creates a run requires the commenter to be a repository collaborator.
Add the shipguarde label. Reviews run when the PR is labelled, and re-run incrementally on new commits.
@shipguarde run or a plain-English request on the PR.
Hit Re-run on the ShipGuarde check, or call the Action / API from CI.
Mention @shipguarde at the start of a line. run, review, check, and test are equivalent run verbs.
@shipguarde runReview this PR with the default suite.
@shipguarde run code-review securityRun only the named agents (see the agent catalog for kinds).
@shipguarde review src/apiRe-review a single path prefix (code review only).
@shipguarde verify login works on https://preview.example.comDescribe a flow in plain English; it runs visual QA against that URL.
@shipguarde ignore src/legacyStop flagging issues under a path. @shipguarde ignore all mutes the project.
@shipguarde helpPost the command list.
You do not have to leave the PR. Reply to any inline finding and ShipGuarde acts on it.
Suppresses the finding and remembers it, so it will not be raised again on future runs.
Accepts the finding as a deliberate choice and mutes it going forward.
Re-checks the file at the latest commit, verifies the issue is gone, and resolves the thread with evidence.
The first two actions are also available as checkboxes on every finding comment.
Commit a config file to the repo and it is read at the PR head, so the policy is reviewed in the same PR. Looked up as .shipguarde.yml, .yaml, or .json.
v1 supports one key. Richer knobs (block-on-major, block-on-lint, skip-drafts, per-agent enable/disable) live in your project settings in the app for now, not the file.
The Action starts a PR-mode run, waits for the verdict, and exits non-zero per fail-on so your job gates the merge independently of the check.
| INPUT | DEFAULT |
|---|---|
api-key | required |
project-id | required |
api-url | https://api.shipguarde.com |
target-url | (none) |
agents | project policy |
fail-on | block |
timeout-seconds | 900 |
Outputs: run-id and verdict. fail-on accepts block, block_or_warn, or never.
Create a personal access token (sg_pat_…) in the app, then start a run and poll for the verdict.
Poll run.status until terminal (completed, cancelled, or errored), then read run.verdict.decision: ship · ship_with_warnings · block · inconclusive.
Use a kind as a token in @shipguarde run <kind>. DEFAULT agents run automatically; OPT-IN ones are a toggle in project settings.
code-reviewlintsecuritydependency-licenseschema-driftmigration-safetybundle-budgetvisual-qavisual-regressionconsole-networkseo-metaa11yperformanceruntime-securitybroken-linkscontent-copycookie-privacyvision-defectDiffs are computed against the merge base, so a branch that is behind its target is reviewed only for its own changes, and large PRs are scoped to the highest-signal files with a note on coverage.
On new commits it reviews what changed since the last review, not the whole PR again. Scope a single path with @shipguarde review <path>.
ship is clear, ship_with_warnings is endorsed with non-blocking notes, block holds a critical issue. Rarely inconclusive when it could not reach a confident ruling.
A block is advisory by default. Set failCheckOnBlock (repo or project) so branch protection can require the check, or use the Action's fail-on to fail the CI job.
Point it at a URL and it drives your app the way a person would, grounding on what is visible rather than CSS selectors, so flows survive redesigns.
Run a flow on demand against any public URL, or on a cron schedule for continuous monitoring.
Store credentials per project (encrypted at rest) so it can sign in and test authenticated pages.
A run-completion certificate by email, plus Slack, with per-run recipient lists and reusable org mailing lists.
Status checks, inline comments, and a sticky summary land on the PR. For URL runs, a shareable report.
More on PR review, visual QA, and security. Something unclear? Email [email protected].
Code review checks the diff. ShipGuarde also checks the running product, so a release does not ship on the hope that nothing broke.
NO CREDIT CARD · CONNECT GITHUB IN UNDER FIVE MINUTES · CANCEL ANY TIME
RELEASE CLEARANCE BUREAU
ISSUING AUTHORITY FOR SOFTWARE RELEASES
[email protected]