User:Swatjester/Sentinel

Sentinel is a user script for counter-disruption patrolling on the English Wikipedia, particularly around WP:MILHIST topics. It puts contentious topic/general sanctions alerts, standard user warnings, a set of single-issue notices that don't have good template equivalents, and barnstars all into one floating panel. It also features an optional capability for AI-assisted analysis and triage of a target user's recent edits. It is not a Twinkle replacement. It doesn't revert, doesn't report to AIV, and doesn't block or have any access to any privileged tools. It simply posts talk page notices, and tries to help you make sure they're the right notices, to the right person, at the right level.

Note: This script is under active initial development -- it is not yet stable, and may be buggy or exhibit surprising behavior. Always doublecheck that any warnings are going to the right target and always take the time to read the confirmation dialogues and use the preview to be sure. You are responsible for your actions with this script once you take off dry run mode.

Add the following to your common.js (English Wikipedia only; the script refuses to run anywhere else):

importScript('User:Swatjester/Sentinel.js');// Backlink: [[User:Swatjester/Sentinel.js]]

A "Sentinel" link appears in your personal toolbar (on Vector 2022, next to the user menu). New installs start in dry-run mode: everything works and previews render but nothing actually posts. Turn that off in Settings once you've seen what it does and trust it and are willing to take responsibility for anything that goes wrong.

The panel detects the user you're probably looking at (diff author, contributions page, user talk page, and so on) and tells you where it got the name from. Detection that relies on scraping the page body is flagged in orange so you verify before posting. If it guesses wrong, Alt-click any user link on the page to target that user instead.

• CTOPS and GS alerts. Checks the target's full talk history, including revision tags, to decide between {{Contentious topics/alert/first }} and {{Contentious topics/alert }}, and uses {{Gs/alert }} for community-authorized areas.
• Standard warnings. The multi-level uw- series. These are mostly the same warnings you'd get in Twinkle (though some are new), grouped by problem type, with level clamping so that it won't try to post a level 4 of a template that stops at 3. It does not include all warnings, only the ones most commonly used in counter-disruption patrolling.
• Single-issue notices. WP:BURDEN and WP:ONUS reminders, source misrepresentation, battleground conduct, and similar reminders to help address conduct and content issues that are potentially disruptive.
• Warning history checks. Before posting a warning Sentinel scans the target's talk page and the last 90 days of talk page edit summaries (i.e. blanking a level 3 doesn't reset the count), then asks whether to escalate, keep your selected level, or stop.
• Previews. A "Rendered" tab shows the message exactly as the recipient will see it, with things like subst and signature expanded; a "Wikitext" tab shows exactly the raw content what gets saved. The confirmation dialog shows the rendered version again before anything posts.
• Barnstars. Patrolling isn't all warnings. You should, over time, begin to recognize certain editors as being quality contributors, and this is a nice way to reward them for their work. Like warnings, not all types of barnstars are present, just a few that are relevant to this kind of work (especially in WP:MILHIST).

Posting should be edit-conflict safe.

Every edit Sentinel makes carries the Sentinel change tag in addition to the summary link, so its edits are filterable in histories, watchlists, and recent changes. If the tag ever can't be applied, the edit goes through untagged rather than failing.

• Dry run: on by default for new installs, turn off to actually use the script for real
• Confirm before posting: on by default. Leave it on.
• Watchlist behavior: whether to add the relevant page to your watchlist. Options are no change, watch, or use your preferences.
• Per-page rules: Ignore this until you've read the below section for a detailed explanation.
• Model: pre-filled per API format, cheapest first; Custom accepts any model string, but currently only Anthropic models work. In general, Haiku is adequate for most work but may struggle with complex cases, and Sonnet is good enough for 99% of anything you'll encounter. But, if you want to burn the tokens, Opus and Fable are (overkill) options too.
• Reasoning: Off by default; higher tiers are slower and cost more. If verification is on, this is less likely to be necessary. Consider only turning it on when you have a particularly thorny problem to check. Note: With reasoning off, results will be nearly deterministic, while with reasoning on, they are less repeatable/reproducible.^[a]
• Verification: Standard by default; runs web searches as needed. Can set to Off (no web verification) or Thorough (requires a search for any sourcing-related finding). Web searches add to cost (about 0ドル.01 per search). See details below.

