Community Operations

Design and implement automatic community commenting workflows driven by existing site content, with optional support for automatic posting and multi-account...

Security Scan

The skill is coherent as an implementation guide for an automated commenting system, but it omits and mismatches several operational requirements (credentials, runtime language) that are necessary to actually run it — the omissions should be clarified before use.

Purpose & Capability

The name/description match the instructions: this is an implementation guide for content-driven automatic commenting with account rotation, scheduling, and optional moderation. However, the manifest declares a required binary (python3) while the SKILL.md repeatedly references PHP services/controllers and database tables (e.g., CommunityService, ContentsService, php CLI commands). There is no code in the bundle, so the python3 requirement appears unnecessary or unexplained.

Instruction Scope

SKILL.md stays largely within the declared purpose: it explicitly instructs how to select content, generate comments, rotate accounts, schedule, and hand off to moderation. It also references specific internal tables, controllers, and methods (e.g., post, contents, books, CommunityService::createPostComment()), which assumes the operator has access to the target codebase and DB. There is no instruction to read unrelated system files or exfiltrate secrets, but the guidance presumes privileged access to internal application state.

Install Mechanism

No install spec and no code files are included; this is instruction-only documentation. That minimizes direct supply-chain risk because nothing is downloaded or executed by the skill itself.

Credentials

The instructions require access to databases, account pools, and publishing endpoints (and implicitly account credentials and DB credentials) but the skill declares no required environment variables, config paths, or primary credential. This mismatch is important: a real deployment would need sensitive credentials/config access that are not declared or scoped by the skill metadata.

Persistence & Privilege

The skill does not request persistent presence (always:false), does not modify other skills, and has no install-time scripts. Autonomous invocation is allowed (platform default) but not combined with additional red flags in this package.

What to consider before installing

This package is an instruction-only design/implementation guide for automating comments. Before you adopt it: (1) note that it assumes privileged access to your app (DB tables, account records, existing comment APIs) — it does not declare the credentials or config needed, so decide and provision those securely (least privilege, separate operational accounts, audit logging). (2) The manifest lists python3 but the guidance mainly references PHP services and CLI commands — confirm which runtime/tools you will actually use. (3) Because automated multi-account commenting can be abused, enforce moderation checkpoints, rate limits, audit trails, and a manual kill-switch in staging before any production rollout. (4) If you need the skill to run code automatically, prefer implementing integrations that explicitly declare and scope the specific credentials/config paths required; do not provide broad admin credentials. If you want, I can list the exact credentials/config entries this design will require and how to scope them minimally.

Overview

Use this skill to build or operate content-driven automatic commenting systems. The primary use case is: read existing site content from the database, generate comments that match the content type, assign those comments to one or more accounts, and publish them with scheduling, rate limits, and optional moderation handoff.

This skill can later expand into automatic posting, but the first priority is automatic commenting based on existing content.

Core boundary

Keep responsibilities separate:

• This skill owns:

  • content selection for commenting
  • comment generation strategy
  • account rotation
  • scheduling and task orchestration
  • publishing execution
  • duplicate suppression
  • frequency control
  • operation logging

• This skill does not own:

  • moderation policy itself
  • ad/contact-risk rules
  • final moderation result semantics

If moderation is required, integrate a dedicated moderation skill or service such as post-content-moderation.

First-priority capability

Prioritize this workflow first:

existing content in database
→ extract content summary
→ generate comment candidates
→ choose account
→ optional moderation
→ submit comment
→ log result

Target content sources include:

• comics
• articles
• novels
• videos

Content-driven automatic commenting

Supported source types

Build a unified comment-input structure even if the original tables differ.

Recommended normalized fields:

• content_type
• content_id
• title
• summary
• author
• tags
• category_id
• topic_id
• published_at
• extra

Example:

{
  "content_type": "comic",
  "content_id": 123,
  "title": "标题",
  "summary": "摘要",
  "author": "作者",
  "tags": ["热血", "校园"],
  "extra": {}
}

Comment generation rules

Do not use one generic template for every content type. Generate comments differently based on the source.

Comics

Prefer comments about:

• art style
• character appeal
• plot progression
• update expectations
• favorite scenes

