Content Compliance Reviewer

Runs a pre-publication compliance and quality review on finished tech blogs, customer cases, product updates, or press releases. Only checks and reports — never auto-modifies the original.

When to use

• Need to check data facts, customer redaction, product official names, competitor rules, and internal information in an article.
• Need to confirm citation traceability and formatting before publication.
• Need a pre-review report with an approval recommendation.

Do not use

• Monthly performance analysis and content retrospectives — handled by content-performance-analyst.
• Auto-modifying or rewriting the original; provide only location and fix suggestions.
• Initial writing or channel adaptation.

Input

draft_path:
article_type: tech_blog | case_study | product_update | other
compliance_profile: path or object
  - brand_rules:
  - sensitive_terms:
  - product_public_status:
  - customer_redaction_policy:
  - competitor_policy:
review_requested_by:

The compliance profile is supplied by the project's private configuration. The generic engine uses logical fields; real paths and rule tables stay in the private layer.

Workflow

Step 1: [Deterministic] Load the draft and reference

1. Read the article under review.
2. Read the brand rules, sensitive-term list, product-public-status, and customer-redaction rules from the compliance profile.
3. Look up the corresponding product section in the knowledge base as needed, to verify data provenance.

Step 2: [LLM] Item-by-item inspection

Every item gets: PASS / NEEDS_FIX / FAIL.

Step 3: [LLM] Generate pre-review report

Output:

# Pre-Review Report

## Summary

| Item | Result | Note |
|---|---|---|
| Customer redaction | PASS/NEEDS_FIX/FAIL | |
| Product name | PASS/NEEDS_FIX/FAIL | |
| Competitor | PASS/NEEDS_FIX/FAIL | |
| Data traceability | PASS/NEEDS_FIX/FAIL | |
| Internal info | PASS/NEEDS_FIX/FAIL | |
| Format | PASS/NEEDS_FIX/FAIL | |
| Content quality | PASS/NEEDS_FIX/FAIL | |

## Specific issues

- Location, problem, suggested fix for each NEEDS_FIX or FAIL.

## Citation verification

| Claim | Source | Status |
|---|---|---|

## Overall assessment

- Publishable / Minor fixes / Major revision / Rewrite recommended

## Recommended approval level

- Level and rationale.

Step 4: [Deterministic] Save

Save to: content/drafts/{original-name}-compliance-review.md

Execution summary:

## Execution Summary
- Article reviewed:
- Results: N pass / M needs-fix / K fail
- Overall: publishable | minor-fix | major-fix | rewrite
- Critical issues:

Pre-publish strengthened checks (backstop for high-frequency rework points)

Beyond the seven general checks, run mandatory checks on high-frequency rework points (corresponding to the P0/P1 items found by the claim / cross-material governance lines). These are also the pre-publish backstop for content-writer's expression red lines:

• P0 naming consistency: the tech-blog product's external name must match verbatim the already-published authoritative materials of the same campaign (press release / official site / official account); must not add its own version number or suffix (e.g. if the external name is uniformly "X", the blog must not write "X 2.0"). Inconsistency = FAIL.
• P0 meta-language / self-reference: sentences that break the frame — "this article…", "the press release makes it clear that…", "deserves its own section", "back to the overall narrative" — = FAIL; replace with a direct content transition.
• P0 business jargon: four-character slogans like "多、快、好、省" = FAIL; rewrite in engineering dimensions (load coverage / execution efficiency / operations experience / resource efficiency).
• P1 absolutist phrasing: scan for "naturally connected / seamless / inevitable / certain / zero" etc.; require a bounded qualifier instead.
• P1 out-of-scope scenarios: landing industries/scenarios without a knowledge-base or published-article source must be marked [needs confirmation] or removed; do not list scenarios from memory (e.g. an industry/scenario needs internal-source backing).
• P1 faithful transcription vs quantified claims: infrastructure capabilities backed by an architecture diagram may be stated; quantified speedup multiples without an official figure = FAIL.

> When publishing externally and multiple materials on the same topic already exist, after a PASS pre-review it is recommended to also run the three-piece governance line — claim-to-source-auditor + cross-material-consistency-auditor + tech-content-review-panel — before finalizing.

Hard Rules

1. Never modify the original draft. Only report issues and suggestions.
2. Data checks must reference an approved source. Missing sources receive a fail.
3. Any real customer name hit is an automatic fail.
4. Employer or unrelated brand names must not appear in outward-facing content unless the piece is officially co-branded; a hit is a fail even when the sentence is otherwise correct.
5. Unconfirmed product capabilities receive a needs-fix.
6. Competitor named references must be flagged.
7. Internal code names or project names are an automatic fail.
8. Human confirmation required before marking the review complete and handing off to adaptation.

Failure Handling

Output Format

content/drafts/{original-name}-compliance-review.md

Verification

• [ ] All seven inspection items evaluated.
• [ ] Every data claim checked against approved source.
• [ ] Every real customer name flagged.
• [ ] Report saved without modifying the original draft.
• [ ] Execution summary includes next action.

中文摘要

Content Compliance Reviewer 是发布前合规与质量预审 Skill：检查事实引用、客户脱敏、产品口径、竞品规则、内部信息、格式与 AI 痕迹，只报告不修改原文。除七项通用检查外，对高发返工点做强制兜底（P0 命名一致性/元语言/商务腔，P1 绝对化/超范围场景/量化断言），与 content-writer 的表达红线前后呼应。多份同主题物料对外发布前，建议再跑 claim-to-source + cross-material + tech-content-review 三件套治理线。