My recommendation is to use: Dry Run off, Confirm before posting on, Watchlist behavior watch, no per page rules, Haiku for your model, with reasoning Off, and verification set to either Standard or Thorough. This is the best balance of cost, accuracy, and safety. Bump the model up to Sonnet or stronger and/or turn on reasoning if you want better analysis of policy and for more complex datasets (complex move vandals, sockpuppetry, etc) at greater cost.

Note: I have not tested this functionality since prior to the release of Sonnet 5 (nor added in Fable as an option), so if you encounter errors due to changes in the model API, my script may not be up-to-date, please let me know.

The code contains an optional feature that sends a target's recent diffs to an LLM endpoint for triage: source misrepresentation, unsourced additions, ECR concerns, and the like, flagged for human review and never acted on (just information presented to you).

• Q: Why these specific sets of warnings/notices? Can we change them?
  • A: These are the ones I use most frequently on a daily basis, and I made this tool for myself first, with a secondary goal of being possibly useful to others who edit in a similar namespace. If you want to use different warnings, just fork a copy on your own and add your own warnings -- just make sure to change the name away from "Sentinel" so as not to confuse anyone into thinking it is the original base version.

• Q: Can the tool revert or block?
  • A: Not at this time. That functionality is adequately handled by Twinkle already, so it's not on the shortlist to add either.

Hit me up on my main talk. Include your skin, what you clicked, and a permalink or diff if there is one. This is a beta, and you are responsible for every edit it makes under your name, same as any other tool.

1.3.1

• Fixed analysis results rendering as "Unparseable response" when the model narrated prose around its JSON answer (common when web search is active): the parser now locates the JSON anywhere in the response. When no JSON exists at all, the raw text is shown.

1.3.0

• Fixed the worst class of AI false positives (date cutoff issues): the model is now told the current date and forbidden from alleging hoaxes or fabrication based on its own knowledge cutoff. This was the source of "this 2026 event hasn't happened" findings.
• Added new Verification setting (default: Standard): the model runs live web searches before flagging recent events or claims as hoaxes or unverifiable. Multiple independent hits weigh against a hoax; an empty search caps the finding at medium severity. Thorough mode requires a search before any sourcing-related finding. This adds to the cost of the analysis: rates are around 1ドル per 100 searches plus the input token cost for the retrieved output. On default settings using Haiku, you might expect between two and six searches per analysis, which probably adds between 0ドル.02-0ドル.10 total cost. Higher fidelity models and searches with more hits requiring verification will increase this. As always, cap your spending to prevent surprises.
• Findings now show what was searched and found on a per-issue verification line.
• The model can also search English Wikipedia itself to bolster corroboration, executed through the normal MediaWiki API. "Corroboration" in this context does not mean verification as per WP:V, but rather represents feedback of data points into the model's confidence level as to the likelihood that a user is not being intentionally disruptive. For instance, an editor inputs a name that appears in dozens of other articles, the model interprets it as a weak signal that the actions are not a hoax and likely to be in good faith. Actual verification is still handled by the aforementioned live web searches.

1.2.1

• Fixed the panel loading midway up the page: a click on the header background (without dragging) was being saved as a position, and saved positions were top-anchored. Dragging now requires actual movement, positions persist bottom-anchored so the panel keeps hugging the bottom edge, stale saved positions are cleared automatically, and double-clicking the header resets to the default corner.
• AI analysis findings now render readably instead of as raw JSON: severity badges, plain-language issue categories, and the affected revisions as clickable diff links, sorted most-severe first.

1.2.0

• The custom page criteria JSON box is replaced by a plain-language rule editor in settings. Existing criteria carry over unchanged.

1.1.0

