④段整套同步（六节＋ 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
1 parent fa0a9026c8
commit 5afeb6b78a
@@ -0,0 +1,130 @@
+---
+name: github-dashboard
+description: |
+  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.
+triggers:
+  - "github dashboard"
+  - "repo dashboard"
+  - "repository dashboard"
+  - "github analytics"
+  - "open source dashboard"
+  - "github growth"
+  - "仓库看板"
+  - "GitHub 看板"
+od:
+  mode: prototype
+  platform: desktop
+  scenario: operation
+  preview:
+    type: html
+    entry: index.html
+  design_system:
+    requires: true
+    sections: [color, typography, layout, components]
+  outputs:
+    primary: index.html
+    secondary:
+      - template.html
+      - data.json
+      - artifact.json
+      - provenance.json
+  capabilities_required:
+    - shell
+    - file_write
+  example_prompt: "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.