github-dashboard

Files (7)

• SKILL.md
• example.html
• README.md · references/
• artifact-example.json · references/
• example-data.json · references/
• provenance-example.json · references/
• template.html · references/

SKILL.md (first lines)

# 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-readable-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.

From sanghyunna/readable-studio, Apache-2.0.

More from sanghyunna/readable-studio