Setup
On first use, read setup.md for integration behavior and memory initialization.
When to Use
Use this skill when the user needs to define, track, analyze, or report metrics for any domain such as social media, sales, product, operations, finance, or personal systems.
This skill structures metric definitions, computes reliable formulas, builds reusable report packs, and maintains scalable automation rules that can grow with the user over time.
Architecture
Working memory lives in ~/metrics/. See memory-template.md for base structure and status behavior.
CODEBLOCK0
Quick Reference
Load only the file needed for the current task to keep context focused.
| Topic | File |
|---|
| Setup and integration | INLINECODE3 |
| Memory schema |
memory-template.md |
| Metric contract design |
metric-registry.md |
| Formula design and governance |
formula-playbook.md |
| Report cadences and templates |
reporting-pack.md |
| Automation and alerting patterns |
automation-patterns.md |
| Data validation and quality gates |
data-quality.md |
Core Rules
1. Define a Metric Contract Before Any Calculation
Every metric must have one clear contract: business meaning, numerator, denominator, source tables, update latency, and owner.
Never compute or compare metrics when the contract is missing or ambiguous.
2. Separate Raw Signals from Derived Metrics
Raw events are evidence. Metrics are interpreted aggregates. Keep them separate.
Store and reason in this order:
- 1. Raw signal
- Normalized base metric
- Derived metric
- Decision recommendation
3. Use Dimensions to Scale, Not New One-Off Metrics
When users ask for "the same metric but by X", add a dimension instead of creating a duplicate metric.
Common high-value dimensions:
- - Time grain
- Source/channel
- Segment/persona
- Geography
- Product or workflow stage
4. Version Formulas and Annotate Breaking Changes
Formulas evolve. Comparability fails when formula changes are not tracked.
For every formula update, store:
- - version
- change reason
- impact expectation
- backfill policy
- first report date with new logic
5. Reports Must Be Decision-Oriented
A report is incomplete unless each section ties to a decision owner and explicit next action.
Minimum output block for every report:
- - What changed
- Why it changed
- What to do now
- Who owns the action
- When to review again
6. Automate Thresholds with Response Playbooks
Alerts without response rules create noise.
Each threshold must include:
- - trigger condition
- severity level
- owner
- first response action
- escalation condition
7. Prefer Reusable Reporting Packs Over Custom One-Offs
Build reusable templates for daily, weekly, monthly, and campaign reports so the system can scale across teams and domains.
Only create custom formats when a stakeholder decision cannot be served by existing packs.
Common Traps
- - Mixing different metric definitions under one name -> trend lines become invalid.
- Changing formulas without version notes -> historical comparisons break silently.
- Reporting totals without segment cuts -> root causes remain hidden.
- Creating too many vanity metrics -> operators lose focus on decision metrics.
- Sending alerts without action ownership -> teams ignore notifications.
- Adding one-off dashboards for every request -> reporting system becomes unmaintainable.
Security & Privacy
Data that leaves your machine:
Data that stays local:
- - Metrics context and definitions under
~/metrics/. - Formula versions, report logs, and alert policies stored locally.
This skill does NOT:
- - Access files outside
~/metrics/ for memory storage. - Send metrics to third-party APIs by default.
- Create background automations without explicit user confirmation.
Related Skills
Install with
clawhub install <slug> if user confirms:
- -
analytics — metric analysis patterns and interpretation workflows. - INLINECODE14 — KPI visualization design and reporting layouts.
- INLINECODE15 — structured reporting outputs for stakeholders.
- INLINECODE16 — query generation for metric extraction pipelines.
- INLINECODE17 — spreadsheet-based metric operations and exports.
Feedback
- - If useful: INLINECODE18
- Stay updated: INLINECODE19
设置
首次使用时,请阅读 setup.md 了解集成行为和内存初始化。
使用时机
当用户需要为社交媒体、销售、产品、运营、财务或个人系统等任何领域定义、追踪、分析或报告指标时,使用本技能。
本技能可结构化指标定义、计算可靠公式、构建可复用报告包,并维护可随用户长期扩展的自动化规则。
架构
工作内存位于 ~/metrics/。基础结构和状态行为请参见 memory-template.md。
~/metrics/
├── memory.md # 热区:目标、活跃指标、报告节奏
├── registry/ # 温区:指标合约与维度字典
├── formulas/ # 温区:含版本历史的公式规范
├── reports/ # 温区:按节奏和利益相关方输出的报告
├── automations/ # 温区:定时检查与告警策略
└── archive/ # 冷区:已退役指标和历史报告周期
快速参考
仅加载当前任务所需的文件,以保持上下文聚焦。
memory-template.md |
| 指标合约设计 | metric-registry.md |
| 公式设计与治理 | formula-playbook.md |
| 报告节奏与模板 | reporting-pack.md |
| 自动化与告警模式 | automation-patterns.md |
| 数据验证与质量关卡 | data-quality.md |
核心规则
1. 计算前先定义指标合约
每个指标必须有一份清晰的合约:业务含义、分子、分母、数据源表、更新延迟和负责人。
合约缺失或模糊时,绝不计算或比较指标。
2. 区分原始信号与衍生指标
原始事件是证据。指标是经过解释的聚合数据。两者需保持分离。
按以下顺序存储和推理:
- 1. 原始信号
- 标准化基础指标
- 衍生指标
- 决策建议
3. 使用维度扩展,而非创建一次性指标
当用户要求同样的指标,但按X维度查看时,添加维度而非创建重复指标。
常见高价值维度:
- - 时间粒度
- 来源/渠道
- 细分群体/用户画像
- 地理区域
- 产品或工作流阶段
4. 对公式进行版本管理并标注重大变更
公式会演变。若公式变更未追踪,可比性将失效。
每次公式更新需存储:
- - 版本号
- 变更原因
- 预期影响
- 回填策略
- 首次使用新逻辑的报告日期
5. 报告必须以决策为导向
报告每个部分若未关联决策负责人和明确的下一步行动,则视为不完整。
每份报告的最小输出模块:
- - 发生了什么变化
- 变化原因
- 现在该做什么
- 行动负责人
- 下次审查时间
6. 自动化阈值需配合响应预案
没有响应规则的告警只会制造噪音。
每个阈值必须包含:
7. 优先使用可复用报告包,而非定制一次性报告
构建日、周、月及活动报告的可复用模板,使系统能跨团队和领域扩展。
仅在现有报告包无法满足利益相关方决策需求时,才创建定制格式。
常见陷阱
- - 将不同指标定义混用同一名称 → 趋势线失效
- 变更公式时不记录版本说明 → 历史对比悄然断裂
- 报告总数而不做细分切割 → 根本原因被隐藏
- 创建过多虚荣指标 → 操作者失去对决策指标的关注
- 发送告警却不指定行动负责人 → 团队忽略通知
- 为每个请求添加一次性仪表盘 → 报告系统变得不可维护
安全与隐私
离开您设备的数据:
保留在本地数据:
- - ~/metrics/ 下的指标上下文和定义。
- 公式版本、报告日志和告警策略本地存储。
本技能不会:
- - 访问 ~/metrics/ 以外的文件用于内存存储。
- 默认将指标发送至第三方API。
- 未经用户明确确认创建后台自动化。
相关技能
若用户确认,使用 clawhub install 安装:
- - analytics — 指标分析模式与解读工作流
- dashboard — KPI可视化设计与报告布局
- report — 面向利益相关方的结构化报告输出
- sql — 指标提取管道的查询生成
- excel-xlsx — 基于电子表格的指标操作与导出
反馈
- - 如觉有用:clawhub star metrics
- 保持更新:clawhub sync