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 skills/oleg494/coding-kit/dashboard-designnpx skills add oleg494/coding-kit --skill dashboard-designgit clone --depth 1 https://github.com/oleg494/coding-kitWhat 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.00074 | $0.01441 |
| Opus 5 | $0.00037 | $0.00720 |
| Sonnet 5 | $0.00015 | $0.00288 |
| Haiku 4.5 | $0.00007 | $0.00144 |
Grade A, and why
dashboard-design 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 yesterday.
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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Dashboard Design
Design dashboards as decision tools, not collections of cards. Make data easier to decide from, not merely decorative. A dashboard is not ready until its important states and interaction paths are verified in the browser, not only in source.
Use when
- Redesigning a marketplace or back-office dashboard
- Reworking KPI cards, charts, filters, tables, navigation, or detail panels
- Choosing chart/table forms for KPIs, trends, rankings, funnels
- Verifying a changed dashboard UI in the running app before calling it done
- Improving visual hierarchy, density, responsive behavior, or empty states
Do not use when
- The task is only backend, data modeling, or query optimization
- The user asks for a poster, presentation, logo, or static illustration
Workflow
- Inspect before proposing. Read the existing routes, components, tokens, data shape, and current UI. For every metric find the source definition, unit, aggregation, scope, time zone, freshness, and comparison period — never infer business meaning from a label or fabricate sample values.
- Name the primary decision. State who uses the dashboard, what they need to decide, and the three to five questions the screen must answer. If a visual supports no decision or comparison, prefer a clear value, status, or table over a chart. Remove elements that do not support those questions.
- Set information hierarchy. Put the primary status and action first, then KPI context, trend or comparison, details, and secondary actions. Keep filters and the active period visible. Use a table when exact values or row-level actions matter.
- Choose the least complex visual form. KPI for a current value, delta for comparison, line for time series, bars for category comparison/ranking, table for exact values or row actions, funnel only when stages and denominators are defined. Maps, pies, gauges, and dual axes only when the data genuinely requires them. Keep title, units, time range, scope, comparison basis, and freshness attached — no hover-only essential values.
- Use honest scales and accessible encoding. Zero baseline for bars unless a documented exception is clearer; no distorted axes, unexplained smoothing, false precision, or truncated labels. Never communicate important differences through color alone — add labels, patterns, or direct annotations; provide a text/table alternative for meaningful charts.
- Define a compact visual system. Prefer the existing design tokens. If none exist, define semantic tokens for surface, text, muted text, border, success, warning, danger, accent, spacing, type scale, radius, and elevation. Components must consume tokens instead of scattered raw colors. Keep color meaning stable across the product.
- Design every meaningful state. Cover loading, no data, insufficient data, error, stale/partial data, disabled/permission-limited actions, long labels or numbers, and values outside the expected range. Explain the next useful action and keep the layout stable.
- Handle responsive behavior intentionally. Check desktop, tablet, and mobile layouts. Stack or reprioritize content before shrinking it; recheck long category names and large numbers. Allow horizontal scrolling only for genuinely wide data tables; never let the whole page overflow. Keep keyboard focus visible and respect reduced-motion preferences.
- Critique before implementation. Remove one decorative element, one redundant label, and any card, chart, or animation that does not improve comprehension or actionability.
- Verify in the running app. A rendered check is part of the work, not optional follow-up: launch the real app (project run instructions, browser/DevTools or Playwright — never a source-only inspection), inspect representative viewports (1440/1024/768/375px or closest supported), exercise navigation, period controls, filters, tabs, sorting, pagination, row actions, and dialogs, and check the state matrix from step 7 plus the browser console for errors. Fix confirmed issues and rerun the affected check; claim completion only after the rerun is clean. Record evidence: surface, viewport, path/state, observed result, pass|defect, location.
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.
- yesterday First seen · 76 lines · 74 tokens per session scan A ea979c4571c1
dashboard-design is a skill published in the GitHub repository oleg494/coding-kit (1 stars, last pushed 2d ago), licensed MIT. It adds 74 tokens to every session and 1,441 once invoked, about $0.0004 per session on Opus 5. 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 skills, from other repositories
run
Execute a named agent role with optimized instructions. Explicit invocation only ($run). Never trigger implicitly.
tip
Deliver a transformative life perspective shift and a productivity tip. Use when the user invokes /tip or wants non-technical inspiration or a fresh mental model.
agentic-evals
Design evaluation contracts and test plans for agentic systems. Create deterministic tests, trajectory evals, quality dimensions, gold-set criteria, and CI gates before or after implementation. Use when asked for tests first, an eval plan, success criteria, non-deterministic testing, LLM-as-judge setup, or…
agentic-production-readiness
Prepare an AI agent system for production operation. Cover SHIELD controls, sandbox/canary/production rollout, OpenTelemetry observability with GenAI semantic conventions, Agent Card drafting, governance, and post-deploy monitoring. Use for production readiness checks, go-live checklists, agent monitoring, agent…
agentic-security-review
Run a security and dependency audit for agent systems, tool-using AI apps, MCP/A2A integrations, or security-sensitive AI-generated code. Check slopsquatting risk, tool shadowing, rug pulls, memory/context poisoning, secrets, unsafe permissions, and common CWE patterns. Use when asked for security review, dependency…
agentic-spec
Create a structured specification before agentic coding work. Assemble the six context types, scale rigor for prototype/internal/production tasks, produce SPEC.md, and configure focused AGENTS.md boundaries. Use when asked to write a spec, plan a feature, design an agent/system, define architecture, or create…