oc-dash-forge

# Dash Forge

Dashboard and dense-information UI designer. Takes data (from data-architect handoff, upstream spec, or direct input) and produces:

1. **Design spec** — layout, density, component choices, interaction model, design tokens
2. **Working React prototype** — renderable artifact with mock data, archetype-appropriate viz stack
3. **Handoff packet** — spec + prototype + integration notes for oc-app-architect Phase 6 build

**Scope:** Design and prototype. Not production data wiring, not backend. Prototype uses mock data that looks realistic.

---

## /oc-data-forge — Command Reference

Entry command: `/oc-data-forge` (or aliases `/oc-dash-forge`, `/dashforge`). Sub-commands use `/df-*` prefix.

```
DASH FORGE COMMANDS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Entry: /oc-data-forge  (shows this menu)

  CORE FLOW
  /oc-df-intake      Understand users, decisions, data, density requirements
  /oc-df-archetype   Pick archetype (exec / ops / analyst) with defense
  /oc-df-layout      Information architecture + grid + component inventory
  /oc-df-tokens      Design tokens (color semantics, density scale, type ramp)
  /oc-df-prototype   Build working React prototype with mock data
  /oc-df-spec-only   Skip prototype — produce design spec only
  /oc-df-full        Run all phases end-to-end

  UTILITIES
  /oc-df-audit       Quality checks (density, legibility, chart fit, a11y)
  /oc-df-status      Checkpoint progress
  /oc-df-resume      Resume from last checkpoint
  /df-reset       Archive and restart
  /oc-df-variants    Generate 2-3 layout variants for user to choose

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

### `/oc-df-full` behavior

Runs all phases with one gate:
1. Intake (adaptive — skim upstream context first)
2. Archetype pick (auto-proceed if clear)
3. Layout + tokens (show, proceed)
4. **Gate: "Layout look right? (Y/n or describe changes)"**
5. Prototype build, run `/oc-df-audit` silently
6. Report prototype artifact path + handoff file

User interrupts with "pause" or "change X" to revert to manual control.

### `/oc-df-spec-only` behavior

Skip Phase 3 (prototype). Run phases 0–2, then generate a spec document covering:
- Archetype pick + defense
- Layout + grid + component inventory
- Tokens (color, type, density, spacing)
- Chart selections per tile with rationale
- Interaction spec
- Handoff notes for whoever builds it

Use when the user already has a frontend team and only needs the design, or when iterating on the design before committing to a prototype build.

---

## Parent Skill Integration (Checkpoints)

oc-dash-forge can run standalone OR be invoked by `/oc-ux-engineer` or `/oc-app-architect` mid-flow. In both cases:

### Checkpoint coordination

- oc-dash-forge writes its own `oc-dash-forge.checkpoint.json` to `{project-dir}/.checkpoints/`
- Parent skill's checkpoint adds a `sub_skill_invocations` entry pointing at the oc-dash-forge checkpoint
- `/status` in either skill reads both and surfaces combined progress

### Context inheritance

On invocation, oc-dash-forge inherits:

| From | Read | Use in |
|---|---|---|
| `data-architect-handoff.md` | Schema, top-10 analytics, platform | Phase 0 intake (what data exists) |
| oc-ux-engineer tokens file | Color/type/spacing tokens | Phase 2 (as constraints, specialize inside) |
| oc-app-architect style book | Brand palette, component patterns | Phase 2 (align tokens with app) |
| parent spec.md | User persona, decision context | Phase 0 intake (shortcut) |

### Token handoff out

At end of Phase 2, oc-dash-forge writes `tokens.ts` in the handoff bundle with this format (consumable by oc-ux-engineer):

```ts
export const dashboardTokens = {
  color: {
    neutral: { /* scale */ },
    accent: { primary: "#..." },
    state: { success: "#...", warning: "#...", danger: "#...", info: "#..." },
    series: ["#...", "#...", /* ≤7 colors, colorblind-safe */],
  },
  density: {
    archetype: "exec" | "ops" | "analyst",
    kpiFontSize: number,
    bodyFontSize: number,
    tilePaddingPx: number,
    gutterPx: number,
  },
  type: {
    display: { size: number, weight: number },
    headline: { size: number, weight: number },
    body: { size: number, weight: number },
    caption: { size: number, weight: number },
  },
  chart: {
    // recommended defaults for the archetype
    gridlineColor: string,
    axisLabelColor: string,
    tooltipStyle: object,
  },
};
```

oc-ux-engineer reads this to update its living component library.

---

## When to Use This Skill vs. oc-ux-engineer

| Use oc-dash-forge when | Use oc-ux-engineer when |
|---|---|
| Screen is primarily data display | Screen is primarily forms / workflow / content |
| ≥3 charts or ≥5 KPIs on the same view | General app UI |
| User mentions "dashboard", "BI", "analytics", "report" | User mentions "app", "page", "component library" |
| Dense info needs scannability design | Design system / token work |
| Upstream is data-architect or a data source | Upstream is discovery / spec |

**If both apply** (e.g., a data-heavy feature in a larger app), oc-dash-forge handles the dashboard surface and hands component tokens back to oc-ux-engineer for app-wide consistency.

---

## The 4-Phase Pipeline

```
Phase 0: Intake                (adaptive — skim upstream, ask gaps)
   ↓
Phase 1: Archetype Pick        (exec / ops / analyst, defend)
   ↓
Phase 2: Layout + Tokens       (IA, grid, density, semantic color)
   ↓
Phase 3: React Prototype       (archetype-routed viz stack, mock data)
   ↓
Phase 4: Handoff               (spec + prototype + integration notes)
```

---

## Phase 0: Intake (Adaptive)

Before asking anything, **check for upstream context:**

1. Is there a `data-architect-handoff.md` in the project dir? Read it — schema, analytics top 10, platform are all relevant.
2. Was this called from `/oc-ux-engineer`? Read its design spec / tokens for consistency.
3. Was this called from `/oc-app-architect`? Read the spec + style book.
4. Is there a checkpoint from a p