RFC: Content policy categories

[Patrick-Erichsen]

Context

ClawHub needs a clearer content-policy frame for deciding which skills belong in the public registry, which skills should be hidden or removed, and which uploads need human review.

This is intentionally not a complete RFC yet. It is a lightweight discussion thread based on the current category list so maintainers and contributors can agree on the shape before turning it into public policy.

Goals

• Turn the category list into clear review buckets.
• Separate low-quality or duplicate content from malicious or abusive content.
• Identify which categories should affect search visibility, registry inclusion, upload review, or account enforcement.
• Keep reviewer-only signals and exact detection tactics out of public policy.

Non-goals

• Define every scanner threshold, review workflow, or ban runbook.
• Decide final enforcement severity for every category.
• Publish private reports, reporter identities, or sensitive audit details.
• Treat VirusTotal alone as a malicious-content source of truth.

Draft category list

Category	Draft policy question	Likely default treatment	Notes
Possibly spam: bulk accounts, bot accounts, test/junk	Is this upload/account pattern primarily noise or automated registry abuse?	Hide from browse/search pending review; repeated or obvious abuse may lead to account action.	Needs examples that distinguish harmless testing from bulk spam.
Crypto / blockchain / finance / trade	Should ClawHub allow skills whose primary purpose is crypto, blockchain, finance, or trading?	Current leaning: do not allow these categories in the public registry.	Needs discussion on whether any narrow read-only or educational exceptions should exist.
Malicious as determined by security scans	Do security scans identify the artifact or author workflow as malicious?	Hide/remove the artifact and consider account-level review.	Security scan findings can support enforcement and should be reviewable by maintainers.

Feedback requested

Please comment with:

• category wording that feels too broad, too narrow, or confusing
• missing allowed, not-allowed, or edge-case examples
• which parts should become public acceptable-usage policy versus reviewer guidance
• whether any category should affect discovery, installability, official totals/reporting, or account enforcement

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 18, 2026, 4:14 PM ET / 20:14 UTC.

Summary
Keep this open: this collaborator-authored moderation/security RFC is still an active product and security policy discussion. Current main has broader acceptable-usage docs, moderation-state docs, and scanner-context safeguards, including the merged SkillSpector scraping delegation, but it does not fully settle the requested category-to-consequence matrix for crypto/blockchain boundaries, quality/spam handling, discovery, installability, upload review, and account enforcement.

Reproducibility: not applicable. this is a moderation/security policy RFC, not a runtime bug report. The high-confidence check is live discussion plus current docs, specs, source, and history review.

Root-cause cluster
Relationship: canonical
Canonical: #2321
Summary: This issue is the canonical discussion for content-policy categories; related trust-signal and security-plugin issues overlap but do not supersede it.

Members:

• partial_overlap: [Data] Quality signals for ClawHub Skills — we analyzed the top 50 and found trust gaps #1310 - It discusses public quality and trust gaps that overlap with the RFC's trust-signal and category-consequence questions.
• partial_overlap: Complementary tool: automated skill quality scoring for curation workflow #2042 - It proposes optional quality-scoring tooling for curation, which overlaps the RFC's distinction between quality/spam and malicious content.
• partial_overlap: Optional pre-agent security plugins for higher-assurance deployments #2280 - It asks for clearer review and trust paths for security-sensitive plugins, which overlaps but is not the same as content-policy category definition.
• partial_overlap: Delegate browser automation scanning to SkillSpector #2577 - The merged PR resolved one scraping/browser-automation scanner lane by delegating to SkillSpector, but it does not close the overall category RFC.
• adjacent_distinct: Request to restore paulgnz account access and skill visibility #2203 - The account and visibility recovery case supplied incident context for policy discussion but is closed and not the canonical category work.
• 1 more in the report.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
Manual maintainer and security review is required because the remaining work is policy synthesis, not a narrow source fix.

Security
Needs attention: Needs attention because this RFC can change registry access, scanner interpretation, installability, and account enforcement policy.

Review details

Best possible solution:

Maintainers should synthesize the RFC into a category-to-consequence matrix, land public-facing policy in docs, and preserve reviewer-only scanner and enforcement invariants in specs.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a moderation/security policy RFC, not a runtime bug report. The high-confidence check is live discussion plus current docs, specs, source, and history review.

