Files
workbuddy_skills/open-design/design-templates/github-dashboard/SKILL.md
T
admin 5afeb6b78a ④段整套同步(六节 + P/S/F/J + 模板)+ open-design 移到技能根
一、④段整套同步(用户选候选 A)
- 新增 `references/stage-proto-doc/assets/产品文档模板.html`(16 KB/247 行,从备份拷、转 LF)。
- ④段 SKILL.md 换成备份 15:28 那版,并按模板口径改齐:
  · 「产品文档框架」从「四块+一附录」改成**六节** —— 页面结构/功能清单/使用场景/操作流程/
    跨页与界面状态/待确认与偏离;与模板同构,⛔ 不从空白页重写结构。
  · 编号从 R/S/F 改成 **P 页面/S 场景/F 功能/J 二级功能**,各自唯一、按展示顺序通排。
  · 保留旧版有价值的要求:每项功能补齐 做什么/入口在哪/输入边界/异常与恢复;重点功能三处标红;
    横向流程图每步写清页面/功能/操作/完成判据。
  · 完成标准「七节」→「六节」,自查清单同步换掉「需求」那批条目,补模板与配图两条。
  · 路径 `designs/<项目>/` → `docs/pm/<项目>/ui/`(2 处)。
  · 补回本机那条「每份产出文档开头都要有一张图」的引用(指向主 skill,段内不复述)。
- 主 skill 同步:四段结构表④行、④段沿革、画图小节(④段画页面结构图 + 用户路径)。

二、open-design 移到技能根(用户选候选 A)
- `git mv product-planning/references/stage-delivery/assets/open-design → open-design/`(4178 文件)。
- `.gitignore` 白名单加 `!/open-design/` —— 否则移出去就不再纳入版本控制。
- 引用改 11 处:路径形态 `assets/open-design/...` → `<技能根>/open-design/...`;
  「随段携带的自带件」改称「同根技能」;「路径怎么找」那条改成自带件(段内相对路径)与
  同根技能(`<技能根>/<技能名>/`)两类分开写。
- open-design 自己的 ATTRIBUTION.md 两处同步(它现在与 oil-ui-pro 同层)。
- 副作用(有益):命名闸门读数由 2063 降到 225 —— 此前它把 open-design 里 919 个第三方 md
  当成规则一起扫了;现在只扫本包 23 个 md。已确认④段的 H1 与 4a/4b/4c 子步仍在检查范围内。

三、验收
- check_naming.py --ws E:/ProgramData/AIProject/contentm_agent = 通过 225 / 失败 0 / 提示 27。
- 活文件里 `assets/open-design` 残留 0;工作区 CRLF 文件 0。
2026-10-15 21:17:28 +08:00

7.2 KiB
Raw Blame History

name, description, triggers, od
name description triggers od
github-dashboard GitHub repository analytics dashboard — stars, forks, contributors, issues, pull requests, recent activity, and top contributors. Use when the brief asks for a GitHub repo dashboard, open-source growth report, repository health page, or GitHub analytics view.
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 Dashboard Skill

Create a single-screen GitHub repository analytics dashboard in the FlowAI / Soft Paper Workspace visual style: warm off-white canvas, white rounded panels, a fixed left sidebar, compact KPI cards, pastel pills, dense tables, and low-contrast hairlines.

Resource map

github-dashboard/
├── SKILL.md
├── example.html                         ← rendered reference dashboard
└── references/
    ├── template.html                    ← live-artifact-compatible HTML template
    ├── example-data.json                ← normalized public GitHub data shape
    ├── artifact-example.json            ← minimal live-artifact create input
    └── provenance-example.json          ← safe source/provenance example

When to use this skill

Use this when the user asks for a dashboard or report about a single GitHub repository, for example:

  • repository growth dashboard
  • open-source project health report
  • GitHub stars / forks / contributors analytics
  • issue and pull-request activity page
  • maintainer / contributor dashboard

If the user asks for refreshability, source auditability, or scheduled updates, produce the live-artifact source set (template.html, data.json, artifact.json, provenance.json) and follow the live-artifact contract. If they only need a visual artifact, produce a self-contained index.html.

