Files
2026-07-13 21:35:40 +08:00

7.0 KiB
Raw Permalink Blame History

name, description, triggers, od
name description triggers od
github-dashboard GitHub 仓库分析看板 —— 星标、复刻、贡献者、 Issue、Pull Request、近期活动及主要贡献者。当需求中提及 GitHub 仓库看板、开源项目增长报告、仓库健康页面或 GitHub 分析视图时使用。
github dashboard
repo dashboard
repository dashboard
github analytics
open source dashboard
github growth
仓库看板
GitHub 看板
mode platform scenario preview design_system outputs capabilities_required example_prompt
prototype desktop operation
type entry
html index.html
requires sections
true
color
typography
layout
components
primary secondary
index.html
template.html
data.json
artifact.json
provenance.json
shell
file_write
Build a GitHub dashboard for nexu-io/open-design — stars, forks, contributors, issues, PRs, recent activity, and top contributors.

GitHub 看板技能

以 FlowAI / Soft Paper Workspace 视觉风格创建单个屏幕的 GitHub 仓库分析看板:暖白画布、白色圆角面板、固定左侧边栏、紧凑的 KPI 卡片、柔和色块、密集表格以及低对比度细线。

资源结构

github-dashboard/
├── SKILL.md
├── example.html                         ← 渲染后的参考看板
└── references/
    ├── template.html                    ← 兼容 live-artifact 的 HTML 模板
    ├── example-data.json                ← 标准化的公开 GitHub 数据形态
    ├── artifact-example.json            ← 最简 live-artifact 创建输入
    └── provenance-example.json          ← 安全的数据来源/溯源示例

何时使用此技能

当用户请求针对单个 GitHub 仓库的看板或报告时使用,例如:

  • 仓库增长看板
  • 开源项目健康报告
  • GitHub 星标 / 复刻 / 贡献者分析
  • Issue 与 Pull Request 活动页面
  • 维护者 / 贡献者看板

如果用户要求可刷新、来源可审计或定时更新,则生成 live-artifact 源文件集(template.htmldata.jsonartifact.jsonprovenance.json)并遵循 live-artifact 约定。如果仅需可视化产物,则生成独立自包含的 index.html

工作流程

  1. 确认仓库范围

    • 从需求中解析 owner/repo
    • 本 v1 版技能仅针对单个仓库。如果请求多个仓库,请用户选择主仓库,或为每个仓库分别创建看板。
    • 如果仓库缺失,用一句话询问 GitHub URL 或 owner/repo
  2. 收集公开 GitHub 数据

    • 优先使用 GitHub CLI/API 获取公开仓库数据。
    • 当前星标/复刻/关注者/开放 Issue 数量:GET /repos/{owner}/{repo}stargazers_countforks_countwatchers_countopen_issues_count)。
    • 贡献者:分页请求 GET /repos/{owner}/{repo}/contributors?per_page=100&page=N,按 contributions 降序排列,取看板使用的前 N 名。如果只取到第 1 页,将总数标注为首页估算值。
    • Issue:使用 GitHub 搜索 APIrepo:{owner}/{repo} is:issue)获取总数,或分页请求 GET /repos/{owner}/{repo}/issues?state=all 并过滤掉含有 pull_request 字段的条目。
    • Pull Request:使用 GitHub 搜索 APIrepo:{owner}/{repo} is:pr)获取总数,或分页请求 GET /repos/{owner}/{repo}/pulls?state=all 并通过 Link 头部统计页数。
    • 近期活动:合并最新的 Issue 和 Pull Request,将其规范化为可直接展示的行,预览列表控制在 5–10 条。
    • 增长/增量指标:GitHub REST 不提供完整的历史星标/复刻增量。可使用 GraphQL、星标事件快照、Events API(可用时),或在 provenance.json 中明确标注增量为估算/合成数据。
    • 不得存储认证令牌、原始 HTTP 信封、Cookie、速率限制头部或私有元数据。
  3. 标准化为看板数据

    • 必填 repositorynamefullNameurldescriptionlanguagelicensecreatedlastUpdated
    • 必填 metrics:星标、复刻、贡献者、Issue、Pull Request。存储可直接展示的总数及小幅增量或增长说明。
    • 必填 contributors:前 58 位贡献者,包含 loginavatarcontributions
    • 必填 recentActivity:可直接展示的行,包含 titletypeTexttypeClasslabellabelClassauthorauthorAvatarupdated。不得依赖模板条件判断来处理 Issue/PR 切换。
    • 图表数据仅在 GitHub 未暴露精确历史数据时可为合成数据;在 provenance 中记录转换过程。
  4. 应用视觉系统

    • 存在活跃的 DESIGN.md 令牌时优先使用。
    • 如果未提供设计系统,使用 references/template.html 中所反映的 Soft Paper 默认值:#F2F2F0 画布、白色卡片、#ECECEA 边框、#0A0A0A 墨色、Geist/Inter 字体、256px 侧边栏、48px 顶栏、16px 卡片圆角。
    • 颜色使用应克制且具有语义:绿色代表健康指标、琥珀色代表警告、蓝色代表功能/PR 标签,红色仅用于缺陷或风险。
  5. 布局页面

    • 外壳:256px 侧边栏 + 主面板,均为白色、圆角 16px、1px 细线边框。
    • 顶栏:左侧为仓库上下文,右侧为刷新/导出/操作入口。
    • 头部:仓库名称、描述及日期/设置/操作行。
    • KPI 条:5 张紧凑卡片,分别展示星标、复刻、贡献者、Issue、PR。
    • 主网格:2fr/1fr 分割,左侧为增长图表或活动表格,右侧为热门贡献者/健康卡片。
    • 页脚:以小号浅色文字显示来源/最后更新时间。
  6. 写入产物

    • 对于静态产物,写入一个独立的 index.html,内联 CSS,不依赖外部 JS 库。
    • 对于 live artifact,写入 template.htmldata.jsonartifact.jsonprovenance.jsonindex.html 由守护进程派生。
    • 用稳定的 data-od-id 值标记主要区域:sidebartopbarrepo-headerkpi-stripgrowth-chartcontributorsactivityprovenance

视觉规则

  • 仅限浅色模式。
  • 桌面端 256px 固定侧边栏;窄屏幕时堆叠排列。
  • 第一行放置 4 或 5 张 KPI 卡片。
  • 所有计数使用表格衬线数字。
  • 头像为圆形,表格和贡献者列表中为 28–32px。
  • 表格正文 13px,列表列标签 11px 大写,行分隔线 1px。
  • 卡片使用细线边框,最多使用几乎不可见的阴影:0 1px 2px rgba(10,10,10,.04), 0 1px 1px rgba(10,10,10,.02)
  • 除小型工作流/仓库图标占位符外,不使用渐变。
  • 页面不得看起来像 GitHub 本身。这是一个自定义运营看板,而非 GitHub UI 克隆。

自查清单

  • 每个指标都有来源或溯源说明。
  • 不持久化任何私有数据或凭据。
  • 数据标签与具体仓库对应,而非占位符。
  • 在 50% 缩放比例下屏幕仍清晰可读。
  • 每个区域最多使用一个纯黑色主要操作按钮。
  • 状态标签和 Issue/PR 标签为柔和色块,而非高饱和度徽章。