Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
106 changes: 106 additions & 0 deletions .claude/skills/router-design/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
---
name: router-design
description: 'Stage 2: Analyze reference implementations and produce design decisions from the stage 1 JSON. Reads 01-router-concepts.json and reference code, emits JSON conforming to output.schema.json.'
---

# Stage 2: Design Decisions

## Context

You are Stage 2 of the router integration pipeline. Your job is to read the structured router concepts from Stage 1, analyze the existing reference implementations, and produce explicit design decisions that will guide code generation in Stage 3.

The pipeline invokes you with `claude -p --output-format json --json-schema .claude/skills/router-design/output.schema.json`. Your final message must be a single JSON object conforming to that schema; the harness validates it and writes the CLI wrapper to `docs/integrations/<framework>/02-design-decisions.json` with the payload on `.structured_output`.

## Input

You receive a **framework identifier** as skill param (e.g. `angular`, `vue`, `tanstack-react-router`).

Read:

1. `docs/integrations/<framework>/01-router-concepts.json` — stage 1 CLI wrapper. Extract the router-concepts payload with `jq '.structured_output' <file>`.
2. Reference implementations (to understand SDK patterns):
- Plugin files: `packages/rum-vue/src/domain/vuePlugin.ts`, `packages/rum-react/src/domain/reactPlugin.ts`, `packages/rum-nextjs/src/domain/nextjsPlugin.ts`
- Vue router: `packages/rum-vue/src/domain/router/` (all `.ts` files)
- React router: `packages/rum-react/src/domain/reactRouter/` (all `.ts` files)
- Next.js router: `packages/rum-nextjs/src/domain/nextJSRouter/` (all `.ts` files)
- Entry points: `packages/rum-vue/src/entries/main.ts`, `packages/rum-react/src/entries/main.ts`, `packages/rum-nextjs/src/entries/main.ts`
- Package configs: `packages/rum-vue/package.json`, `packages/rum-react/package.json`, `packages/rum-nextjs/package.json`
- Plugin interface: `packages/rum-core/src/domain/plugins.ts`

## Process

### 1. Hook Selection (Deterministic)

Apply these priority rules to the `hooks` array from `01-router-concepts.json`.

**The integration must be client-side only.** Only consider hooks that fire on the client. Use the `access` field and `ssr` section from `01-router-concepts.json` to determine this.

**Priority rules (in order):**

1. `afterCancellation: true` — **required**. Never start a RUM view for a navigation that didn't occur.
2. `afterRedirects: true` — **prefer**. Report the final destination, not intermediate routes.
3. `afterFetch: false` AND `afterRender: false` — **prefer**. Start the view before data loading and DOM mutation so RUM events (fetch resources, long tasks, interactions) are attributed to the new view, not the previous one.

Apply in order:

- Filter to `afterCancellation: true`. If no hooks pass, flag as critical issue and stop.
- Among those, prefer `afterRedirects: true`.
- Among those, prefer `afterFetch: false` AND `afterRender: false`.
- If rules conflict (no hook satisfies all), higher-priority rule wins.
- If multiple hooks still tie, prefer the one that fires earliest in the lifecycle.

Document which hooks were considered, which rules each passed/failed, and why the selected hook won.

### 2. Wrapping Strategy (LLM Judgment)

Read the selected hook's `access` field from `01-router-concepts.json`. Determine the most idiomatic way for users to integrate the plugin in this framework.

Consider:

- How existing plugins/libraries are typically added in this framework's ecosystem
- Whether the hook needs a router instance (→ wrap the factory that creates it)
- Whether the hook needs component context (→ renderless component or hook)
- Whether the hook needs DI (→ provider registration)

Reference patterns from existing implementations:

- Vue: wraps `createRouter()` factory to get router instance for `afterEach`
- React: wraps `createBrowserRouter()` factory OR wraps `useRoutes()` hook
- Angular: provider with `inject(Router)` for `router.events` observable

### 3. View Name Algorithm (LLM Classification)

Read the selected hook's `availableApi` from `01-router-concepts.json`. Classify into one of three families (in preference order):

- **`route-id`** — Framework provides the parameterized route pattern as a string. Minimal post-processing needed (e.g. strip route groups). Example: SvelteKit `route.id`.
- **`matched-records`** — Framework provides matched route records (array or tree). Iterate and concatenate path segments. Handle catch-all substitution. Example: Vue `to.matched[]`, React `state.matches[]`.
- **`param-substitution`** — Framework provides only the evaluated pathname + params object. Must reconstruct the route template by substituting values back with placeholders. Least preferred — heuristic and fragile. Example: Next.js `useParams()` + `usePathname()`.

### 4. Target Package (LLM Judgment)

Determine whether this router needs a new package or extends an existing one.

- **`new-package`** — The router belongs to a framework with no existing SDK package (e.g., SvelteKit, Angular). Create `packages/rum-<framework>/`.
- **`extend-existing`** — The router is an alternative router for a framework that already has an SDK package (e.g., TanStack Router is a React router → extends `rum-react`). Add files under a subdirectory within the existing package.

