DEI Dashboard

DEI Dashboard helps define diversity and inclusion metrics with privacy conditions built into the proposed workflow. It starts from voluntary data, aggregates anonymously, records stage metrics and supports a review leading to action. Groups must be large enough to protect people, and any breakdown that could identify someone is skipped.

The skill separates advice, review, conversion and build requests before producing artifacts. Advice receives a short recommendation and an offer of a relevant build. An explicit build request proceeds once essential missing facts are resolved. It asks one question at a time, reuses answers already supplied and stops when further answers would not change the deliverable. Unknown information remains unknown rather than receiving invented values.

Use it for diversity reporting, workforce diversity metrics, inclusion tracking or a DEI dashboard structure. It fits scale-stage businesses deciding whether to cover hiring, progression or both, by department or overall.

It produces empty templates and does not collect personal data, make hiring decisions or set targets on the user's behalf. Anonymity and minimum group size are prerequisites for the proposed metrics. The skill does not calculate payroll, tax, leave balances or KPIs. Automation, reminders and synchronization require an integration layer. Legal, tax and HR review is required before templates drive real decisions.

Inputs cover existing data, voluntary self-identification, anonymization, relevant stages, external benchmarks or internal targets, current HRIS or spreadsheet tracking and the desired metric set or view. Fields record metric, department, period, measure type, value, target, group size, whether the minimum group size is met, data source, notes and metric ID. Measure types distinguish counts, percentages, ratios and averages. The group-size checkbox records the privacy condition alongside each metric rather than treating it as an optional afterthought.

Requested artifacts can include CSV, SQL DDL, JSON Schema, Notion property mappings or an Excel workbook. The formats derive from one field list: CSV and JSON retain matching display names, while SQL uses normalized identifiers. Dates retain date types, money retains currency types and cross-table references retain relation types. Select options are a starting set that can be renamed to match the business.

One SQL example is:

CREATE TABLE dei_dashboard (
  metric VARCHAR(255),
  department VARCHAR(255),
  period VARCHAR(255),
  measure_type VARCHAR(100) NOT NULL,
  value NUMERIC NOT NULL,
  target NUMERIC NOT NULL,
  group_size NUMERIC NOT NULL,
  minimum_group_size_met BOOLEAN NOT NULL,
  data_source VARCHAR(255),
  notes TEXT,
  metric_id SERIAL PRIMARY KEY,
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

Templates are empty by default. Example rows are produced only on request and remain obviously synthetic. Sensitive identifiers should not be repeated unnecessarily during a requested review. Machine-readable data stays separate from explanatory prose and any material validation failures. Excel-compatible CSV uses UTF-8 with a byte order mark and accompanying guidance about number, date and currency columns. An XLSX workbook is a separate requested output rather than a renamed CSV.

The Notion output routes to notion-manual-import for CSV, property mappings, import steps and verification. Manual mappings require no connection. Requested live workspace changes require actual tool access, a verified target and authorization. Imported columns may initially be Text and need their mapped property types applied. Relation links resolve after both relevant databases are imported. A static mapping alone does not establish a completed workspace change.