{"id":"575736ea-a2b2-4e4d-860d-88bafc87b0b9","entityType":"agent","slug":"clawhub-haiyangchenbj-tcms-writer","name":"tcms-writer","canonicalUrl":"https://www.xpersona.co/agent/clawhub-haiyangchenbj-tcms-writer","canonicalPath":"/agent/clawhub-haiyangchenbj-tcms-writer","generatedAt":"2026-10-12T13:22:40.195Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T22:37:48.448Z","emptyReason":null},"description":"For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis. Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation. Not for neutral industry research — use industry-deep-dive-pipeline for that. Skill: tcms-writer Owner: haiyangchenbj Summary: For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis. Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation. Not for neutral industry research — use industry-deep-dive-pipeline","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 983 downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17672gh0nx9qr7sjp84kz7xen83jv7v:tcms-writer","sourceUrl":"https://clawhub.ai/haiyangchenbj/tcms-writer","homepage":"https://clawhub.ai/haiyangchenbj/skills/tcms-writer","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/haiyangchenbj/tcms-writer","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/haiyangchenbj/skills/tcms-writer","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party ana"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T22:37:48.448Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T22:37:48.448Z","emptyReason":null},"stars":null,"forks":null,"downloads":983,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"1.3.0","tractionLabel":"983 downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T22:37:48.348Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T22:37:48.448Z","lastCrawledAt":"2026-10-11T22:37:48.348Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T22:37:48.348Z","lastVerifiedAt":null,"highlights":[{"version":"1.3.0","createdAt":"2026-09-20T03:54:55.288Z","changelog":"Full-package republish: now includes references (brand rules, sensitive terms, 3 content templates) and bilingual READMEs that were missing from earlier uploads. Skill body is the 1.3.0 English edition.","fileCount":10,"zipByteSize":12095},{"version":"1.2.5","createdAt":"2026-09-08T03:11:43.821Z","changelog":"Refresh release: align version number across ClawHub / SkillHub / GitHub, no content changes","fileCount":3,"zipByteSize":6487},{"version":"1.2.3","createdAt":"2026-08-24T06:11:44.347Z","changelog":"Add not_for routing field (agent-consumption-first design)","fileCount":3,"zipByteSize":6554},{"version":"1.2.2","createdAt":"2026-08-07T06:39:16.580Z","changelog":"tcms-writer 1.2.2 - Added Chinese summary (description_zh) to skill metadata. - Removed deprecated file: skill-card.md. - No changes to core functionality or workflows.","fileCount":10,"zipByteSize":12523},{"version":"1.2.1","createdAt":"2026-08-02T15:57:02.819Z","changelog":"Sync local 1.2.1 with --slug standardization; no content change from 1.2.0","fileCount":10,"zipByteSize":12599},{"version":"1.2.0","createdAt":"2026-07-31T04:50:40.380Z","changelog":"English-body localization: translate SKILL.md to English per ClawHub convention; retain Chinese read_when triggers and a Chinese tail summary; de-branded expression red lines and pre-publish governance checks preserved; version bump.","fileCount":10,"zipByteSize":12247},{"version":"1.1.0","createdAt":"2026-07-31T03:11:05.333Z","changelog":"Add de-branded expression red-lines (no meta-language, no biz-jargon, no absolutization, P0 naming consistency, faithful transcription vs quantified claims) and pre-publish reinforcement checks, distilled from multi-round draft revision and the three-piece governance line.","fileCount":10,"zipByteSize":11680},{"version":"1.0.2","createdAt":"2026-07-30T11:21:37.713Z","changelog":"Initial public release of the TCMS (tech-product content-marketing) skill family. Brand-side content for tech-product marketing teams. De-branded engine, no vendor-specific info.","fileCount":10,"zipByteSize":10843}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17672gh0nx9qr7sjp84kz7xen83jv7v:tcms-writer","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-haiyangchenbj-tcms-writer/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-haiyangchenbj-tcms-writer/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-haiyangchenbj-tcms-writer/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-haiyangchenbj-tcms-writer/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-haiyangchenbj-tcms-writer/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-haiyangchenbj-tcms-writer/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-12T13:22:40.192Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-haiyangchenbj-tcms-writer/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-haiyangchenbj-tcms-writer/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-haiyangchenbj-tcms-writer/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-haiyangchenbj-tcms-writer/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T22:37:48.448Z","emptyReason":null},"readme":"Skill: tcms-writer\n\nOwner: haiyangchenbj\n\nSummary: For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis. Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation. Not for neutral industry research — use industry-deep-dive-pipeline for that.\n\nTags: brand-writing:1.1.0, content-marketing:1.1.0, latest:1.3.0, tech-product:1.1.0\n\nVersion history:\n\nv1.3.0 | 2026-09-20T03:54:55.288Z | user\n\nFull-package republish: now includes references (brand rules, sensitive terms, 3 content templates) and bilingual READMEs that were missing from earlier uploads. Skill body is the 1.3.0 English edition.\n\nv1.2.5 | 2026-09-08T03:11:43.821Z | user\n\nRefresh release: align version number across ClawHub / SkillHub / GitHub, no content changes\n\nv1.2.3 | 2026-08-24T06:11:44.347Z | user\n\nAdd not_for routing field (agent-consumption-first design)\n\nv1.2.2 | 2026-08-07T06:39:16.580Z | auto\n\ntcms-writer 1.2.2\n\n- Added Chinese summary (description_zh) to skill metadata.\n- Removed deprecated file: skill-card.md.\n- No changes to core functionality or workflows.\n\nv1.2.1 | 2026-08-02T15:57:02.819Z | user\n\nSync local 1.2.1 with --slug standardization; no content change from 1.2.0\n\nv1.2.0 | 2026-07-31T04:50:40.380Z | user\n\nEnglish-body localization: translate SKILL.md to English per ClawHub convention; retain Chinese read_when triggers and a Chinese tail summary; de-branded expression red lines and pre-publish governance checks preserved; version bump.\n\nv1.1.0 | 2026-07-31T03:11:05.333Z | user\n\nAdd de-branded expression red-lines (no meta-language, no biz-jargon, no absolutization, P0 naming consistency, faithful transcription vs quantified claims) and pre-publish reinforcement checks, distilled from multi-round draft revision and the three-piece governance line.\n\nv1.0.2 | 2026-07-30T11:21:37.713Z | user\n\nInitial public release of the TCMS (tech-product content-marketing) skill family. Brand-side content for tech-product marketing teams. De-branded engine, no vendor-specific info.\n\nArchive index:\n\nArchive v1.3.0: 10 files, 12095 bytes\n\nFiles: _meta.json (130b), README_zh.md (1188b), README.md (1286b), references/brand-rules.md (1807b), references/sensitive-terms.md (939b), references/templates/case-study.md (1124b), references/templates/product-update.md (1066b), references/templates/tech-blog.md (1162b), skill-card.md (2749b), SKILL.md (8658b)\n\nFile v1.3.0:SKILL.md\n\n---\r\nname: tcms-writer\r\nversion: \"1.3.0\"\r\ndescription: |\r\n  For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis.\r\n  Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation.\r\n  Not for neutral industry research — use industry-deep-dive-pipeline for that.\r\nread_when:\r\n  - 写文章\r\n  - 写稿\r\n  - 写初稿\r\n  - 起草\r\n  - 技术博客\r\n  - 品牌技术稿\r\n  - 案例文章\r\n  - 客户案例\r\n  - 产品解读\r\n  - 产品稿\r\n  - 新闻稿\r\n  - content brief\r\n  - draft\r\n  - 按brief写\r\nallowed-tools:\r\n  - read_file\r\n  - write_to_file\r\n  - replace_in_file\r\n  - web_fetch\r\n  - search_content\r\n  - search_file\r\n  - list_dir\r\ndisable: false\r\n---\r\n\r\n# TCMS Writer\r\n\r\n基于产品知识库、品牌规范和选题Brief，产出高质量的长文初稿。\r\n\r\n## 工作模式：提示链（Prompt Chaining）\r\n\r\n按固定步骤执行，每一步输入输出明确。\r\n\r\n---\r\n\r\n## Step 1: 确认选题 [确定性]\r\n\r\n读取用户提供的选题信息，确认以下要素：\r\n\r\n| 要素 | 必须明确 | 缺失时处理 |\r\n|------|---------|-----------|\r\n| 文章类型 | 技术博客 / 客户案例 / 产品解读 | 询问用户 |\r\n| 目标产品 | 具体产品名 | 询问用户 |\r\n| 目标读者 | 架构师/CTO/工程师/分析师 | 默认\"技术决策者\" |\r\n| 核心信息 | 要传达的关键价值点 | 从知识库提取 |\r\n| 素材来源 | 知识库/内部材料/已发文章 | 默认使用知识库 |\r\n| 保密要求 | 是否有内部案例需脱敏 | 默认全部脱敏 |\r\n\r\n如果用户提供了Brief文件路径，直接读取Brief。\r\n\r\n---\r\n\r\n## Step 2: 读取素材 [确定性]\r\n\r\n**只读与目标产品相关的文件，不加载无关产品信息：**\r\n\r\n1. **产品知识库** → 搜索目标产品对应章节（不读全文，用search_content定位）\r\n2. **品牌规范** → `references/brand-rules.md`（每次都读）\r\n3. **文章模板** → 按文章类型读取对应模板：\r\n   - 技术博客：`references/templates/tech-blog.md`\r\n   - 客户案例：`references/templates/case-study.md`\r\n   - 产品解读：`references/templates/product-update.md`\r\n4. **补充素材**（按需）：Brief中指定的内部文档或已发布文章\r\n\r\n> 以上路径需根据实际项目目录配置。\r\n\r\n---\r\n\r\n## Step 3: 写作 [LLM]\r\n\r\n### 写作规则\r\n\r\n**产品名称**：\r\n- 首次提及使用官网全称（参见brand-rules.md产品名称对照表）\r\n- 后续可用简称\r\n\r\n**品牌露出**：\r\n- 标题中包含品牌名或具体产品官方名称\r\n- 开头两段内引入品牌或具体产品\r\n- 结尾有固定品牌格式\r\n\r\n**数据引用**：\r\n- 所有数据必须来自知识库或已发布文章，不可编造\r\n- 引用时记录来源（用于Step 5生成引用表）\r\n\r\n**客户信息**：\r\n- 内部来源的客户案例**默认脱敏**\r\n- 脱敏格式：\"某+行业+企业规模\"\r\n- 不出现客户公司名、内部人员姓名、项目代号\r\n- 用户明确告知已授权的可使用客户名称\r\n\r\n**竞品处理**：\r\n- 不直接点名任何竞品\r\n- 使用\"某友商平台\"等替代表述\r\n\r\n**产品能力来源验证**：\r\n- 只引用知识库中存在的产品能力\r\n- 不确定是否已公开的，在预审清单中标注\"需确认\"\r\n\r\n### 英文稿 AI 强特征与作者性门禁 [英文稿必过]\r\n\r\n本节是 TCMS 对统一英文规则源 `tech-writing-pipeline/references/english-ai-writing-strategy.md` 的应用说明。可访问该规则源时必须加载；本 Skill 不另建禁词表，也不以 AI detector 分数作为发布结论。本节规则不替代产品、品牌、客户、竞品、命名和知识库约束。\r\n\r\n1. **先建英文 claim map。** 英文稿动笔前，用英文记录 `Claim / Evidence / Counterargument / Boundary / What the reader should not infer` 五项。英文稿按英文读者的论证顺序重写，不按中文句序逐句翻译。\r\n2. **P0 直接停止。** 出现虚构事实、数字、引语、关系或归因；空泛开场或结尾承载主要信息；只有积极形容词没有对象、证据和条件；`studies show` / `experts believe` 没有可核查来源；反方只被提及却未评价；把中文平行结构或媒体表达直接搬进英文稿，均退回Brief或素材重建。\r\n3. **P1 进入人工复核。** 单段内修辞包装词成组出现，反复使用 `not just X but Y` 等对举模板，破折号或同构三项并列变成节奏骨架，或积极表述超过对象、来源、测量和限定条件时，进入人工复核。单个风格词不构成问题。\r\n4. **作者性检查。** 每个主要段落都要能指出具体对象、事件、数字或观察行为；作者愿意承担的判断；最强合理反驳；对反驳的处理；以及会使判断变窄或失效的条件。\r\n5. **按渠道解释结构。** LinkedIn 的对象清单、责任清单、承担事实功能的三项并列或结构母题不能单独判为 AI 腔。只有它们与空泛开场、来源不裁决、作者判断缺席或修辞包装叠加时，才升级处理。detector 分数只能作为观察项，不能进入 PASS/FAIL。\r\n\r\n### 文章结构\r\n\r\n不写成：功能1 → 功能2 → 功能3 的产品说明书\r\n\r\n要写成：**问题 → 为什么难 → 方案（自然引入产品能力）→ 效果 → 适用判断**\r\n\r\n每篇文章要有明确的读者收获——读完能做出一个判断或学到一个方法。\r\n\r\n### 字数\r\n\r\n目标 1500-3000字。超过3500字需压缩，低于1200字需补充。\r\n\r\n---\r\n\r\n## Step 4: 自检 [LLM]\r\n\r\n| 检查项 | 通过标准 | 不通过处理 |\r\n|--------|---------|-----------|\r\n| 客户名称泄露 | 内部来源案例无客户名 | 立即替换为脱敏版 |\r\n| 竞品点名 | 无竞品公司名 | 替换 |\r\n| 产品名规范 | 首次提及用官网全称 | 修正 |\r\n| 品牌露出 | 标题/开头/结尾均有 | 补充 |\r\n| 数据有出处 | 每个数字都能指向知识库条目 | 删除无出处数据 |\r\n| 内部代号 | 无未公开的产品代号/功能名 | 删除 |\r\n| 英文 claim map | 英文稿包含 Claim / Evidence / Counterargument / Boundary / What the reader should not infer | 停止并重建 |\r\n| 英文作者性 | 每个主要段落都有具体对象、作者判断、反驳、回应与边界 | 人工复核 |\r\n| 英文 AI 强特征组合 | 无 P0；P1 按上下文复核，不按单词禁用表判定 | 停止或修改 |\r\n| 字数范围 | 1500-3000字 | 调整 |\r\n\r\n---\r\n\r\n## Step 5: 输出 [确定性]\r\n\r\n产出两个文件：\r\n\r\n**文件1：文章初稿**\r\n保存路径：`content/drafts/YYYY-MM-{产品}-{主题简称}.md`\r\n\r\n**文件2：引用追溯表 + 预审清单**\r\n保存路径：同目录，文件名加 `-review` 后缀\r\n\r\n```markdown\r\n## 执行摘要\r\n- 读取素材：[列出实际读取的文件]\r\n- 模板选择：[文章类型]\r\n- 文章字数：[实际字数]\r\n- 引用数据点：[N]个（[M]个公开，[K]个内部脱敏）\r\n- 自检结果：10项检查，[X]通过[Y]修正\r\n\r\n## 引用追溯\r\n\r\n| 文中数据点 | 知识库条目/来源 | 公开状态 |\r\n|-----------|----------------|---------|\r\n| \"xxx\" | xxx条目 / 来源文章 | ✅公开 / 📋内部(已脱敏) |\r\n\r\n## 预审清单\r\n\r\n- [ ] 客户名称脱敏检查\r\n- [ ] 产品能力公开状态\r\n- [ ] PM需确认的数据点\r\n```\r\n\r\n---\r\n\r\n## 硬性规则\r\n\r\n1. **不编造数据。** 没有出处的数字不写。\r\n2. **内部案例默认脱敏。** 除非用户明确告知已授权。\r\n3. **不点名竞品。**\r\n4. **产品名以官网为准。**\r\n5. **不引用知识库中没有的产品能力。** 不确定的标注\"需确认\"。\r\n6. **每篇文章必须附引用追溯表。**\r\n7. **未确认对外口径的产品不推广。**\r\n8. **英文稿必须通过英文 AI 强特征与作者性门禁**：先建 claim map，再检查 P0、组合式 P1、作者判断、反方处理和证据边界；不得用禁词表或 detector 分数替代门禁。\r\n\r\n---\r\n\r\n## 失败处理\r\n\r\n| 场景 | 处理 |\r\n|------|------|\r\n| 知识库中找不到目标产品信息 | 停止生成，报告\"知识库中无{产品}的信息\" |\r\n| Brief中要求的文章类型没有对应模板 | 使用tech-blog模板作为默认 |\r\n| 引用数据标注为\"已过期\" | 不引用，预审清单中标注 |\r\n| 客户授权状态不明 | 默认脱敏 |\r\n| 文章超过3500字 | 给出压缩建议 |\r\n\r\n---\r\n\r\n## ⚠️ 人工介入\r\n\r\n输出完成后，文章进入**人工review环节**。本Skill不自动发布，所有初稿必须经人工确认后才能进入content-adapter进行渠道适配。\n\nFile v1.3.0:README.md\n\n# TCMS Writer\n\n**Part of the `tcms-*` family** — brand-side content skills for tech-product marketing teams.\n*Not for neutral third-party industry research — that is `industry-deep-dive-pipeline`'s job.*\n\n## What it does\n\nTurns a product knowledge base and brand rules into **brand-side long-form drafts** (technical blogs, customer case studies, product write-ups). Produces only 1500–3000 word drafts from a content brief.\n\nIt does **not** handle social posts, short content, or channel adaptation (see `tcms-adapter`).\n\n## When to use\n\n- You have a topic brief and need a long-form brand marketing draft.\n- The piece is promotional / product-positioning in nature.\n\n## When NOT to use\n\n- Neutral, third-party industry deep-dives → use `industry-deep-dive-pipeline`.\n- Single-article pre-publish compliance check → use `tcms-compliance-reviewer`.\n- Channel adaptation → use `tcms-adapter`.\n\n## Trigger phrases\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## Pipeline position\n\n`tcms-planner` (brief) → **`tcms-writer`** (draft) → `tcms-compliance-reviewer` (review) → `tcms-adapter` (channels) → `tcms-performance-analyst` (monthly report)\n\nFile v1.3.0:_meta.json\n\n{\n  \"ownerId\": \"kn70yg6zwmkftx4939qrs89awx82rr9a\",\n  \"slug\": \"tcms-writer\",\n  \"version\": \"1.3.0\",\n  \"publishedAt\": 1789876495288\n}\n\nFile v1.3.0:references/brand-rules.md\n\n# 品牌与内容规范\r\n\r\n> 按实际品牌和产品线配置以下内容。\r\n\r\n## 产品正式名称\r\n\r\n首次提及用全称，后续可用简称。\r\n\r\n| 简称 | 官网全称 | 首次引用格式 |\r\n|------|---------|------------|\r\n| 产品A | xxx平台 | XX云xxx平台（产品A） |\r\n| 产品B | xxx服务 | XX云xxx服务（产品B） |\r\n| ... | ... | ... |\r\n\r\n> 从官网产品页获取正式名称，保持一致。\r\n\r\n## 品牌露出规则\r\n\r\n- 标题中包含品牌名或具体产品官方名称\r\n- 开头两段内引入品牌或具体产品\r\n- 结尾固定格式：**{品牌名}，帮助/助力 xxx企业xxx。**\r\n- 正文中产品首次出现用全称，后续用简称\r\n\r\n## 写作调性\r\n\r\n- 专业、克制、有判断。不油腻，不夸张，不AI营销腔\r\n- 允许专业术语，紧跟一句通俗解释\r\n- 给结论和判断，不只堆信息\r\n- 像成熟的技术分析者，不像内容农场\r\n\r\n## 禁用表达\r\n\r\n| 类型 | 禁用 | 替代 |\r\n|------|------|------|\r\n| 竞品点名 | 具体竞品名称 | \"某友商平台\"\"原有闭源平台\" |\r\n| 未确认产品 | 内部规划中未正式发布的产品 | 不提及 |\r\n| 空话 | 赋能/闭环/端到端/强大/显著/大幅/打造 | 用具体数据和场景替代 |\r\n| 内部代号 | 任何未在官网出现的产品代号 | 不使用 |\r\n\r\n## 客户脱敏规则\r\n\r\n内部来源的客户案例默认脱敏：\r\n\r\n| 场景 | 脱敏格式 |\r\n|------|---------|\r\n| 知名企业 | 某+行业+规模，如\"某头部券商\" |\r\n| 一般企业 | 某+行业+企业类型，如\"某SaaS服务商\" |\r\n| 人员信息 | 不出现姓名/工号/企业微信ID |\r\n\r\n> 在此处维护具体客户名→脱敏名的映射表（不随代码同步）。\r\n\r\n## 已授权可公开引用的客户\r\n\r\n> 在此处维护已明确授权的客户名单。\n\nFile v1.3.0:references/sensitive-terms.md\n\n# 敏感词与禁用表达\r\n\r\n## 禁止出现的客户名称（内部来源，未确认授权）\r\n\r\n> 在此处维护具体客户名称列表。内部材料中出现的客户名必须脱敏处理。\r\n\r\n## 禁止出现的竞品名称\r\n\r\n> 在此处维护竞品公司名和产品名列表。\r\n\r\n替代表述：某友商平台 / 原有闭源平台 / 国际主流平台 / 其他同类产品\r\n\r\n## 禁止出现的未确认产品\r\n\r\n> 在此处维护内部规划中、对外口径未确认的产品名。\r\n\r\n## 禁止出现的内部信息\r\n\r\n- 内部项目代号\r\n- 内部人员姓名和通讯ID\r\n- 内部材料中的管理备注（如\"需和XX确认\"）\r\n- 内部材料roadmap中标注但官网未上线的功能（需逐条验证）\r\n\r\n## 慎用表达（非禁止，但尽量避免）\r\n\r\n赋能, 闭环, 端到端, 强大, 显著, 大幅, 打造, 一站式, 全面, 领先, 极致, 颠覆, 革命性\r\n→ 用具体数据和场景描述替代\n\nFile v1.3.0:references/templates/case-study.md\n\n# 客户案例模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题\r\n   格式A（已授权）：{客户名}+{产品}+{核心成果}\r\n   格式B（脱敏）：某{行业}{规模}企业+{场景}+{核心成果}\r\n\r\n2. 客户背景（1段）\r\n   - 企业定位（行业/规模/业务特点）\r\n   - 脱敏案例不写太具体的业务描述，避免被反推\r\n\r\n3. 业务挑战（3-4个痛点）\r\n   - 每个痛点一句话标题+2-3句展开\r\n   - 痛点要具体到技术层面，不是泛泛的\"效率低\"\r\n\r\n4. 方案选型\r\n   - 为什么选这个方案（简要）\r\n   - 使用了哪些产品（用官网全称）\r\n   - 架构概述\r\n\r\n5. 实施效果\r\n   - 硬数据（性能提升x%、成本降低x%等）\r\n   - 来自知识库，标注出处\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2000字\r\n\r\n## 要点\r\n- 月报来源的案例**默认全文脱敏**\r\n- 已在CSDN公开发布的案例可直接引用客户名\r\n- 痛点部分是案例文章最有价值的部分——读者通过痛点判断\"跟我的情况像不像\"\r\n- 方案部分不要写成产品功能清单，重点是\"选型逻辑\"\n\nFile v1.3.0:references/templates/product-update.md\n\n# 产品解读模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含产品名+核心升级/认证/能力）\r\n\r\n2. 开头（1段）\r\n   - 一句话说清\"什么产品出了什么变化\"\r\n   - 立即说明这个变化对用户意味着什么\r\n\r\n3. 背景与趋势（1-2段）\r\n   - 行业背景：为什么需要这个能力/认证\r\n   - 不要写太长的行业铺垫，读者关心的是产品变化\r\n\r\n4. 核心内容（主体）\r\n   - 新能力/新版本：具体是什么、怎么用、有什么数据\r\n   - 认证解读：认证标准考什么、通过意味着什么、对选型的参考价值\r\n   - 不罗列全部功能，选最有差异化的2-3个展开\r\n\r\n5. 对用户的影响\r\n   - 现有用户怎么用（升级路径/兼容性）\r\n   - 潜在用户怎么看（选型参考）\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2200字\r\n\r\n## 要点\r\n- 不写成\"我们发布了好厉害\"的自夸体\r\n- 读者关心的是\"这对我有什么用\"\r\n- 认证类文章重点解读标准本身的价值，而非通过考试的荣耀感\n\nFile v1.3.0:references/templates/tech-blog.md\n\n# 技术博客模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含品牌名或产品名）\r\n\r\n2. 开头（1-2段）\r\n   - 场景引入：什么场景下，企业面临什么问题\r\n   - 自然引出品牌xxx产品（不晚于第二段）\r\n\r\n3. 问题展开（2-4个子问题）\r\n   - 每个问题用一句话标题概括\r\n   - 展开说明为什么这个问题难解决\r\n   - 不要写成产品功能列表\r\n\r\n4. 方案（核心部分）\r\n   - 围绕解决问题展开，自然引入产品能力\r\n   - 每个能力点附具体技术说明或数据\r\n   - 有架构层面的说明（存算分离/组件选型等）\r\n\r\n5. 效果数据\r\n   - 来自知识库的具体数字\r\n   - 如有客户场景，脱敏后引用\r\n\r\n6. 适用判断\r\n   - 适合什么场景/企业\r\n   - 不适合什么场景（体现客观性）\r\n\r\n7. 结尾\r\n   - 一句话总结\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n   - *{品牌名}团队*\r\n```\r\n\r\n## 字数：2000-2500字\r\n\r\n## 要点\r\n- 读者视角是\"我遇到了这个问题，怎么解决\"，不是\"这个产品有什么功能\"\r\n- 技术深度要到架构选择层面，不停在概念层\r\n- 结尾的适用判断体现专业客观性\n\nFile v1.3.0:README_zh.md\n\n# TCMS Writer（中文说明）\n\n**`tcms-*` 系列的一员** —— 面向科技产品营销团队的品牌方内容 Skill。\n*不是中立第三方产业研究，那是 `industry-deep-dive-pipeline` 的职责。*\n\n## 功能\n\n基于产品知识库与品牌规范，产出**品牌营销类长文初稿**（技术博客、客户案例、产品解读）。仅从 content brief 产出 1500–3000 字长文。\n\n不负责社交帖、短内容、渠道适配（见 `tcms-adapter`）。\n\n## 适用场景\n\n- 已有选题 Brief，需要品牌营销长文初稿。\n- 文章属推广 / 产品定位性质。\n\n## 不适用场景\n\n- 中立第三方产业深度研究 → 用 `industry-deep-dive-pipeline`。\n- 单篇发布前合规预审 → 用 `tcms-compliance-reviewer`。\n- 渠道适配 → 用 `tcms-adapter`。\n\n## 触发词\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## 流水线位置\n\n`tcms-planner`（选题）→ **`tcms-writer`**（初稿）→ `tcms-compliance-reviewer`（预审）→ `tcms-adapter`（渠道）→ `tcms-performance-analyst`（月度报告）\n\nFile v1.3.0:skill-card.md\n\n## Description:\n\nFor tech-product marketing teams, tcms-writer turns product knowledge bases, brand rules, and content briefs into 1500-3000 word brand-side drafts for technical blogs, customer case studies, and product write-ups.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[haiyangchenbj](https://clawhub.ai/user/haiyangchenbj)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nTechnology product marketing teams use this skill to draft long-form brand marketing content from an approved brief, product knowledge base, brand rules, and article template. It is intended for promotional product-positioning drafts, not neutral industry research, short-form social content, channel adaptation, or automatic publication.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may activate on broad writing requests that are not intended to be brand-side long-form marketing drafts.\n\nMitigation: Confirm the user has a content brief and that the requested article is a technical blog, customer case study, or product write-up before drafting.\n\nRisk: Drafts could include unsupported data points, product claims, customer identifiers, or internal information if the source material is not reviewed carefully.\n\nMitigation: Use only approved knowledge-base or published sources, keep the generated source-trace table, apply the sensitive-term and customer anonymization rules, and review the draft before publishing.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/haiyangchenbj/skills/tcms-writer)\n- [README](artifact/README.md)\n- [Skill definition](artifact/SKILL.md)\n- [Brand and content rules](artifact/references/brand-rules.md)\n- [Sensitive terms and prohibited expressions](artifact/references/sensitive-terms.md)\n- [Technical blog template](artifact/references/templates/tech-blog.md)\n- [Case study template](artifact/references/templates/case-study.md)\n- [Product update template](artifact/references/templates/product-update.md)\n\n## Skill Output:\n\n**Output Type(s):** [markdown, text, guidance]\n\n**Output Format:** [Markdown draft article plus Markdown source-trace table and pre-review checklist]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces a long-form draft and a companion review artifact; generated content requires human review before publication or channel adaptation.]\n\n## Skill Version(s):\n\n1.3.0 (source: SKILL.md frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.2.5: 3 files, 6487 bytes\n\nFiles: _meta.json (130b), skill-card.md (2448b), SKILL.md (10727b)\n\nFile v1.2.5:SKILL.md\n\n---\nslug: tcms-writer\ndisplayName: Tcms Writer\nname: tcms-writer\nversion: \"1.2.5\"\nnot_for:\n  - Social posts, short content, or channel adaptation (use an adaptation skill)\n  - Neutral third-party industry research (use a deep-dive pipeline skill)\n  - Publishing or distributing the draft (stops at first draft + review package)\n  - Writing without a content brief or source knowledge base\ndescription: |\n  For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis.\n  Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation.\n  Not for neutral industry research — use industry-deep-dive-pipeline for that.\ndescription_zh: \"技术产品营销写作器：面向技术产品营销团队，将产品知识库转化为品牌侧长文草稿（博客、案例、产品稿），仅产 1500-3000 字长文，不做社媒短文或渠道适配。\"\n\nread_when:\n  - 写文章\n  - 写稿\n  - 写初稿\n  - 起草\n  - 技术博客\n  - 品牌技术稿\n  - 案例文章\n  - 客户案例\n  - 产品解读\n  - 产品稿\n  - 新闻稿\n  - content brief\n  - draft\n  - 按brief写\nallowed-tools:\n  - read_file\n  - write_to_file\n  - replace_in_file\n  - web_fetch\n  - search_content\n  - search_file\n  - list_dir\nmetadata:\n  openclaw:\n    tags:\n      - content-marketing\n      - tech-product\n      - writing\n      - copywriting\n      - b2b\n      - brand-marketing\n      - tech-blog\n      - long-form\ndisable: false\n---\n\n# Content Writer\n\nProduces high-quality long-form first drafts from a product knowledge base, brand guidelines, and a content brief.\n\n## Operating mode: prompt chaining\n\nExecutes in fixed steps; each step has clear inputs and outputs.\n\n---\n\n## Step 1: Confirm the topic [deterministic]\n\nRead the topic information provided by the user and confirm the following elements:\n\n| Element | Must be clear | If missing |\n|---------|---------------|------------|\n| Article type | tech blog / customer case / product update | ask the user |\n| Target product | specific product name | ask the user |\n| Target reader | architect / CTO / engineer / analyst | default \"technical decision-maker\" |\n| Core message | the key value point to convey | extract from knowledge base |\n| Source material | knowledge base / internal material / published article | default knowledge base |\n| Confidentiality | whether internal cases need redaction | default full redaction |\n\nIf the user provides a brief file path, read the brief directly.\n\n---\n\n## Step 2: Read source material [deterministic]\n\n**Read only files related to the target product; do not load unrelated product information:**\n\n1. **Product knowledge base** → search the target product's section (don't read in full; use `search_content` to locate)\n2. **Brand guidelines** → `references/brand-rules.md` (read every time)\n3. **Article templates** → read the template matching the article type:\n   - tech blog: `references/templates/tech-blog.md`\n   - customer case: `references/templates/case-study.md`\n   - product update: `references/templates/product-update.md`\n4. **Supplementary material** (as needed): internal docs or published articles specified in the brief\n\n> The paths above must be configured per the actual project directory.\n\n---\n\n## Step 3: Writing [LLM]\n\n### Writing rules\n\n**Product names:**\n- First mention uses the official full name (see the product-name mapping table in `brand-rules.md`)\n- Subsequent mentions may use the short name\n\n**Brand presence:**\n- Title includes the brand name or the specific product's official name\n- Introduce the brand or specific product within the first two paragraphs\n- Fixed brand format at the end\n\n**Data citations:**\n- All data must come from the knowledge base or published articles; never fabricate\n- Record the source when citing (used to build the citation table in Step 5)\n\n**Customer information:**\n- Customer cases from internal sources are **redacted by default**\n- Redaction format: \"a {industry} {company-scale} company\"\n- Never show the customer's company name, internal staff names, or project code names\n- Use the real customer name only when the user has explicitly confirmed authorization\n\n**Competitor handling:**\n- Never name any competitor directly\n- Use substitute phrasing such as \"a peer platform\"\n\n**Product-capability source verification:**\n- Cite only capabilities that exist in the knowledge base\n- If unsure whether something is publicly released, mark it \"needs confirmation\" in the pre-review checklist\n\n### Expression red lines (writing discipline for tech-product marketing copy; converged from multiple revision rounds and the three-piece governance line — must not be violated)\n\n1. **No meta-language / self-reference.** Delete any sentence that steps outside the article to talk about its own structure — e.g. \"this article…\", \"the press release makes it clear that…\", \"deserves its own section\", \"back to the overall narrative\", \"as mentioned in the published draft\", \"the next section will…\". Transition with the content facts directly.\n2. **No business-jargon four-character slogans.** Slogans like \"多、快、好、省\" (many/fast/good/cheap) must be rewritten in engineering dimensions: load coverage / execution efficiency / operations experience / resource efficiency.\n3. **No absolutist phrasing.** Words like \"naturally connected\", \"seamless\", \"inevitable\", \"certain\", \"zero\" must be replaced with bounded qualifiers (e.g. \"permissions and lineage inherit uniformly with the table object, reducing cross-engine re-authorization and fragmentation\").\n4. **Naming consistency (P0).** A product's external name must match the already-published authoritative materials of the same campaign (press release / official site / official account) verbatim; the tech blog 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\"); naming within the same campaign must be byte-for-byte consistent.\n5. **Faithful transcription vs quantified claims.** Infrastructure capabilities (e.g. a specific networking/storage technique) may be stated as-is if backed by an architecture diagram or published material; but quantified speedup multiples (e.g. \"X accelerates N times\") must not be written without an official figure — use qualitative phrasing instead.\n\n### Article structure\n\nDo not write: feature 1 → feature 2 → feature 3 (a product spec sheet).\n\nDo write: **problem → why it's hard → solution (naturally introducing product capability) → effect → applicability judgment**.\n\nEvery article must leave the reader with a clear takeaway — a judgment they can make, or a method they can learn.\n\n### Word count\n\nTarget 1500-3000 words. Compress if over 3500; supplement if under 1200.\n\n---\n\n## Step 4: Self-check [LLM]\n\n| Check | Pass criterion | If fail |\n|-------|----------------|---------|\n| Customer-name leak | no customer name in internally-sourced cases | immediately replace with redacted version |\n| Competitor naming | no competitor company name | replace |\n| Product-name规范 | first mention uses official full name | fix |\n| Brand presence | present in title / opening / closing | supplement |\n| Data has source | every number points to a knowledge-base entry | delete unsourced data |\n| Internal code name | no undisclosed product code name / feature name | delete |\n| Word-count range | 1500-3000 words | adjust |\n\n---\n\n## Step 5: Output [deterministic]\n\nProduce two files:\n\n**File 1: article first draft**\nPath: `content/drafts/YYYY-MM-{product}-{topic-short}.md`\n\n**File 2: citation-traceability table + pre-review checklist**\nPath: same directory, filename with `-review` suffix\n\n```markdown\n## Execution summary\n- Source material read: [list actual files read]\n- Template chosen: [article type]\n- Article word count: [actual]\n- Cited data points: [N] ( [M] public, [K] internal redacted)\n- Self-check: 7 checks, [X] passed [Y] fixed\n\n## Citation traceability\n\n| Data point in text | Knowledge-base entry / source | Public status |\n|--------------------|------------------------------|---------------|\n| \"xxx\" | xxx entry / source article | ✅ public / 📋 internal (redacted) |\n\n## Pre-review checklist\n\n- [ ] Customer-name redaction check\n- [ ] Product-capability public-status check\n- [ ] Data points PM needs to confirm\n```\n\n---\n\n## Hard rules\n\n1. **Never fabricate data.** Don't write numbers without a source.\n2. **Internal cases are redacted by default.** Unless the user has explicitly confirmed authorization.\n3. **Never name competitors.**\n4. **Product names follow the official site.**\n5. **Don't cite product capabilities not in the knowledge base.** Mark uncertain ones \"needs confirmation\".\n6. **Every article must attach a citation-traceability table.**\n7. **Don't promote products whose external messaging is unconfirmed.**\n8. **Expression red lines are non-negotiable** (see the \"Expression red lines\" subsection in Step 3): no meta-language/self-reference, no business-jargon four-character slogans, no absolutist phrasing, naming consistency (P0 — external name follows the same-campaign published materials, no version-number suffix), faithful transcription vs quantified claims. Must be followed while writing; issues of the same kind found in pre-publication audit count as a miss by this Skill.\n\n---\n\n## Failure handling\n\n| Scenario | Handling |\n|----------|----------|\n| Target product not found in knowledge base | stop generation, report \"no information on {product} in knowledge base\" |\n| Brief requests an article type with no template | use tech-blog template as default |\n| Cited data marked \"expired\" | don't cite; flag in pre-review checklist |\n| Customer authorization status unclear | default redaction |\n| Article over 3500 words | give compression suggestions |\n\n---\n\n## ⚠️ Human-in-the-loop\n\nAfter output, the article enters **human review**. This Skill does not auto-publish; every first draft must be confirmed by a human before entering `content-adapter` for channel adaptation.\n\n---\n\n## 中文摘要\n\nContent Writer 是面向品牌营销的长文创作 Agent：基于产品知识库、品牌规范与选题 Brief，产出 1500–3000 字的技术博客、客户案例或产品解读初稿（不含社交帖与渠道适配）。写作严守五条表达红线（禁用元语言/自我指涉、禁用商务腔四字总结、禁止绝对化表述、P0 命名一致性、忠实转录 vs 量化断言）；内部客户案例默认脱敏、不点名竞品、所有数据须有出处并附引用追溯表。初稿完成后进入人工 review，不自动发布。\n\nFile v1.2.5:_meta.json\n\n{\n  \"ownerId\": \"kn70yg6zwmkftx4939qrs89awx82rr9a\",\n  \"slug\": \"tcms-writer\",\n  \"version\": \"1.2.5\",\n  \"publishedAt\": 1788837103821\n}\n\nFile v1.2.5:skill-card.md\n\n## Description:\n\nFor tech-product marketing teams, this skill turns a product knowledge base and content brief into brand-side long-form first drafts such as tech blogs, customer cases, and product write-ups.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[haiyangchenbj](https://clawhub.ai/user/haiyangchenbj)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nProduct marketing teams use this skill to draft 1500-3000 word brand-side technical articles from a content brief, product knowledge base, brand rules, and article templates. It is scoped to first drafts and review packages, not social posts, neutral industry research, channel adaptation, or publication.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad writing triggers may route ordinary drafting requests to this product-marketing skill in environments with many writing skills.\n\nMitigation: Review activation settings and reserve this skill for product-marketing long-form drafting from a known brief and source material.\n\nRisk: The skill depends on project-specific brand rules, templates, and product knowledge base files.\n\nMitigation: Confirm the referenced brand rules, article templates, and source knowledge base exist in the target project before using the skill.\n\nRisk: Drafts can include confidential customer or product details if source material is not reviewed carefully.\n\nMitigation: Keep human review in the workflow, redact internal customer cases by default, and verify all cited data against the knowledge base before publication.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/haiyangchenbj/skills/tcms-writer)\n- [Publisher profile](https://clawhub.ai/user/haiyangchenbj)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Files, Guidance]\n\n**Output Format:** [Markdown article draft plus a Markdown citation traceability table and pre-review checklist]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Drafts target 1500-3000 words and include source traceability and human review checks before publication.]\n\n## Skill Version(s):\n\n1.2.5 (source: SKILL.md frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.2.3: 3 files, 6554 bytes\n\nFiles: skill-card.md (2513b), SKILL.md (10727b), _meta.json (130b)\n\nFile v1.2.3:SKILL.md\n\n---\nslug: tcms-writer\ndisplayName: Tcms Writer\nname: tcms-writer\nversion: \"1.2.3\"\nnot_for:\n  - Social posts, short content, or channel adaptation (use an adaptation skill)\n  - Neutral third-party industry research (use a deep-dive pipeline skill)\n  - Publishing or distributing the draft (stops at first draft + review package)\n  - Writing without a content brief or source knowledge base\ndescription: |\n  For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis.\n  Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation.\n  Not for neutral industry research — use industry-deep-dive-pipeline for that.\ndescription_zh: \"技术产品营销写作器：面向技术产品营销团队，将产品知识库转化为品牌侧长文草稿（博客、案例、产品稿），仅产 1500-3000 字长文，不做社媒短文或渠道适配。\"\n\nread_when:\n  - 写文章\n  - 写稿\n  - 写初稿\n  - 起草\n  - 技术博客\n  - 品牌技术稿\n  - 案例文章\n  - 客户案例\n  - 产品解读\n  - 产品稿\n  - 新闻稿\n  - content brief\n  - draft\n  - 按brief写\nallowed-tools:\n  - read_file\n  - write_to_file\n  - replace_in_file\n  - web_fetch\n  - search_content\n  - search_file\n  - list_dir\nmetadata:\n  openclaw:\n    tags:\n      - content-marketing\n      - tech-product\n      - writing\n      - copywriting\n      - b2b\n      - brand-marketing\n      - tech-blog\n      - long-form\ndisable: false\n---\n\n# Content Writer\n\nProduces high-quality long-form first drafts from a product knowledge base, brand guidelines, and a content brief.\n\n## Operating mode: prompt chaining\n\nExecutes in fixed steps; each step has clear inputs and outputs.\n\n---\n\n## Step 1: Confirm the topic [deterministic]\n\nRead the topic information provided by the user and confirm the following elements:\n\n| Element | Must be clear | If missing |\n|---------|---------------|------------|\n| Article type | tech blog / customer case / product update | ask the user |\n| Target product | specific product name | ask the user |\n| Target reader | architect / CTO / engineer / analyst | default \"technical decision-maker\" |\n| Core message | the key value point to convey | extract from knowledge base |\n| Source material | knowledge base / internal material / published article | default knowledge base |\n| Confidentiality | whether internal cases need redaction | default full redaction |\n\nIf the user provides a brief file path, read the brief directly.\n\n---\n\n## Step 2: Read source material [deterministic]\n\n**Read only files related to the target product; do not load unrelated product information:**\n\n1. **Product knowledge base** → search the target product's section (don't read in full; use `search_content` to locate)\n2. **Brand guidelines** → `references/brand-rules.md` (read every time)\n3. **Article templates** → read the template matching the article type:\n   - tech blog: `references/templates/tech-blog.md`\n   - customer case: `references/templates/case-study.md`\n   - product update: `references/templates/product-update.md`\n4. **Supplementary material** (as needed): internal docs or published articles specified in the brief\n\n> The paths above must be configured per the actual project directory.\n\n---\n\n## Step 3: Writing [LLM]\n\n### Writing rules\n\n**Product names:**\n- First mention uses the official full name (see the product-name mapping table in `brand-rules.md`)\n- Subsequent mentions may use the short name\n\n**Brand presence:**\n- Title includes the brand name or the specific product's official name\n- Introduce the brand or specific product within the first two paragraphs\n- Fixed brand format at the end\n\n**Data citations:**\n- All data must come from the knowledge base or published articles; never fabricate\n- Record the source when citing (used to build the citation table in Step 5)\n\n**Customer information:**\n- Customer cases from internal sources are **redacted by default**\n- Redaction format: \"a {industry} {company-scale} company\"\n- Never show the customer's company name, internal staff names, or project code names\n- Use the real customer name only when the user has explicitly confirmed authorization\n\n**Competitor handling:**\n- Never name any competitor directly\n- Use substitute phrasing such as \"a peer platform\"\n\n**Product-capability source verification:**\n- Cite only capabilities that exist in the knowledge base\n- If unsure whether something is publicly released, mark it \"needs confirmation\" in the pre-review checklist\n\n### Expression red lines (writing discipline for tech-product marketing copy; converged from multiple revision rounds and the three-piece governance line — must not be violated)\n\n1. **No meta-language / self-reference.** Delete any sentence that steps outside the article to talk about its own structure — e.g. \"this article…\", \"the press release makes it clear that…\", \"deserves its own section\", \"back to the overall narrative\", \"as mentioned in the published draft\", \"the next section will…\". Transition with the content facts directly.\n2. **No business-jargon four-character slogans.** Slogans like \"多、快、好、省\" (many/fast/good/cheap) must be rewritten in engineering dimensions: load coverage / execution efficiency / operations experience / resource efficiency.\n3. **No absolutist phrasing.** Words like \"naturally connected\", \"seamless\", \"inevitable\", \"certain\", \"zero\" must be replaced with bounded qualifiers (e.g. \"permissions and lineage inherit uniformly with the table object, reducing cross-engine re-authorization and fragmentation\").\n4. **Naming consistency (P0).** A product's external name must match the already-published authoritative materials of the same campaign (press release / official site / official account) verbatim; the tech blog 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\"); naming within the same campaign must be byte-for-byte consistent.\n5. **Faithful transcription vs quantified claims.** Infrastructure capabilities (e.g. a specific networking/storage technique) may be stated as-is if backed by an architecture diagram or published material; but quantified speedup multiples (e.g. \"X accelerates N times\") must not be written without an official figure — use qualitative phrasing instead.\n\n### Article structure\n\nDo not write: feature 1 → feature 2 → feature 3 (a product spec sheet).\n\nDo write: **problem → why it's hard → solution (naturally introducing product capability) → effect → applicability judgment**.\n\nEvery article must leave the reader with a clear takeaway — a judgment they can make, or a method they can learn.\n\n### Word count\n\nTarget 1500-3000 words. Compress if over 3500; supplement if under 1200.\n\n---\n\n## Step 4: Self-check [LLM]\n\n| Check | Pass criterion | If fail |\n|-------|----------------|---------|\n| Customer-name leak | no customer name in internally-sourced cases | immediately replace with redacted version |\n| Competitor naming | no competitor company name | replace |\n| Product-name规范 | first mention uses official full name | fix |\n| Brand presence | present in title / opening / closing | supplement |\n| Data has source | every number points to a knowledge-base entry | delete unsourced data |\n| Internal code name | no undisclosed product code name / feature name | delete |\n| Word-count range | 1500-3000 words | adjust |\n\n---\n\n## Step 5: Output [deterministic]\n\nProduce two files:\n\n**File 1: article first draft**\nPath: `content/drafts/YYYY-MM-{product}-{topic-short}.md`\n\n**File 2: citation-traceability table + pre-review checklist**\nPath: same directory, filename with `-review` suffix\n\n```markdown\n## Execution summary\n- Source material read: [list actual files read]\n- Template chosen: [article type]\n- Article word count: [actual]\n- Cited data points: [N] ( [M] public, [K] internal redacted)\n- Self-check: 7 checks, [X] passed [Y] fixed\n\n## Citation traceability\n\n| Data point in text | Knowledge-base entry / source | Public status |\n|--------------------|------------------------------|---------------|\n| \"xxx\" | xxx entry / source article | ✅ public / 📋 internal (redacted) |\n\n## Pre-review checklist\n\n- [ ] Customer-name redaction check\n- [ ] Product-capability public-status check\n- [ ] Data points PM needs to confirm\n```\n\n---\n\n## Hard rules\n\n1. **Never fabricate data.** Don't write numbers without a source.\n2. **Internal cases are redacted by default.** Unless the user has explicitly confirmed authorization.\n3. **Never name competitors.**\n4. **Product names follow the official site.**\n5. **Don't cite product capabilities not in the knowledge base.** Mark uncertain ones \"needs confirmation\".\n6. **Every article must attach a citation-traceability table.**\n7. **Don't promote products whose external messaging is unconfirmed.**\n8. **Expression red lines are non-negotiable** (see the \"Expression red lines\" subsection in Step 3): no meta-language/self-reference, no business-jargon four-character slogans, no absolutist phrasing, naming consistency (P0 — external name follows the same-campaign published materials, no version-number suffix), faithful transcription vs quantified claims. Must be followed while writing; issues of the same kind found in pre-publication audit count as a miss by this Skill.\n\n---\n\n## Failure handling\n\n| Scenario | Handling |\n|----------|----------|\n| Target product not found in knowledge base | stop generation, report \"no information on {product} in knowledge base\" |\n| Brief requests an article type with no template | use tech-blog template as default |\n| Cited data marked \"expired\" | don't cite; flag in pre-review checklist |\n| Customer authorization status unclear | default redaction |\n| Article over 3500 words | give compression suggestions |\n\n---\n\n## ⚠️ Human-in-the-loop\n\nAfter output, the article enters **human review**. This Skill does not auto-publish; every first draft must be confirmed by a human before entering `content-adapter` for channel adaptation.\n\n---\n\n## 中文摘要\n\nContent Writer 是面向品牌营销的长文创作 Agent：基于产品知识库、品牌规范与选题 Brief，产出 1500–3000 字的技术博客、客户案例或产品解读初稿（不含社交帖与渠道适配）。写作严守五条表达红线（禁用元语言/自我指涉、禁用商务腔四字总结、禁止绝对化表述、P0 命名一致性、忠实转录 vs 量化断言）；内部客户案例默认脱敏、不点名竞品、所有数据须有出处并附引用追溯表。初稿完成后进入人工 review，不自动发布。\n\nFile v1.2.3:_meta.json\n\n{\n  \"ownerId\": \"kn70yg6zwmkftx4939qrs89awx82rr9a\",\n  \"slug\": \"tcms-writer\",\n  \"version\": \"1.2.3\",\n  \"publishedAt\": 1787551904347\n}\n\nFile v1.2.3:skill-card.md\n\n## Description:\n\nTcms Writer helps tech-product marketing teams turn a product knowledge base, brand guidelines, and a content brief into brand-side long-form drafts such as technical blogs, customer cases, and product write-ups.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[haiyangchenbj](https://clawhub.ai/user/haiyangchenbj)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nMarketing writers and product teams use this skill to draft 1500-3000 word brand-side technical articles from a clear content brief and source knowledge base. It is intended for long-form first drafts and review packages, not social posts, neutral industry research, or publishing.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: A draft could expose internal customer names, staff names, project code names, or unapproved customer case details.\n\nMitigation: The skill defaults internal customer cases to redacted descriptions and requires human review before further use.\n\nRisk: A draft could include unsupported numbers, product claims, or externally unconfirmed messaging.\n\nMitigation: The skill requires all data to come from the knowledge base or published articles, attaches citation traceability, and flags uncertain public-status claims for review.\n\nRisk: The skill could be invoked too broadly in workspaces with many writing skills or sensitive product documents.\n\nMitigation: Narrow activation phrases for the workspace and provide a clear brief before use.\n\nRisk: A first draft could be mistaken for publish-ready content.\n\nMitigation: The skill produces a draft and review package only; it does not publish or adapt content for channels.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/haiyangchenbj/skills/tcms-writer)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance, files]\n\n**Output Format:** [Markdown files: a long-form article draft plus a citation-traceability table and pre-review checklist.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Targets 1500-3000 word drafts, records cited data points, and stops before publication or channel adaptation.]\n\n## Skill Version(s):\n\n1.2.3 (source: frontmatter and server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.2.2: 10 files, 12523 bytes\n\nFiles: _meta.json (130b), README_zh.md (1188b), README.md (1286b), references/brand-rules.md (1807b), references/sensitive-terms.md (939b), references/templates/case-study.md (1124b), references/templates/product-update.md (1066b), references/templates/tech-blog.md (1162b), skill-card.md (2611b), SKILL.md (10600b)\n\nFile v1.2.2:SKILL.md\n\n---\r\nname: tcms-writer\r\nversion: \"1.2.2\"\r\ndescription: |\r\n  For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis.\r\n  Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation.\r\n  Not for neutral industry research — use industry-deep-dive-pipeline for that.\r\ndescription_zh: \"技术产品营销写作器：面向技术产品营销团队，将产品知识库转化为品牌侧长文草稿（博客、案例、产品稿），仅产 1500-3000 字长文，不做社媒短文或渠道适配。\"\r\n\r\nread_when:\r\n  - 写文章\r\n  - 写稿\r\n  - 写初稿\r\n  - 起草\r\n  - 技术博客\r\n  - 品牌技术稿\r\n  - 案例文章\r\n  - 客户案例\r\n  - 产品解读\r\n  - 产品稿\r\n  - 新闻稿\r\n  - content brief\r\n  - draft\r\n  - 按brief写\r\nallowed-tools:\r\n  - read_file\r\n  - write_to_file\r\n  - replace_in_file\r\n  - web_fetch\r\n  - search_content\r\n  - search_file\r\n  - list_dir\r\nmetadata:\r\n  openclaw:\r\n    tags:\r\n      - content-marketing\r\n      - tech-product\r\n      - writing\r\n      - copywriting\r\n      - b2b\r\n      - brand-marketing\r\n      - tech-blog\r\n      - long-form\r\ndisable: false\r\n---\r\n\r\n# Content Writer\r\n\r\nProduces high-quality long-form first drafts from a product knowledge base, brand guidelines, and a content brief.\r\n\r\n## Operating mode: prompt chaining\r\n\r\nExecutes in fixed steps; each step has clear inputs and outputs.\r\n\r\n---\r\n\r\n## Step 1: Confirm the topic [deterministic]\r\n\r\nRead the topic information provided by the user and confirm the following elements:\r\n\r\n| Element | Must be clear | If missing |\r\n|---------|---------------|------------|\r\n| Article type | tech blog / customer case / product update | ask the user |\r\n| Target product | specific product name | ask the user |\r\n| Target reader | architect / CTO / engineer / analyst | default \"technical decision-maker\" |\r\n| Core message | the key value point to convey | extract from knowledge base |\r\n| Source material | knowledge base / internal material / published article | default knowledge base |\r\n| Confidentiality | whether internal cases need redaction | default full redaction |\r\n\r\nIf the user provides a brief file path, read the brief directly.\r\n\r\n---\r\n\r\n## Step 2: Read source material [deterministic]\r\n\r\n**Read only files related to the target product; do not load unrelated product information:**\r\n\r\n1. **Product knowledge base** → search the target product's section (don't read in full; use `search_content` to locate)\r\n2. **Brand guidelines** → `references/brand-rules.md` (read every time)\r\n3. **Article templates** → read the template matching the article type:\r\n   - tech blog: `references/templates/tech-blog.md`\r\n   - customer case: `references/templates/case-study.md`\r\n   - product update: `references/templates/product-update.md`\r\n4. **Supplementary material** (as needed): internal docs or published articles specified in the brief\r\n\r\n> The paths above must be configured per the actual project directory.\r\n\r\n---\r\n\r\n## Step 3: Writing [LLM]\r\n\r\n### Writing rules\r\n\r\n**Product names:**\r\n- First mention uses the official full name (see the product-name mapping table in `brand-rules.md`)\r\n- Subsequent mentions may use the short name\r\n\r\n**Brand presence:**\r\n- Title includes the brand name or the specific product's official name\r\n- Introduce the brand or specific product within the first two paragraphs\r\n- Fixed brand format at the end\r\n\r\n**Data citations:**\r\n- All data must come from the knowledge base or published articles; never fabricate\r\n- Record the source when citing (used to build the citation table in Step 5)\r\n\r\n**Customer information:**\r\n- Customer cases from internal sources are **redacted by default**\r\n- Redaction format: \"a {industry} {company-scale} company\"\r\n- Never show the customer's company name, internal staff names, or project code names\r\n- Use the real customer name only when the user has explicitly confirmed authorization\r\n\r\n**Competitor handling:**\r\n- Never name any competitor directly\r\n- Use substitute phrasing such as \"a peer platform\"\r\n\r\n**Product-capability source verification:**\r\n- Cite only capabilities that exist in the knowledge base\r\n- If unsure whether something is publicly released, mark it \"needs confirmation\" in the pre-review checklist\r\n\r\n### Expression red lines (writing discipline for tech-product marketing copy; converged from multiple revision rounds and the three-piece governance line — must not be violated)\r\n\r\n1. **No meta-language / self-reference.** Delete any sentence that steps outside the article to talk about its own structure — e.g. \"this article…\", \"the press release makes it clear that…\", \"deserves its own section\", \"back to the overall narrative\", \"as mentioned in the published draft\", \"the next section will…\". Transition with the content facts directly.\r\n2. **No business-jargon four-character slogans.** Slogans like \"多、快、好、省\" (many/fast/good/cheap) must be rewritten in engineering dimensions: load coverage / execution efficiency / operations experience / resource efficiency.\r\n3. **No absolutist phrasing.** Words like \"naturally connected\", \"seamless\", \"inevitable\", \"certain\", \"zero\" must be replaced with bounded qualifiers (e.g. \"permissions and lineage inherit uniformly with the table object, reducing cross-engine re-authorization and fragmentation\").\r\n4. **Naming consistency (P0).** A product's external name must match the already-published authoritative materials of the same campaign (press release / official site / official account) verbatim; the tech blog 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\"); naming within the same campaign must be byte-for-byte consistent.\r\n5. **Faithful transcription vs quantified claims.** Infrastructure capabilities (e.g. a specific networking/storage technique) may be stated as-is if backed by an architecture diagram or published material; but quantified speedup multiples (e.g. \"X accelerates N times\") must not be written without an official figure — use qualitative phrasing instead.\r\n\r\n### Article structure\r\n\r\nDo not write: feature 1 → feature 2 → feature 3 (a product spec sheet).\r\n\r\nDo write: **problem → why it's hard → solution (naturally introducing product capability) → effect → applicability judgment**.\r\n\r\nEvery article must leave the reader with a clear takeaway — a judgment they can make, or a method they can learn.\r\n\r\n### Word count\r\n\r\nTarget 1500-3000 words. Compress if over 3500; supplement if under 1200.\r\n\r\n---\r\n\r\n## Step 4: Self-check [LLM]\r\n\r\n| Check | Pass criterion | If fail |\r\n|-------|----------------|---------|\r\n| Customer-name leak | no customer name in internally-sourced cases | immediately replace with redacted version |\r\n| Competitor naming | no competitor company name | replace |\r\n| Product-name规范 | first mention uses official full name | fix |\r\n| Brand presence | present in title / opening / closing | supplement |\r\n| Data has source | every number points to a knowledge-base entry | delete unsourced data |\r\n| Internal code name | no undisclosed product code name / feature name | delete |\r\n| Word-count range | 1500-3000 words | adjust |\r\n\r\n---\r\n\r\n## Step 5: Output [deterministic]\r\n\r\nProduce two files:\r\n\r\n**File 1: article first draft**\r\nPath: `content/drafts/YYYY-MM-{product}-{topic-short}.md`\r\n\r\n**File 2: citation-traceability table + pre-review checklist**\r\nPath: same directory, filename with `-review` suffix\r\n\r\n```markdown\r\n## Execution summary\r\n- Source material read: [list actual files read]\r\n- Template chosen: [article type]\r\n- Article word count: [actual]\r\n- Cited data points: [N] ( [M] public, [K] internal redacted)\r\n- Self-check: 7 checks, [X] passed [Y] fixed\r\n\r\n## Citation traceability\r\n\r\n| Data point in text | Knowledge-base entry / source | Public status |\r\n|--------------------|------------------------------|---------------|\r\n| \"xxx\" | xxx entry / source article | ✅ public / 📋 internal (redacted) |\r\n\r\n## Pre-review checklist\r\n\r\n- [ ] Customer-name redaction check\r\n- [ ] Product-capability public-status check\r\n- [ ] Data points PM needs to confirm\r\n```\r\n\r\n---\r\n\r\n## Hard rules\r\n\r\n1. **Never fabricate data.** Don't write numbers without a source.\r\n2. **Internal cases are redacted by default.** Unless the user has explicitly confirmed authorization.\r\n3. **Never name competitors.**\r\n4. **Product names follow the official site.**\r\n5. **Don't cite product capabilities not in the knowledge base.** Mark uncertain ones \"needs confirmation\".\r\n6. **Every article must attach a citation-traceability table.**\r\n7. **Don't promote products whose external messaging is unconfirmed.**\r\n8. **Expression red lines are non-negotiable** (see the \"Expression red lines\" subsection in Step 3): no meta-language/self-reference, no business-jargon four-character slogans, no absolutist phrasing, naming consistency (P0 — external name follows the same-campaign published materials, no version-number suffix), faithful transcription vs quantified claims. Must be followed while writing; issues of the same kind found in pre-publication audit count as a miss by this Skill.\r\n\r\n---\r\n\r\n## Failure handling\r\n\r\n| Scenario | Handling |\r\n|----------|----------|\r\n| Target product not found in knowledge base | stop generation, report \"no information on {product} in knowledge base\" |\r\n| Brief requests an article type with no template | use tech-blog template as default |\r\n| Cited data marked \"expired\" | don't cite; flag in pre-review checklist |\r\n| Customer authorization status unclear | default redaction |\r\n| Article over 3500 words | give compression suggestions |\r\n\r\n---\r\n\r\n## ⚠️ Human-in-the-loop\r\n\r\nAfter output, the article enters **human review**. This Skill does not auto-publish; every first draft must be confirmed by a human before entering `content-adapter` for channel adaptation.\r\n\r\n---\r\n\r\n## 中文摘要\r\n\r\nContent Writer 是面向品牌营销的长文创作 Agent：基于产品知识库、品牌规范与选题 Brief，产出 1500–3000 字的技术博客、客户案例或产品解读初稿（不含社交帖与渠道适配）。写作严守五条表达红线（禁用元语言/自我指涉、禁用商务腔四字总结、禁止绝对化表述、P0 命名一致性、忠实转录 vs 量化断言）；内部客户案例默认脱敏、不点名竞品、所有数据须有出处并附引用追溯表。初稿完成后进入人工 review，不自动发布。\n\nFile v1.2.2:README.md\n\n# TCMS Writer\n\n**Part of the `tcms-*` family** — brand-side content skills for tech-product marketing teams.\n*Not for neutral third-party industry research — that is `industry-deep-dive-pipeline`'s job.*\n\n## What it does\n\nTurns a product knowledge base and brand rules into **brand-side long-form drafts** (technical blogs, customer case studies, product write-ups). Produces only 1500–3000 word drafts from a content brief.\n\nIt does **not** handle social posts, short content, or channel adaptation (see `tcms-adapter`).\n\n## When to use\n\n- You have a topic brief and need a long-form brand marketing draft.\n- The piece is promotional / product-positioning in nature.\n\n## When NOT to use\n\n- Neutral, third-party industry deep-dives → use `industry-deep-dive-pipeline`.\n- Single-article pre-publish compliance check → use `tcms-compliance-reviewer`.\n- Channel adaptation → use `tcms-adapter`.\n\n## Trigger phrases\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## Pipeline position\n\n`tcms-planner` (brief) → **`tcms-writer`** (draft) → `tcms-compliance-reviewer` (review) → `tcms-adapter` (channels) → `tcms-performance-analyst` (monthly report)\n\nFile v1.2.2:_meta.json\n\n{\n  \"ownerId\": \"kn70yg6zwmkftx4939qrs89awx82rr9a\",\n  \"slug\": \"tcms-writer\",\n  \"version\": \"1.2.2\",\n  \"publishedAt\": 1786084756580\n}\n\nFile v1.2.2:references/brand-rules.md\n\n# 品牌与内容规范\r\n\r\n> 按实际品牌和产品线配置以下内容。\r\n\r\n## 产品正式名称\r\n\r\n首次提及用全称，后续可用简称。\r\n\r\n| 简称 | 官网全称 | 首次引用格式 |\r\n|------|---------|------------|\r\n| 产品A | xxx平台 | XX云xxx平台（产品A） |\r\n| 产品B | xxx服务 | XX云xxx服务（产品B） |\r\n| ... | ... | ... |\r\n\r\n> 从官网产品页获取正式名称，保持一致。\r\n\r\n## 品牌露出规则\r\n\r\n- 标题中包含品牌名或具体产品官方名称\r\n- 开头两段内引入品牌或具体产品\r\n- 结尾固定格式：**{品牌名}，帮助/助力 xxx企业xxx。**\r\n- 正文中产品首次出现用全称，后续用简称\r\n\r\n## 写作调性\r\n\r\n- 专业、克制、有判断。不油腻，不夸张，不AI营销腔\r\n- 允许专业术语，紧跟一句通俗解释\r\n- 给结论和判断，不只堆信息\r\n- 像成熟的技术分析者，不像内容农场\r\n\r\n## 禁用表达\r\n\r\n| 类型 | 禁用 | 替代 |\r\n|------|------|------|\r\n| 竞品点名 | 具体竞品名称 | \"某友商平台\"\"原有闭源平台\" |\r\n| 未确认产品 | 内部规划中未正式发布的产品 | 不提及 |\r\n| 空话 | 赋能/闭环/端到端/强大/显著/大幅/打造 | 用具体数据和场景替代 |\r\n| 内部代号 | 任何未在官网出现的产品代号 | 不使用 |\r\n\r\n## 客户脱敏规则\r\n\r\n内部来源的客户案例默认脱敏：\r\n\r\n| 场景 | 脱敏格式 |\r\n|------|---------|\r\n| 知名企业 | 某+行业+规模，如\"某头部券商\" |\r\n| 一般企业 | 某+行业+企业类型，如\"某SaaS服务商\" |\r\n| 人员信息 | 不出现姓名/工号/企业微信ID |\r\n\r\n> 在此处维护具体客户名→脱敏名的映射表（不随代码同步）。\r\n\r\n## 已授权可公开引用的客户\r\n\r\n> 在此处维护已明确授权的客户名单。\n\nFile v1.2.2:references/sensitive-terms.md\n\n# 敏感词与禁用表达\r\n\r\n## 禁止出现的客户名称（内部来源，未确认授权）\r\n\r\n> 在此处维护具体客户名称列表。内部材料中出现的客户名必须脱敏处理。\r\n\r\n## 禁止出现的竞品名称\r\n\r\n> 在此处维护竞品公司名和产品名列表。\r\n\r\n替代表述：某友商平台 / 原有闭源平台 / 国际主流平台 / 其他同类产品\r\n\r\n## 禁止出现的未确认产品\r\n\r\n> 在此处维护内部规划中、对外口径未确认的产品名。\r\n\r\n## 禁止出现的内部信息\r\n\r\n- 内部项目代号\r\n- 内部人员姓名和通讯ID\r\n- 内部材料中的管理备注（如\"需和XX确认\"）\r\n- 内部材料roadmap中标注但官网未上线的功能（需逐条验证）\r\n\r\n## 慎用表达（非禁止，但尽量避免）\r\n\r\n赋能, 闭环, 端到端, 强大, 显著, 大幅, 打造, 一站式, 全面, 领先, 极致, 颠覆, 革命性\r\n→ 用具体数据和场景描述替代\n\nFile v1.2.2:references/templates/case-study.md\n\n# 客户案例模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题\r\n   格式A（已授权）：{客户名}+{产品}+{核心成果}\r\n   格式B（脱敏）：某{行业}{规模}企业+{场景}+{核心成果}\r\n\r\n2. 客户背景（1段）\r\n   - 企业定位（行业/规模/业务特点）\r\n   - 脱敏案例不写太具体的业务描述，避免被反推\r\n\r\n3. 业务挑战（3-4个痛点）\r\n   - 每个痛点一句话标题+2-3句展开\r\n   - 痛点要具体到技术层面，不是泛泛的\"效率低\"\r\n\r\n4. 方案选型\r\n   - 为什么选这个方案（简要）\r\n   - 使用了哪些产品（用官网全称）\r\n   - 架构概述\r\n\r\n5. 实施效果\r\n   - 硬数据（性能提升x%、成本降低x%等）\r\n   - 来自知识库，标注出处\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2000字\r\n\r\n## 要点\r\n- 月报来源的案例**默认全文脱敏**\r\n- 已在CSDN公开发布的案例可直接引用客户名\r\n- 痛点部分是案例文章最有价值的部分——读者通过痛点判断\"跟我的情况像不像\"\r\n- 方案部分不要写成产品功能清单，重点是\"选型逻辑\"\n\nFile v1.2.2:references/templates/product-update.md\n\n# 产品解读模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含产品名+核心升级/认证/能力）\r\n\r\n2. 开头（1段）\r\n   - 一句话说清\"什么产品出了什么变化\"\r\n   - 立即说明这个变化对用户意味着什么\r\n\r\n3. 背景与趋势（1-2段）\r\n   - 行业背景：为什么需要这个能力/认证\r\n   - 不要写太长的行业铺垫，读者关心的是产品变化\r\n\r\n4. 核心内容（主体）\r\n   - 新能力/新版本：具体是什么、怎么用、有什么数据\r\n   - 认证解读：认证标准考什么、通过意味着什么、对选型的参考价值\r\n   - 不罗列全部功能，选最有差异化的2-3个展开\r\n\r\n5. 对用户的影响\r\n   - 现有用户怎么用（升级路径/兼容性）\r\n   - 潜在用户怎么看（选型参考）\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2200字\r\n\r\n## 要点\r\n- 不写成\"我们发布了好厉害\"的自夸体\r\n- 读者关心的是\"这对我有什么用\"\r\n- 认证类文章重点解读标准本身的价值，而非通过考试的荣耀感\n\nFile v1.2.2:references/templates/tech-blog.md\n\n# 技术博客模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含品牌名或产品名）\r\n\r\n2. 开头（1-2段）\r\n   - 场景引入：什么场景下，企业面临什么问题\r\n   - 自然引出品牌xxx产品（不晚于第二段）\r\n\r\n3. 问题展开（2-4个子问题）\r\n   - 每个问题用一句话标题概括\r\n   - 展开说明为什么这个问题难解决\r\n   - 不要写成产品功能列表\r\n\r\n4. 方案（核心部分）\r\n   - 围绕解决问题展开，自然引入产品能力\r\n   - 每个能力点附具体技术说明或数据\r\n   - 有架构层面的说明（存算分离/组件选型等）\r\n\r\n5. 效果数据\r\n   - 来自知识库的具体数字\r\n   - 如有客户场景，脱敏后引用\r\n\r\n6. 适用判断\r\n   - 适合什么场景/企业\r\n   - 不适合什么场景（体现客观性）\r\n\r\n7. 结尾\r\n   - 一句话总结\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n   - *{品牌名}团队*\r\n```\r\n\r\n## 字数：2000-2500字\r\n\r\n## 要点\r\n- 读者视角是\"我遇到了这个问题，怎么解决\"，不是\"这个产品有什么功能\"\r\n- 技术深度要到架构选择层面，不停在概念层\r\n- 结尾的适用判断体现专业客观性\n\nFile v1.2.2:README_zh.md\n\n# TCMS Writer（中文说明）\n\n**`tcms-*` 系列的一员** —— 面向科技产品营销团队的品牌方内容 Skill。\n*不是中立第三方产业研究，那是 `industry-deep-dive-pipeline` 的职责。*\n\n## 功能\n\n基于产品知识库与品牌规范，产出**品牌营销类长文初稿**（技术博客、客户案例、产品解读）。仅从 content brief 产出 1500–3000 字长文。\n\n不负责社交帖、短内容、渠道适配（见 `tcms-adapter`）。\n\n## 适用场景\n\n- 已有选题 Brief，需要品牌营销长文初稿。\n- 文章属推广 / 产品定位性质。\n\n## 不适用场景\n\n- 中立第三方产业深度研究 → 用 `industry-deep-dive-pipeline`。\n- 单篇发布前合规预审 → 用 `tcms-compliance-reviewer`。\n- 渠道适配 → 用 `tcms-adapter`。\n\n## 触发词\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## 流水线位置\n\n`tcms-planner`（选题）→ **`tcms-writer`**（初稿）→ `tcms-compliance-reviewer`（预审）→ `tcms-adapter`（渠道）→ `tcms-performance-analyst`（月度报告）\n\nFile v1.2.2:skill-card.md\n\n## Description:\n\nFor tech-product marketing teams, tcms-writer turns a product knowledge base, brand rules, and a content brief into brand-side long-form drafts such as technical blogs, customer case studies, and product write-ups.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[haiyangchenbj](https://clawhub.ai/user/haiyangchenbj)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nMarketing and product teams use this skill to create 1500-3000 word brand-side drafts from a content brief, product knowledge base, and brand guidelines. It is intended for promotional or product-positioning long-form content, not neutral industry research, compliance review, social posts, short content, or channel adaptation.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generic writing requests such as draft or writing an article may activate the skill on sensitive product materials.\n\nMitigation: Confirm the intended article type, target product, source files, and confidentiality posture before using it with sensitive knowledge bases.\n\nRisk: Drafts based on internal cases could expose customer names, unreleased product details, internal project names, or unsourced claims.\n\nMitigation: Apply the skill's default redaction rules, cite only sourced data, mark uncertain product capabilities for confirmation, and require human review before publication.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/haiyangchenbj/skills/tcms-writer)\n- [README](artifact/README.md)\n- [Brand and content rules](artifact/references/brand-rules.md)\n- [Sensitive terms and prohibited expressions](artifact/references/sensitive-terms.md)\n- [Case study template](artifact/references/templates/case-study.md)\n- [Product update template](artifact/references/templates/product-update.md)\n- [Tech blog template](artifact/references/templates/tech-blog.md)\n\n## Skill Output:\n\n**Output Type(s):** [markdown, files, guidance]\n\n**Output Format:** [Markdown files: an article first draft plus a citation-traceability table and pre-review checklist]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Drafts target 1500-3000 words and require human review before publication or channel adaptation.]\n\n## Skill Version(s):\n\n1.2.2 (source: SKILL.md frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.2.1: 10 files, 12599 bytes\n\nFiles: _meta.json (130b), README_zh.md (1188b), README.md (1286b), references/brand-rules.md (1807b), references/sensitive-terms.md (939b), references/templates/case-study.md (1124b), references/templates/product-update.md (1066b), references/templates/tech-blog.md (1162b), skill-card.md (3145b), SKILL.md (10366b)\n\nFile v1.2.1:SKILL.md\n\n---\r\nname: tcms-writer\r\nversion: \"1.2.1\"\r\ndescription: |\r\n  For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis.\r\n  Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation.\r\n  Not for neutral industry research — use industry-deep-dive-pipeline for that.\r\nread_when:\r\n  - 写文章\r\n  - 写稿\r\n  - 写初稿\r\n  - 起草\r\n  - 技术博客\r\n  - 品牌技术稿\r\n  - 案例文章\r\n  - 客户案例\r\n  - 产品解读\r\n  - 产品稿\r\n  - 新闻稿\r\n  - content brief\r\n  - draft\r\n  - 按brief写\r\nallowed-tools:\r\n  - read_file\r\n  - write_to_file\r\n  - replace_in_file\r\n  - web_fetch\r\n  - search_content\r\n  - search_file\r\n  - list_dir\r\nmetadata:\r\n  openclaw:\r\n    tags:\r\n      - content-marketing\r\n      - tech-product\r\n      - writing\r\n      - copywriting\r\n      - b2b\r\n      - brand-marketing\r\n      - tech-blog\r\n      - long-form\r\ndisable: false\r\n---\r\n\r\n# Content Writer\r\n\r\nProduces high-quality long-form first drafts from a product knowledge base, brand guidelines, and a content brief.\r\n\r\n## Operating mode: prompt chaining\r\n\r\nExecutes in fixed steps; each step has clear inputs and outputs.\r\n\r\n---\r\n\r\n## Step 1: Confirm the topic [deterministic]\r\n\r\nRead the topic information provided by the user and confirm the following elements:\r\n\r\n| Element | Must be clear | If missing |\r\n|---------|---------------|------------|\r\n| Article type | tech blog / customer case / product update | ask the user |\r\n| Target product | specific product name | ask the user |\r\n| Target reader | architect / CTO / engineer / analyst | default \"technical decision-maker\" |\r\n| Core message | the key value point to convey | extract from knowledge base |\r\n| Source material | knowledge base / internal material / published article | default knowledge base |\r\n| Confidentiality | whether internal cases need redaction | default full redaction |\r\n\r\nIf the user provides a brief file path, read the brief directly.\r\n\r\n---\r\n\r\n## Step 2: Read source material [deterministic]\r\n\r\n**Read only files related to the target product; do not load unrelated product information:**\r\n\r\n1. **Product knowledge base** → search the target product's section (don't read in full; use `search_content` to locate)\r\n2. **Brand guidelines** → `references/brand-rules.md` (read every time)\r\n3. **Article templates** → read the template matching the article type:\r\n   - tech blog: `references/templates/tech-blog.md`\r\n   - customer case: `references/templates/case-study.md`\r\n   - product update: `references/templates/product-update.md`\r\n4. **Supplementary material** (as needed): internal docs or published articles specified in the brief\r\n\r\n> The paths above must be configured per the actual project directory.\r\n\r\n---\r\n\r\n## Step 3: Writing [LLM]\r\n\r\n### Writing rules\r\n\r\n**Product names:**\r\n- First mention uses the official full name (see the product-name mapping table in `brand-rules.md`)\r\n- Subsequent mentions may use the short name\r\n\r\n**Brand presence:**\r\n- Title includes the brand name or the specific product's official name\r\n- Introduce the brand or specific product within the first two paragraphs\r\n- Fixed brand format at the end\r\n\r\n**Data citations:**\r\n- All data must come from the knowledge base or published articles; never fabricate\r\n- Record the source when citing (used to build the citation table in Step 5)\r\n\r\n**Customer information:**\r\n- Customer cases from internal sources are **redacted by default**\r\n- Redaction format: \"a {industry} {company-scale} company\"\r\n- Never show the customer's company name, internal staff names, or project code names\r\n- Use the real customer name only when the user has explicitly confirmed authorization\r\n\r\n**Competitor handling:**\r\n- Never name any competitor directly\r\n- Use substitute phrasing such as \"a peer platform\"\r\n\r\n**Product-capability source verification:**\r\n- Cite only capabilities that exist in the knowledge base\r\n- If unsure whether something is publicly released, mark it \"needs confirmation\" in the pre-review checklist\r\n\r\n### Expression red lines (writing discipline for tech-product marketing copy; converged from multiple revision rounds and the three-piece governance line — must not be violated)\r\n\r\n1. **No meta-language / self-reference.** Delete any sentence that steps outside the article to talk about its own structure — e.g. \"this article…\", \"the press release makes it clear that…\", \"deserves its own section\", \"back to the overall narrative\", \"as mentioned in the published draft\", \"the next section will…\". Transition with the content facts directly.\r\n2. **No business-jargon four-character slogans.** Slogans like \"多、快、好、省\" (many/fast/good/cheap) must be rewritten in engineering dimensions: load coverage / execution efficiency / operations experience / resource efficiency.\r\n3. **No absolutist phrasing.** Words like \"naturally connected\", \"seamless\", \"inevitable\", \"certain\", \"zero\" must be replaced with bounded qualifiers (e.g. \"permissions and lineage inherit uniformly with the table object, reducing cross-engine re-authorization and fragmentation\").\r\n4. **Naming consistency (P0).** A product's external name must match the already-published authoritative materials of the same campaign (press release / official site / official account) verbatim; the tech blog 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\"); naming within the same campaign must be byte-for-byte consistent.\r\n5. **Faithful transcription vs quantified claims.** Infrastructure capabilities (e.g. a specific networking/storage technique) may be stated as-is if backed by an architecture diagram or published material; but quantified speedup multiples (e.g. \"X accelerates N times\") must not be written without an official figure — use qualitative phrasing instead.\r\n\r\n### Article structure\r\n\r\nDo not write: feature 1 → feature 2 → feature 3 (a product spec sheet).\r\n\r\nDo write: **problem → why it's hard → solution (naturally introducing product capability) → effect → applicability judgment**.\r\n\r\nEvery article must leave the reader with a clear takeaway — a judgment they can make, or a method they can learn.\r\n\r\n### Word count\r\n\r\nTarget 1500-3000 words. Compress if over 3500; supplement if under 1200.\r\n\r\n---\r\n\r\n## Step 4: Self-check [LLM]\r\n\r\n| Check | Pass criterion | If fail |\r\n|-------|----------------|---------|\r\n| Customer-name leak | no customer name in internally-sourced cases | immediately replace with redacted version |\r\n| Competitor naming | no competitor company name | replace |\r\n| Product-name规范 | first mention uses official full name | fix |\r\n| Brand presence | present in title / opening / closing | supplement |\r\n| Data has source | every number points to a knowledge-base entry | delete unsourced data |\r\n| Internal code name | no undisclosed product code name / feature name | delete |\r\n| Word-count range | 1500-3000 words | adjust |\r\n\r\n---\r\n\r\n## Step 5: Output [deterministic]\r\n\r\nProduce two files:\r\n\r\n**File 1: article first draft**\r\nPath: `content/drafts/YYYY-MM-{product}-{topic-short}.md`\r\n\r\n**File 2: citation-traceability table + pre-review checklist**\r\nPath: same directory, filename with `-review` suffix\r\n\r\n```markdown\r\n## Execution summary\r\n- Source material read: [list actual files read]\r\n- Template chosen: [article type]\r\n- Article word count: [actual]\r\n- Cited data points: [N] ( [M] public, [K] internal redacted)\r\n- Self-check: 7 checks, [X] passed [Y] fixed\r\n\r\n## Citation traceability\r\n\r\n| Data point in text | Knowledge-base entry / source | Public status |\r\n|--------------------|------------------------------|---------------|\r\n| \"xxx\" | xxx entry / source article | ✅ public / 📋 internal (redacted) |\r\n\r\n## Pre-review checklist\r\n\r\n- [ ] Customer-name redaction check\r\n- [ ] Product-capability public-status check\r\n- [ ] Data points PM needs to confirm\r\n```\r\n\r\n---\r\n\r\n## Hard rules\r\n\r\n1. **Never fabricate data.** Don't write numbers without a source.\r\n2. **Internal cases are redacted by default.** Unless the user has explicitly confirmed authorization.\r\n3. **Never name competitors.**\r\n4. **Product names follow the official site.**\r\n5. **Don't cite product capabilities not in the knowledge base.** Mark uncertain ones \"needs confirmation\".\r\n6. **Every article must attach a citation-traceability table.**\r\n7. **Don't promote products whose external messaging is unconfirmed.**\r\n8. **Expression red lines are non-negotiable** (see the \"Expression red lines\" subsection in Step 3): no meta-language/self-reference, no business-jargon four-character slogans, no absolutist phrasing, naming consistency (P0 — external name follows the same-campaign published materials, no version-number suffix), faithful transcription vs quantified claims. Must be followed while writing; issues of the same kind found in pre-publication audit count as a miss by this Skill.\r\n\r\n---\r\n\r\n## Failure handling\r\n\r\n| Scenario | Handling |\r\n|----------|----------|\r\n| Target product not found in knowledge base | stop generation, report \"no information on {product} in knowledge base\" |\r\n| Brief requests an article type with no template | use tech-blog template as default |\r\n| Cited data marked \"expired\" | don't cite; flag in pre-review checklist |\r\n| Customer authorization status unclear | default redaction |\r\n| Article over 3500 words | give compression suggestions |\r\n\r\n---\r\n\r\n## ⚠️ Human-in-the-loop\r\n\r\nAfter output, the article enters **human review**. This Skill does not auto-publish; every first draft must be confirmed by a human before entering `content-adapter` for channel adaptation.\r\n\r\n---\r\n\r\n## 中文摘要\r\n\r\nContent Writer 是面向品牌营销的长文创作 Agent：基于产品知识库、品牌规范与选题 Brief，产出 1500–3000 字的技术博客、客户案例或产品解读初稿（不含社交帖与渠道适配）。写作严守五条表达红线（禁用元语言/自我指涉、禁用商务腔四字总结、禁止绝对化表述、P0 命名一致性、忠实转录 vs 量化断言）；内部客户案例默认脱敏、不点名竞品、所有数据须有出处并附引用追溯表。初稿完成后进入人工 review，不自动发布。\n\nFile v1.2.1:README.md\n\n# TCMS Writer\n\n**Part of the `tcms-*` family** — brand-side content skills for tech-product marketing teams.\n*Not for neutral third-party industry research — that is `industry-deep-dive-pipeline`'s job.*\n\n## What it does\n\nTurns a product knowledge base and brand rules into **brand-side long-form drafts** (technical blogs, customer case studies, product write-ups). Produces only 1500–3000 word drafts from a content brief.\n\nIt does **not** handle social posts, short content, or channel adaptation (see `tcms-adapter`).\n\n## When to use\n\n- You have a topic brief and need a long-form brand marketing draft.\n- The piece is promotional / product-positioning in nature.\n\n## When NOT to use\n\n- Neutral, third-party industry deep-dives → use `industry-deep-dive-pipeline`.\n- Single-article pre-publish compliance check → use `tcms-compliance-reviewer`.\n- Channel adaptation → use `tcms-adapter`.\n\n## Trigger phrases\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## Pipeline position\n\n`tcms-planner` (brief) → **`tcms-writer`** (draft) → `tcms-compliance-reviewer` (review) → `tcms-adapter` (channels) → `tcms-performance-analyst` (monthly report)\n\nFile v1.2.1:_meta.json\n\n{\n  \"ownerId\": \"kn70yg6zwmkftx4939qrs89awx82rr9a\",\n  \"slug\": \"tcms-writer\",\n  \"version\": \"1.2.1\",\n  \"publishedAt\": 1785686222819\n}\n\nFile v1.2.1:references/brand-rules.md\n\n# 品牌与内容规范\r\n\r\n> 按实际品牌和产品线配置以下内容。\r\n\r\n## 产品正式名称\r\n\r\n首次提及用全称，后续可用简称。\r\n\r\n| 简称 | 官网全称 | 首次引用格式 |\r\n|------|---------|------------|\r\n| 产品A | xxx平台 | XX云xxx平台（产品A） |\r\n| 产品B | xxx服务 | XX云xxx服务（产品B） |\r\n| ... | ... | ... |\r\n\r\n> 从官网产品页获取正式名称，保持一致。\r\n\r\n## 品牌露出规则\r\n\r\n- 标题中包含品牌名或具体产品官方名称\r\n- 开头两段内引入品牌或具体产品\r\n- 结尾固定格式：**{品牌名}，帮助/助力 xxx企业xxx。**\r\n- 正文中产品首次出现用全称，后续用简称\r\n\r\n## 写作调性\r\n\r\n- 专业、克制、有判断。不油腻，不夸张，不AI营销腔\r\n- 允许专业术语，紧跟一句通俗解释\r\n- 给结论和判断，不只堆信息\r\n- 像成熟的技术分析者，不像内容农场\r\n\r\n## 禁用表达\r\n\r\n| 类型 | 禁用 | 替代 |\r\n|------|------|------|\r\n| 竞品点名 | 具体竞品名称 | \"某友商平台\"\"原有闭源平台\" |\r\n| 未确认产品 | 内部规划中未正式发布的产品 | 不提及 |\r\n| 空话 | 赋能/闭环/端到端/强大/显著/大幅/打造 | 用具体数据和场景替代 |\r\n| 内部代号 | 任何未在官网出现的产品代号 | 不使用 |\r\n\r\n## 客户脱敏规则\r\n\r\n内部来源的客户案例默认脱敏：\r\n\r\n| 场景 | 脱敏格式 |\r\n|------|---------|\r\n| 知名企业 | 某+行业+规模，如\"某头部券商\" |\r\n| 一般企业 | 某+行业+企业类型，如\"某SaaS服务商\" |\r\n| 人员信息 | 不出现姓名/工号/企业微信ID |\r\n\r\n> 在此处维护具体客户名→脱敏名的映射表（不随代码同步）。\r\n\r\n## 已授权可公开引用的客户\r\n\r\n> 在此处维护已明确授权的客户名单。\n\nFile v1.2.1:references/sensitive-terms.md\n\n# 敏感词与禁用表达\r\n\r\n## 禁止出现的客户名称（内部来源，未确认授权）\r\n\r\n> 在此处维护具体客户名称列表。内部材料中出现的客户名必须脱敏处理。\r\n\r\n## 禁止出现的竞品名称\r\n\r\n> 在此处维护竞品公司名和产品名列表。\r\n\r\n替代表述：某友商平台 / 原有闭源平台 / 国际主流平台 / 其他同类产品\r\n\r\n## 禁止出现的未确认产品\r\n\r\n> 在此处维护内部规划中、对外口径未确认的产品名。\r\n\r\n## 禁止出现的内部信息\r\n\r\n- 内部项目代号\r\n- 内部人员姓名和通讯ID\r\n- 内部材料中的管理备注（如\"需和XX确认\"）\r\n- 内部材料roadmap中标注但官网未上线的功能（需逐条验证）\r\n\r\n## 慎用表达（非禁止，但尽量避免）\r\n\r\n赋能, 闭环, 端到端, 强大, 显著, 大幅, 打造, 一站式, 全面, 领先, 极致, 颠覆, 革命性\r\n→ 用具体数据和场景描述替代\n\nFile v1.2.1:references/templates/case-study.md\n\n# 客户案例模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题\r\n   格式A（已授权）：{客户名}+{产品}+{核心成果}\r\n   格式B（脱敏）：某{行业}{规模}企业+{场景}+{核心成果}\r\n\r\n2. 客户背景（1段）\r\n   - 企业定位（行业/规模/业务特点）\r\n   - 脱敏案例不写太具体的业务描述，避免被反推\r\n\r\n3. 业务挑战（3-4个痛点）\r\n   - 每个痛点一句话标题+2-3句展开\r\n   - 痛点要具体到技术层面，不是泛泛的\"效率低\"\r\n\r\n4. 方案选型\r\n   - 为什么选这个方案（简要）\r\n   - 使用了哪些产品（用官网全称）\r\n   - 架构概述\r\n\r\n5. 实施效果\r\n   - 硬数据（性能提升x%、成本降低x%等）\r\n   - 来自知识库，标注出处\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2000字\r\n\r\n## 要点\r\n- 月报来源的案例**默认全文脱敏**\r\n- 已在CSDN公开发布的案例可直接引用客户名\r\n- 痛点部分是案例文章最有价值的部分——读者通过痛点判断\"跟我的情况像不像\"\r\n- 方案部分不要写成产品功能清单，重点是\"选型逻辑\"\n\nFile v1.2.1:references/templates/product-update.md\n\n# 产品解读模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含产品名+核心升级/认证/能力）\r\n\r\n2. 开头（1段）\r\n   - 一句话说清\"什么产品出了什么变化\"\r\n   - 立即说明这个变化对用户意味着什么\r\n\r\n3. 背景与趋势（1-2段）\r\n   - 行业背景：为什么需要这个能力/认证\r\n   - 不要写太长的行业铺垫，读者关心的是产品变化\r\n\r\n4. 核心内容（主体）\r\n   - 新能力/新版本：具体是什么、怎么用、有什么数据\r\n   - 认证解读：认证标准考什么、通过意味着什么、对选型的参考价值\r\n   - 不罗列全部功能，选最有差异化的2-3个展开\r\n\r\n5. 对用户的影响\r\n   - 现有用户怎么用（升级路径/兼容性）\r\n   - 潜在用户怎么看（选型参考）\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2200字\r\n\r\n## 要点\r\n- 不写成\"我们发布了好厉害\"的自夸体\r\n- 读者关心的是\"这对我有什么用\"\r\n- 认证类文章重点解读标准本身的价值，而非通过考试的荣耀感\n\nFile v1.2.1:references/templates/tech-blog.md\n\n# 技术博客模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含品牌名或产品名）\r\n\r\n2. 开头（1-2段）\r\n   - 场景引入：什么场景下，企业面临什么问题\r\n   - 自然引出品牌xxx产品（不晚于第二段）\r\n\r\n3. 问题展开（2-4个子问题）\r\n   - 每个问题用一句话标题概括\r\n   - 展开说明为什么这个问题难解决\r\n   - 不要写成产品功能列表\r\n\r\n4. 方案（核心部分）\r\n   - 围绕解决问题展开，自然引入产品能力\r\n   - 每个能力点附具体技术说明或数据\r\n   - 有架构层面的说明（存算分离/组件选型等）\r\n\r\n5. 效果数据\r\n   - 来自知识库的具体数字\r\n   - 如有客户场景，脱敏后引用\r\n\r\n6. 适用判断\r\n   - 适合什么场景/企业\r\n   - 不适合什么场景（体现客观性）\r\n\r\n7. 结尾\r\n   - 一句话总结\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n   - *{品牌名}团队*\r\n```\r\n\r\n## 字数：2000-2500字\r\n\r\n## 要点\r\n- 读者视角是\"我遇到了这个问题，怎么解决\"，不是\"这个产品有什么功能\"\r\n- 技术深度要到架构选择层面，不停在概念层\r\n- 结尾的适用判断体现专业客观性\n\nFile v1.2.1:README_zh.md\n\n# TCMS Writer（中文说明）\n\n**`tcms-*` 系列的一员** —— 面向科技产品营销团队的品牌方内容 Skill。\n*不是中立第三方产业研究，那是 `industry-deep-dive-pipeline` 的职责。*\n\n## 功能\n\n基于产品知识库与品牌规范，产出**品牌营销类长文初稿**（技术博客、客户案例、产品解读）。仅从 content brief 产出 1500–3000 字长文。\n\n不负责社交帖、短内容、渠道适配（见 `tcms-adapter`）。\n\n## 适用场景\n\n- 已有选题 Brief，需要品牌营销长文初稿。\n- 文章属推广 / 产品定位性质。\n\n## 不适用场景\n\n- 中立第三方产业深度研究 → 用 `industry-deep-dive-pipeline`。\n- 单篇发布前合规预审 → 用 `tcms-compliance-reviewer`。\n- 渠道适配 → 用 `tcms-adapter`。\n\n## 触发词\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## 流水线位置\n\n`tcms-planner`（选题）→ **`tcms-writer`**（初稿）→ `tcms-compliance-reviewer`（预审）→ `tcms-adapter`（渠道）→ `tcms-performance-analyst`（月度报告）\n\nFile v1.2.1:skill-card.md\n\n## Description: <br>\nFor tech-product marketing teams, tcms-writer turns product knowledge bases and brand rules into brand-side long-form drafts such as technical blogs, customer case studies, and product write-ups. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[haiyangchenbj](https://clawhub.ai/user/haiyangchenbj) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nMarketing and product-content teams use this skill to draft long-form, brand-side technical marketing content from a topic brief, product knowledge base, brand rules, and the matching article template. It is intended for promotional or product-positioning drafts, not neutral industry research, short social content, channel adaptation, or pre-publication compliance review. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad trigger phrases may activate the skill for general writing requests outside its intended marketing-draft scope. <br>\nMitigation: Confirm the request is for a brand-side long-form marketing draft before reading source material or creating files. <br>\nRisk: Drafts based on internal materials may expose customer names, staff details, project code names, or unconfirmed product messaging. <br>\nMitigation: Apply default customer redaction, remove internal identifiers, verify public product names against authoritative material, and route the draft through human review. <br>\nRisk: Marketing copy may include unsupported quantified claims or fabricated data if source material is incomplete. <br>\nMitigation: Use only data from the product knowledge base or published articles, attach citation traceability, and delete or flag unconfirmed figures in the pre-review checklist. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/haiyangchenbj/skills/tcms-writer) <br>\n- [README](artifact/README.md) <br>\n- [Brand and content rules](artifact/references/brand-rules.md) <br>\n- [Sensitive terms and prohibited expressions](artifact/references/sensitive-terms.md) <br>\n- [Technical blog template](artifact/references/templates/tech-blog.md) <br>\n- [Case study template](artifact/references/templates/case-study.md) <br>\n- [Product update template](artifact/references/templates/product-update.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, files, guidance] <br>\n**Output Format:** [Markdown files: one long-form article draft plus a citation traceability table and pre-review checklist] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Targets 1500-3000 word drafts and requires source-backed data, customer redaction by default, competitor anonymization, and human review before publication.] <br>\n\n## Skill Version(s): <br>\n1.2.1 (source: server release metadata and SKILL.md frontmatter) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.2.0: 10 files, 12247 bytes\n\nFiles: README_zh.md (1188b), README.md (1286b), references/brand-rules.md (1807b), references/sensitive-terms.md (939b), references/templates/case-study.md (1124b), references/templates/product-update.md (1066b), references/templates/tech-blog.md (1162b), skill-card.md (2396b), SKILL.md (10168b), _meta.json (130b)\n\nFile v1.2.0:SKILL.md\n\n---\r\nname: tcms-writer\r\nversion: \"1.2.0\"\r\ndescription: |\r\n  For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis.\r\n  Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation.\r\n  Not for neutral industry research — use industry-deep-dive-pipeline for that.\r\nread_when:\r\n  - 写文章\r\n  - 写稿\r\n  - 写初稿\r\n  - 起草\r\n  - 技术博客\r\n  - 品牌技术稿\r\n  - 案例文章\r\n  - 客户案例\r\n  - 产品解读\r\n  - 产品稿\r\n  - 新闻稿\r\n  - content brief\r\n  - draft\r\n  - 按brief写\r\nallowed-tools:\r\n  - read_file\r\n  - write_to_file\r\n  - replace_in_file\r\n  - web_fetch\r\n  - search_content\r\n  - search_file\r\n  - list_dir\r\ndisable: false\r\n---\r\n\r\n# Content Writer\r\n\r\nProduces high-quality long-form first drafts from a product knowledge base, brand guidelines, and a content brief.\r\n\r\n## Operating mode: prompt chaining\r\n\r\nExecutes in fixed steps; each step has clear inputs and outputs.\r\n\r\n---\r\n\r\n## Step 1: Confirm the topic [deterministic]\r\n\r\nRead the topic information provided by the user and confirm the following elements:\r\n\r\n| Element | Must be clear | If missing |\r\n|---------|---------------|------------|\r\n| Article type | tech blog / customer case / product update | ask the user |\r\n| Target product | specific product name | ask the user |\r\n| Target reader | architect / CTO / engineer / analyst | default \"technical decision-maker\" |\r\n| Core message | the key value point to convey | extract from knowledge base |\r\n| Source material | knowledge base / internal material / published article | default knowledge base |\r\n| Confidentiality | whether internal cases need redaction | default full redaction |\r\n\r\nIf the user provides a brief file path, read the brief directly.\r\n\r\n---\r\n\r\n## Step 2: Read source material [deterministic]\r\n\r\n**Read only files related to the target product; do not load unrelated product information:**\r\n\r\n1. **Product knowledge base** → search the target product's section (don't read in full; use `search_content` to locate)\r\n2. **Brand guidelines** → `references/brand-rules.md` (read every time)\r\n3. **Article templates** → read the template matching the article type:\r\n   - tech blog: `references/templates/tech-blog.md`\r\n   - customer case: `references/templates/case-study.md`\r\n   - product update: `references/templates/product-update.md`\r\n4. **Supplementary material** (as needed): internal docs or published articles specified in the brief\r\n\r\n> The paths above must be configured per the actual project directory.\r\n\r\n---\r\n\r\n## Step 3: Writing [LLM]\r\n\r\n### Writing rules\r\n\r\n**Product names:**\r\n- First mention uses the official full name (see the product-name mapping table in `brand-rules.md`)\r\n- Subsequent mentions may use the short name\r\n\r\n**Brand presence:**\r\n- Title includes the brand name or the specific product's official name\r\n- Introduce the brand or specific product within the first two paragraphs\r\n- Fixed brand format at the end\r\n\r\n**Data citations:**\r\n- All data must come from the knowledge base or published articles; never fabricate\r\n- Record the source when citing (used to build the citation table in Step 5)\r\n\r\n**Customer information:**\r\n- Customer cases from internal sources are **redacted by default**\r\n- Redaction format: \"a {industry} {company-scale} company\"\r\n- Never show the customer's company name, internal staff names, or project code names\r\n- Use the real customer name only when the user has explicitly confirmed authorization\r\n\r\n**Competitor handling:**\r\n- Never name any competitor directly\r\n- Use substitute phrasing such as \"a peer platform\"\r\n\r\n**Product-capability source verification:**\r\n- Cite only capabilities that exist in the knowledge base\r\n- If unsure whether something is publicly released, mark it \"needs confirmation\" in the pre-review checklist\r\n\r\n### Expression red lines (writing discipline for tech-product marketing copy; converged from multiple revision rounds and the three-piece governance line — must not be violated)\r\n\r\n1. **No meta-language / self-reference.** Delete any sentence that steps outside the article to talk about its own structure — e.g. \"this article…\", \"the press release makes it clear that…\", \"deserves its own section\", \"back to the overall narrative\", \"as mentioned in the published draft\", \"the next section will…\". Transition with the content facts directly.\r\n2. **No business-jargon four-character slogans.** Slogans like \"多、快、好、省\" (many/fast/good/cheap) must be rewritten in engineering dimensions: load coverage / execution efficiency / operations experience / resource efficiency.\r\n3. **No absolutist phrasing.** Words like \"naturally connected\", \"seamless\", \"inevitable\", \"certain\", \"zero\" must be replaced with bounded qualifiers (e.g. \"permissions and lineage inherit uniformly with the table object, reducing cross-engine re-authorization and fragmentation\").\r\n4. **Naming consistency (P0).** A product's external name must match the already-published authoritative materials of the same campaign (press release / official site / official account) verbatim; the tech blog 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\"); naming within the same campaign must be byte-for-byte consistent.\r\n5. **Faithful transcription vs quantified claims.** Infrastructure capabilities (e.g. a specific networking/storage technique) may be stated as-is if backed by an architecture diagram or published material; but quantified speedup multiples (e.g. \"X accelerates N times\") must not be written without an official figure — use qualitative phrasing instead.\r\n\r\n### Article structure\r\n\r\nDo not write: feature 1 → feature 2 → feature 3 (a product spec sheet).\r\n\r\nDo write: **problem → why it's hard → solution (naturally introducing product capability) → effect → applicability judgment**.\r\n\r\nEvery article must leave the reader with a clear takeaway — a judgment they can make, or a method they can learn.\r\n\r\n### Word count\r\n\r\nTarget 1500-3000 words. Compress if over 3500; supplement if under 1200.\r\n\r\n---\r\n\r\n## Step 4: Self-check [LLM]\r\n\r\n| Check | Pass criterion | If fail |\r\n|-------|----------------|---------|\r\n| Customer-name leak | no customer name in internally-sourced cases | immediately replace with redacted version |\r\n| Competitor naming | no competitor company name | replace |\r\n| Product-name规范 | first mention uses official full name | fix |\r\n| Brand presence | present in title / opening / closing | supplement |\r\n| Data has source | every number points to a knowledge-base entry | delete unsourced data |\r\n| Internal code name | no undisclosed product code name / feature name | delete |\r\n| Word-count range | 1500-3000 words | adjust |\r\n\r\n---\r\n\r\n## Step 5: Output [deterministic]\r\n\r\nProduce two files:\r\n\r\n**File 1: article first draft**\r\nPath: `content/drafts/YYYY-MM-{product}-{topic-short}.md`\r\n\r\n**File 2: citation-traceability table + pre-review checklist**\r\nPath: same directory, filename with `-review` suffix\r\n\r\n```markdown\r\n## Execution summary\r\n- Source material read: [list actual files read]\r\n- Template chosen: [article type]\r\n- Article word count: [actual]\r\n- Cited data points: [N] ( [M] public, [K] internal redacted)\r\n- Self-check: 7 checks, [X] passed [Y] fixed\r\n\r\n## Citation traceability\r\n\r\n| Data point in text | Knowledge-base entry / source | Public status |\r\n|--------------------|------------------------------|---------------|\r\n| \"xxx\" | xxx entry / source article | ✅ public / 📋 internal (redacted) |\r\n\r\n## Pre-review checklist\r\n\r\n- [ ] Customer-name redaction check\r\n- [ ] Product-capability public-status check\r\n- [ ] Data points PM needs to confirm\r\n```\r\n\r\n---\r\n\r\n## Hard rules\r\n\r\n1. **Never fabricate data.** Don't write numbers without a source.\r\n2. **Internal cases are redacted by default.** Unless the user has explicitly confirmed authorization.\r\n3. **Never name competitors.**\r\n4. **Product names follow the official site.**\r\n5. **Don't cite product capabilities not in the knowledge base.** Mark uncertain ones \"needs confirmation\".\r\n6. **Every article must attach a citation-traceability table.**\r\n7. **Don't promote products whose external messaging is unconfirmed.**\r\n8. **Expression red lines are non-negotiable** (see the \"Expression red lines\" subsection in Step 3): no meta-language/self-reference, no business-jargon four-character slogans, no absolutist phrasing, naming consistency (P0 — external name follows the same-campaign published materials, no version-number suffix), faithful transcription vs quantified claims. Must be followed while writing; issues of the same kind found in pre-publication audit count as a miss by this Skill.\r\n\r\n---\r\n\r\n## Failure handling\r\n\r\n| Scenario | Handling |\r\n|----------|----------|\r\n| Target product not found in knowledge base | stop generation, report \"no information on {product} in knowledge base\" |\r\n| Brief requests an article type with no template | use tech-blog template as default |\r\n| Cited data marked \"expired\" | don't cite; flag in pre-review checklist |\r\n| Customer authorization status unclear | default redaction |\r\n| Article over 3500 words | give compression suggestions |\r\n\r\n---\r\n\r\n## ⚠️ Human-in-the-loop\r\n\r\nAfter output, the article enters **human review**. This Skill does not auto-publish; every first draft must be confirmed by a human before entering `content-adapter` for channel adaptation.\r\n\r\n---\r\n\r\n## 中文摘要\r\n\r\nContent Writer 是面向品牌营销的长文创作 Agent：基于产品知识库、品牌规范与选题 Brief，产出 1500–3000 字的技术博客、客户案例或产品解读初稿（不含社交帖与渠道适配）。写作严守五条表达红线（禁用元语言/自我指涉、禁用商务腔四字总结、禁止绝对化表述、P0 命名一致性、忠实转录 vs 量化断言）；内部客户案例默认脱敏、不点名竞品、所有数据须有出处并附引用追溯表。初稿完成后进入人工 review，不自动发布。\n\nFile v1.2.0:README.md\n\n# TCMS Writer\n\n**Part of the `tcms-*` family** — brand-side content skills for tech-product marketing teams.\n*Not for neutral third-party industry research — that is `industry-deep-dive-pipeline`'s job.*\n\n## What it does\n\nTurns a product knowledge base and brand rules into **brand-side long-form drafts** (technical blogs, customer case studies, product write-ups). Produces only 1500–3000 word drafts from a content brief.\n\nIt does **not** handle social posts, short content, or channel adaptation (see `tcms-adapter`).\n\n## When to use\n\n- You have a topic brief and need a long-form brand marketing draft.\n- The piece is promotional / product-positioning in nature.\n\n## When NOT to use\n\n- Neutral, third-party industry deep-dives → use `industry-deep-dive-pipeline`.\n- Single-article pre-publish compliance check → use `tcms-compliance-reviewer`.\n- Channel adaptation → use `tcms-adapter`.\n\n## Trigger phrases\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## Pipeline position\n\n`tcms-planner` (brief) → **`tcms-writer`** (draft) → `tcms-compliance-reviewer` (review) → `tcms-adapter` (channels) → `tcms-performance-analyst` (monthly report)\n\nFile v1.2.0:_meta.json\n\n{\n  \"ownerId\": \"kn70yg6zwmkftx4939qrs89awx82rr9a\",\n  \"slug\": \"tcms-writer\",\n  \"version\": \"1.2.0\",\n  \"publishedAt\": 1785473440380\n}\n\nFile v1.2.0:references/brand-rules.md\n\n# 品牌与内容规范\r\n\r\n> 按实际品牌和产品线配置以下内容。\r\n\r\n## 产品正式名称\r\n\r\n首次提及用全称，后续可用简称。\r\n\r\n| 简称 | 官网全称 | 首次引用格式 |\r\n|------|---------|------------|\r\n| 产品A | xxx平台 | XX云xxx平台（产品A） |\r\n| 产品B | xxx服务 | XX云xxx服务（产品B） |\r\n| ... | ... | ... |\r\n\r\n> 从官网产品页获取正式名称，保持一致。\r\n\r\n## 品牌露出规则\r\n\r\n- 标题中包含品牌名或具体产品官方名称\r\n- 开头两段内引入品牌或具体产品\r\n- 结尾固定格式：**{品牌名}，帮助/助力 xxx企业xxx。**\r\n- 正文中产品首次出现用全称，后续用简称\r\n\r\n## 写作调性\r\n\r\n- 专业、克制、有判断。不油腻，不夸张，不AI营销腔\r\n- 允许专业术语，紧跟一句通俗解释\r\n- 给结论和判断，不只堆信息\r\n- 像成熟的技术分析者，不像内容农场\r\n\r\n## 禁用表达\r\n\r\n| 类型 | 禁用 | 替代 |\r\n|------|------|------|\r\n| 竞品点名 | 具体竞品名称 | \"某友商平台\"\"原有闭源平台\" |\r\n| 未确认产品 | 内部规划中未正式发布的产品 | 不提及 |\r\n| 空话 | 赋能/闭环/端到端/强大/显著/大幅/打造 | 用具体数据和场景替代 |\r\n| 内部代号 | 任何未在官网出现的产品代号 | 不使用 |\r\n\r\n## 客户脱敏规则\r\n\r\n内部来源的客户案例默认脱敏：\r\n\r\n| 场景 | 脱敏格式 |\r\n|------|---------|\r\n| 知名企业 | 某+行业+规模，如\"某头部券商\" |\r\n| 一般企业 | 某+行业+企业类型，如\"某SaaS服务商\" |\r\n| 人员信息 | 不出现姓名/工号/企业微信ID |\r\n\r\n> 在此处维护具体客户名→脱敏名的映射表（不随代码同步）。\r\n\r\n## 已授权可公开引用的客户\r\n\r\n> 在此处维护已明确授权的客户名单。\n\nFile v1.2.0:references/sensitive-terms.md\n\n# 敏感词与禁用表达\r\n\r\n## 禁止出现的客户名称（内部来源，未确认授权）\r\n\r\n> 在此处维护具体客户名称列表。内部材料中出现的客户名必须脱敏处理。\r\n\r\n## 禁止出现的竞品名称\r\n\r\n> 在此处维护竞品公司名和产品名列表。\r\n\r\n替代表述：某友商平台 / 原有闭源平台 / 国际主流平台 / 其他同类产品\r\n\r\n## 禁止出现的未确认产品\r\n\r\n> 在此处维护内部规划中、对外口径未确认的产品名。\r\n\r\n## 禁止出现的内部信息\r\n\r\n- 内部项目代号\r\n- 内部人员姓名和通讯ID\r\n- 内部材料中的管理备注（如\"需和XX确认\"）\r\n- 内部材料roadmap中标注但官网未上线的功能（需逐条验证）\r\n\r\n## 慎用表达（非禁止，但尽量避免）\r\n\r\n赋能, 闭环, 端到端, 强大, 显著, 大幅, 打造, 一站式, 全面, 领先, 极致, 颠覆, 革命性\r\n→ 用具体数据和场景描述替代\n\nFile v1.2.0:references/templates/case-study.md\n\n# 客户案例模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题\r\n   格式A（已授权）：{客户名}+{产品}+{核心成果}\r\n   格式B（脱敏）：某{行业}{规模}企业+{场景}+{核心成果}\r\n\r\n2. 客户背景（1段）\r\n   - 企业定位（行业/规模/业务特点）\r\n   - 脱敏案例不写太具体的业务描述，避免被反推\r\n\r\n3. 业务挑战（3-4个痛点）\r\n   - 每个痛点一句话标题+2-3句展开\r\n   - 痛点要具体到技术层面，不是泛泛的\"效率低\"\r\n\r\n4. 方案选型\r\n   - 为什么选这个方案（简要）\r\n   - 使用了哪些产品（用官网全称）\r\n   - 架构概述\r\n\r\n5. 实施效果\r\n   - 硬数据（性能提升x%、成本降低x%等）\r\n   - 来自知识库，标注出处\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2000字\r\n\r\n## 要点\r\n- 月报来源的案例**默认全文脱敏**\r\n- 已在CSDN公开发布的案例可直接引用客户名\r\n- 痛点部分是案例文章最有价值的部分——读者通过痛点判断\"跟我的情况像不像\"\r\n- 方案部分不要写成产品功能清单，重点是\"选型逻辑\"\n\nFile v1.2.0:references/templates/product-update.md\n\n# 产品解读模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含产品名+核心升级/认证/能力）\r\n\r\n2. 开头（1段）\r\n   - 一句话说清\"什么产品出了什么变化\"\r\n   - 立即说明这个变化对用户意味着什么\r\n\r\n3. 背景与趋势（1-2段）\r\n   - 行业背景：为什么需要这个能力/认证\r\n   - 不要写太长的行业铺垫，读者关心的是产品变化\r\n\r\n4. 核心内容（主体）\r\n   - 新能力/新版本：具体是什么、怎么用、有什么数据\r\n   - 认证解读：认证标准考什么、通过意味着什么、对选型的参考价值\r\n   - 不罗列全部功能，选最有差异化的2-3个展开\r\n\r\n5. 对用户的影响\r\n   - 现有用户怎么用（升级路径/兼容性）\r\n   - 潜在用户怎么看（选型参考）\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2200字\r\n\r\n## 要点\r\n- 不写成\"我们发布了好厉害\"的自夸体\r\n- 读者关心的是\"这对我有什么用\"\r\n- 认证类文章重点解读标准本身的价值，而非通过考试的荣耀感\n\nFile v1.2.0:references/templates/tech-blog.md\n\n# 技术博客模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含品牌名或产品名）\r\n\r\n2. 开头（1-2段）\r\n   - 场景引入：什么场景下，企业面临什么问题\r\n   - 自然引出品牌xxx产品（不晚于第二段）\r\n\r\n3. 问题展开（2-4个子问题）\r\n   - 每个问题用一句话标题概括\r\n   - 展开说明为什么这个问题难解决\r\n   - 不要写成产品功能列表\r\n\r\n4. 方案（核心部分）\r\n   - 围绕解决问题展开，自然引入产品能力\r\n   - 每个能力点附具体技术说明或数据\r\n   - 有架构层面的说明（存算分离/组件选型等）\r\n\r\n5. 效果数据\r\n   - 来自知识库的具体数字\r\n   - 如有客户场景，脱敏后引用\r\n\r\n6. 适用判断\r\n   - 适合什么场景/企业\r\n   - 不适合什么场景（体现客观性）\r\n\r\n7. 结尾\r\n   - 一句话总结\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n   - *{品牌名}团队*\r\n```\r\n\r\n## 字数：2000-2500字\r\n\r\n## 要点\r\n- 读者视角是\"我遇到了这个问题，怎么解决\"，不是\"这个产品有什么功能\"\r\n- 技术深度要到架构选择层面，不停在概念层\r\n- 结尾的适用判断体现专业客观性\n\nFile v1.2.0:README_zh.md\n\n# TCMS Writer（中文说明）\n\n**`tcms-*` 系列的一员** —— 面向科技产品营销团队的品牌方内容 Skill。\n*不是中立第三方产业研究，那是 `industry-deep-dive-pipeline` 的职责。*\n\n## 功能\n\n基于产品知识库与品牌规范，产出**品牌营销类长文初稿**（技术博客、客户案例、产品解读）。仅从 content brief 产出 1500–3000 字长文。\n\n不负责社交帖、短内容、渠道适配（见 `tcms-adapter`）。\n\n## 适用场景\n\n- 已有选题 Brief，需要品牌营销长文初稿。\n- 文章属推广 / 产品定位性质。\n\n## 不适用场景\n\n- 中立第三方产业深度研究 → 用 `industry-deep-dive-pipeline`。\n- 单篇发布前合规预审 → 用 `tcms-compliance-reviewer`。\n- 渠道适配 → 用 `tcms-adapter`。\n\n## 触发词\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## 流水线位置\n\n`tcms-planner`（选题）→ **`tcms-writer`**（初稿）→ `tcms-compliance-reviewer`（预审）→ `tcms-adapter`（渠道）→ `tcms-performance-analyst`（月度报告）\n\nFile v1.2.0:skill-card.md\n\n## Description: <br>\nFor tech-product marketing teams, TCMS Writer turns a product knowledge base, brand guidelines, and a content brief into brand-side long-form drafts such as technical blogs, customer case studies, and product write-ups. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[haiyangchenbj](https://clawhub.ai/user/haiyangchenbj) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nMarketing and product teams use this skill to draft 1500-3000 word brand-side technical blogs, customer case studies, and product update articles from a content brief and approved source material. It is intended for long-form promotional product writing, not neutral industry research, short social content, or channel adaptation. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may read internal product and case-study material and generate brand-facing drafts that include sensitive customer, product, or capability details. <br>\nMitigation: Use clear briefs and approved product names, keep internal customer cases redacted by default, require source traceability for data points, and send every draft through human review before publication. <br>\n\n\n## Reference(s): <br>\n- [Brand and Content Rules](references/brand-rules.md) <br>\n- [Sensitive Terms and Prohibited Expressions](references/sensitive-terms.md) <br>\n- [Case Study Template](references/templates/case-study.md) <br>\n- [Product Update Template](references/templates/product-update.md) <br>\n- [Technical Blog Template](references/templates/tech-blog.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Markdown, Files, Guidance] <br>\n**Output Format:** [Markdown draft plus a Markdown citation traceability table and pre-review checklist] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Produces a long-form article draft and a paired review file with source material read, cited data points, and human pre-review checks.] <br>\n\n## Skill Version(s): <br>\n1.2.0 (source: frontmatter and release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.1.0: 10 files, 11680 bytes\n\nFiles: README_zh.md (1188b), README.md (1286b), references/brand-rules.md (1807b), references/sensitive-terms.md (939b), references/templates/case-study.md (1124b), references/templates/product-update.md (1066b), references/templates/tech-blog.md (1162b), skill-card.md (2614b), SKILL.md (7879b), _meta.json (130b)\n\nFile v1.1.0:SKILL.md\n\n---\r\nname: tcms-writer\r\nversion: \"1.1.0\"\r\ndescription: |\r\n  For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis.\r\n  Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation.\r\n  Not for neutral industry research — use industry-deep-dive-pipeline for that.\r\nread_when:\r\n  - 写文章\r\n  - 写稿\r\n  - 写初稿\r\n  - 起草\r\n  - 技术博客\r\n  - 品牌技术稿\r\n  - 案例文章\r\n  - 客户案例\r\n  - 产品解读\r\n  - 产品稿\r\n  - 新闻稿\r\n  - content brief\r\n  - draft\r\n  - 按brief写\r\nallowed-tools:\r\n  - read_file\r\n  - write_to_file\r\n  - replace_in_file\r\n  - web_fetch\r\n  - search_content\r\n  - search_file\r\n  - list_dir\r\ndisable: false\r\n---\r\n\r\n# TCMS Writer\r\n\r\n基于产品知识库、品牌规范和选题Brief，产出高质量的长文初稿。\r\n\r\n## 工作模式：提示链（Prompt Chaining）\r\n\r\n按固定步骤执行，每一步输入输出明确。\r\n\r\n---\r\n\r\n## Step 1: 确认选题 [确定性]\r\n\r\n读取用户提供的选题信息，确认以下要素：\r\n\r\n| 要素 | 必须明确 | 缺失时处理 |\r\n|------|---------|-----------|\r\n| 文章类型 | 技术博客 / 客户案例 / 产品解读 | 询问用户 |\r\n| 目标产品 | 具体产品名 | 询问用户 |\r\n| 目标读者 | 架构师/CTO/工程师/分析师 | 默认\"技术决策者\" |\r\n| 核心信息 | 要传达的关键价值点 | 从知识库提取 |\r\n| 素材来源 | 知识库/内部材料/已发文章 | 默认使用知识库 |\r\n| 保密要求 | 是否有内部案例需脱敏 | 默认全部脱敏 |\r\n\r\n如果用户提供了Brief文件路径，直接读取Brief。\r\n\r\n---\r\n\r\n## Step 2: 读取素材 [确定性]\r\n\r\n**只读与目标产品相关的文件，不加载无关产品信息：**\r\n\r\n1. **产品知识库** → 搜索目标产品对应章节（不读全文，用search_content定位）\r\n2. **品牌规范** → `references/brand-rules.md`（每次都读）\r\n3. **文章模板** → 按文章类型读取对应模板：\r\n   - 技术博客：`references/templates/tech-blog.md`\r\n   - 客户案例：`references/templates/case-study.md`\r\n   - 产品解读：`references/templates/product-update.md`\r\n4. **补充素材**（按需）：Brief中指定的内部文档或已发布文章\r\n\r\n> 以上路径需根据实际项目目录配置。\r\n\r\n---\r\n\r\n## Step 3: 写作 [LLM]\r\n\r\n### 写作规则\r\n\r\n**产品名称**：\r\n- 首次提及使用官网全称（参见brand-rules.md产品名称对照表）\r\n- 后续可用简称\r\n\r\n**品牌露出**：\r\n- 标题中包含品牌名或具体产品官方名称\r\n- 开头两段内引入品牌或具体产品\r\n- 结尾有固定品牌格式\r\n\r\n**数据引用**：\r\n- 所有数据必须来自知识库或已发布文章，不可编造\r\n- 引用时记录来源（用于Step 5生成引用表）\r\n\r\n**客户信息**：\r\n- 内部来源的客户案例**默认脱敏**\r\n- 脱敏格式：\"某+行业+企业规模\"\r\n- 不出现客户公司名、内部人员姓名、项目代号\r\n- 用户明确告知已授权的可使用客户名称\r\n\r\n**竞品处理**：\r\n- 不直接点名任何竞品\r\n- 使用\"某友商平台\"等替代表述\r\n\r\n**产品能力来源验证**：\r\n- 只引用知识库中存在的产品能力\r\n- 不确定是否已公开的，在预审清单中标注\"需确认\"\r\n\r\n### 表达红线（技术产品营销文写作纪律，多轮改稿与三件套治理线收敛，不可违反）\r\n\r\n1. **禁用元语言 / 自我指涉**。凡\"本文…\"\"新闻稿把…讲清楚了\"\"值得单独展开\"\"回到…整体叙事\"\"已发布的稿件中提到\"\"下文将…\"等跳出文章谈框架的句式一律删除，用内容事实直接过渡。\r\n2. **禁用商务腔四字总结**。\"多、快、好、省\"等四字口号在技术博客里必须改写为工程维度：负载覆盖 / 执行效率 / 运维体验 / 资源效率。\r\n3. **禁止绝对化表述**。\"天然打通\"\"无缝\"\"必然\"\"一定\"\"零\"等绝对化词，改用带边界的定性（如\"权限与血缘随表对象统一继承，减少跨引擎的二次授权与割裂\"）。\r\n4. **命名一致性（P0）**。产品对外名以同 campaign / 发布项目已发布权威物料（新闻稿/官网/公众号）为准，技术博客不得自行加版本号或后缀（如对外统一叫 X，博客不得写\"X 2.0\"）；同一 campaign 内命名必须逐字一致。\r\n5. **忠实转录 vs 量化断言**。基础设施能力（如特定网络/存储技术）有架构图或已发布物料背书可如实写；但量化加速倍数（如\"X 加速 N 倍\"）无官方口径不得写，改定性表述。\r\n\r\n### 文章结构\r\n\r\n不写成：功能1 → 功能2 → 功能3 的产品说明书\r\n\r\n要写成：**问题 → 为什么难 → 方案（自然引入产品能力）→ 效果 → 适用判断**\r\n\r\n每篇文章要有明确的读者收获——读完能做出一个判断或学到一个方法。\r\n\r\n### 字数\r\n\r\n目标 1500-3000字。超过3500字需压缩，低于1200字需补充。\r\n\r\n---\r\n\r\n## Step 4: 自检 [LLM]\r\n\r\n| 检查项 | 通过标准 | 不通过处理 |\r\n|--------|---------|-----------|\r\n| 客户名称泄露 | 内部来源案例无客户名 | 立即替换为脱敏版 |\r\n| 竞品点名 | 无竞品公司名 | 替换 |\r\n| 产品名规范 | 首次提及用官网全称 | 修正 |\r\n| 品牌露出 | 标题/开头/结尾均有 | 补充 |\r\n| 数据有出处 | 每个数字都能指向知识库条目 | 删除无出处数据 |\r\n| 内部代号 | 无未公开的产品代号/功能名 | 删除 |\r\n| 字数范围 | 1500-3000字 | 调整 |\r\n\r\n---\r\n\r\n## Step 5: 输出 [确定性]\r\n\r\n产出两个文件：\r\n\r\n**文件1：文章初稿**\r\n保存路径：`content/drafts/YYYY-MM-{产品}-{主题简称}.md`\r\n\r\n**文件2：引用追溯表 + 预审清单**\r\n保存路径：同目录，文件名加 `-review` 后缀\r\n\r\n```markdown\r\n## 执行摘要\r\n- 读取素材：[列出实际读取的文件]\r\n- 模板选择：[文章类型]\r\n- 文章字数：[实际字数]\r\n- 引用数据点：[N]个（[M]个公开，[K]个内部脱敏）\r\n- 自检结果：7项检查，[X]通过[Y]修正\r\n\r\n## 引用追溯\r\n\r\n| 文中数据点 | 知识库条目/来源 | 公开状态 |\r\n|-----------|----------------|---------|\r\n| \"xxx\" | xxx条目 / 来源文章 | ✅公开 / 📋内部(已脱敏) |\r\n\r\n## 预审清单\r\n\r\n- [ ] 客户名称脱敏检查\r\n- [ ] 产品能力公开状态\r\n- [ ] PM需确认的数据点\r\n```\r\n\r\n---\r\n\r\n## 硬性规则\r\n\r\n1. **不编造数据。** 没有出处的数字不写。\r\n2. **内部案例默认脱敏。** 除非用户明确告知已授权。\r\n3. **不点名竞品。**\r\n4. **产品名以官网为准。**\r\n5. **不引用知识库中没有的产品能力。** 不确定的标注\"需确认\"。\r\n6. **每篇文章必须附引用追溯表。**\r\n7. **未确认对外口径的产品不推广。**\r\n8. **表达红线不可违反**（详见 Step 3「表达红线」小节）：禁用元语言/自我指涉、禁用商务腔四字总结、禁止绝对化表述、命名一致性（P0，对外名以同 campaign 已发布物料为准不加版本号后缀）、忠实转录 vs 量化断言。写稿即须遵守，发布前审计发现的同类问题即视为本 Skill 漏防。\r\n\r\n---\r\n\r\n## 失败处理\r\n\r\n| 场景 | 处理 |\r\n|------|------|\r\n| 知识库中找不到目标产品信息 | 停止生成，报告\"知识库中无{产品}的信息\" |\r\n| Brief中要求的文章类型没有对应模板 | 使用tech-blog模板作为默认 |\r\n| 引用数据标注为\"已过期\" | 不引用，预审清单中标注 |\r\n| 客户授权状态不明 | 默认脱敏 |\r\n| 文章超过3500字 | 给出压缩建议 |\r\n\r\n---\r\n\r\n## ⚠️ 人工介入\r\n\r\n输出完成后，文章进入**人工review环节**。本Skill不自动发布，所有初稿必须经人工确认后才能进入content-adapter进行渠道适配。\n\nFile v1.1.0:README.md\n\n# TCMS Writer\n\n**Part of the `tcms-*` family** — brand-side content skills for tech-product marketing teams.\n*Not for neutral third-party industry research — that is `industry-deep-dive-pipeline`'s job.*\n\n## What it does\n\nTurns a product knowledge base and brand rules into **brand-side long-form drafts** (technical blogs, customer case studies, product write-ups). Produces only 1500–3000 word drafts from a content brief.\n\nIt does **not** handle social posts, short content, or channel adaptation (see `tcms-adapter`).\n\n## When to use\n\n- You have a topic brief and need a long-form brand marketing draft.\n- The piece is promotional / product-positioning in nature.\n\n## When NOT to use\n\n- Neutral, third-party industry deep-dives → use `industry-deep-dive-pipeline`.\n- Single-article pre-publish compliance check → use `tcms-compliance-reviewer`.\n- Channel adaptation → use `tcms-adapter`.\n\n## Trigger phrases\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## Pipeline position\n\n`tcms-planner` (brief) → **`tcms-writer`** (draft) → `tcms-compliance-reviewer` (review) → `tcms-adapter` (channels) → `tcms-performance-analyst` (monthly report)\n\nFile v1.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn70yg6zwmkftx4939qrs89awx82rr9a\",\n  \"slug\": \"tcms-writer\",\n  \"version\": \"1.1.0\",\n  \"publishedAt\": 1785467465333\n}\n\nFile v1.1.0:references/brand-rules.md\n\n# 品牌与内容规范\r\n\r\n> 按实际品牌和产品线配置以下内容。\r\n\r\n## 产品正式名称\r\n\r\n首次提及用全称，后续可用简称。\r\n\r\n| 简称 | 官网全称 | 首次引用格式 |\r\n|------|---------|------------|\r\n| 产品A | xxx平台 | XX云xxx平台（产品A） |\r\n| 产品B | xxx服务 | XX云xxx服务（产品B） |\r\n| ... | ... | ... |\r\n\r\n> 从官网产品页获取正式名称，保持一致。\r\n\r\n## 品牌露出规则\r\n\r\n- 标题中包含品牌名或具体产品官方名称\r\n- 开头两段内引入品牌或具体产品\r\n- 结尾固定格式：**{品牌名}，帮助/助力 xxx企业xxx。**\r\n- 正文中产品首次出现用全称，后续用简称\r\n\r\n## 写作调性\r\n\r\n- 专业、克制、有判断。不油腻，不夸张，不AI营销腔\r\n- 允许专业术语，紧跟一句通俗解释\r\n- 给结论和判断，不只堆信息\r\n- 像成熟的技术分析者，不像内容农场\r\n\r\n## 禁用表达\r\n\r\n| 类型 | 禁用 | 替代 |\r\n|------|------|------|\r\n| 竞品点名 | 具体竞品名称 | \"某友商平台\"\"原有闭源平台\" |\r\n| 未确认产品 | 内部规划中未正式发布的产品 | 不提及 |\r\n| 空话 | 赋能/闭环/端到端/强大/显著/大幅/打造 | 用具体数据和场景替代 |\r\n| 内部代号 | 任何未在官网出现的产品代号 | 不使用 |\r\n\r\n## 客户脱敏规则\r\n\r\n内部来源的客户案例默认脱敏：\r\n\r\n| 场景 | 脱敏格式 |\r\n|------|---------|\r\n| 知名企业 | 某+行业+规模，如\"某头部券商\" |\r\n| 一般企业 | 某+行业+企业类型，如\"某SaaS服务商\" |\r\n| 人员信息 | 不出现姓名/工号/企业微信ID |\r\n\r\n> 在此处维护具体客户名→脱敏名的映射表（不随代码同步）。\r\n\r\n## 已授权可公开引用的客户\r\n\r\n> 在此处维护已明确授权的客户名单。\n\nFile v1.1.0:references/sensitive-terms.md\n\n# 敏感词与禁用表达\r\n\r\n## 禁止出现的客户名称（内部来源，未确认授权）\r\n\r\n> 在此处维护具体客户名称列表。内部材料中出现的客户名必须脱敏处理。\r\n\r\n## 禁止出现的竞品名称\r\n\r\n> 在此处维护竞品公司名和产品名列表。\r\n\r\n替代表述：某友商平台 / 原有闭源平台 / 国际主流平台 / 其他同类产品\r\n\r\n## 禁止出现的未确认产品\r\n\r\n> 在此处维护内部规划中、对外口径未确认的产品名。\r\n\r\n## 禁止出现的内部信息\r\n\r\n- 内部项目代号\r\n- 内部人员姓名和通讯ID\r\n- 内部材料中的管理备注（如\"需和XX确认\"）\r\n- 内部材料roadmap中标注但官网未上线的功能（需逐条验证）\r\n\r\n## 慎用表达（非禁止，但尽量避免）\r\n\r\n赋能, 闭环, 端到端, 强大, 显著, 大幅, 打造, 一站式, 全面, 领先, 极致, 颠覆, 革命性\r\n→ 用具体数据和场景描述替代\n\nFile v1.1.0:references/templates/case-study.md\n\n# 客户案例模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题\r\n   格式A（已授权）：{客户名}+{产品}+{核心成果}\r\n   格式B（脱敏）：某{行业}{规模}企业+{场景}+{核心成果}\r\n\r\n2. 客户背景（1段）\r\n   - 企业定位（行业/规模/业务特点）\r\n   - 脱敏案例不写太具体的业务描述，避免被反推\r\n\r\n3. 业务挑战（3-4个痛点）\r\n   - 每个痛点一句话标题+2-3句展开\r\n   - 痛点要具体到技术层面，不是泛泛的\"效率低\"\r\n\r\n4. 方案选型\r\n   - 为什么选这个方案（简要）\r\n   - 使用了哪些产品（用官网全称）\r\n   - 架构概述\r\n\r\n5. 实施效果\r\n   - 硬数据（性能提升x%、成本降低x%等）\r\n   - 来自知识库，标注出处\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2000字\r\n\r\n## 要点\r\n- 月报来源的案例**默认全文脱敏**\r\n- 已在CSDN公开发布的案例可直接引用客户名\r\n- 痛点部分是案例文章最有价值的部分——读者通过痛点判断\"跟我的情况像不像\"\r\n- 方案部分不要写成产品功能清单，重点是\"选型逻辑\"\n\nFile v1.1.0:references/templates/product-update.md\n\n# 产品解读模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含产品名+核心升级/认证/能力）\r\n\r\n2. 开头（1段）\r\n   - 一句话说清\"什么产品出了什么变化\"\r\n   - 立即说明这个变化对用户意味着什么\r\n\r\n3. 背景与趋势（1-2段）\r\n   - 行业背景：为什么需要这个能力/认证\r\n   - 不要写太长的行业铺垫，读者关心的是产品变化\r\n\r\n4. 核心内容（主体）\r\n   - 新能力/新版本：具体是什么、怎么用、有什么数据\r\n   - 认证解读：认证标准考什么、通过意味着什么、对选型的参考价值\r\n   - 不罗列全部功能，选最有差异化的2-3个展开\r\n\r\n5. 对用户的影响\r\n   - 现有用户怎么用（升级路径/兼容性）\r\n   - 潜在用户怎么看（选型参考）\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2200字\r\n\r\n## 要点\r\n- 不写成\"我们发布了好厉害\"的自夸体\r\n- 读者关心的是\"这对我有什么用\"\r\n- 认证类文章重点解读标准本身的价值，而非通过考试的荣耀感\n\nFile v1.1.0:references/templates/tech-blog.md\n\n# 技术博客模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含品牌名或产品名）\r\n\r\n2. 开头（1-2段）\r\n   - 场景引入：什么场景下，企业面临什么问题\r\n   - 自然引出品牌xxx产品（不晚于第二段）\r\n\r\n3. 问题展开（2-4个子问题）\r\n   - 每个问题用一句话标题概括\r\n   - 展开说明为什么这个问题难解决\r\n   - 不要写成产品功能列表\r\n\r\n4. 方案（核心部分）\r\n   - 围绕解决问题展开，自然引入产品能力\r\n   - 每个能力点附具体技术说明或数据\r\n   - 有架构层面的说明（存算分离/组件选型等）\r\n\r\n5. 效果数据\r\n   - 来自知识库的具体数字\r\n   - 如有客户场景，脱敏后引用\r\n\r\n6. 适用判断\r\n   - 适合什么场景/企业\r\n   - 不适合什么场景（体现客观性）\r\n\r\n7. 结尾\r\n   - 一句话总结\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n   - *{品牌名}团队*\r\n```\r\n\r\n## 字数：2000-2500字\r\n\r\n## 要点\r\n- 读者视角是\"我遇到了这个问题，怎么解决\"，不是\"这个产品有什么功能\"\r\n- 技术深度要到架构选择层面，不停在概念层\r\n- 结尾的适用判断体现专业客观性\n\nFile v1.1.0:README_zh.md\n\n# TCMS Writer（中文说明）\n\n**`tcms-*` 系列的一员** —— 面向科技产品营销团队的品牌方内容 Skill。\n*不是中立第三方产业研究，那是 `industry-deep-dive-pipeline` 的职责。*\n\n## 功能\n\n基于产品知识库与品牌规范，产出**品牌营销类长文初稿**（技术博客、客户案例、产品解读）。仅从 content brief 产出 1500–3000 字长文。\n\n不负责社交帖、短内容、渠道适配（见 `tcms-adapter`）。\n\n## 适用场景\n\n- 已有选题 Brief，需要品牌营销长文初稿。\n- 文章属推广 / 产品定位性质。\n\n## 不适用场景\n\n- 中立第三方产业深度研究 → 用 `industry-deep-dive-pipeline`。\n- 单篇发布前合规预审 → 用 `tcms-compliance-reviewer`。\n- 渠道适配 → 用 `tcms-adapter`。\n\n## 触发词\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## 流水线位置\n\n`tcms-planner`（选题）→ **`tcms-writer`**（初稿）→ `tcms-compliance-reviewer`（预审）→ `tcms-adapter`（渠道）→ `tcms-performance-analyst`（月度报告）\n\nFile v1.1.0:skill-card.md\n\n## Description: <br>\nFor tech-product marketing teams, this skill turns a product knowledge base, brand rules, and a content brief into brand-side long-form drafts such as technical blogs, customer case studies, and product write-ups. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[haiyangchenbj](https://clawhub.ai/user/haiyangchenbj) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nMarketing and product-content teams use this skill to draft 1500-3000 word brand-side technical blogs, customer case studies, and product update articles from a brief and source materials. It is scoped to long-form promotional or product-positioning drafts and excludes neutral industry research, short-form content, social posts, and channel adaptation. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Generic writing requests could be routed to this specialized marketing-draft skill when another writing or research skill would be more appropriate. <br>\nMitigation: Confirm routing rules before installation and reserve this skill for brand-side product marketing drafts with a brief and source materials. <br>\nRisk: Drafts may contain customer-identifying details, inconsistent product names, or source claims that are not ready for external publication. <br>\nMitigation: Review generated drafts for customer anonymization, product naming, and source citations before any external use. <br>\n\n\n## Reference(s): <br>\n- [Brand and Content Rules](references/brand-rules.md) <br>\n- [Sensitive Terms and Prohibited Expressions](references/sensitive-terms.md) <br>\n- [Technical Blog Template](references/templates/tech-blog.md) <br>\n- [Case Study Template](references/templates/case-study.md) <br>\n- [Product Update Template](references/templates/product-update.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Markdown, Files, Analysis, Guidance] <br>\n**Output Format:** [Markdown draft files with a Markdown citation-trace and pre-review checklist] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Produces a long-form article draft and a companion review file; expected draft length is 1500-3000 words.] <br>\n\n## Skill Version(s): <br>\n1.1.0 (source: SKILL.md frontmatter and server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.2: 10 files, 10843 bytes\n\nFiles: README_zh.md (1188b), README.md (1286b), references/brand-rules.md (1807b), references/sensitive-terms.md (939b), references/templates/case-study.md (1124b), references/templates/product-update.md (1066b), references/templates/tech-blog.md (1162b), skill-card.md (2695b), SKILL.md (6217b), _meta.json (130b)\n\nFile v1.0.2:SKILL.md\n\n---\r\nname: tcms-writer\r\nversion: \"1.0.2\"\r\ndescription: |\r\n  For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis.\r\n  Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation.\r\n  Not for neutral industry research — use industry-deep-dive-pipeline for that.\r\nread_when:\r\n  - 写文章\r\n  - 写稿\r\n  - 写初稿\r\n  - 起草\r\n  - 技术博客\r\n  - 品牌技术稿\r\n  - 案例文章\r\n  - 客户案例\r\n  - 产品解读\r\n  - 产品稿\r\n  - 新闻稿\r\n  - content brief\r\n  - draft\r\n  - 按brief写\r\nallowed-tools:\r\n  - read_file\r\n  - write_to_file\r\n  - replace_in_file\r\n  - web_fetch\r\n  - search_content\r\n  - search_file\r\n  - list_dir\r\ndisable: false\r\n---\r\n\r\n# TCMS Writer\r\n\r\n基于产品知识库、品牌规范和选题Brief，产出高质量的长文初稿。\r\n\r\n## 工作模式：提示链（Prompt Chaining）\r\n\r\n按固定步骤执行，每一步输入输出明确。\r\n\r\n---\r\n\r\n## Step 1: 确认选题 [确定性]\r\n\r\n读取用户提供的选题信息，确认以下要素：\r\n\r\n| 要素 | 必须明确 | 缺失时处理 |\r\n|------|---------|-----------|\r\n| 文章类型 | 技术博客 / 客户案例 / 产品解读 | 询问用户 |\r\n| 目标产品 | 具体产品名 | 询问用户 |\r\n| 目标读者 | 架构师/CTO/工程师/分析师 | 默认\"技术决策者\" |\r\n| 核心信息 | 要传达的关键价值点 | 从知识库提取 |\r\n| 素材来源 | 知识库/内部材料/已发文章 | 默认使用知识库 |\r\n| 保密要求 | 是否有内部案例需脱敏 | 默认全部脱敏 |\r\n\r\n如果用户提供了Brief文件路径，直接读取Brief。\r\n\r\n---\r\n\r\n## Step 2: 读取素材 [确定性]\r\n\r\n**只读与目标产品相关的文件，不加载无关产品信息：**\r\n\r\n1. **产品知识库** → 搜索目标产品对应章节（不读全文，用search_content定位）\r\n2. **品牌规范** → `references/brand-rules.md`（每次都读）\r\n3. **文章模板** → 按文章类型读取对应模板：\r\n   - 技术博客：`references/templates/tech-blog.md`\r\n   - 客户案例：`references/templates/case-study.md`\r\n   - 产品解读：`references/templates/product-update.md`\r\n4. **补充素材**（按需）：Brief中指定的内部文档或已发布文章\r\n\r\n> 以上路径需根据实际项目目录配置。\r\n\r\n---\r\n\r\n## Step 3: 写作 [LLM]\r\n\r\n### 写作规则\r\n\r\n**产品名称**：\r\n- 首次提及使用官网全称（参见brand-rules.md产品名称对照表）\r\n- 后续可用简称\r\n\r\n**品牌露出**：\r\n- 标题中包含品牌名或具体产品官方名称\r\n- 开头两段内引入品牌或具体产品\r\n- 结尾有固定品牌格式\r\n\r\n**数据引用**：\r\n- 所有数据必须来自知识库或已发布文章，不可编造\r\n- 引用时记录来源（用于Step 5生成引用表）\r\n\r\n**客户信息**：\r\n- 内部来源的客户案例**默认脱敏**\r\n- 脱敏格式：\"某+行业+企业规模\"\r\n- 不出现客户公司名、内部人员姓名、项目代号\r\n- 用户明确告知已授权的可使用客户名称\r\n\r\n**竞品处理**：\r\n- 不直接点名任何竞品\r\n- 使用\"某友商平台\"等替代表述\r\n\r\n**产品能力来源验证**：\r\n- 只引用知识库中存在的产品能力\r\n- 不确定是否已公开的，在预审清单中标注\"需确认\"\r\n\r\n### 文章结构\r\n\r\n不写成：功能1 → 功能2 → 功能3 的产品说明书\r\n\r\n要写成：**问题 → 为什么难 → 方案（自然引入产品能力）→ 效果 → 适用判断**\r\n\r\n每篇文章要有明确的读者收获——读完能做出一个判断或学到一个方法。\r\n\r\n### 字数\r\n\r\n目标 1500-3000字。超过3500字需压缩，低于1200字需补充。\r\n\r\n---\r\n\r\n## Step 4: 自检 [LLM]\r\n\r\n| 检查项 | 通过标准 | 不通过处理 |\r\n|--------|---------|-----------|\r\n| 客户名称泄露 | 内部来源案例无客户名 | 立即替换为脱敏版 |\r\n| 竞品点名 | 无竞品公司名 | 替换 |\r\n| 产品名规范 | 首次提及用官网全称 | 修正 |\r\n| 品牌露出 | 标题/开头/结尾均有 | 补充 |\r\n| 数据有出处 | 每个数字都能指向知识库条目 | 删除无出处数据 |\r\n| 内部代号 | 无未公开的产品代号/功能名 | 删除 |\r\n| 字数范围 | 1500-3000字 | 调整 |\r\n\r\n---\r\n\r\n## Step 5: 输出 [确定性]\r\n\r\n产出两个文件：\r\n\r\n**文件1：文章初稿**\r\n保存路径：`content/drafts/YYYY-MM-{产品}-{主题简称}.md`\r\n\r\n**文件2：引用追溯表 + 预审清单**\r\n保存路径：同目录，文件名加 `-review` 后缀\r\n\r\n```markdown\r\n## 执行摘要\r\n- 读取素材：[列出实际读取的文件]\r\n- 模板选择：[文章类型]\r\n- 文章字数：[实际字数]\r\n- 引用数据点：[N]个（[M]个公开，[K]个内部脱敏）\r\n- 自检结果：7项检查，[X]通过[Y]修正\r\n\r\n## 引用追溯\r\n\r\n| 文中数据点 | 知识库条目/来源 | 公开状态 |\r\n|-----------|----------------|---------|\r\n| \"xxx\" | xxx条目 / 来源文章 | ✅公开 / 📋内部(已脱敏) |\r\n\r\n## 预审清单\r\n\r\n- [ ] 客户名称脱敏检查\r\n- [ ] 产品能力公开状态\r\n- [ ] PM需确认的数据点\r\n```\r\n\r\n---\r\n\r\n## 硬性规则\r\n\r\n1. **不编造数据。** 没有出处的数字不写。\r\n2. **内部案例默认脱敏。** 除非用户明确告知已授权。\r\n3. **不点名竞品。**\r\n4. **产品名以官网为准。**\r\n5. **不引用知识库中没有的产品能力。** 不确定的标注\"需确认\"。\r\n6. **每篇文章必须附引用追溯表。**\r\n7. **未确认对外口径的产品不推广。**\r\n\r\n---\r\n\r\n## 失败处理\r\n\r\n| 场景 | 处理 |\r\n|------|------|\r\n| 知识库中找不到目标产品信息 | 停止生成，报告\"知识库中无{产品}的信息\" |\r\n| Brief中要求的文章类型没有对应模板 | 使用tech-blog模板作为默认 |\r\n| 引用数据标注为\"已过期\" | 不引用，预审清单中标注 |\r\n| 客户授权状态不明 | 默认脱敏 |\r\n| 文章超过3500字 | 给出压缩建议 |\r\n\r\n---\r\n\r\n## ⚠️ 人工介入\r\n\r\n输出完成后，文章进入**人工review环节**。本Skill不自动发布，所有初稿必须经人工确认后才能进入content-adapter进行渠道适配。\n\nFile v1.0.2:README.md\n\n# TCMS Writer\n\n**Part of the `tcms-*` family** — brand-side content skills for tech-product marketing teams.\n*Not for neutral third-party industry research — that is `industry-deep-dive-pipeline`'s job.*\n\n## What it does\n\nTurns a product knowledge base and brand rules into **brand-side long-form drafts** (technical blogs, customer case studies, product write-ups). Produces only 1500–3000 word drafts from a content brief.\n\nIt does **not** handle social posts, short content, or channel adaptation (see `tcms-adapter`).\n\n## When to use\n\n- You have a topic brief and need a long-form brand marketing draft.\n- The piece is promotional / product-positioning in nature.\n\n## When NOT to use\n\n- Neutral, third-party industry deep-dives → use `industry-deep-dive-pipeline`.\n- Single-article pre-publish compliance check → use `tcms-compliance-reviewer`.\n- Channel adaptation → use `tcms-adapter`.\n\n## Trigger phrases\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## Pipeline position\n\n`tcms-planner` (brief) → **`tcms-writer`** (draft) → `tcms-compliance-reviewer` (review) → `tcms-adapter` (channels) → `tcms-performance-analyst` (monthly report)\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn70yg6zwmkftx4939qrs89awx82rr9a\",\n  \"slug\": \"tcms-writer\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1785410497713\n}\n\nFile v1.0.2:references/brand-rules.md\n\n# 品牌与内容规范\r\n\r\n> 按实际品牌和产品线配置以下内容。\r\n\r\n## 产品正式名称\r\n\r\n首次提及用全称，后续可用简称。\r\n\r\n| 简称 | 官网全称 | 首次引用格式 |\r\n|------|---------|------------|\r\n| 产品A | xxx平台 | XX云xxx平台（产品A） |\r\n| 产品B | xxx服务 | XX云xxx服务（产品B） |\r\n| ... | ... | ... |\r\n\r\n> 从官网产品页获取正式名称，保持一致。\r\n\r\n## 品牌露出规则\r\n\r\n- 标题中包含品牌名或具体产品官方名称\r\n- 开头两段内引入品牌或具体产品\r\n- 结尾固定格式：**{品牌名}，帮助/助力 xxx企业xxx。**\r\n- 正文中产品首次出现用全称，后续用简称\r\n\r\n## 写作调性\r\n\r\n- 专业、克制、有判断。不油腻，不夸张，不AI营销腔\r\n- 允许专业术语，紧跟一句通俗解释\r\n- 给结论和判断，不只堆信息\r\n- 像成熟的技术分析者，不像内容农场\r\n\r\n## 禁用表达\r\n\r\n| 类型 | 禁用 | 替代 |\r\n|------|------|------|\r\n| 竞品点名 | 具体竞品名称 | \"某友商平台\"\"原有闭源平台\" |\r\n| 未确认产品 | 内部规划中未正式发布的产品 | 不提及 |\r\n| 空话 | 赋能/闭环/端到端/强大/显著/大幅/打造 | 用具体数据和场景替代 |\r\n| 内部代号 | 任何未在官网出现的产品代号 | 不使用 |\r\n\r\n## 客户脱敏规则\r\n\r\n内部来源的客户案例默认脱敏：\r\n\r\n| 场景 | 脱敏格式 |\r\n|------|---------|\r\n| 知名企业 | 某+行业+规模，如\"某头部券商\" |\r\n| 一般企业 | 某+行业+企业类型，如\"某SaaS服务商\" |\r\n| 人员信息 | 不出现姓名/工号/企业微信ID |\r\n\r\n> 在此处维护具体客户名→脱敏名的映射表（不随代码同步）。\r\n\r\n## 已授权可公开引用的客户\r\n\r\n> 在此处维护已明确授权的客户名单。\n\nFile v1.0.2:references/sensitive-terms.md\n\n# 敏感词与禁用表达\r\n\r\n## 禁止出现的客户名称（内部来源，未确认授权）\r\n\r\n> 在此处维护具体客户名称列表。内部材料中出现的客户名必须脱敏处理。\r\n\r\n## 禁止出现的竞品名称\r\n\r\n> 在此处维护竞品公司名和产品名列表。\r\n\r\n替代表述：某友商平台 / 原有闭源平台 / 国际主流平台 / 其他同类产品\r\n\r\n## 禁止出现的未确认产品\r\n\r\n> 在此处维护内部规划中、对外口径未确认的产品名。\r\n\r\n## 禁止出现的内部信息\r\n\r\n- 内部项目代号\r\n- 内部人员姓名和通讯ID\r\n- 内部材料中的管理备注（如\"需和XX确认\"）\r\n- 内部材料roadmap中标注但官网未上线的功能（需逐条验证）\r\n\r\n## 慎用表达（非禁止，但尽量避免）\r\n\r\n赋能, 闭环, 端到端, 强大, 显著, 大幅, 打造, 一站式, 全面, 领先, 极致, 颠覆, 革命性\r\n→ 用具体数据和场景描述替代\n\nFile v1.0.2:references/templates/case-study.md\n\n# 客户案例模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题\r\n   格式A（已授权）：{客户名}+{产品}+{核心成果}\r\n   格式B（脱敏）：某{行业}{规模}企业+{场景}+{核心成果}\r\n\r\n2. 客户背景（1段）\r\n   - 企业定位（行业/规模/业务特点）\r\n   - 脱敏案例不写太具体的业务描述，避免被反推\r\n\r\n3. 业务挑战（3-4个痛点）\r\n   - 每个痛点一句话标题+2-3句展开\r\n   - 痛点要具体到技术层面，不是泛泛的\"效率低\"\r\n\r\n4. 方案选型\r\n   - 为什么选这个方案（简要）\r\n   - 使用了哪些产品（用官网全称）\r\n   - 架构概述\r\n\r\n5. 实施效果\r\n   - 硬数据（性能提升x%、成本降低x%等）\r\n   - 来自知识库，标注出处\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2000字\r\n\r\n## 要点\r\n- 月报来源的案例**默认全文脱敏**\r\n- 已在CSDN公开发布的案例可直接引用客户名\r\n- 痛点部分是案例文章最有价值的部分——读者通过痛点判断\"跟我的情况像不像\"\r\n- 方案部分不要写成产品功能清单，重点是\"选型逻辑\"\n\nFile v1.0.2:references/templates/product-update.md\n\n# 产品解读模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含产品名+核心升级/认证/能力）\r\n\r\n2. 开头（1段）\r\n   - 一句话说清\"什么产品出了什么变化\"\r\n   - 立即说明这个变化对用户意味着什么\r\n\r\n3. 背景与趋势（1-2段）\r\n   - 行业背景：为什么需要这个能力/认证\r\n   - 不要写太长的行业铺垫，读者关心的是产品变化\r\n\r\n4. 核心内容（主体）\r\n   - 新能力/新版本：具体是什么、怎么用、有什么数据\r\n   - 认证解读：认证标准考什么、通过意味着什么、对选型的参考价值\r\n   - 不罗列全部功能，选最有差异化的2-3个展开\r\n\r\n5. 对用户的影响\r\n   - 现有用户怎么用（升级路径/兼容性）\r\n   - 潜在用户怎么看（选型参考）\r\n\r\n6. 结尾\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n```\r\n\r\n## 字数：1500-2200字\r\n\r\n## 要点\r\n- 不写成\"我们发布了好厉害\"的自夸体\r\n- 读者关心的是\"这对我有什么用\"\r\n- 认证类文章重点解读标准本身的价值，而非通过考试的荣耀感\n\nFile v1.0.2:references/templates/tech-blog.md\n\n# 技术博客模板\r\n\r\n## 结构\r\n\r\n```\r\n1. 标题（含品牌名或产品名）\r\n\r\n2. 开头（1-2段）\r\n   - 场景引入：什么场景下，企业面临什么问题\r\n   - 自然引出品牌xxx产品（不晚于第二段）\r\n\r\n3. 问题展开（2-4个子问题）\r\n   - 每个问题用一句话标题概括\r\n   - 展开说明为什么这个问题难解决\r\n   - 不要写成产品功能列表\r\n\r\n4. 方案（核心部分）\r\n   - 围绕解决问题展开，自然引入产品能力\r\n   - 每个能力点附具体技术说明或数据\r\n   - 有架构层面的说明（存算分离/组件选型等）\r\n\r\n5. 效果数据\r\n   - 来自知识库的具体数字\r\n   - 如有客户场景，脱敏后引用\r\n\r\n6. 适用判断\r\n   - 适合什么场景/企业\r\n   - 不适合什么场景（体现客观性）\r\n\r\n7. 结尾\r\n   - 一句话总结\r\n   - **{品牌名}，帮助xxx企业xxx。**\r\n   - *{品牌名}团队*\r\n```\r\n\r\n## 字数：2000-2500字\r\n\r\n## 要点\r\n- 读者视角是\"我遇到了这个问题，怎么解决\"，不是\"这个产品有什么功能\"\r\n- 技术深度要到架构选择层面，不停在概念层\r\n- 结尾的适用判断体现专业客观性\n\nFile v1.0.2:README_zh.md\n\n# TCMS Writer（中文说明）\n\n**`tcms-*` 系列的一员** —— 面向科技产品营销团队的品牌方内容 Skill。\n*不是中立第三方产业研究，那是 `industry-deep-dive-pipeline` 的职责。*\n\n## 功能\n\n基于产品知识库与品牌规范，产出**品牌营销类长文初稿**（技术博客、客户案例、产品解读）。仅从 content brief 产出 1500–3000 字长文。\n\n不负责社交帖、短内容、渠道适配（见 `tcms-adapter`）。\n\n## 适用场景\n\n- 已有选题 Brief，需要品牌营销长文初稿。\n- 文章属推广 / 产品定位性质。\n\n## 不适用场景\n\n- 中立第三方产业深度研究 → 用 `industry-deep-dive-pipeline`。\n- 单篇发布前合规预审 → 用 `tcms-compliance-reviewer`。\n- 渠道适配 → 用 `tcms-adapter`。\n\n## 触发词\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## 流水线位置\n\n`tcms-planner`（选题）→ **`tcms-writer`**（初稿）→ `tcms-compliance-reviewer`（预审）→ `tcms-adapter`（渠道）→ `tcms-performance-analyst`（月度报告）\n\nFile v1.0.2:skill-card.md\n\n## Description: <br>\nFor tech-product marketing teams, this skill turns a product knowledge base, brand rules, and a content brief into brand-side long-form drafts such as technical blogs, customer case studies, and product write-ups. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[haiyangchenbj](https://clawhub.ai/user/haiyangchenbj) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nMarketing teams and content operators use this skill to draft 1500-3000 word brand-side articles from approved product knowledge, brand rules, and a content brief. It is intended for promotional product-positioning drafts, not neutral industry research, short-form social content, or channel adaptation. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill reads product knowledge-base files and may process customer names, internal data, or unpublished product details while preparing drafts. <br>\nMitigation: Use only approved source materials, keep internal customer cases de-identified by default, and review the companion pre-review checklist before external publication. <br>\nRisk: Generated marketing drafts may include unsupported data points or product claims if the input knowledge base is incomplete or outdated. <br>\nMitigation: Require every numeric claim and product capability to appear in the citation traceability table, and remove or mark uncertain claims for product or legal review. <br>\n\n\n## Reference(s): <br>\n- [TCMS Writer ClawHub page](https://clawhub.ai/haiyangchenbj/skills/tcms-writer) <br>\n- [Brand and content rules](references/brand-rules.md) <br>\n- [Sensitive terms and banned expressions](references/sensitive-terms.md) <br>\n- [Technical blog template](references/templates/tech-blog.md) <br>\n- [Case study template](references/templates/case-study.md) <br>\n- [Product update template](references/templates/product-update.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, files, guidance] <br>\n**Output Format:** [Markdown draft files with a citation traceability table and pre-review checklist] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Produces one long-form draft and one companion review file; target article length is 1500-3000 words.] <br>\n\n## Skill Version(s): <br>\n1.0.2 (source: frontmatter and release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>","readmeExcerpt":"Skill: tcms-writer Owner: haiyangchenbj Summary: For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis. Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation. Not for neutral industry research — use industry-deep-dive-pipeline ","codeSnippets":[],"executableExamples":[{"language":"markdown","snippet":"## Execution summary\n- Source material read: [list actual files read]\n- Template chosen: [article type]\n- Article word count: [actual]\n- Cited data points: [N] ( [M] public, [K] internal redacted)\n- Self-check: 7 checks, [X] passed [Y] fixed\n\n## Citation traceability\n\n| Data point in text | Knowledge-base entry / source | Public status |\n|--------------------|------------------------------|---------------|\n| \"xxx\" | xxx entry / source article | ✅ public / 📋 internal (redacted) |\n\n## Pre-review checklist\n\n- [ ] Customer-name redaction check\n- [ ] Product-capability public-status check\n- [ ] Data points PM needs to confirm"},{"language":"markdown","snippet":"## Execution summary\n- Source material read: [list actual files read]\n- Template chosen: [article type]\n- Article word count: [actual]\n- Cited data points: [N] ( [M] public, [K] internal redacted)\n- Self-check: 7 checks, [X] passed [Y] fixed\n\n## Citation traceability\n\n| Data point in text | Knowledge-base entry / source | Public status |\n|--------------------|------------------------------|---------------|\n| \"xxx\" | xxx entry / source article | ✅ public / 📋 internal (redacted) |\n\n## Pre-review checklist\n\n- [ ] Customer-name redaction check\n- [ ] Product-capability public-status check\n- [ ] Data points PM needs to confirm"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\r\nname: tcms-writer\r\nversion: \"1.3.0\"\r\ndescription: |\r\n  For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis.\r\n  Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation.\r\n  Not for neutral industry research — use industry-deep-dive-pipeline for that.\r\nread_when:\r\n  - 写文章\r\n  - 写稿\r\n  - 写初稿\r\n  - 起草\r\n  - 技术博客\r\n  - 品牌技术稿\r\n  - 案例文章\r\n  - 客户案例\r\n  - 产品解读\r\n  - 产品稿\r\n  - 新闻稿\r\n  - content brief\r\n  - draft\r\n  - 按brief写\r\nallowed-tools:\r\n  - read_file\r\n  - write_to_file\r\n  - replace_in_file\r\n  - web_fetch\r\n  - search_content\r\n  - search_file\r\n  - list_dir\r\ndisable: false\r\n---\r\n\r\n# TCMS Writer\r\n\r\n基于产品知识库、品牌规范和选题Brief，产出高质量的长文初稿。\r\n\r\n## 工作模式：提示链（Prompt Chaining）\r\n\r\n按固定步骤执行，每一步输入输出明确。\r\n\r\n---\r\n\r\n## Step 1: 确认选题 [确定性]\r\n\r\n读取用户提供的选题信息，确认以下要素：\r\n\r\n| 要素 | 必须明确 | 缺失时处理 |\r\n|------|---------|-----------|\r\n| 文章类型 | 技术博客 / 客户案例 / 产品解读 | 询问用户 |\r\n| 目标产品 | 具体产品名 | 询问用户 |\r\n| 目标读者 | 架构师/CTO/工程师/分析师 | 默认\"技术决策者\" |\r\n| 核心信息 | 要传达的关键价值点 | 从知识库提取 |\r\n| 素材来源 | 知识库/内部材料/已发文章 | 默认使用知识库 |\r\n| 保密要求 | 是否有内部案例需脱敏 | 默认全部脱敏 |\r\n\r\n如果用户提供了Brief文件路径，直接读取Brief。\r\n\r\n---\r\n\r\n## Step 2: 读取素材 [确定性]\r\n\r\n**只读与目标产品相关的文件，不加载无关产品信息：**\r\n\r\n1. **产品知识库** → 搜索目标产品对应章节（不读全文，用search_content定位）\r\n2. **品牌规范** → `references/brand-rules.md`（每次都读）\r\n3. **文章模板** → 按文章类型读取对应模板：\r\n   - 技术博客：`references/templates/tech-blog.md`\r\n   - 客户案例：`references/templates/case-study.md`\r\n   - 产品解读：`references/templates/product-update.md`\r\n4. **补充素材**（按需）：Brief中指定的内部文档或已发布文章\r\n\r\n> 以上路径需根据实际项目目录配置。\r\n\r\n---\r\n\r\n## Step 3: 写作 [LLM]\r\n\r\n### 写作规则\r\n\r\n**产品名称**：\r\n- 首次提及使用官网全称（参见brand-rules.md产品名称对照表）\r\n- 后续可用简称\r\n\r\n**品牌露出**：\r\n- 标题中包含品牌名或具体产品官方名称\r\n- 开头两段内引入品牌或具体产品\r\n- 结尾有固定品牌格式\r\n\r\n**数据引用**：\r\n- 所有数据必须来自知识库或已发布文章，不可编造\r\n- 引用时记录来源（用于Step 5生成引用表）\r\n\r\n**客户信息**：\r\n- 内部来源的客户案例**默认脱敏**\r\n- 脱敏格式：\"某+行业+企业规模\"\r\n- 不出现客户公司名、内部人员姓名、项目代号\r\n- 用户明确告知已授权的可使用客户名称\r\n\r\n**竞品处理**：\r\n- 不直接点名任何竞品\r\n- 使用\"某友商平台\"等替代表述\r\n\r\n**产品能力来源验证**：\r\n- 只引用知识库中存在的产品能力\r\n- 不确定是否已公开的，在预审清单中标注\"需确认\"\r\n\r\n### 英文稿 AI 强特征与作者性门禁 [英文稿必过]\r\n\r\n本节是 TCMS 对统一英文规则源 `tech-writing-pipeline/references/english-ai-writing-strategy.md` 的应用说明。可访问该规则源时必须加载；本 Skill 不另建禁词表，也不以 AI detector 分数作为发布结论。本节规则不替代产品、品牌、客户、竞品、命名和知识库约束。\r\n\r\n1. **先建英文 claim map。** 英文稿动笔前，用英文记录 `Claim / Evidence / Counterargument / Boundary / What the reader should not infer` 五项。英文稿按英文读者的论证顺序重写，不按中文句序逐句翻译。\r\n2. **P0 直接停止。** 出现虚构事实、数字、引语、关系或归因；空泛开场或结尾承载主要信息；只有积极形容词没有对象、证据和条件；`studies show` / `experts believe` 没有可核查来源；反方只被提及却未评价；把中文平行结构或媒体表达直接搬进英文稿，均退回Brief或素材重建。\r\n3. **P1 进入人工复核。** 单段内修辞包装词成组出现，反复使用 `not just X but Y` 等对举模板，破折号或同构三项并列变成节奏骨架，或积极表述超过对象、来源、测量和限定条件时，进入人工复核。单个风格词不构成问题。\r\n4. **作者性检查。** 每个主要段落都要能指出具体对象、事件、数字或观察行为；作者愿意承担的判断；最强合理反驳；对反驳的处理；以及会使判断变窄或失效的条件。\r\n5. **按渠道解释结构。** LinkedIn 的对象清单、责任清单、承担事实功能的三项并列或结构母题不能单独判为 AI 腔。只有它们与空泛开场、来源不裁决、作者判断缺席或修辞包装叠加时，才升级处理。detector 分数只能作为观察项，不能进入 PASS/FAIL。\r\n\r\n### 文章结构\r\n\r\n不写成：功能1 → 功能2 → 功能3 的产品说明书\r\n\r\n要写成：**问题 → 为什么难 → 方案（自然引入产品能力）→ 效果 → 适用判断**\r\n\r"},{"path":"README.md","content":"# TCMS Writer\n\n**Part of the `tcms-*` family** — brand-side content skills for tech-product marketing teams.\n*Not for neutral third-party industry research — that is `industry-deep-dive-pipeline`'s job.*\n\n## What it does\n\nTurns a product knowledge base and brand rules into **brand-side long-form drafts** (technical blogs, customer case studies, product write-ups). Produces only 1500–3000 word drafts from a content brief.\n\nIt does **not** handle social posts, short content, or channel adaptation (see `tcms-adapter`).\n\n## When to use\n\n- You have a topic brief and need a long-form brand marketing draft.\n- The piece is promotional / product-positioning in nature.\n\n## When NOT to use\n\n- Neutral, third-party industry deep-dives → use `industry-deep-dive-pipeline`.\n- Single-article pre-publish compliance check → use `tcms-compliance-reviewer`.\n- Channel adaptation → use `tcms-adapter`.\n\n## Trigger phrases\n\n写文章, 写稿, 写初稿, 起草, 技术博客, 品牌技术稿, 案例文章, 客户案例, 产品解读, 产品稿, 新闻稿, content brief, draft, 按brief写\n\n## Pipeline position\n\n`tcms-planner` (brief) → **`tcms-writer`** (draft) → `tcms-compliance-reviewer` (review) → `tcms-adapter` (channels) → `tcms-performance-analyst` (monthly report)"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn70yg6zwmkftx4939qrs89awx82rr9a\",\n  \"slug\": \"tcms-writer\",\n  \"version\": \"1.3.0\",\n  \"publishedAt\": 1789876495288\n}"},{"path":"references/brand-rules.md","content":"# 品牌与内容规范\r\n\r\n> 按实际品牌和产品线配置以下内容。\r\n\r\n## 产品正式名称\r\n\r\n首次提及用全称，后续可用简称。\r\n\r\n| 简称 | 官网全称 | 首次引用格式 |\r\n|------|---------|------------|\r\n| 产品A | xxx平台 | XX云xxx平台（产品A） |\r\n| 产品B | xxx服务 | XX云xxx服务（产品B） |\r\n| ... | ... | ... |\r\n\r\n> 从官网产品页获取正式名称，保持一致。\r\n\r\n## 品牌露出规则\r\n\r\n- 标题中包含品牌名或具体产品官方名称\r\n- 开头两段内引入品牌或具体产品\r\n- 结尾固定格式：**{品牌名}，帮助/助力 xxx企业xxx。**\r\n- 正文中产品首次出现用全称，后续用简称\r\n\r\n## 写作调性\r\n\r\n- 专业、克制、有判断。不油腻，不夸张，不AI营销腔\r\n- 允许专业术语，紧跟一句通俗解释\r\n- 给结论和判断，不只堆信息\r\n- 像成熟的技术分析者，不像内容农场\r\n\r\n## 禁用表达\r\n\r\n| 类型 | 禁用 | 替代 |\r\n|------|------|------|\r\n| 竞品点名 | 具体竞品名称 | \"某友商平台\"\"原有闭源平台\" |\r\n| 未确认产品 | 内部规划中未正式发布的产品 | 不提及 |\r\n| 空话 | 赋能/闭环/端到端/强大/显著/大幅/打造 | 用具体数据和场景替代 |\r\n| 内部代号 | 任何未在官网出现的产品代号 | 不使用 |\r\n\r\n## 客户脱敏规则\r\n\r\n内部来源的客户案例默认脱敏：\r\n\r\n| 场景 | 脱敏格式 |\r\n|------|---------|\r\n| 知名企业 | 某+行业+规模，如\"某头部券商\" |\r\n| 一般企业 | 某+行业+企业类型，如\"某SaaS服务商\" |\r\n| 人员信息 | 不出现姓名/工号/企业微信ID |\r\n\r\n> 在此处维护具体客户名→脱敏名的映射表（不随代码同步）。\r\n\r\n## 已授权可公开引用的客户\r\n\r\n> 在此处维护已明确授权的客户名单。"},{"path":"references/sensitive-terms.md","content":"# 敏感词与禁用表达\r\n\r\n## 禁止出现的客户名称（内部来源，未确认授权）\r\n\r\n> 在此处维护具体客户名称列表。内部材料中出现的客户名必须脱敏处理。\r\n\r\n## 禁止出现的竞品名称\r\n\r\n> 在此处维护竞品公司名和产品名列表。\r\n\r\n替代表述：某友商平台 / 原有闭源平台 / 国际主流平台 / 其他同类产品\r\n\r\n## 禁止出现的未确认产品\r\n\r\n> 在此处维护内部规划中、对外口径未确认的产品名。\r\n\r\n## 禁止出现的内部信息\r\n\r\n- 内部项目代号\r\n- 内部人员姓名和通讯ID\r\n- 内部材料中的管理备注（如\"需和XX确认\"）\r\n- 内部材料roadmap中标注但官网未上线的功能（需逐条验证）\r\n\r\n## 慎用表达（非禁止，但尽量避免）\r\n\r\n赋能, 闭环, 端到端, 强大, 显著, 大幅, 打造, 一站式, 全面, 领先, 极致, 颠覆, 革命性\r\n→ 用具体数据和场景描述替代"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis. Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation. Not for neutral industry research — use industry-deep-dive-pipeline for that. Skill: tcms-writer Owner: haiyangchenbj Summary: For tech-product marketing teams — turns a product knowledge base into brand-side long-form drafts (blogs, case studies, product write-ups), not third-party analysis. Produces only 1500-3000 word long-form drafts from a content brief; does not handle social posts, short content, or channel adaptation. Not for neutral industry research — use industry-deep-dive-pipeline","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":956,"uniquenessScore":49,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T22:37:48.448Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T22:37:48.448Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-12T13:22:40.195Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}