Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/alwkala/tidyfactor-design/dashboardgit clone --depth 1 https://github.com/alwkala/tidyfactor-designWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/alwkala/tidyfactor-design/dashboard)<a href="https://agentmods.dev/commands/alwkala/tidyfactor-design/dashboard"><img src="https://agentmods.dev/badge/commands/alwkala/tidyfactor-design/dashboard.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.00485 |
| Opus 5 | $0.00000 | $0.00243 |
| Sonnet 5 | $0.00000 | $0.00097 |
| Haiku 4.5 | $0.00000 | $0.00049 |
Grade A, and why
dashboard scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 46 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Command: dashboard — Add an App/Dashboard Screen
Purpose
Dashboards are structurally different from marketing pages (persistent navigation shell, data-density, empty/loading/error states are core to the experience, not edge cases) — kept as its own command so those differences get deliberate handling instead of the marketing-page template stretched to fit.
When to run it
- Any app-shell screen: overview/analytics, a data table view, a settings screen, a detail/record view, an onboarding step.
- User phrasing: "design a dashboard screen", "add the settings page to
the app",
dashboard.
What it does
- Confirm (or establish, on the first
dashboardrun) the persistent shell: sidebar or topbar navigation, defined once as a component, reused identically across every dashboard screen — never rebuilt per screen. - Compose the screen's content area from
components.css/foundation library data surfaces: stat cards, data tables, charts-as-static-visual (a prototype doesn't need live data binding, but the visual should read as real data, not a placeholder grid), filters, forms. - Build the full state set as part of this command, not as an afterthought: populated, empty (with a clear next action), loading (skeleton, not a spinner-only blank), and error — a dashboard prototype that only shows the happy path isn't credible to a client review.
- Keep density and information hierarchy deliberate — a dashboard's job is scanning, not persuading; resist marketing-page hero treatment here.
- Same drift rule as
page: any missing pattern gets routed throughcomponents, never improvised in place.
Output convention
pages/dashboard-<screen-name>.html
<nav class="app-shell__sidebar">...</nav> ← identical markup across every dashboard screen
Checklist
- Shell (nav) markup identical across all dashboard screens in the project
- Empty, loading, and error states built alongside the populated state
- Data surfaces read as real data, not obvious placeholder content
- No page-level CSS/JS — same rule as
page
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 46 lines · 0 tokens per session scan A 2db508899bc6
dashboard is a command published in the GitHub repository alwkala/tidyfactor-design (5 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 485 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
github-issue
Create a GitHub issue from a natural language description.
test
Hello world test command.
critique-screen
Run all seven visual critiques on a screen and output a prioritised fix list.
critique-ux
Run a focused UX critique on a screen — affordances, information density, and hierarchy — and output a prioritised fix list.
design-onboarding
Design a first-run experience end to end — activation path, progressive disclosure, and time to first value.
frame-problem
Structure an ambiguous design challenge into a clear problem definition with constraints and criteria.