What maintainers need

A workflow should be able to skip a rule group based on who opened the pull request. For example, "Skip when the author is a GitHub App bot" would exempt App-authored PRs from file-count and rate-limit checks. The inverse, "Skip when the author is a user," would run those checks for App bots only. Maintainers also want to allow or block a set of named accounts and optionally subscribe to a shared list of accounts confirmed to be sending spam.

Stage 1 · Account checks and repo policy

• Expose the PR author's account kind in Skip when and as a normal check. Support App bot, user account, and unknown. Treat unknown as insufficient evidence to skip in either direction. Classify the PR author from GitHub data and test events where the webhook sender differs from the author.
• Test both an App using an installation token and an App acting on behalf of a user. GitHub attributes the latter to the user. A username suffix or the webhook's installation field is insufficient to establish the author's account kind. GitHub App identity reference
• Build on the existing Username custom-rule signal with exact, case-insensitive list membership. Let a repository allowlist skip the selected rule group and let a denylist route to the repository's chosen action. If both match in the same policy, the explicit deny wins.
• Verify the editor, custom-rule builder, SDK, and CLI preserve the same identity, match mode, and skip behavior after save, pull, and push.

Stage 2 · Shared spam blocklist

• Create a separate maintainer-owned repository for the list and its contribution policy. Use reviewed changes and publish versioned, machine-readable snapshots. Key entries by stable GitHub account ID with login as a display label. Require a reason, evidence reference, review or expiry date, and a documented correction and removal process. Keep private evidence out of published snapshots.
• Offer the feed as an opt-in rule per repository. Start with match-only audit or human review on staging, then offer automatic blocking as an explicit action after validation. Make the matched entry, reason, and snapshot revision visible in the run. Keep blocking scoped to the subscriber's repository.
• Validate snapshots before activation. Use the last valid snapshot only until its freshness limit, then report the feed as unavailable. Test rename and login reuse, removal, expired entries, invalid updates, and outages with synthetic accounts before enabling automatic blocking.
• Record the scope decision in DECISIONS.md before implementation of the shared feed. Cross-repo bans are on the current cut list.

The first stage can ship independently. The shared feed adds a separate maintainer responsibility and should start with a review-only staging trial.

Feature flag and launch announcement

• Put the shared blocklist behind a server-side feature flag, off by default. Roll it out to selected repos first and gate the rule, setup controls, and announcement on the same eligibility check. Each eligible repo still opts in and chooses an action.
• Place one New in Tripwire item in the signed-in dashboard's sidebar/header news slot. Show it only to maintainers who can configure the feature on the current repo. The CTA opens setup, where the maintainer can review the list and choose what happens on a match.
• During the review-only trial, use Review matches from the shared spam blocklist. Use the automatic-blocking announcement once that action is available to the viewer.

Automatic-blocking announcement

New in Tripwire

Automatically block known spam accounts

Turn on the shared blocklist to block pull requests from accounts flagged for spam.

CTA · Set up blocklist

Staging pilot delivered

The maintainer opt-in is live on staging scratch. The card's button reads Turn on and New in Tripwire is the parent heading. The worker routes fresh snapshot matches to Human review. The snapshot repo has an empty initial list, validation CI and required review. The feature is off unless the web and worker environments explicitly allow the repository ID.

The promotion PR includes the before-and-after images. Account type, username lists, automatic blocking and wider rollout remain separate work.