To decide: check if `packages/rum-*` already has a package for the same UI framework (React, Vue, etc.). If yes, extend it. If no, create new.

For extend-existing, also determine the subdirectory path for the new router files (e.g., `src/domain/tanstackRouter/`).

### 5. Reference Implementation

Select the `packages/rum-*` implementation that is closest across:

- Hook subscription pattern
- Wrapping strategy
- Algorithm family

Stage 3 reads this implementation as its primary model for code generation.

### 6. SSR Handling (LLM Judgment)

If `ssr.supported: true` in `01-router-concepts.json`, describe how the integration should ensure client-side-only execution. Use the `clientDetection` API from Stage 1 if available.

## Output Schema

Return the populated object as your final message. The pipeline invokes you with `--output-format json --json-schema output.schema.json`; the harness validates the object and writes the full CLI wrapper (with the object on `.structured_output`) to `docs/integrations/<framework>/02-design-decisions.json`. Do not write files yourself.
111 changes: 111 additions & 0 deletions .claude/skills/router-design/output.schema.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,111 @@
{
"title": "DesignDecisions",
"description": "Explicit design decisions derived from Stage 1 router concepts and reference implementations, used by Stage 3 to generate code.",
"type": "object",
"additionalProperties": false,
"required": ["selectedHook", "wrappingStrategy", "viewNameAlgorithm", "targetPackage", "referenceImplementation", "ssr"],
"properties": {
"selectedHook": {
"type": "object",
"additionalProperties": false,
"required": ["name", "rationale"],
"properties": {
"name": {
"type": "string",
"description": "Hook name from 01-router-concepts.json, selected by the deterministic priority rules."
},
"rationale": {
"type": "string",
"description": "Which rules each candidate passed/failed and why the selected hook won."
}
}
},
"wrappingStrategy": {
"type": "object",
"additionalProperties": false,
"required": ["pattern", "target", "rationale"],
"properties": {
"pattern": {
"enum": ["wrap-factory", "renderless-component", "provider", "wrap-hook", "other"],
"description": "wrap-factory: Wrap the router creation function, subscribe to hook inside. renderless-component: Component that calls the hook during lifecycle. provider: DI provider that injects the router and subscribes to events. wrap-hook: Wrap a user-facing hook to intercept route data. other: Escape hatch for unknown patterns."
},
"target": {
"type": "string",
"description": "What specifically to wrap/provide. E.g. 'createRouter from vue-router', 'ENVIRONMENT_INITIALIZER with inject(Router)'."
},
"rationale": {
"type": "string",
"description": "Why this is idiomatic for the framework."
}
}
},
"viewNameAlgorithm": {
"type": "object",
"additionalProperties": false,
"required": ["family", "rationale"],
"properties": {
"family": {
"enum": ["route-id", "matched-records", "param-substitution"],
"description": "route-id: Framework provides parameterized route pattern as string. Minimal post-processing. matched-records: Framework provides matched route records. Iterate and concatenate path segments. param-substitution: Framework provides evaluated pathname + params. Reconstruct route template. Least preferred."
},
"rationale": {
"type": "string",
"description": "Why this family, based on the hook's availableApi."
}
}
},
"targetPackage": {
"type": "object",
"additionalProperties": false,
"required": ["mode", "package"],
"properties": {
"mode": {
"enum": ["new-package", "extend-existing"],
"description": "new-package: Create a new packages/rum-<framework>/ from scratch. extend-existing: Add router support to an existing package (e.g. adding TanStack Router to rum-react)."
},
"package": {
"type": "string",
"description": "Target package directory name. For new-package: 'rum-<framework>'. For extend-existing: the existing package (e.g. 'rum-react')."
},
"subpath": {
"type": "string",
"description": "Only for extend-existing. The subdirectory for this router's files within the existing package. E.g. 'src/domain/tanstackRouter/' within packages/rum-react/."
}
}
},
"referenceImplementation": {
"type": "object",
"additionalProperties": false,
"required": ["primary", "rationale"],
"properties": {
"primary": {
"type": "string",
"description": "Which packages/rum-* to model after (e.g. 'rum-vue'). Stage 3 reads this implementation as its primary source for code patterns."
},
"rationale": {
"type": "string",
"description": "Why this is the closest match."
}
}
},
"ssr": {
"type": "object",
"additionalProperties": false,
"required": ["handling"],
"properties": {
"handling": {
"type": "string",
"description": "How to ensure client-side-only execution. 'N/A' if ssr.supported is false in Stage 1."
}
}
},
"notes": {
"type": "string",
"description": "Free text for additional design context, trade-offs, unmapped concepts, or anything Stage 3 needs to know."
},
"exitReason": {
"type": "string",
"description": "Only set if Stage 2 cannot proceed (e.g., no hook satisfies afterCancellation: true). When set, all other fields may be empty stubs and the pipeline will stop."
}
}
}
140 changes: 140 additions & 0 deletions .claude/skills/router-experiment/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,140 @@
---
name: router-experiment
description: Run the router pipeline N times in parallel worktrees for the same framework to measure output consistency. Usage: /router-experiment <npm-package-url> [runs=3]
---

