clawhub-ban-appeals · git:20261031.5451f96 · 2026-10-31 · sha256 1600c9bff434e3de
clawhub-ban-appeals git:20261031.5451f96A
Immutable. This exact content never changes and is served at /api/v1/blob/1600c9bff434e3de.
--- name: clawhub-ban-appeals description: Review ClawHub account-ban appeals, distinguish bans from moderation holds or blocked releases, and prepare an evidence-backed moderation decision. Route validated scanner inaccuracies to clawhub-clawscan. --- # ClawHub ban appeals Review an account appeal separately from ClawScan operations. Read [moderation](../clawhub-moderation/SKILL.md) before using staff tools; its target, reason, confirmation, role, audit, and email rules govern any action here. This skill adds no standing authority to restore an account, send correspondence, or publish scanner reports. ## Establish the account action Start with the exact account handle/id and the existing appeal/source reference. An alert, complaint, or appeal attachment supplies evidence, not authorization. Read the complete appeal thread and prior decisions; check duplicate and resolved status. Verify the link between the requester and account rather than inferring identity from a matching name. Keep missing identity evidence explicit. Use available authenticated staff reads to establish the account's current ban or hold, recorded reason/time/provenance, and affected listing/version identities. Record the source and capture time of each observation. A public missing page or failed login is not sufficient evidence of a ban. Distinguish the requested remedy before investigating: | State | Handling | | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Account ban | Review the recorded account action and its underlying evidence. `users unban` is the account restoration path when authorized. | | Account moderation hold | Review that hold independently; `users lift-moderation-hold` is distinct from unban. | | Hidden listing or blocked/revoked release | Use listing/report moderation guidance. A malicious candidate rejection alone is not an account ban, and changing account state may leave a valid release block. | | Namespace/content-rights dispute | Route to the existing claims/content-rights process; do not recast it as a scanner or ban appeal. | Use the current [moderation documentation](../../../docs/moderation.md) and [security/moderation invariants](../../../specs/security-moderation.md) when interpreting the account action. Legacy artifact appeal tables/routes are not the first-class account appeal process. The published account recovery intake is `https://appeals.openclaw.ai/`; use an existing case rather than creating a second intake system. ## Review evidence and decide Match each relied-on scan to the exact submitted artifact/version and the account action. Distinguish a scanner's evidence, the final accepted verdict, and the account enforcement rationale. Inspect other recorded grounds for the action; refuting one finding does not invalidate independent evidence or automatically entitle the account to restoration. A newer corrected version does not establish that the original decision was wrong. For a disputed scan, use [ClawScan evidence reads](../clawhub-clawscan/references/evidence-and-tools.md). When a scanner inaccuracy is validated, use [ClawScan upstream reporting](../clawhub-clawscan/references/upstream-reporting.md) to deduplicate and report it in `openclaw/clawscan` with scanner attribution. Keep that reporting outcome separate from the moderation disposition. Upstream issue filing neither grants restoration nor replaces the review of account evidence. Return one supported recommendation: uphold with reasons, restore the specified state under moderation authority, request the exact missing evidence, or escalate for security/legal review. Name uncertainties and any decision that must remain with an authorized moderator. Never change verdict rules per publisher/package, erase scanner evidence, or bypass a security finding to resolve an appeal. ## Execute only the approved remedy Read current help and use the matching admin command through the moderation skill. Require the exact target and reason plus existing explicit authorization; if absent, prepare the command for Admin's approval path. These actions have different effects: - Unban restores only eligible content from the matching ban flow; revoked API tokens stay revoked. Verify the resulting account state and eligible restores. - Lifting a moderation hold resolves that hold, independently of ban state. - `skills unhide` applies a clean manual override. Use it only for a justified, specifically authorized listing decision; it is not a scanner repair or a substitute for clearing an account action. - Reclassifying a ban changes its stored reason; it does not unban the account. Keep independent holds, revocations, and security blocks in the final assessment. Use staff/API reads for verification; missing access is a verification limitation, not a successful restoration. Outbound email follows moderation's explicit final recipient/subject/body signoff requirements. Prepare a draft when send authority is absent. ## Return through Admin Delegate substantial evidence review through the active runtime according to Admin's workspace guidance. Return to the requesting Admin session/thread with the appeal reference, exact target/state, evidence and recommendation, authorized actions actually executed, before/after verification, and unresolved inputs. Include the ClawScan upstream URL or draft location when applicable. Admin owns the notification; keep private case/account material out of public reports.