dashboards-to-decisions — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited dashboards-to-decisions (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
When someone asks "I need a dashboard," the first question is: "What decision will this inform?"
If they can't answer, the dashboard shouldn't exist yet. Not "never build it." Just "not yet." Get the decision clear first.
Ask: "What decision will this dashboard help you make? Be specific — not 'understand performance' but 'decide whether to expand into the Southeast region this quarter.'"
If the requester struggles, use these prompts:
If no decision emerges: the request is a monitoring need, not a decision need. Route to Layer 1 (dashboard craft) and move on.
| Element | Question | Example |
|---|---|---|
| Decision | What specifically is being decided? | "Expand to Southeast: yes/no" |
| Decision-maker | Who has authority? | "VP of Operations, with CFO sign-off" |
| Timeline | When does this decision get made? | "Q3 planning, due July 15" |
| Metrics needed | What data informs this? | "Market size, current penetration, operational capacity, P&L impact" |
| Threshold | What number triggers action? | "If projected ROI > 15% AND capacity utilization < 80%" |
| Context | What else does the decision-maker need to know? | "Previous expansion to Midwest failed at 12% ROI" |
| Failure mode | What would make the wrong decision? | "Misleading market size data (happened with Midwest)" |
Write a decision specification that captures:
Only after Steps 1-3 are clear, design the visualization. Now you know:
| Layer | What This Skill Adds |
|---|---|
| Layer 1: Dashboard Craft | The dashboard itself (this is where most teams stop) |
| Layer 2: Decision Context | The "what you need to know before looking at the data" document |
| Layer 3: Decision Intent | The thresholds and metric priorities that encode business judgment |
| Layer 4: Decision Infrastructure | The full spec that lets the decision-maker self-serve |
Cross-reference stakeholder-alignment for translating between data teams and business stakeholders.
Ask your team: "Name 3 decisions that changed because of something we shipped last quarter."
If they can't, you're stuck at Layer 1. This skill moves you to Layer 2+.
# Decision Specification: [Decision Name]
Date: [date]
Requester: [who asked for this]
## The Decision
[Plain language question]
## Decision-Maker & Timeline
[Who decides, by when]
## Metrics Required
| Metric | Definition | Source | Current Value |
|--------|-----------|--------|---------------|
| [metric] | [precise definition] | [data source] | [if known] |
## Decision Threshold
[What number triggers which action]
## Context
[What the decision-maker needs to know before looking at data]
## Intent (When Metrics Conflict)
[Which metric wins and why]
## Failure Modes
[What would lead to a wrong decision]
## Dashboard Recommendation
[Now we can spec the visualization — layout, key charts, highlights]From the Decision Engineering framework. Generic decision tools: decision-architecture.
Part of the Data Product Operator plugin.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.