comment_moderation v1.0.0

name: comment_moderation description: Set up and run comment moderation for a community, page, or forum. Builds tiered policies (severity levels with matching enforcement actions), configures automation assists like keyword blocklists and trusted-user bypass, and provides a raid/brigade response playbook. Triggers when someone asks to moderate comments, write a moderation policy, handle spam or trolls, set up comment filters, or deal with coordinated harassment or brigades. metadata: { "includeInPrompt": true }

Comment Moderation

Purpose

Give an agent everything it needs to stand up comment moderation for a community: a written policy with clear tiers, enforcement actions that scale with severity and repeat behavior, automation that handles the volume, and a plan for coordinated attacks (brigades and raids). One clear job: keep the comment section usable without silencing the community.

Workflow

1. Define the policy tiers

Every moderation decision hangs on two questions: what is it, and how bad is it. Start by naming the harm categories that matter for THIS community, then slot each into a severity level:

• Critical, always block: threats of violence, CSAM, terrorism, doxxing, anything illegal. No warnings, no second chances.
• High, usually remove: targeted harassment, hate speech, graphic violence. First offense may earn a warning in a small community; remove on sight at scale.
• Medium, flag or warn: profanity, spam, off-topic floods, misinformation. The comment lives or gets held for review; the user gets told why.
• Low, allow: mild negativity, criticism, unpopular opinions. Moderating these is how communities die.

Context decides. The same sentence can be therapeutic in a support group and a violation in a gaming forum. Write the tiers for the actual community in front of you, not a generic internet.

2. Map severity and history to enforcement actions

Decide the actions before you need them, and write them down so enforcement is consistent no matter who is on shift:

• Warn with explanation: tell the user which rule they broke and what happens next. Explaining the why trains the whole community, not just the offender.
• Hide or remove the comment: the content goes, the user stays.
• Temporary ban: hours to days. Use fixed windows (e.g. 48 hours) so it is predictable.
• Permanent ban: repeat offenders only, and always reviewable.
• Shadow block: the user's posts are visible to them alone. Use sparingly, for persistent bad actors, and know that users in many communities consider it dishonest. Prefer transparent actions when you can.
• Escalate legally: real threats, CSAM, anything criminal goes to law enforcement. Preserve evidence (screenshots, logs, timestamps) before you act.

Then build a repeat-offender ladder, for example: first offense warn, second offense 48-hour ban plus removal, third offense permanent ban. Critical-tier violations skip the ladder entirely. These are worked examples, adjust them to fit the community.

3. Set up automation assists

Automation handles volume; humans handle judgment. Layer them:

• Keyword blocklists: two lists, not one. A hold list sends matching comments to a review queue (safe for broad or partial matches, since substring matching catches innocent words too). A trash list rejects outright (only exact, unambiguous terms). Review both lists regularly; language moves fast.
• Link limits: hold comments with more than a set number of links (2 is a common default). Bots live on links.
• Trusted-user bypass: users with a previously approved comment skip the moderation queue. This is the single cheapest way to cut queue volume as the community grows.
• Pre-moderation vs post-moderation: pre-moderation (approve before posting) fits small, high-trust spaces and brand pages. Post-moderation (live immediately, reviewed after) fits real-time communities, but it needs the queue cleared fast. Pick one and say why.
• Community-driven moderation: user reports, mute, block, and upvote/downvote collapse. Make reporting easy to find, and let reporters attach context. Every report is a free moderator.
• Platform-native filters first: most platforms ship built-in toxicity and spam filters. Turn them on before buying a third-party tool.

4. Prepare the raid and brigade playbook

Brigades (coordinated mass downvoting, reporting, or flooding from another community) and raids (a sudden influx of hostile commenters) need a different tempo than day-to-day moderation. When one hits:

1. Detect early: watch for a sudden spike in comment volume, brand-new accounts commenting in lockstep, or identical copy-pasted text across many comments. These are the signals.
2. Slow the feed: enable slow mode, rate limits, or require a minimum account age before commenting. This breaks coordination without banning anyone.
3. Contain, then sort: hold suspicious comments for review rather than banning on sight. Many raid participants are followers, not ringleaders; you want the organizers, not the crowd.
4. Ban the coordinators: accounts posting the call-to-arms, dropping the target link, or running sockpuppets get permanent bans immediately. A raid is a critical-tier event, it skips the ladder.
5. Communicate once, publicly: a short pinned note saying what is happening, what you are doing, and where the rules are. One calm message beats forty reactive deletions. Do not argue with raiders in the comments.
6. Log everything: timestamps, account names, what was posted, what you did. You need it for appeals, for platform reports, and for the next time.

5. Build reporting and appeals in from day one

A moderation system without appeals breeds conspiracy theories. Every enforcement action should tell the user: what rule was broken, what the consequence is, and how to appeal. Appeals go to a human, not the same automation that acted. Log every decision with the rule cited so you can audit consistency later.

6. Review the policy on a schedule

Language, threats, and community norms all drift. Re-read the tiers and the blocklists quarterly, or right after any major incident. Retire rules nobody enforces and add the ones the queue keeps proving you need.

Output Contract

When this skill is asked to set up moderation for a community, deliver:

1. The policy tiers written for that specific community: harm categories, severity levels, and the context notes that make borderline calls obvious.
2. The enforcement ladder: which actions map to which severity, and the repeat-offender sequence.
3. The automation config: hold list, trash list, link threshold, pre/post moderation choice, trusted-user bypass setting, and which platform filters are enabled. Use bin/moderate_dryrun.py to sanity-check the config against sample comments before going live.
4. The raid playbook filled in with the community's actual tools (where slow mode lives, who has ban rights, the pinned-message template).
5. The appeals path: how a user finds out why they were actioned and how they appeal.

A policy template with worked examples lives in references/policy_template.md. Adapt it, do not ship it as-is.

Operating Rules

1. Never invent statistics, case law, or platform features. Every factual claim traces to a source in references/ or a primary document you have actually read.
2. Context beats pattern matching: a keyword hit is a signal for review, not proof of a violation, unless the term is unambiguous.
3. Proportionality is the whole game. A first-time minor violation gets a warning and an explanation, never a ban.
4. Low-tier content (criticism, mild negativity) is not a violation. Moderating disagreement destroys trust faster than any troll.
5. Critical-tier violations skip the ladder. Coordinated raids skip the ladder.
6. Every action is logged with the rule cited. Every user can appeal to a human.
7. At scale, keep humans on the edge cases: automation blocks the obvious, humans decide the ambiguous. Shadow blocks are a last resort, not a convenience.