# Router Pipeline Consistency Experiment

You run the router pipeline multiple times in parallel (each in its own git worktree) for the same npm package, then diff the outputs to measure consistency. Each run creates its own draft PR with a unique branch suffix.

## Input

- **Arg 1** (required): npm package URL (e.g. `https://www.npmjs.com/package/vue-router`)
- **Arg 2** (optional): number of parallel runs (default: 3)

## Step 1: Setup

```bash
RUNS=<N> # default 3
EXPERIMENT_DIR="/tmp/router-experiment-$(date +%s)"
mkdir -p "$EXPERIMENT_DIR"
```

Create worktrees from main:

```bash
for i in $(seq 1 $RUNS); do
git worktree add "$EXPERIMENT_DIR/run-$i" main
done
```

## Step 2: Launch Parallel Runs

Each run invokes `/router-pipeline` (stages 1–4) in its own worktree. Branch collisions are handled inside `/router-pr`, which appends a random suffix to the branch name.

```bash
NPM_URL="<npm-url>"

for i in $(seq 1 $RUNS); do
(
cd "$EXPERIMENT_DIR/run-$i"
claude -p "/router-pipeline $NPM_URL" \
--model opus \
--allowedTools "Skill,Read,Write,Edit,Glob,Grep,Bash,WebFetch,WebSearch,Agent"
) > "$EXPERIMENT_DIR/run-$i.log" 2>&1 &
done

wait
```

Run via Bash with a generous timeout (up to 10 minutes). Use `run_in_background: true` so you can monitor progress.

## Step 3: Compare Outputs

### 3a. Discover framework name

```bash
FRAMEWORK=$(basename $(dirname $(ls "$EXPERIMENT_DIR"/run-1/docs/integrations/*/01-router-concepts.json)))
```

### 3b. Diff artifacts

The stage 1/2 artifacts are full `claude -p` wrappers — they include `duration_ms`, `session_id`, `total_cost_usd`, etc. that vary run-to-run. Diff the `structured_output` only, normalized with `jq -S`:

```bash
for artifact in 01-router-concepts.json 02-design-decisions.json; do
echo "=== $artifact (structured_output) ==="
for i in $(seq 2 $RUNS); do
echo "--- run-1 vs run-$i ---"
diff -u \
<(jq -S '.structured_output' "$EXPERIMENT_DIR/run-1/docs/integrations/$FRAMEWORK/$artifact") \
<(jq -S '.structured_output' "$EXPERIMENT_DIR/run-$i/docs/integrations/$FRAMEWORK/$artifact") || true
done
done

# Cost / duration / turns side-by-side
echo "=== cost & duration ==="
for i in $(seq 1 $RUNS); do
for artifact in 01-router-concepts.json 02-design-decisions.json; do
jq -r --arg run "run-$i" --arg art "$artifact" \
'[$run, $art, .duration_ms, .num_turns, .total_cost_usd] | @tsv' \
"$EXPERIMENT_DIR/run-$i/docs/integrations/$FRAMEWORK/$artifact"
done
done | column -t

echo "=== 03-generation-manifest.md ==="
for i in $(seq 2 $RUNS); do
echo "--- run-1 vs run-$i ---"
diff -u "$EXPERIMENT_DIR/run-1/docs/integrations/$FRAMEWORK/03-generation-manifest.md" \
"$EXPERIMENT_DIR/run-$i/docs/integrations/$FRAMEWORK/03-generation-manifest.md" || true
done
```

### 3c. Diff generated source code

```bash
echo "=== Source code ==="
for i in $(seq 2 $RUNS); do
echo "--- run-1 vs run-$i ---"
diff -rq "$EXPERIMENT_DIR/run-1/packages/" "$EXPERIMENT_DIR/run-$i/packages/" || true
done
```

For files that differ, show the actual diff:

```bash
for i in $(seq 2 $RUNS); do
diff -ru "$EXPERIMENT_DIR/run-1/packages/" "$EXPERIMENT_DIR/run-$i/packages/" || true
done
```

## Step 4: Report

Present a summary table:

```
## Experiment Results: <framework> (N=<RUNS>)

| Artifact | Identical? | Diff lines |
|---------------------------|------------|------------|
| 01-router-concepts.json | ✅ / ❌ | <count> |
| 02-design-decisions.json | ✅ / ❌ | <count> |
| 03-generation-manifest.md | ✅ / ❌ | <count> |
| Generated source code | ✅ / ❌ | <count> |

### Observations
<Summarize what varied and what stayed consistent. Note any semantic vs cosmetic differences.>
```

If any diffs exist, show the most interesting ones inline (truncated if large).

## Step 5: Cleanup

Remove the worktrees:

```bash
for i in $(seq 1 $RUNS); do
git worktree remove "$EXPERIMENT_DIR/run-$i" --force
done
rm -rf "$EXPERIMENT_DIR"
```
Loading
Loading