Workflow

  1. Resolve repository scope

    • Parse owner/repo from the brief.
    • This v1 skill is scoped to one repository. If multiple repositories are requested, ask the user to pick the primary repository or create one dashboard per repository.
    • If the repo is missing, ask one concise question for the GitHub URL or owner/repo.
  2. Collect public GitHub data

    • Prefer GitHub CLI/API for public repository data when available.
    • Current stars/forks/watchers/open issue count: GET /repos/{owner}/{repo} (stargazers_count, forks_count, watchers_count, open_issues_count).
    • Contributors: paginate GET /repos/{owner}/{repo}/contributors?per_page=100&page=N, sort by contributions descending, and take the top N used by the dashboard. If only page 1 is available, label totals as first-page estimates.
    • Issues: use GitHub Search API (repo:{owner}/{repo} is:issue) for total counts, or paginate GET /repos/{owner}/{repo}/issues?state=all and filter out items with a pull_request field.
    • Pull requests: use GitHub Search API (repo:{owner}/{repo} is:pr) for total counts, or paginate GET /repos/{owner}/{repo}/pulls?state=all and count pages via the Link header.
    • Recent activity: combine the newest issues and pull requests, normalize them into display-ready rows, and cap the preview list at 5–10 items.
    • Growth/delta metrics: GitHub REST does not expose complete historical star/fork deltas. Use GraphQL, stargazer event snapshots, the Events API where available, or explicitly mark deltas as estimated/synthetic in provenance.json.
    • Do not store auth tokens, raw HTTP envelopes, cookies, rate-limit headers, or private metadata.
  3. Normalize into dashboard data

    • Required repository: name, fullName, url, description, language, license, created, lastUpdated.
    • Required metrics: stars, forks, contributors, issues, pull requests. Store display-ready totals plus small deltas or growth notes.
    • Required contributors: top 5–8 contributors with login, avatar, and contributions.
    • Required recentActivity: display-ready rows with title, typeText, typeClass, label, labelClass, author, authorAvatar, and updated. Do not rely on template conditionals for issue/PR switching.
    • Chart data can be synthetic only when GitHub does not expose the exact history; document the transformation in provenance.
  4. Apply the visual system

    • Use the active DESIGN.md tokens when present.
    • If no design system is provided, use the Soft Paper defaults reflected in references/template.html: #F2F2F0 canvas, white cards, #ECECEA borders, #0A0A0A ink, Geist/Inter typography, 256px sidebar, 48px topbar, and 16px card radius.
    • Keep color small and semantic: green for healthy metrics, amber for warning, blue for feature/PR labels, red only for defects or risk.
  5. Lay out the page

    • Shell: 256px sidebar + main panel, both white, rounded 16px, 1px hairline border.
    • Topbar: repo context on the left, refresh/export/action affordances on the right.
    • Header: repository name, description, and date/settings/actions row.
    • KPI strip: 5 compact cards for stars, forks, contributors, issues, PRs.
    • Main grid: 2fr/1fr split with a growth chart or activity table on the left and top contributors/health cards on the right.
    • Footer: provenance/last-updated note in small muted text.
  6. Write the artifact

    • For a static artifact, write one self-contained index.html with inline CSS and no external JS libraries.
    • For a live artifact, write template.html, data.json, artifact.json, and provenance.json; index.html is derived by the daemon.
    • Tag major regions with stable data-od-id values: sidebar, topbar, repo-header, kpi-strip, growth-chart, contributors, activity, provenance.

Visual rules

  • Light mode only.
  • 256px fixed sidebar on desktop; stack on narrow screens.
  • 4 or 5 KPI cards in the first row.
  • Use tabular lining numerals for all counts.
  • Avatars are circular, 28–32px in tables and contributor lists.
  • Tables use 13px body text, 11px uppercase column labels, 1px row dividers.
  • Cards use hairline borders and a barely visible shadow at most: 0 1px 2px rgba(10,10,10,.04), 0 1px 1px rgba(10,10,10,.02).
  • Do not use gradients except tiny workflow/repo icon placeholders.
  • Do not make the page look like GitHub itself. This is a custom operational dashboard, not a GitHub UI clone.

Self-check

  • Every metric has a source or a provenance note.
  • No private data or credentials are persisted.
  • Data labels are specific to the repository, not placeholders.
  • The screen still reads clearly at 50% zoom.
  • The dashboard uses at most one solid black primary action per area.
  • Status labels and issue/PR chips are pastel pills, not saturated badges.