project-dashboard
Skill0 starsChanged 34 days agoMITView on GitHub
Build a visual dashboard of a project's real state - features by status, contract and validation evidence, tests and CI, git position, debts and lessons - as a single-file interactive HTML page in the reader's chat language, every number measured from the repository itself (ledger files, git, command outputs), screenshot-inspected before delivery. Use when the user asks for a dashboard, a visual status of the project, a sprint or weekly review, the state of the repo, or at sprint closure. Not for explaining a single result (that is the explainer skill).
2 other projects use a version of this.
Adopted by
Most recently taken up by
- babamba2/superclaude-for-saptheir own version, first seen Nov 1, 2026
- leosimini/keelokittheir own version, first seen Oct 13, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- babamba2/superclaude-for-sap★ 71same name
- leosimini/keelokit★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository58 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agySkill
- animate-expoSkill
- animateSkill
- animation-performanceSkill
- animation-vocabularySkill
- apple-designSkill
- ask-sonnerSkill
- break-uiSkill
- docs-fishingSkill
- emil-design-engSkill
- explainerSkill
- ffmpeg-skillSkill
- find-animation-opportunitiesSkill
- frontend-designSkill
- good-cssSkill
- improve-animationsSkill
- minimal-change-engineerSkill
- mobile-nativeSkill
- moli-webfetchSkill
- pick-ui-librarySkill
- project-dashboardSkill
- prototypeSkill
- reality-checkerSkill
- review-animationsSkill
- rust-refactoringSkill
- skill-creatorSkill
- using-superpowersSkill
- voice-ai-engineeringSkill
- write-swiftSkill
- agySkill
- animate-expoSkill
- animateSkill
- animation-performanceSkill
- animation-vocabularySkill
- apple-designSkill
- ask-sonnerSkill
- break-uiSkill
- docs-fishingSkill
- emil-design-engSkill
- explainerSkill
- ffmpeg-skillSkill
- find-animation-opportunitiesSkill
- frontend-designSkill
- good-cssSkill
- improve-animationsSkill
- minimal-change-engineerSkill
- mobile-nativeSkill
- moli-webfetchSkill
- pick-ui-librarySkill
- prototypeSkill
- reality-checkerSkill
- review-animationsSkill
- rust-refactoringSkill
- skill-creatorSkill
- using-superpowersSkill
- voice-ai-engineeringSkill
- write-swiftSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 24
Provenance: - every number on the page cites its source file or command in a tooltip or caption.
- Distinctive: line 46
Read-only on the repository: the dashboard never modifies state files.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Project dashboard
A repository tells its state through scattered files: a feature list, a contract, a progress sheet, a log, git history. Reading them one by one is work. A dashboard reads them all and answers one question: where does this project stand? Every project in the fleet can have this, on demand.
Data recipe - measure, never invent
- Ledger files -
feature_list.json(active features and statuses; archive count),contract.md(criteria),progress.md(validated evidence per criterion),log.md(the ~10 most recent entries). Read them from disk; never reconstruct them from memory. - Git - current branch, ahead/behind versus the remote, the last commits (subject and date), count of uncommitted changes.
- Health - the test and lint commands the repository's §7 declares: run them when cheap; otherwise cite the last recorded evidence and mark it "not re-run". Never present an unexecuted check as green.
- Provenance - every number on the page cites its source file or command in a tooltip or caption.
Page contract
- Single self-contained HTML file: inline CSS and JS, no CDN, no network,
no build step. Under
scratch/(or the location the repository declares), named<project>-dashboard-YYYY-MM-DD.html. Disposable: never wired into the docs or the build unless asked. - Written in the reader's chat language (the language the repository declares for replies to the user), whatever the content language is.
- Sections: headline numbers (features by status, checks, git position) - feature cards with per-criterion validation state - activity timeline from the log - debts and lessons (the §7 pitfalls) - a provenance footer with the measurement date and sources.
- Interactivity: filter chips by status, search, hover detail.
- Quality bar: deliberate layout, typography and color hierarchy; a page with no styling decisions is not done. Screenshot the rendered page and inspect it before delivery - verified means seen.
Rules
- Read-only on the repository: the dashboard never modifies state files.
- Stale, partial or unverifiable data is labeled as such on the page, never silently smoothed over.
- The dashboard accompanies the chat: deliver it with a short summary and the one action the picture makes obvious (a blocked feature, a red check, a branch never pushed).
Outputs
scratch/<project>-dashboard-YYYY-MM-DD.html(or the declared location)- a screenshot kept as evidence of the visual inspection
- a short chat summary, the artifact path, and the next action to take
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.