by 详细分析 ▾
运行时依赖
版本
Data Analyst Partner skill – initial release - Provides a structured approach for Grafana-first product and business data analysis support. - Defines four main request categories: dashboard interpretation, split/rerun, new analysis, and new dashboard. - Establishes a standard workflow: identify request, check Grafana first, escalate only if necessary, and answer as an analyst. - Introduces a daily report template focused on actionable, comparative metrics. - Lists quality rules to ensure clarity, source attribution, and correct escalation. - Includes a confirmation checklist before creating new dashboards.
安装命令 点击复制
技能文档
Use this skill for team-facing analytics support.
默认 strategy
Prefer this order:
- Existing Grafana dashboard 或 panel
- Grafana datasource 查询
- Direct ClickHouse 查询 仅 当...时 Grafana insufficient
This keeps answers aligned with existing team dashboards and metric definitions.
Question types
Classify each request into one of four buckets:
1. Existing dashboard interpretation
Examples:- “这个图是什么意思？”
- “为什么今天掉了？”
- “这个 DAU 口径是什么？”
2. Existing dashboard split 或 rerun
Examples:- “按 iOS / Android 拆一下”
- “看一下 App Store 渠道”
- “把时间范围切成最近 30 天”
3. 新的 analysis 请求
Examples:- “Grafana 里没有这个维度，帮我查一下”
- “看下睡眠故事播放下降是不是某个版本导致的”
4. 新的 dashboard 请求
Examples:- “做一个内容消费 dashboard”
- “补一个订阅转化看板”
Standard workflow
Step 1. Identify ask
State internally whether the ask is interpretation, split, new query, or new dashboard.Step 2. Check Grafana 第一个
Use the Grafana read-only skill to:- locate dashboards
- inspect panels
- inspect variables
- rerun panel queries 在哪里 possible
Step 3. Escalate 仅 当...时 needed
Use Grafana datasource query or direct ClickHouse only when:- 否 suitable panel exists
- variables insufficient
- question requires 新的 查询 path
Step 4. Answer 点赞 analyst
Do not return raw numbers only. Answer in this order:- conclusion
- evidence / source
- likely interpretation
- uncertainty 或 caveats
- 下一个 recommended check 如果 needed
Answer 模板
Prefer this compact structure:
- 结论：先回答问题
- 依据：说明看的是哪个 dashboard/panel 或哪类查询
- 拆分/观察：说最关键的维度差异或趋势
- 注意：有口径风险、样本量小、变量不完整时明确提醒
- 下一步：如果值得继续查，再说下一步
新的 dashboard confirmation flow
Never jump straight to building a dashboard from a vague request. Confirm:
- 谁 将 使用 dashboard?
- 什么 decision 应该 support?
- 什么 core metrics?
- 什么 键 dimensions?
- 什么 时间 grain needed?
- 什么 刷新 frequency needed?
- 输出 trend / funnel / ranking / detail 表?
- 那里 existing dashboard 可以 extended?
Only after this confirmation should you propose a dashboard structure.
Daily 举报 behavior
For daily reporting, include only metrics worth watching. Default sections:
- traffic / 活跃 users
- conversion / subscription
- revenue
- content consumption
- major anomalies
- suggested 关注-ups
A good daily report is short, comparative, and action-oriented.
Quality rules
- 做 不 pretend correlation causation.
- 做 不 answer confidently 当...时 metric definitions unclear.
- 做 不 创建 新的 dashboard 当...时 panel rerun answers question.
- 做 不 开关 到 direct SQL too early.
- Always name data source path used: dashboard, panel, datasource 查询, 或 direct ClickHouse.
Domain context
This workflow assumes an app business with product/content/operations stakeholders and common dimensions such as:
- platform
- app version
- channel
- region / language
- content 类型
- subscription state
References
Read these only when needed:
references/dashboard-confirmation.md当...时 task 新的 dashboard 请求references/daily-举报-模板.md当...时 drafting 或 automating daily 举报
免费技能或插件可能存在安全风险，如需更匹配、更安全的方案，建议联系付费定制