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.
118 changes: 118 additions & 0 deletions .claude/skills/router-design/output.schema.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,118 @@
{
"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."
}
}
}
85 changes: 85 additions & 0 deletions .claude/skills/router-fetch-docs/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
---
name: router-fetch-docs
description: 'Stage 1: Fetch framework router documentation and extract structured routing concepts as JSON conforming to output.schema.json from an npm package URL.'
---

# Stage 1: Fetch Router Documentation

## Context

You are Stage 1 of the router integration pipeline. Your job is to resolve package metadata, fetch framework router documentation, and extract structured routing concepts as **factual data** for later stages.

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

Do NOT analyze which hooks the SDK should use, recommend approaches, or compare with existing SDK integrations. Only document what the framework provides.

## Input

You receive an **npm package URL** as skill param (e.g. `https://www.npmjs.com/package/vue-router`).

## Process

### 1. Resolve Package Metadata

Use WebFetch on the provided npm URL to extract:

- **Package name** (e.g. `vue-router`, `@angular/router`)
- **Framework identifier** — derive a lowercase identifier from the package name (e.g. `vue-router` → `vue`, `@angular/router` → `angular`, `@tanstack/react-router` → `tanstack-react-router`)
- Homepage / repository URL
- Keywords and description

Then **find router documentation URLs** — from the npm page metadata (homepage, repository links), locate the framework's official routing documentation:

- Check the homepage URL for docs links
- Check the GitHub repository README for documentation links
- Look for `/docs/`, `/guide/`, `/routing` paths on the framework's site
- Collect 1-3 relevant documentation URLs focused on routing

The pipeline creates the artifact directory for you — do not run `mkdir` yourself.

### 2. Fetch Documentation

Before fetching the provided URLs directly, try to find LLM-friendly versions of the docs:

1. **Check for `llms.txt`** — Fetch `<site-root>/llms.txt` (e.g. `https://svelte.dev/llms.txt`). This file indexes markdown documentation pages designed for LLM consumption. If it exists, use it to navigate to the relevant routing pages.
2. **Try `.md` suffix** — For each doc URL, try appending `.md` to the path (e.g. `https://svelte.dev/docs/kit/routing.md`). Many doc sites serve a raw markdown version this way, which is much easier to parse accurately.
3. **Fall back to HTML** — If neither LLM-friendly format is available, fetch the original URLs.

Use the WebFetch tool for all fetches. If a URL fails, note it and continue with remaining URLs. If all URLs fail, stop without emitting a JSON object — the harness will mark the run as an error.

**Prefer over-fetching to under-fetching.** Fetch every routing-related page you can find — API references, guides, tutorials. It is better to fetch a page and not need it than to miss information that a later stage requires. When in doubt, fetch it.

### 3. Extract Router Concepts into the JSON Schema

Analyze the fetched documentation and populate every field in the JSON schema. Use `null` for features the framework does not support.

#### Sourcing Rules

Every leaf field has a sibling `source` field. This is **mandatory** — the schema validation fails without it.

- If extracted from documentation: set `source` to the URL (with anchor if possible)
- If inferred from multiple sources or reasoning: set `source` to `"inferred: <one-line reasoning>"`
- API names, hook names, type names — everything factual must be traceable to a specific doc page

#### JSON Schema

Read `output.schema.json` (next to this SKILL.md) for the schema and field descriptions.

### 4. Compatibility Assessment

A framework is **incompatible** if it lacks:

- A client-side route tree or route matching mechanism
- Dynamic segment parameters
- Navigation lifecycle events that can be hooked into

If incompatible: stop without emitting a JSON object. The harness will mark the run as an error.

A framework is **compatible** even if:

- It uses file-based routing (as long as there's a runtime route representation)
- Some hooks fire later than ideal (trade-off is documented, not a blocker)

## Output

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>/01-router-concepts.json`. Do not write files yourself.
Loading
Loading