• Model picker pre-filled per API format (Haiku/Sonnet/Opus/Fable for Anthropic), cheapest as default, with a Custom entry for any model string.
• Reasoning setting: extended-thinking budgets on Anthropic, reasoning_effort passthrough on OpenAI-format endpoints. Off by default.
• The Sentinel change tag is now always applied (with a graceful untagged retry if the tag can't be); the settings toggle for it is gone.
• OpenAI-compatible format labeled as requiring a relay, which doesn't exist yet; clearer error text distinguishing CSP blocks from endpoint-side browser refusal.

0.9.1

• Merged the duplicate Sourcing, Conduct, and Style categories. Each category dropdown now holds both the leveled warnings and the single-issue notices for that problem type, separated within the menu.
• The preview pane updates when you change a dropdown selection, not on mouseover. Stray hovers no longer swap the preview out from under you.
• Fixed a dialog bug that asked for confirmation a second time, in a plain browser dialog, after the rendered confirmation had already been accepted.

0.9.0

• Dark mode support via Codex design tokens; renders identically on Monobook and legacy Vector.
• Project-page link in summaries centralized to one constant (WP:SENTINEL); history matching is case-insensitive.
• Escalation thresholds named and documented (leveled warnings surface prior level 3+; unleveled notices only surface a prior final warning).
• Settings now warn that the API key is stored unencrypted in the browser.
• Changelog moved out of the script and onto this page.

0.8.0

• OOUI dialogs replace window.confirm/prompt, with fallback to native prompts if OOUI fails to load. Escalation gets real labelled buttons; the post-confirmation dialog shows the rendered message.
• Panel: draggable header, position and open/closed state persist across page loads, compact mode.
• Warning history also scans the last 90 days of talk page edit summaries (Sentinel and Twinkle formats), so blanked or archived warnings still count.
• Page field suggests the target's last five distinct edited titles.
• Month-section merge ignores header lookalikes inside nowiki/pre/syntaxhighlight/comments.
• Custom page criteria keys normalized through mw.Title.

0.7.0

• User targeting overhaul: wgRelevantUserName takes priority, detection source shown in the panel, redetect button, Alt-click any user link to target, username validation before posting.
• Fixed: on a user talk page, explicitly choosing a different user was silently overridden by the page's root user for both content and target.
• Successful posts link the saved diff in the status line and a notification.
• AbuseFilter warn-mode resubmission fixed; watchlist behavior is now a setting; dry-run default for fresh installs; visible launcher placement on Vector 2022.

0.6.0

• Talk page writes resolve redirects and use base/start timestamps, so concurrent edits raise a conflict (retried once) instead of being overwritten.
• Preview pane gains Rendered and Wikitext tabs; the rendered view shows the recipient's-eye message with subst and signature expanded. Parses are cached and debounced.
• Prior-CTOPS-alert lookups cached per user instead of re-walking full talk histories on hover.

0.5.2

• Synchronized the userscript metadata version and in-panel displayed version.
• Added regression coverage to ensure the metadata `@version` and internal `VERSION` value remain matched.
• Added README documentation covering installation, notices, warning shortcuts, AI analysis, and current limitations.

0.5.1

• Added barnstar support, including Military History, Original, and Constitutional barnstars.
• Added custom barnstar message support using the shared additional-text field.
• Added barnstar preview and posting support in the Sentinel panel.
• Added tests for barnstar wikitext formatting.

0.5.0

• Added talk-page warning-history detection for prior standard and custom warnings.
• Added safeguards for recent warnings and high-level warning escalation.
• Added warning-level clamping so templates that do not support level 4 or 4im fall back to the highest valid level.
• Added tests for warning-history parsing and level handling.

0.4

• Expanded quick warning support with grouped standard warnings for sourcing, conduct, content, communication, style, and related patrol issues.
• Added Sentinel-specific custom warnings for source misrepresentation, unreliable sourcing, `WP:BURDEN`, consensus, `WP:ONUS`, status quo, BRD/discussion, battleground editing, and related recurring workflows.
• Added support for optional page names and additional custom text in warnings.
• Added month-section insertion so repeated notices and warnings are placed cleanly under the current monthly heading.
• Added tests for custom warning formatting and month-section insertion.

0.3

• Added one-click contentious-topic and general-sanctions notices.
• Added support for US politics, Indian military history, Arab-Israeli conflict, Iranian politics, and Russia-Ukraine War notice workflows.
• Added detection of prior contentious-topic alerts using talk-page revision tags and talk-page text.
• Added correct first-alert versus subsequent-alert handling for ArbCom contentious-topic notices.
• Added AbuseFilter warning handling for contentious-topic alerts, with confirmation and retry using `ignorewarnings`.
• Added tests for contentious-topic and general-sanctions notice formatting.

0.2

• Added target-user detection from user pages, user-talk pages, diffs, contributions links, and relevant MediaWiki page context.
• Added page-title detection for warning page parameters from diffs, referrers, and article URLs.
• Added safeguards to avoid treating non-content namespaces as article targets.
• Added tests for user and page target parsing.

0.1

• Initial Sentinel userscript implementation for English Wikipedia.
• Added personal-toolbar launch link and panel UI.
• Added persistent settings support using userscript storage with localStorage fallback.
• Added OpenRouter-compatible AI analysis settings and request flow.
• Added recent-contribution and diff collection for AI-assisted patrol triage.
• Added configurable per-page criteria for article-specific review checks.