Poll competitive crawl triggers, aggregate the last 6 months of product, review, and QA data by category, produce structured analysis context and a report skeleton, upload outputs to OSS, then send a DingTalk summary. Use for database-driven scheduled competitor analysis in OpenClaw.

Poll competitive crawl triggers, aggregate the last 6 months of product, review, and QA data by category, produce structured analysis context and a report sk...

Security Scan

The skill is internally consistent with its stated purpose: it reads a PostgreSQL database, aggregates competitive product/review/QA data, renders reports, uploads artifacts to OSS, and posts a DingTalk summary — the required credentials and code match those actions.

Purpose & Capability

The name and description match the required resources and behavior: a PostgreSQL DSN to read/mark triggers, OSS credentials to upload reports, and a DingTalk webhook to send summaries. Required binary (python3) is appropriate.

Instruction Scope

SKILL.md and the code limit runtime actions to database queries/updates, local report rendering, optional OSS upload, and DingTalk webhook posts. The README explicitly forbids calling external LLM APIs. No instructions ask the agent to read unrelated system files or transmit data to unexpected endpoints.

Install Mechanism

This is an instruction-only skill with bundled scripts; there is no automated download or install step. Runtime Python dependencies (psycopg, optional oss2) are declared via code and fail with clear messages if missing — no external arbitrary downloads or extracted archives are used.

Credentials

Requested env vars (COMPETITIVE_ANALYSIS_DSN, OSS_*, DINGTALK_WEBHOOK/SECRET) directly support DB access, artifact upload, and notification. Note: the script requires DB write privileges on the trigger table (to mark consumed/failed) — that is expected for this workflow but is a higher-privilege DB role than read-only.

Persistence & Privilege

The skill does not request permanent inclusion (always:false) and does not modify other skills or system-wide settings. It updates its own domain (database trigger rows and writes report files) as part of normal operation.

Assessment

This package appears to do what it claims, but check these operational matters before installing: 1) Limit the PostgreSQL DSN to the minimum required privileges (SELECT on product/review/qa tables and UPDATE on the competitive_crawl_trigger consumption fields); avoid providing a superuser DSN. 2) Understand that providing OSS_ACCESS_KEY_* typically grants write/list access to a bucket — prefer a scoped/short-lived key and a dedicated bucket/prefix so generated report URLs cannot leak unrelated data. 3) The generated report URLs are likely public by default (SKILL uses public URL construction); verify OSS_PUBLIC_BASE_URL and bucket ACLs if you want artifacts private. 4) DingTalk webhook messages include links to report files — ensure the webhook and message contents are acceptable to your privacy rules. 5) Review and test in a staging environment first to confirm schema expectations (the skill will fail fast if required trigger columns are missing) and to avoid mass consumption of triggers in production. 6) Keep secrets out of shared openclaw.json or rotate them regularly. If you want a lower blast radius, run the skill under an account with tightly scoped DB/OSS permissions.

Competitive Analysis

Use When

• The competitor analysis tables already exist.
• You need to poll competitive_crawl_trigger on a schedule.
• You need standardized reports grouped by category.
• You need to send summaries to a DingTalk robot.

Do not use this skill for:

• one-off ad hoc analysis
• open-ended research without database inputs
• flexible report generation without a fixed template

Required Inputs

• Database connection: COMPETITIVE_ANALYSIS_DSN
• OSS endpoint: OSS_ENDPOINT
• OSS bucket: OSS_BUCKET
• OSS access key id: OSS_ACCESS_KEY_ID
• OSS access key secret: OSS_ACCESS_KEY_SECRET
• DingTalk webhook: DINGTALK_WEBHOOK
• Optional DingTalk signing secret: DINGTALK_SECRET
• In OpenClaw, prefer environment injection through skills.entries.competitive_analysis.env

Goal

1. Find unconsumed trigger rows where status='success'.
2. Load the last 6 months of product, review, and QA data.
3. Aggregate results by category.
4. Produce analysis_context.json for the host to continue narrative generation.
5. Generate a Markdown/HTML skeleton that follows the reference PDF structure.
6. Send a DingTalk summary.
7. Mark trigger rows as consumed after success.

Entry Points

Primary command:

python3 {baseDir}/scripts/run_report.py

Common arguments:

• --category CATEGORY
• --since-months 6
• --limit 20

Files

• SKILL.md: skill entry instructions
• references/report-outline.md: report structure contract
• references/data-contract.md: data contract and field expectations
• references/openclaw-setup.md: OpenClaw setup example
• scripts/run_report.py: main CLI
• scripts/render_report.py: Markdown/HTML rendering
• scripts/send_dingtalk.py: DingTalk delivery
• analysis_context.json: structured analysis context for the host runtime

Rules

• Follow the reference PDF for section order.
• If fields are missing, keep the section and mark values as 未采集 or 待补充.
• Keep the CLI stateless and let an external scheduler trigger it.
• Do not call any external LLM API from the script.
• Let the host runtime generate deeper narrative content from analysis_context.json and references/report-outline.md.
• In OpenClaw, prefer host-managed environment injection over .env.

Minimal Workflow

1. Read references/data-contract.md.
2. Confirm that the trigger table already includes the consumption fields.
3. Configure skills.entries.competitive_analysis.env as shown in references/openclaw-setup.md.
4. Start a new OpenClaw session so the skill reloads.
5. Run python3 {baseDir}/scripts/run_report.py or invoke it from an external scheduler.
6. Read the generated analysis_context.json.
7. Let the host runtime generate the final narrative based on references/report-outline.md.
8. Validate the final output against the report outline.

Success Criteria

• New successful trigger rows are detected.
• Reports are generated per category.
• Section structure matches the reference report.
• DingTalk receives the summary message.
• Trigger rows are marked as consumed.