.hacktron/config.yaml file to your repository to control Hacktron’s Code Review behavior:
- Skip specific pull and merge requests so they aren’t scanned.
- Fail the Hacktron check when a finding meets a severity threshold, so risky changes can’t merge.
.hacktron/rules.md, which shapes the quality of a review. config.yaml controls whether a PR is scanned and whether its check passes.
File location
Place the file at the root of the repository, inside the.hacktron directory:
.hacktron
config.yaml
rules.md
apps
packages
package.json
.hacktron/config.yaml or .hacktron/config.yml is accepted. If both exist, .yaml is used.
Example
config.yaml means Hacktron behaves as it does today: it scans all covered PRs and the check stays green unless the scan itself errors.
Skip scans
Use theskip block to tell Hacktron not to scan a pull or merge request. When a PR matches, Hacktron records a skipped check on the PR/MR and posts a short comment naming the rule that matched. No scan runs, and no developer seat is used.
Rules are evaluated in this order; the first match wins:
| Key | Matches when | Match style |
|---|---|---|
skip.labels | the PR/MR carries one of these labels | exact, case-insensitive |
skip.keywords | the PR/MR title contains one of these strings | case-insensitive substring |
skip.paths | every changed file matches one of these patterns | gitignore-style globs |
skip.paths skips a scan only when every changed file matches one of the
patterns. If even one changed file falls outside the patterns, the PR is
scanned as usual. Patterns use the same syntax as .gitignore — for example
vendor/**, **/*.md, or docs/.@hacktronai review comment always runs a scan, even when a skip rule would otherwise match — use it to force a one-off review of an otherwise-skipped PR.
Fail the check on findings
By default, the Hacktron check is green as long as the scan completes — findings are posted as inline comments but don’t block the merge. Setfail_on.severity to turn the check red when a finding is found at or above a severity threshold.
severity must be one of, from most to least severe:
critical › high › medium › low › info
The threshold is inclusive: severity: high fails the check on high and critical findings, while severity: critical fails only on critical. When a finding triggers the gate, the GitHub check run (or GitLab commit status) is marked failed with a reason such as 2 findings at or above high severity.
Only findings that haven’t been dismissed as false positives count toward
the threshold. Triaging a finding as a false positive removes it from the
gate. If no
fail_on.severity is set, the check passes regardless of what
Hacktron finds.How invalid config is handled
Hacktron is fail-open about configuration — a config problem never silently blocks your development:- A missing, empty, or malformed
config.yamlis ignored. Hacktron scans normally and the check stays green. - Unknown keys are ignored, so a config can carry settings for future features without breaking today’s scans.
- A type mismatch on a known key (for example
fail_on.severity: 7) causes the whole file to be ignored. Keep values in the shapes shown above.
Related
Project rules
Add
.hacktron/rules.md to give reviews repository-specific context.Setup
Connect a Git provider, enable repositories, and choose covered branches.