team-validation-dashboard

name: team-validation-dashboard description: "Use for organization-wide visibility across multiple projects' validation health — not for a single project (use forge-benchmark for that). Aggregates posture scores, coverage %, regression trends, and journey ownership across all registered projects in a team's portfolio. Flags critical projects (score < 60) for attention. Reach for it on phrases like 'team dashboard', 'show validation across all projects', 'which projects need attention', 'quarterly validation review', 'who owns journey X', or for CI/CD reporting in multi-project orgs." triggers: - "team dashboard" - "validation posture" - "show team metrics" - "which projects need attention" - "who owns this journey" - "validation across all projects" - "quarterly validation review" - "portfolio validation health" context_priority: reference

team-validation-dashboard

Aggregate team validation posture into a shared dashboard. Shows coverage, posture scores, regression trends, and ownership assignments across all registered projects.

Trigger

• "team dashboard", "validation posture", "show team metrics"
• "which projects need attention", "who owns this journey"
• After running /validate-team or requesting an engineering lead summary

Architecture

Scripts live at the ValidationForge repo root under scripts/ — not in the skill directory. Invoke them via bash scripts/<name>.sh from the project root.

<repo-root>/scripts/
├── collect-team-metrics.sh  → .vf/team/snapshot.json
├── team-dashboard.sh        → .vf/team/dashboard.md + terminal table
└── assign-ownership.sh      → .vf/team/ownership.json

Dashboard Columns

Score colors: Green (80–100), Yellow (60–79), Red (0–59).

Why these thresholds

• Why 60 = critical: Below this, more than 40% of the team's posture is regressing or unmeasured — too noisy to act on without intervention. A project here needs a dedicated validation run, not a dashboard note.
• Why 80 = healthy: Matches the CI gate threshold in .vf/config.json (benchmark.min_aggregate: 80). A project ≥ 80 passes the same bar CI would enforce, so no extra attention is warranted.
• 60–79 (yellow): Not broken, but drifting. Review at the next weekly/quarterly cycle before it crosses into critical.

Data Availability Note

The posture_score field is populated from the aggregate.weighted_score in existing /validate-benchmark output. The coverage_pct, regression_count, and journey_count fields require an enriched benchmark format (not yet generated by the current toolset) and will display as 0 for projects validated with the existing tools.

Workflow

Step 1: Collect Metrics

Run the metrics collector to scan all registered projects:

bash scripts/collect-team-metrics.sh

Reads .vf/team/projects.json. Each entry requires name and path. If no registry exists, the script creates a template. Add projects before re-running:

{
  "team": "my-team",
  "projects": [
    { "name": "my-app", "path": "/path/to/my-app" }
  ]
}

Output: .vf/team/snapshot.json with per-project metrics.

Step 2: Render Dashboard

bash scripts/team-dashboard.sh

Options:

• --json — raw snapshot JSON (machine-readable, skips terminal table)
• --html — also write .vf/team/dashboard.html
• --no-collect — skip metrics collection, use cached snapshot
• --team-dir <path> — override default .vf/team directory

Output: color-coded terminal table + .vf/team/dashboard.md

Step 3: Identify Projects Needing Attention

After rendering, report projects by urgency:

Critical (score < 60): Run /validate immediately. Assign owners to failing journeys.

Needs attention (score 60–79): Review failing journeys. Assign owners. Schedule validation.

Healthy (score ≥ 80): No action required. Monitor trend at next benchmark cycle.

Present sorted output:

## Projects Needing Attention

### Critical (< 60)
- **project-alpha** — Score: 42% (F). Last validated: 2026-03-01. 3 regressions.

### Needs Attention (60–79)
- **project-beta** — Score: 68% (D). Last validated: 2026-03-28. 1 regression.

### Healthy (≥ 80)
- **project-gamma** — Score: 91% (A). Last validated: 2026-04-09.

Step 4: Assign Ownership

Use assign-ownership.sh to record who is responsible for each journey:

# Assign a journey to a team member
bash scripts/assign-ownership.sh --project my-app --journey login-flow --owner alice

# List all assignments
bash scripts/assign-ownership.sh --list

# List assignments for one project
bash scripts/assign-ownership.sh --list-project my-app

# Remove an assignment
bash scripts/assign-ownership.sh --remove --project my-app --journey login-flow

Ownership is stored in .vf/team/ownership.json and rendered in the dashboard table.

Data Formats

.vf/team/snapshot.json (written by collect-team-metrics.sh):

{
  "generated_at": "2026-04-10T12:00:00Z",
  "team": "engineering",
  "total_projects": 3,
  "avg_posture_score": 74,
  "projects": [
    { "name": "project-alpha", "path": "/path/to/...", "last_validated": "2026-03-01T09:00:00Z",
      "posture_score": 42, "coverage_pct": 35, "regression_count": 3, "journey_count": 8 }
  ]
}

.vf/team/ownership.json (written by assign-ownership.sh):

{
  "assignments": [
    { "project": "project-alpha", "journey": "login-flow", "owner": "alice",
      "assigned_at": "2026-04-10T12:00:00Z" }
  ]
}

Quick Reference