Articles

Prefer comments about:

• viewpoint response
• agreement/disagreement
• practical reflection
• follow-up questions
• short discussion prompts

Novels

Prefer comments about:

• writing style
• pacing
• plot setup
• character development
• expectation for later chapters

Videos

Prefer comments about:

• pacing
• scene quality
• plot reaction
• rewatch value
• performance or presentation

Comment style strategy

Generate multiple styles instead of repeating one voice.

Recommended style buckets:

• praise / appreciation
• discussion / opinion
• expectation / follow-up
• question / interaction
• light emotional reaction

Avoid repetitive low-quality outputs like:

• 不错啊
• 写得真好
• 支持一下
• 期待更新

Those can appear occasionally, but should not dominate the comment pool.

Comment targeting workflow

When asked to build the system, follow this order:

Step 1. Identify content sources

Clarify:

• which tables or models provide comics, articles, novels, and videos
• which fields are available for summarization
• whether comments target only published content
• whether comments should exclude very old content or low-quality content

Step 2. Build a normalized content extractor

Create a common extraction layer that maps different content models into one unified comment input object.

Step 3. Design comment generation

Define:

• generation prompt or template policy
• content-type-specific styles
• duplicate suppression rules
• per-content comment count limits
• unsafe phrase blacklist
• optional moderation checkpoint

Step 4. Design account strategy

Define:

• account pool source
• account roles
• per-account comment quota
• cooldown period
• account disable conditions
• fallback account selection

Step 5. Design execution path

Use this chain:

select target content
→ build normalized content input
→ generate comment candidates
→ filter / deduplicate
→ optional moderation
→ choose account
→ submit comment
→ log result
→ retry or cooldown

Step 6. Add controls

Always add:

• idempotency keys
• timeout handling
• retry limits
• duplicate-comment suppression
• per-account frequency caps
• per-content comment caps
• audit logging
• manual disable switch

Multi-account rules

If multiple accounts are used, always define:

• account id
• account status
• role
• last action time
• cooldown_until
• daily quota
• hourly quota
• failure count

Do not design a system where all accounts can comment indefinitely with no rotation or no cooldown.

Anti-duplication rules

Always prevent:

• same account posting the same comment repeatedly
• many accounts posting nearly identical comments in a short window
• too many comments on the same content in a short period
• same template being used on multiple content items without variation

Recommended controls:

• similarity threshold checks
• comment hash / normalized hash
• per-content cooloff window
• random delay window
• template variation rules

Moderation handoff guidance

If generated comments must be checked, choose one mode:

Mode A. Review before submit

Use when generated comments must not enter the system unless clean.

Mode B. Submit then audit

Use when the project already supports post-save review states.

Mode C. Hybrid

Use when comments get basic local filtering before submit and full moderation after submit.

Do not merge moderation policy directly into this skill. Keep moderation as a dependency.

Logging requirements

At minimum, log:

• task id
• content_type
• content_id
• account id
• generated comment
• generation strategy or style bucket
• moderation mode used
• execution result
• failure reason
• created_at / updated_at

Future expansion

This skill may later expand to:

• automatic posting
• posting + commenting orchestration
• campaign scheduling
• multi-account publishing waves

But first build automatic commenting based on existing content well.

Recommended reusable resources

references/

Store:

• content-extractor template
• comment-style matrix
• account rotation template
• queue design template
• rollout checklist
• project-specific schema plans such as references/51dm-auto-comment-schema-plan.md
• project-specific implementation plans such as references/51dm-auto-comment-implementation-v1.md
• project-specific task breakdowns such as references/51dm-auto-comment-task-breakdown-v1.md
• project-specific reuse plans such as references/51dm-comment-reuse-plan.md
• human-like comment guidance such as references/human-like-comment-strategy.md

scripts/

Store:

• sample comment generator
• comment signature examples if needed
• scheduler/runner examples
• account rotation pseudocode

Default recommendation

For the first version, build only these:

• content extractor
• comment generator
• account selector
• comment submitter
• moderation handoff adapter
• operation logger

Do not start with full posting automation unless the user explicitly prioritizes it.