Setup
If ~/help-center/ does not exist or is empty, explain that local planning files can be created for this skill and follow setup.md.
When to Use
User needs to create, migrate, or improve a help center. Handles provider selection, custom architecture, knowledge base structure, support workflow design, and ongoing optimization.
Architecture
Memory lives in ~/help-center/. See memory-template.md for structure.
CODEBLOCK0
Quick Reference
| Topic | File |
|---|
| Setup and integration | INLINECODE4 |
| Memory template |
memory-template.md |
| Provider comparison |
provider-matrix.md |
| Build your own stack |
build-own-stack.md |
| Migration plan |
migration-playbook.md |
| Content operations |
content-ops.md |
| Launch checklist |
launch-checklist.md |
Core Rules
1. Frame the Support Model Before Picking Tools
Capture support channels, monthly ticket volume, languages, compliance constraints, and team size first. Do not recommend a provider or architecture without these inputs.
2. Compare Provider and Build-Your-Own Paths Explicitly
Use
provider-matrix.md to score at least two vendor options and one custom-stack option against the same criteria: total cost, speed, customization, lock-in risk, and maintenance burden.
3. Design Information Architecture Early
Define categories, article templates, ownership, and review cadence before content migration. A help center without taxonomy rules becomes unsearchable within weeks.
4. Tie the Help Center to Ticketing Workflows
Map every article category to triage tags, escalation routes, and SLA targets. A help center is operational infrastructure, not only documentation.
5. Treat Migration as a Controlled Release
Use
migration-playbook.md for inventory, redirects, URL mapping, and fallback plans. Never migrate content without rollback steps and QA checks.
6. Operate with Leading and Lagging Metrics
Track deflection rate, first response time, article freshness, unresolved search queries, and escalation frequency. Review weekly and update content priorities.
7. Save Decisions and Constraints for Future Sessions
After each strategic choice, update
~/help-center/memory.md with decision rationale, rejected options, and open risks so future work stays consistent.
Common Traps
- - Choosing a provider by brand familiarity alone -> hidden costs and painful migration later.
- Migrating old articles without rewrite standards -> users keep opening tickets for already documented issues.
- Ignoring search analytics -> dead articles stay published while top unanswered intents grow.
- Launching without ownership model -> stale content accumulates and trust drops.
- Tracking only page views -> no visibility into support impact or deflection quality.
Security & Privacy
Data that leaves your machine:
- - None by default. This skill focuses on local planning and decision support.
Data that stays local:
- - Planning notes, scoring decisions, and rollout logs in
~/help-center/.
This skill does NOT:
- - Send local files to third-party APIs.
- Execute provider-side changes automatically.
- Access files outside
~/help-center/ for memory storage.
Related Skills
Install with
clawhub install <slug> if user confirms:
- -
customer-support — run frontline support workflows and escalation handling. - INLINECODE18 — write clear internal and external product documentation.
- INLINECODE19 — design repeatable operational workflows with clear handoffs.
- INLINECODE20 — connect support insights with customer lifecycle systems.
Feedback
- - If useful: INLINECODE21
- Stay updated: INLINECODE22
设置
如果 ~/help-center/ 不存在或为空,说明可以为该技能创建本地规划文件,并遵循 setup.md 的指引。
使用时机
用户需要创建、迁移或优化帮助中心。涵盖供应商选择、自定义架构、知识库结构、支持工作流设计以及持续优化。
架构
记忆文件存储在 ~/help-center/ 中。结构请参考 memory-template.md。
~/help-center/
├── memory.md # 状态、决策和约束
├── provider-score.md # 供应商评分快照
├── content-inventory.md # 现有文章及内容缺口
└── rollout-log.md # 上线及上线后记录
快速参考
memory-template.md |
| 供应商对比 | provider-matrix.md |
| 自建技术栈 | build-own-stack.md |
| 迁移计划 | migration-playbook.md |
| 内容运营 | content-ops.md |
| 上线检查清单 | launch-checklist.md |
核心规则
1. 选择工具前先确定支持模式
首先收集支持渠道、月度工单量、语言、合规约束和团队规模。在没有这些输入的情况下,不要推荐供应商或架构。
2. 明确对比供应商与自建方案
使用 provider-matrix.md,按照相同标准(总成本、速度、可定制性、锁定风险、维护负担)对至少两个供应商方案和一个自建方案进行评分。
3. 尽早设计信息架构
在内容迁移前,定义分类、文章模板、负责人和审核节奏。没有分类规则的帮助中心会在几周内变得无法搜索。
4. 将帮助中心与工单工作流关联
将每个文章分类映射到分类标签、升级路径和SLA目标。帮助中心是运营基础设施,而不仅仅是文档。
5. 将迁移视为受控发布
使用 migration-playbook.md 管理内容清单、重定向、URL映射和回退方案。没有回滚步骤和质量检查,绝不迁移内容。
6. 使用领先和滞后指标进行运营
跟踪拦截率、首次响应时间、文章新鲜度、未解决的搜索查询和升级频率。每周审查并更新内容优先级。
7. 保存决策和约束供后续使用
每次战略选择后,更新 ~/help-center/memory.md,记录决策理由、被否决的方案和未解决的风险,确保后续工作保持一致。
常见陷阱
- - 仅凭品牌知名度选择供应商 → 隐藏成本和痛苦的后续迁移。
- 迁移旧文章时不设定重写标准 → 用户继续为已有文档的问题提交工单。
- 忽略搜索分析 → 无效文章持续发布,而最常被搜索但未解答的问题不断增长。
- 上线时没有明确负责人 → 内容逐渐过时,信任度下降。
- 仅跟踪页面浏览量 → 无法了解对支持的影响或拦截质量。
安全与隐私
离开你设备的数据:
保留在本地设备的数据:
- - 规划笔记、评分决策和上线日志,存储在 ~/help-center/ 中。
该技能不会:
- - 将本地文件发送到第三方API。
- 自动执行供应商端的更改。
- 访问 ~/help-center/ 之外的文件用于记忆存储。
相关技能
如果用户确认,使用 clawhub install 安装:
- - customer-support — 运行一线支持工作流和升级处理。
- documentation — 编写清晰的内外部产品文档。
- workflow — 设计可重复的运营工作流,明确交接环节。
- crm — 将支持洞察与客户生命周期系统连接。
反馈
- - 如果觉得有用:clawhub star help-center
- 保持更新:clawhub sync