Is this the best way to solve the issue?

Yes as the active discussion venue, but not as an implementation-ready automation item. The narrowest maintainable path is maintainer synthesis that separates content eligibility, scanner/audit evidence, trust signals, discovery, installability, and account consequences.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• An overbroad crypto/blockchain/finance bucket could conflate on-chain identity, reputation, escrow, read-only data, trading, wallet operations, and deceptive financial workflows.
• Mixing negative enforcement categories with positive trust signals could make visibility, installability, and account-action decisions inconsistent.
• Public docs need enough clarity for publishers and users without exposing scanner thresholds, evasion indicators, private reports, or reviewer-only tactics.

Codex review notes: model internal, reasoning high; reviewed against 22d3cd133cb6.

Label changes

Label changes:

• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P3: This is an important but non-urgent policy RFC with no current production outage or broken runtime workflow.
• impact:security: The RFC governs malicious-content handling, scanner interpretation, registry access, installability, and possible account enforcement.

Evidence reviewed

Security concerns:

• [medium] Resolve category consequences with security review
  The remaining policy decision should explicitly separate topic eligibility, artifact-backed maliciousness, scanner telemetry, positive trust signals, and account enforcement before docs or implementation changes claim completion.
  Confidence: 0.9

What I checked:

• Live issue discussion: Live GitHub state shows this issue remains open, authored by Patrick-Erichsen, and its comments still ask maintainers to separate enforcement categories from trust signals, distinguish on-chain identity/reputation from trading or wallet operations, and contextualize scanner findings before final policy.
• Current public acceptable-use policy is broader than the RFC matrix: Acceptable Usage now defines allowed and disallowed content plus broad enforcement actions, but it does not map the RFC draft categories to search visibility, registry inclusion, upload review, installability, and account consequences. (docs/acceptable-usage.md:23, 22d3cd133cb6)
• Financial category remains narrower than the open question: The current public policy disallows fraud, scams, and deceptive financial workflows, which is narrower than the RFC's unresolved crypto, blockchain, finance, trading, and possible exception boundaries. (docs/acceptable-usage.md:44, 22d3cd133cb6)
• Moderation docs describe states, not category consequences: Moderation and Account Safety documents holds, hidden or blocked listings, and bans, but it does not assign specific content-policy categories to each outcome. (docs/moderation.md:68, 22d3cd133cb6)
• Scanner/audit docs support but do not replace the RFC: Security Audits separates Pass, Review, Warn, Malicious, risk levels, VirusTotal telemetry, SkillSpector, and ClawScan context, but it is audit guidance rather than a final content-policy category decision. (docs/security-audits.md:36, 22d3cd133cb6)
• Internal scanner policy preserves reviewer-only boundaries: The security-moderation spec says static findings are internal ClawScan evidence, VirusTotal alone must never hide or block, and legacy review/suspicious/malware flags map to visibility differently; this supports the RFC's need to keep scanner tactics separate from public policy. (specs/security-moderation.md:193, 22d3cd133cb6)

Likely related people:

• Patrick-Erichsen: Patrick authored this issue, is listed in CODEOWNERS for backend moderation/security and acceptable-usage docs, and authored the recent acceptable-usage and scanner-policy commits that partially cover this area. (role: RFC author, CODEOWNERS-listed security/docs reviewer, and recent policy contributor; confidence: high; commits: 3a46cdd07e59, effd52a4ea4d, 7b71c15ee12f; files: docs/acceptable-usage.md, docs/moderation.md, docs/security-audits.md)
• Jesse Merhi: Jesse recently updated the security-moderation spec while removing retired moderation surfaces, which is adjacent to the policy-to-implementation mechanics after the RFC direction is decided. (role: recent adjacent moderation-surface contributor; confidence: medium; commits: 303075c82b48; files: specs/security-moderation.md)
• Andy Ye: Andy recently updated package artifact scan and repair invariants in the same moderation/security spec; this is adjacent to scanner/audit mechanics rather than the policy decision itself. (role: recent adjacent package-scan contributor; confidence: low; commits: 6d87fc07ef18; files: specs/security-moderation.md)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.