{"owner":"rivet-dev","repo":"rivet","hasSkills":true,"totalSkillsCount":208,"totalTokensCount":82474,"categories":["anthropic-skill","root-instruction","claude-rule","subagent-persona","command-prompt","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"rivet":{"command":"npx","args":["-y","@modelcontextprotocol/server-rivet"]}}},"found":[".claude/skills/creating-docs-diagrams/SKILL.md",".claude/skills/sanity-check/SKILL.md",".claude/skills/stack-merge/SKILL.md",".claude/skills/driver-test-runner/SKILL.md",".claude/skills/create-launch-post/SKILL.md",".opencode/skills/openspec-ff-change/SKILL.md",".opencode/skills/openspec-archive-change/SKILL.md",".opencode/skills/openspec-continue-change/SKILL.md",".opencode/skills/graphite-is-being-a-piece-of-shit-just-merge-my-stack/SKILL.md",".opencode/skills/openspec-explore/SKILL.md",".opencode/skills/openspec-bulk-archive-change/SKILL.md",".opencode/skills/openspec-apply-change/SKILL.md",".opencode/skills/openspec-new-change/SKILL.md",".opencode/skills/openspec-onboard/SKILL.md",".opencode/skills/openspec-sync-specs/SKILL.md",".opencode/skills/openspec-verify-change/SKILL.md","AGENTS.md","CLAUDE.md","docs/AGENTS.md","docs/CLAUDE.md","engine/AGENTS.md","engine/CLAUDE.md","examples/AGENTS.md","examples/CLAUDE.md","frontend/AGENTS.md","frontend/CLAUDE.md","rivetkit-rust/AGENTS.md","rivetkit-rust/CLAUDE.md","rivetkit-swift/AGENTS.md","rivetkit-swift/CLAUDE.md","rivetkit-typescript/AGENTS.md","rivetkit-typescript/CLAUDE.md",".claude/agents/js-error-handler-auditor.md",".claude/agents/rivetkit-driver-test-writer.md",".claude/commands/release.md",".claude/commands/opsx/apply.md",".claude/commands/opsx/archive.md",".claude/commands/opsx/bulk-archive.md",".claude/commands/opsx/continue.md",".claude/commands/opsx/explore.md",".claude/commands/opsx/ff.md",".claude/commands/opsx/new.md",".claude/commands/opsx/onboard.md",".claude/commands/opsx/sync.md",".claude/commands/opsx/verify.md","engine/packages/depot-client/AGENTS.md","engine/packages/depot-client/CLAUDE.md","engine/packages/depot/AGENTS.md","engine/packages/depot/CLAUDE.md","engine/packages/depot/README.md","engine/packages/depot/TODO.md","engine/packages/epoxy/README.md","engine/packages/guard/AGENTS.md","engine/packages/guard/CLAUDE.md","engine/packages/telemetry/README.md","engine/packages/term/LICENSE.md","engine/packages/term/README.md","engine/packages/types/README.md","frontend/packages/components/components.json","frontend/packages/components/package.json","frontend/packages/components/tsconfig.json","frontend/packages/components/turbo.json","frontend/packages/icons/AGENTS.md","frontend/packages/icons/CLAUDE.md","frontend/packages/icons/README.md","frontend/packages/icons/manifest.json","frontend/packages/icons/package.json","frontend/packages/shared-data/package.json","rivetkit-rust/packages/client/README.md","rivetkit-rust/packages/rivetkit-core/AGENTS.md","rivetkit-rust/packages/rivetkit-core/CLAUDE.md","rivetkit-rust/packages/rivetkit/AGENTS.md","rivetkit-rust/packages/rivetkit/CLAUDE.md","rivetkit-typescript/packages/cli/README.md","rivetkit-typescript/packages/cli/package.json","rivetkit-typescript/packages/cloudflare-workers/README.md","rivetkit-typescript/packages/cloudflare-workers/package.json","rivetkit-typescript/packages/cloudflare-workers/tsconfig.json","rivetkit-typescript/packages/cloudflare-workers/turbo.json","rivetkit-typescript/packages/devtools/README.md","rivetkit-typescript/packages/devtools/package.json","rivetkit-typescript/packages/devtools/tsconfig.json","rivetkit-typescript/packages/devtools/turbo.json","rivetkit-typescript/packages/effect/package.json","rivetkit-typescript/packages/effect/tsconfig.build.json","rivetkit-typescript/packages/effect/tsconfig.json","rivetkit-typescript/packages/effect/turbo.json","rivetkit-typescript/packages/engine-cli/README.md","rivetkit-typescript/packages/engine-cli/package.json","rivetkit-typescript/packages/engine-runner-protocol/package.json","rivetkit-typescript/packages/engine-runner-protocol/tsconfig.json","rivetkit-typescript/packages/engine-runner-protocol/turbo.json","rivetkit-typescript/packages/engine-runner/package.json","rivetkit-typescript/packages/engine-runner/tsconfig.json","rivetkit-typescript/packages/engine-runner/turbo.json","rivetkit-typescript/packages/framework-base/package.json","rivetkit-typescript/packages/framework-base/tsconfig.build.json","rivetkit-typescript/packages/framework-base/tsconfig.json","rivetkit-typescript/packages/framework-base/turbo.json","rivetkit-typescript/packages/mcp-hub/README.md","rivetkit-typescript/packages/mcp-hub/package.docker.json","rivetkit-typescript/packages/mcp-hub/package.json","rivetkit-typescript/packages/mcp-hub/tsconfig.docker.json","rivetkit-typescript/packages/mcp-hub/tsconfig.json","rivetkit-typescript/packages/next-js/README.md","rivetkit-typescript/packages/next-js/package.json","rivetkit-typescript/packages/next-js/tsconfig.json","rivetkit-typescript/packages/next-js/turbo.json","rivetkit-typescript/packages/react/package.json","rivetkit-typescript/packages/react/tsconfig.json","rivetkit-typescript/packages/react/turbo.json","rivetkit-typescript/packages/rivetkit-napi/package-lock.json","rivetkit-typescript/packages/rivetkit-napi/package.json","rivetkit-typescript/packages/rivetkit-napi/turbo.json","rivetkit-typescript/packages/rivetkit-wasm/package.json","rivetkit-typescript/packages/rivetkit-wasm/tsconfig.json","rivetkit-typescript/packages/rivetkit-wasm/turbo.json","rivetkit-typescript/packages/rivetkit/README.md","rivetkit-typescript/packages/rivetkit/package.json","rivetkit-typescript/packages/rivetkit/tsconfig.drizzle-compat.json","rivetkit-typescript/packages/rivetkit/tsconfig.json","rivetkit-typescript/packages/rivetkit/turbo.json","rivetkit-typescript/packages/sql-loader/README.md","rivetkit-typescript/packages/sql-loader/package.json","rivetkit-typescript/packages/sql-loader/tsconfig.json","rivetkit-typescript/packages/sql-loader/turbo.json","rivetkit-typescript/packages/supabase/.size-limit.json","rivetkit-typescript/packages/supabase/README.md","rivetkit-typescript/packages/supabase/package.json","rivetkit-typescript/packages/supabase/tsconfig.json","rivetkit-typescript/packages/supabase/turbo.json","rivetkit-typescript/packages/traces/package.json","rivetkit-typescript/packages/traces/tsconfig.json","rivetkit-typescript/packages/traces/turbo.json","rivetkit-typescript/packages/workflow-engine/AGENTS.md","rivetkit-typescript/packages/workflow-engine/CLAUDE.md","rivetkit-typescript/packages/workflow-engine/QUICKSTART.md","rivetkit-typescript/packages/workflow-engine/TODO.md","rivetkit-typescript/packages/workflow-engine/architecture.md","rivetkit-typescript/packages/workflow-engine/package.json","rivetkit-typescript/packages/workflow-engine/tsconfig.json",".claude/skills/create-launch-post/agents/openai.yaml",".claude/skills/create-launch-post/scripts/render-launch-images.ts",".claude/skills/create-launch-post/scripts/render-technical-image.ts",".claude/skills/create-launch-post/scripts/render-tile-images.ts",".claude/skills/stack-merge/references/gotchas.md",".claude/skills/stack-merge/references/phases.md",".claude/skills/stack-merge/scripts/detect_ralph.sh",".claude/skills/stack-merge/scripts/exec_merge.sh",".claude/skills/stack-merge/scripts/list_merge_path.sh",".claude/skills/stack-merge/scripts/validate.sh","engine/packages/depot/scripts/README.md","frontend/docs/testing/references/actor-states.md","frontend/docs/testing/references/connection-states.md","frontend/docs/testing/references/error-states.md","frontend/docs/testing/references/integration-form.md","frontend/docs/testing/references/onboarding-states.md","frontend/docs/testing/references/ui-components.md","rivetkit-rust/packages/rivetkit-core/inspector-dist/README.md","rivetkit-typescript/packages/workflow-engine/docs/advanced.md","rivetkit-typescript/packages/workflow-engine/docs/cancellation.md","rivetkit-typescript/packages/workflow-engine/docs/control-flow.md","rivetkit-typescript/packages/workflow-engine/docs/high-performance-workflows.md","rivetkit-typescript/packages/workflow-engine/docs/long-running-workflows.md","rivetkit-typescript/packages/workflow-engine/docs/migrating-workflows.md","rivetkit-typescript/packages/workflow-engine/docs/retries.md","rivetkit-typescript/packages/workflow-engine/docs/rollback-behavior.md","rivetkit-typescript/packages/workflow-engine/docs/state.md","rivetkit-typescript/packages/workflow-engine/docs/waiting-for-events-and-human-in-the-loop.md","scripts/skill-evals/evals/js-counter/judge.md","scripts/skill-evals/evals/js-counter/prompt.md","scripts/skill-evals/evals/react-chat/judge.md","scripts/skill-evals/evals/react-chat/prompt.md","scripts/skill-evals/evals/react-counter/judge.md","scripts/skill-evals/evals/react-counter/prompt.md",".claude/skills/create-launch-post/assets/logos/sqlite.svg","engine/packages/test-snapshot-gen/snapshots/epoxy-v1/metadata.json","engine/packages/test-snapshot-gen/snapshots/pb-actor-v1-pre-migration/metadata.json","rivetkit-typescript/packages/cli/npm/darwin-arm64/package.json","rivetkit-typescript/packages/cli/npm/darwin-x64/package.json","rivetkit-typescript/packages/cli/npm/linux-arm64-musl/package.json","rivetkit-typescript/packages/cli/npm/linux-x64-musl/package.json","rivetkit-typescript/packages/cli/npm/win32-x64/package.json","rivetkit-typescript/packages/engine-cli/npm/darwin-arm64/package.json","rivetkit-typescript/packages/engine-cli/npm/darwin-x64/package.json","rivetkit-typescript/packages/engine-cli/npm/linux-arm64-musl/package.json","rivetkit-typescript/packages/engine-cli/npm/linux-x64-musl/package.json","rivetkit-typescript/packages/engine-cli/npm/win32-x64/package.json","rivetkit-typescript/packages/rivetkit-napi/npm/darwin-arm64/README.md","rivetkit-typescript/packages/rivetkit-napi/npm/darwin-arm64/package.json","rivetkit-typescript/packages/rivetkit-napi/npm/darwin-x64/README.md","rivetkit-typescript/packages/rivetkit-napi/npm/darwin-x64/package.json","rivetkit-typescript/packages/rivetkit-napi/npm/linux-arm64-gnu/README.md","rivetkit-typescript/packages/rivetkit-napi/npm/linux-arm64-gnu/package.json","rivetkit-typescript/packages/rivetkit-napi/npm/linux-arm64-musl/README.md","rivetkit-typescript/packages/rivetkit-napi/npm/linux-arm64-musl/package.json","rivetkit-typescript/packages/rivetkit-napi/npm/linux-x64-gnu/README.md","rivetkit-typescript/packages/rivetkit-napi/npm/linux-x64-gnu/package.json","rivetkit-typescript/packages/rivetkit-napi/npm/linux-x64-musl/README.md","rivetkit-typescript/packages/rivetkit-napi/npm/linux-x64-musl/package.json","rivetkit-typescript/packages/rivetkit-napi/npm/win32-x64-msvc/README.md","rivetkit-typescript/packages/rivetkit-napi/npm/win32-x64-msvc/package.json","rivetkit-typescript/packages/rivetkit/tests/platforms/AGENTS.md","rivetkit-typescript/packages/rivetkit/tests/platforms/CLAUDE.md","engine/packages/depot-client/tests/inline/fault/AGENTS.md","engine/packages/depot-client/tests/inline/fault/CLAUDE.md","engine/packages/guard-core/tests/fixtures/tls/README.md","rivetkit-rust/packages/rivetkit-core/tests/migration/v2_2_1/snapshot/metadata.json"],"skills":{".claude/skills/creating-docs-diagrams/SKILL.md":"---\nname: creating-docs-diagrams\ndescription: \"Creates accessible hand-authored inline SVG architecture and sequence diagrams for documentation. Use when adding, replacing, or reviewing docs diagrams, especially Mermaid flowcharts.\"\n---\n\n# Creating Docs Diagrams\n\nCreate literal, responsive raw SVG that fits Rivet's self-hosted perimeter aesthetic.\n\n## Scope\n\n- Apply raw SVG conversion only to documentation pages under `website/src/content/docs/**/*.mdx`.\n- Keep every diagram under `website/src/content/cookbook/**` as Mermaid. Do not convert cookbook Mermaid to raw SVG, including during a repository-wide diagram cleanup.\n- Treat posts, changelog entries, and other content trees as out of scope unless the user explicitly names them.\n\n## Workflow\n\n1. Inventory Mermaid before editing with `rg -n '```mermaid' website/src/content/docs` and record every node, boundary, edge direction, edge label, and line break. Do not broaden this search into cookbooks or posts for conversion work.\n2. Choose an **architecture pattern** for topology and nested deployment boundaries, or a **sequence pattern** for time-ordered messages between participants.\n3. Replace each block with literal inline `...`. Do not use Mermaid, scripts, imported components, external SVGs, or image assets.\n4. Preserve every semantic detail. Keep `<-->` bidirectional with markers at both ends, `-->` directional, nested boundaries intact, and explicit `` lines for labels that used `
`.\n5. Give every SVG `role=\"img\"` and a concise but complete `aria-label`. Give marker IDs unique, descriptive names per page and SVG.\n6. Start the website preview and screenshot every changed diagram at a desktop viewport and at 390 CSS pixels. In Playwright, pass `viewport`, not `viewportSize`, and assert `window.innerWidth` before trusting a mobile capture. Activate every tab so hidden diagrams are also captured.\n7. Keep sticky site chrome out of element screenshots by scrolling the target below it or hiding the chrome only for the capture. For a horizontally scrollable diagram, capture the full diagram at desktop plus its left and right scroll extents at 390px; record `clientWidth` and `scrollWidth` to confirm the screenshots exercise real overflow.\n8. Inspect screenshot pixels, not only DOM bounds. Reject excessive dead space, unnecessarily long arrows, text touching a line, paths crossing unrelated nodes, clipped labels, or inconsistent node styling. Fix and recapture until every diagram passes.\n9. Run `rg -n '```mermaid|foreignObject|` as appropriate, then run Astro or the website build validation.\n\n## Visual contract\n\n- Derive the canvas width from its content. Do not default every diagram to 760px. As a starting range, use 480-560px for two participants, 600-700px for three, 700-800px for four, and only exceed 800px when labels demonstrably require it.\n- Keep participants close enough that arrows communicate a relationship instead of becoming long horizontal rules. A two-participant sequence must not place its lifelines at opposite edges of a 760px canvas.\n- Outer SVG: `style=\"width:100%;max-width:px;height:auto;display:block;margin:2.5rem auto;font-family:system-ui,sans-serif\"` with a `viewBox` matching that natural width.\n- Simple diagrams may scale fluidly when labels remain readable. Detail-dense diagrams may use `
px\">...
`, but the minimum width must equal the diagram's compact natural width, not a shared global width.\n- Deployment and machine boundaries: dashed pine `#2E4034`, `#faf8f3` fill, rounded corners, and uppercase mono labels.\n- Nodes: `#ffffff`, warm-black `#1b1916` 1.3 to 1.4px hairlines, and `rx=\"7\"`. Highlight the key runtime or storage node with pale pine `#e7ece7`.\n- Text: warm-black primary labels and `#56524a` or `#8a8578` secondary labels. Use `system-ui,sans-serif`; use `ui-monospace,monospace` for boundary labels.\n- Arrows: warm-black or pine, 1.4px. Route paths around nodes and minimize crossings. Place an opaque porcelain mask behind any label that intersects an arrow or lifeline.\n- At 390px, preserve readable labels without forcing users to scroll through avoidable empty space. Horizontal scrolling is a fallback for real density, not a substitute for laying out a compact diagram.\n- Avoid bright Mermaid colors, CSS classes, `foreignObject`, gradients, shadows, JavaScript, and external assets.\n\n## Compact patterns\n\nArchitecture topology:\n\n```svg\n\n \n \n YOUR INFRASTRUCTURE\n \n \n \n\n```\n\nSequence diagrams use participant boxes across the top, dashed vertical lifelines, and horizontal directional message arrows in chronological order from top to bottom. Put each message label immediately above its arrow, for example:\n\n```svg\n
\n
\n\n \n \n \n \n \n \n request\n response\n\n
\n
\n```\n",".claude/skills/sanity-check/SKILL.md":"---\nname: sanity-check\ndescription: Run an E2E smoke test that installs rivetkit packages from npm in an isolated temp project, starts the hello-world counter actor, then verifies both HTTP actions and WebSocket actions + events work end-to-end. Use when the user asks to sanity check, smoke test, or verify a rivetkit release/preview-publish works.\n---\n\n# Sanity Check\n\nRun a quick end-to-end sanity check of a published rivetkit version: copy the hello-world example to a temp directory, install the specified package version from the public npm registry, start the dev server, and run a client test script that verifies both HTTP actions and WebSocket connections with event broadcasting.\n\n## When to use\n- User wants to verify a published rivetkit version works (e.g., `rivetkit@0.0.0-pr.4701.a818b77`, `rivetkit@latest`, `rivetkit@2.5.0`)\n- After a preview publish to verify the build is functional\n- After a release to verify the package installs and runs correctly\n- User says \"sanity check\", \"smoke test\", \"verify the build\", or \"test this version\"\n\n## Inputs\n1. **Version or tag** (required) — explicit pkg-pr-new preview, npm dist-tag, or semver. If not provided in the user's message, ask for it.\n2. **Additional test behavior** (optional) — e.g., \"also verify workflows persist\" or \"check that KV works.\" If provided, extend `src/index.ts` + `test.mjs` using the menu in \"Extending with custom tests\" below.\n\n## Usage\n- `/sanity-check ` — run in a temp directory on the host\n- `/sanity-check docker ` — run inside a `node:22` Docker container\n- `/sanity-check ` — any extra instructions (e.g. \"also hit a KV action\", \"verify state persists across restart\", \"use pnpm\", \"test on node 20\")\n\n`` is any npm-resolvable spec: an explicit pkg-pr-new preview (`0.0.0-pr.4701.a818b77`), an npm dist-tag (`latest`, `rc`, `next`), or a semver (`2.3.0-rc.4`). If the user omits it, ask for it.\n\n## What it tests\n\n1. `npm install` of `rivetkit`, `@rivetkit/react`, and the platform-specific `@rivetkit/rivetkit-napi-*` native binding from the public npm registry\n2. Boot the hello-world counter actor server via `registry.start()` on port 6420\n3. **HTTP path**: call `counter.increment(5)`, `counter.increment(3)`, `counter.getCount()` and assert the values\n4. **WebSocket path**: open a `.connect()` conn, subscribe to the `newCount` event, call `increment(10)`, assert the action response AND the broadcast event value match\n5. Report the resolved versions of `rivetkit` + `@rivetkit/rivetkit-napi`\n\n## Requirements\n\n- Node.js 22+ (or Docker with `node:22`)\n- This repo available locally — only used to copy `examples/hello-world/src/` as the seed. Does NOT use any of its `node_modules` or workspace links.\n\n## Steps\n\n### 1. Set up the test project\n\n```bash\nREPO_ROOT=$(git rev-parse --show-toplevel)\nSANITY_DIR=$(mktemp -d /tmp/rivetkit-sanity-XXXXXX)\ncp -r \"$REPO_ROOT/examples/hello-world/src\" \"$REPO_ROOT/examples/hello-world/tsconfig.json\" \"$SANITY_DIR/\"\ncd \"$SANITY_DIR\"\n```\n\nWrite `package.json` with `` substituted:\n\n```json\n{\n \"name\": \"rivetkit-sanity\",\n \"private\": true,\n \"type\": \"module\",\n \"dependencies\": {\n \"rivetkit\": \"\",\n \"@rivetkit/react\": \"\"\n },\n \"devDependencies\": {\n \"tsx\": \"^4\",\n \"typescript\": \"^5\"\n }\n}\n```\n\nFor pkg-pr-new previews, `` can be the bare version string (`0.0.0-pr.4701.a818b77`) — npm resolves it directly. If that fails, fall back to the URL form: `\"rivetkit\": \"https://pkg.pr.new/rivet-dev/rivet/rivetkit@\"`.\n\n### 2. Write `test.mjs`\n\n```js\nimport { createClient } from \"rivetkit/client\";\nimport { spawn } from \"node:child_process\";\n\nconst ENDPOINT = \"http://localhost:6420\";\n\nconsole.log(\"Starting counter actor server...\");\nconst server = spawn(\"npx\", [\"tsx\", \"src/index.ts\"], {\n stdio: [\"ignore\", \"pipe\", \"pipe\"],\n});\nlet log = \"\";\nserver.stdout.on(\"data\", (d) => (log += d));\nserver.stderr.on(\"data\", (d) => (log += d));\n\nasync function waitForServer(timeoutMs = 30000) {\n const deadline = Date.now() + timeoutMs;\n while (Date.now() < deadline) {\n try {\n const r = await fetch(`${ENDPOINT}/health`);\n if (r.ok) return;\n } catch {}\n await new Promise((r) => setTimeout(r, 500));\n }\n console.error(\"--- server log ---\\n\" + log);\n throw new Error(\"server did not become ready\");\n}\n\nlet exitCode = 0;\ntry {\n await waitForServer();\n const client = createClient(ENDPOINT);\n\n // --- HTTP actions ---\n console.log(\"Testing HTTP actions...\");\n const counter = client.counter.getOrCreate([\"sanity\"]);\n const a = await counter.increment(5);\n const b = await counter.increment(3);\n const c = await counter.getCount();\n if (a !== 5) throw new Error(`increment(5) => ${a}, expected 5`);\n if (b !== 8) throw new Error(`increment(3) => ${b}, expected 8`);\n if (c !== 8) throw new Error(`getCount() => ${c}, expected 8`);\n console.log(` HTTP: increment(5)=${a}, increment(3)=${b}, getCount()=${c}`);\n\n // --- WebSocket actions + events ---\n console.log(\"Testing WebSocket + events...\");\n const ws = client.counter.getOrCreate([\"sanity-ws\"]).connect();\n await new Promise((res, rej) => {\n const t = setTimeout(() => rej(new Error(\"ws open timeout\")), 10000);\n ws.onOpen(() => {\n clearTimeout(t);\n res();\n });\n ws.onError(rej);\n });\n const eventPromise = new Promise((res, rej) => {\n const t = setTimeout(() => rej(new Error(\"newCount event timeout\")), 5000);\n ws.on(\"newCount\", (v) => {\n clearTimeout(t);\n res(v);\n });\n });\n const wsCount = await ws.increment(10);\n const eventValue = await eventPromise;\n if (wsCount !== 10) throw new Error(`ws increment(10) => ${wsCount}, expected 10`);\n if (eventValue !== 10) throw new Error(`newCount event => ${eventValue}, expected 10`);\n console.log(` WS: increment(10)=${wsCount}, event=${eventValue}`);\n await ws.dispose();\n\n console.log(\"\\n✅ E2E TEST PASSED\");\n} catch (err) {\n console.error(`\\n❌ E2E TEST FAILED: ${err.message || err}`);\n console.error(\"--- server log (last 2KB) ---\\n\" + log.slice(-2000));\n exitCode = 1;\n} finally {\n server.kill(\"SIGKILL\");\n process.exit(exitCode);\n}\n```\n\n### 3. Install + run\n\n**Default (host):**\n```bash\ncd \"$SANITY_DIR\"\nnpm install\nnode test.mjs\n```\n\nIf you need to inspect a failure after the fact, tee the output:\n```bash\nnode test.mjs 2>&1 | tee /tmp/sanity-check.log\necho \"exit=$?\"\n```\n\n**Docker mode:**\n```bash\ndocker run --rm \\\n -v \"$SANITY_DIR\":/app \\\n -w /app \\\n node:22 \\\n bash -c \"npm install && timeout 120 node test.mjs\"\n```\n\n### 4. Report installed versions\n\nSurface the resolved versions (rivetkit's `exports` doesn't expose `./package.json`, so read the file directly):\n\n```bash\nnode -e \"\nfor (const p of ['rivetkit','@rivetkit/react','@rivetkit/rivetkit-napi']) {\n try {\n const v = JSON.parse(require('fs').readFileSync('node_modules/'+p+'/package.json','utf8')).version;\n console.log(p, v);\n } catch (e) { console.log(p, '(not installed:', e.code || e.message, ')'); }\n}\n\"\n```\n\n### 5. Report results\n\nTell the user:\n- Resolved versions (rivetkit + @rivetkit/rivetkit-napi)\n- HTTP path results\n- WebSocket path results + event value\n- ✅ or ❌ with the last 2KB of server log on failure\n\n### 6. Clean up\n\n```bash\nrm -rf \"$SANITY_DIR\"\n```\n\n## Extending with custom tests\n\nIf the user asks for extra behavior, modify `src/index.ts` and add assertions to `test.mjs` before running. Common asks and where to slot them:\n\n- **KV round-trip**: add `kv` actions (`setKv: (c, key, val) => c.kv.set(key, val)`, `getKv: (c, key) => c.kv.get(key)`), then in test.mjs call set → get and assert.\n- **Workflow**: add a workflow action, await its completion, assert the final state.\n- **SQLite + migrations**: add a migration and a query action, call it, assert rows.\n- **State persistence**: increment, kill the server (`server.kill(\"SIGTERM\")`), await exit, respawn, call `getCount()`, assert value preserved.\n- **Multiple actor instances**: use different keys, verify isolation.\n\nStart from the base test above; layer additions rather than rewriting it.\n\n## Rules\n- Always use a fresh temp directory — never run in the repo itself.\n- Always install from the public npm registry or pkg-pr-new — never use local workspace links / `file:` deps.\n- Pin `rivetkit` + `@rivetkit/react` to the exact user-specified version; let npm's `optionalDependencies` resolve the right `@rivetkit/rivetkit-napi-` binary automatically.\n- If `npm install` fails to resolve a bare pkg-pr-new version string, retry using the `https://pkg.pr.new/rivet-dev/rivet/@` URL form.\n- If the server doesn't reach `/health` in 30s, dump the last 2KB of server stderr/stdout before failing — most install/runtime issues show up there (missing native binary, wrong Node version, port collision).\n- On Docker mode, run `rm -rf $SANITY_DIR` only after `docker run --rm` exits so container-created `node_modules` get cleaned by the `--rm` flag.\n",".claude/skills/stack-merge/SKILL.md":"---\nname: stack-merge\ndescription: Bulk-merge a Graphite stack into main via admin-bypass fast-forward push. Replaces the Graphite merge queue for rivet-dev/rivet. Invoke when the user says \"merge the stack at \", \"ship everything through \", \"bulk-merge up to \", \"fast-forward main to \", or any request to land multiple stacked PRs at once in one shot. Requires repo admin permissions (bypasses branch protection), Graphite (gt) CLI, and GitHub (gh) CLI. After the FF push, closes all in-scope PRs explicitly with `gh pr close` in parallel — GitHub does not auto-mark them as MERGED because their bases point at sibling stack branches, not main.\n---\n\n# Stack Merge\n\nLand an entire Graphite downstack into main in one admin-bypass fast-forward push, then close every in-scope PR explicitly. No per-PR CI gates, no merge commits on main, no `gh pr merge` per PR. PRs end up in **Closed** state (not MERGED) unless their base was already `main`, but their commits are in main's history.\n\nThis skill **replaces** Graphite's merge queue — use when you want the outcome Graphite's queue produces (linear history, all PRs merged) but without waiting for the queue. Requires admin bypass on `main` branch protection.\n\n## When NOT to use\n\n- User wants normal single-PR merge → use `gh pr merge`.\n- User isn't a repo admin → push will reject (tell them to use Graphite's queue).\n- Stack tip has failing CI and user cares → queue would refuse; pause here too.\n\n## Preconditions (verify at start; bail early)\n\n1. **Admin/bypass on main**: `gh api repos/rivet-dev/rivet/branches/main/protection` — check user is in `bypass_pull_request_allowances.users[]` or has repo admin. If not, stop.\n2. **Graphite initialized**: `gt ls` succeeds.\n3. **Clean working tree**: `git status --short` empty. In-flight rebase/merge state must be resolved first.\n4. **Worktree sanity**: `git worktree list` — prune any `prunable` entries with `git worktree prune`. Stale worktrees break rebases with \"already checked out at\" errors. See references/gotchas.md.\n\n## The flow (8 phases)\n\nEach phase has a **validation gate** or **confirmation gate**. Writes happen only after the user explicitly approves the final commands.\n\n### Phase 1 — Scope\n\nInput: target branch name from user.\n\n- Enumerate the merge path: walk `gh pr view --json baseRefName` from target down to `main`. Produces the ordered list of all PRs that will be closed in Phase 8.\n- **Do not infer parents from `gt ls` visual order** — use each PR's `baseRefName`. See gotchas.md.\n- Script: `scripts/list_merge_path.sh `.\n\n### Phase 2 — Sync\n\n- `gt sync --no-interactive`. Pulls latest main, cleans up merged upstream branches.\n- Read output for any `(needs restack)` markers in the merge path.\n\n### Phase 3 — Unfreeze\n\n- List frozen branches in the merge path (`gt ls | grep frozen`).\n- `gt sync` **silently skips frozen branches**. If any frozen branch sits between target and main, the chain stays anchored to its old main SHA forever. See gotchas.md.\n- Unfreeze each one: `gt unfreeze `. Operation is metadata-only, no rewrites yet. Present full list to user and confirm before running.\n\n### Phase 4 — Restack downstack\n\n- `gt restack --downstack` from the target branch. Cascades rebase from main up through the (now-unfrozen) chain to target.\n- Conflicts: **hand off to user** (`gt continue` after resolving each). Do not drive conflict resolution.\n- When restack completes, verify: `git merge-base --is-ancestor origin/main ` must return YES. If NO, main moved during the restack — `gt sync` again and loop.\n\n### Phase 5 — Validation gate (read-only)\n\nScript: `scripts/validate.sh `. Checks:\n\n1. FF safety: `git merge-base --is-ancestor origin/main origin/` → must be YES.\n2. Commits on main not in target: `git rev-list --count origin/..origin/main` → must be 0 (otherwise FF push deletes commits on main).\n3. Local vs remote divergence for every branch in the merge path (restack rewrote SHAs; remote needs updating).\n4. Commit hygiene (informational, not blocking):\n - Ralph-style commits (pattern: `^[a-z]+(\\(.+?\\))?!?:\\s*\\[?US-\\d+\\]?\\s*-\\s`). See scripts/detect_ralph.sh.\n - Unsquashed branches (>1 commit against baseRefName).\n5. Conflict preview via scratch worktree + `git merge origin/main --no-commit --no-ff`. Shouldn't conflict after a clean restack, but if it does, loop back to Phase 4.\n\n**Gate**: if any check fails, stop and present findings.\n\n### Phase 6 — Confirmation gate\n\nPresent to user before any writes:\n\n- main SHA before/after\n- number of commits landing\n- list of PRs that will be closed in Phase 8 (the merge path)\n- list of branches that will be force-pushed\n\nRequire explicit \"yes\". No proceed-on-silence.\n\n### Phase 7 — Push\n\nTwo writes, in order:\n\n1. **Batch force-push all merge-path branches**. Each branch's remote head must match its restacked local SHA so the PR's head-SHA-on-GitHub reflects the post-restack commits. This matters only if restack actually rewrote SHAs; with a clean sync and no-op restack it's a harmless no-op.\n ```bash\n git push origin --force-with-lease \\\n ... \n ```\n Single-transaction multi-refspec push is faster than N sequential pushes. Use `--force-with-lease`, never `--force`.\n2. **FF push main to target tip**.\n ```bash\n git push origin origin/:main\n ```\n Admin bypass will be noted in push output (\"Bypassed rule violations for refs/heads/main\").\n\n### Phase 8 — Close PRs + cleanup\n\n1. **Close every open PR whose head is now reachable from main**, in parallel. This catches both the in-scope PRs and anything below the merge path that also landed.\n ```bash\n main_sha=$(git rev-parse origin/main)\n open_prs=$(gh pr list --state open --limit 200 --json number,headRefOid \\\n --jq '.[] | \"\\(.number)\\t\\(.headRefOid)\"')\n close=()\n while IFS=$'\\t' read -r n sha; do\n git merge-base --is-ancestor \"$sha\" \"$main_sha\" 2>/dev/null && close+=(\"$n\")\n done <<<\"$open_prs\"\n for n in \"${close[@]}\"; do\n (gh pr close \"$n\" --comment \"Landed in main via stack-merge fast-forward push. Commits are in main; closing to match.\" &)\n done\n wait\n ```\n PRs whose base was `main` may have auto-merged by now — `gh pr close` prints `already closed` for those, which is fine.\n2. `gt sync` to clean up locally-merged branches.\n3. Report final state: main SHA, count of PRs closed, any PRs still OPEN (shouldn't be any).\n\n**Why explicit close**: GitHub only auto-closes a PR as MERGED when head ⊆ the PR's **base** branch. Most stacked PRs have base = sibling branch, not main, so the cheap auto-merge check doesn't fire. GitHub's slower background sweep eventually closes them as CLOSED (not MERGED), but it's unreliable and can take 5+ minutes. Close them ourselves.\n\n## References\n\n- [references/gotchas.md](references/gotchas.md) — every trap from the flow's design session. **Read this before writing any push commands.**\n- [references/phases.md](references/phases.md) — per-phase detail, example outputs, decision trees.\n\n## Scripts\n\n- `scripts/list_merge_path.sh ` — enumerate in-scope PRs via baseRefName traversal.\n- `scripts/validate.sh ` — run all Phase 5 read-only checks.\n- `scripts/detect_ralph.sh ` — flag Ralph-style commits in the merge path.\n- `scripts/exec_merge.sh --confirm` — batch force-push + FF push (Phase 7). Requires explicit `--confirm` flag to execute.\n\n## Core rules\n\n- **Never skip the FF safety check.** `git merge-base --is-ancestor origin/main origin/` must be YES before the main push. If commits exist on main that aren't in target, the push deletes them.\n- **`gt ls` visual ordering is not PR parent ordering.** Always use `gh pr view --json baseRefName`. `baseRefName` can be either a real branch name or `graphite-base/` — both are valid.\n- **`gt sync` silently skips frozen branches.** Freeze is opt-out-of-restack. Any frozen branch between target and main breaks the merge path.\n- **Use `--force-with-lease` for all force-pushes.** Bails safely if remote moved; `--force` blindly overwrites.\n- **Hand off conflicts during `gt restack`.** Do not pick sides. The user resolves, then runs `gt continue`.\n- **Close PRs explicitly in Phase 8, don't wait for auto-close.** GitHub only auto-closes as MERGED when head ⊆ base branch, which almost never holds for stacked PRs. See gotchas.md.\n- **Phase 8 closes everything reachable from main, not just `list_merge_path.sh` output.** That script stops at `graphite-base/` boundaries and can miss PRs below.\n",".claude/skills/driver-test-runner/SKILL.md":"---\nname: driver-test-runner\ndescription: Methodically run the RivetKit driver test suite file by file across the native (NAPI) and wasm runtimes, tracking progress in ~/.agents/notes/driver-test-progress.md. Use when you need to validate the driver test suite after changes, bring up a new driver, or debug test failures systematically.\nallowed-tools: Bash, Read, Write, Edit, Grep, Glob, Agent, TaskCreate, TaskUpdate\n---\n\n# Driver Test Suite Runner\n\nMethodically run the RivetKit driver test suite one file group at a time across the native (NAPI) and wasm runtimes, tracking progress in `~/.agents/notes/driver-test-progress.md`.\n\n## Arguments\n\nThe skill accepts optional arguments:\n\n- **`reset`** — Clear progress and start from the beginning.\n- **`resume`** — Pick up from where we left off (default behavior).\n- **`only `** — Run only a specific test file group (e.g., `only actor-conn`).\n- **`from `** — Start from a specific file group, skipping earlier ones.\n- **`runtime `** — Which runtime(s) to run (default: `both`).\n- **`encoding `** — Override encoding (default: `bare`).\n- **`registry `** — Override registry type (default: `static`).\n\n## Runtime Matrix\n\nThe driver suite runs over a runtime × SQLite-backend × encoding matrix defined in `rivetkit-typescript/packages/rivetkit/tests/driver/shared-matrix.ts`. The runtime dimension has two values:\n\n- **`native`** — NAPI bindings (`@rivetkit/rivetkit-napi`). Pairs with `sqlite=local` for the primary native driver pass.\n- **`wasm`** — WebAssembly bindings (`@rivetkit/rivetkit-wasm`). Wasm **cannot** use local SQLite; it must pair with `sqlite=remote` (executes SQL through the engine over the wire).\n\nThe skill defaults to running each test file twice: once on `native/local` and once on `wasm/remote`, each at `encoding=bare`. A file is checked off only when both runtimes pass.\n\nThe test harness does not read environment variables for matrix selection. Always select matrix cells with Vitest `-t` using the full inner describe name: `runtime () / sqlite () / encoding ()`.\n\n## How It Works\n\n### 0. Anchor the reference before fixing parity bugs\n\nIf a RivetKit driver test fails because native or Rust behavior diverges from the old runtime, do this before inventing a separate debugging workflow:\n\n1. Treat `rivetkit-typescript/packages/rivetkit` driver tests as the primary oracle.\n2. Compare the failing behavior against the original TypeScript implementation at ref `feat/sqlite-vfs-v2` using `git show` or `git diff`.\n3. Patch native/Rust to match the original TypeScript behavior.\n4. Rerun the same TypeScript driver test before adding any lower-level native tests.\n\nIf a test passes on `native` but fails on `wasm` (or vice versa), the divergence is in the runtime adapter (`packages/rivetkit/src/registry/wasm-runtime.ts` or `napi-runtime.ts`) or in `rivetkit-core`'s wasm/native feature gates — not in user-facing actor code.\n\nNative unit tests are allowed only after the failing TypeScript driver test has reproduced the bug and after the fix is validated against that same TypeScript driver test.\n\n### 1. Ensure runtime artifacts are built\n\nBoth runtime adapters need their build outputs on disk before the suite can load them. A fresh checkout, a Rust edit under `packages/rivetkit-napi` / `packages/sqlite-native`, or any change under `packages/rivetkit-wasm` invalidates these.\n\n**NAPI (`@rivetkit/rivetkit-napi`)** — produces a platform-specific `.node` next to `package.json`:\n\n```bash\nls rivetkit-typescript/packages/rivetkit-napi/*.node 2>/dev/null\n# missing? rebuild:\npnpm --filter @rivetkit/rivetkit-napi run build:force\n```\n\nAfter Rust changes, always use `build:force` (per `rivetkit-typescript/CLAUDE.md`); the non-`:force` variant can skip the rebuild and leave the suite running against a stale `.node`.\n\n**Wasm (`@rivetkit/rivetkit-wasm`)** — produces `packages/rivetkit-wasm/pkg/rivetkit_wasm.{js,wasm,d.ts}`:\n\n```bash\nls rivetkit-typescript/packages/rivetkit-wasm/pkg/rivetkit_wasm.wasm 2>/dev/null\n# missing? rebuild (uses the package-pinned wasm-pack, do not use npx):\npnpm --filter @rivetkit/rivetkit-wasm run build\n```\n\nSkip the wasm build only if `runtime` is `native` and you're certain the wasm fixture path won't be loaded. With the default `runtime=both`, the wasm build is always required.\n\n### 2. Ensure the engine is running\n\nBefore running any tests, check if the RocksDB engine is already running:\n\n```bash\ncurl -sf http://127.0.0.1:6420/health || echo \"NOT RUNNING\"\n```\n\nIf it's not running, start it:\n\n```bash\n./scripts/run/engine-rocksdb.sh >/tmp/rivet-engine-startup.log 2>&1 &\n```\n\nWait for health check to pass (poll every 2 seconds, up to 60 seconds).\n\n### 3. Initialize or load progress file\n\nThe progress file lives at `~/.agents/notes/driver-test-progress.md`. If it doesn't exist or `reset` was passed, create it with the template below. If it exists and `resume` was passed, read it and pick up from the first file with an unchecked runtime box.\n\nEach file row gets two checkboxes — one for each runtime. Check off a runtime independently as soon as it passes, and only advance to the next file when both runtimes for the current file are checked.\n\nProgress file template:\n\n```markdown\n# Driver Test Suite Progress\n\nStarted: \nConfig: registry (static), encoding (bare), runtimes (native, wasm)\n\nEach row: `[native] [wasm] | `\n\n## Fast Tests\n\n- [ ] [ ] manager-driver | Manager Driver Tests\n- [ ] [ ] actor-conn | Actor Connection Tests\n- [ ] [ ] actor-conn-state | Actor Connection State Tests\n- [ ] [ ] conn-error-serialization | Connection Error Serialization Tests\n- [ ] [ ] actor-destroy | Actor Destroy Tests\n- [ ] [ ] request-access | Request Access in Lifecycle Hooks\n- [ ] [ ] actor-handle | Actor Handle Tests\n- [ ] [ ] action-features | Action Features Tests\n- [ ] [ ] access-control | access control\n- [ ] [ ] actor-vars | Actor Variables\n- [ ] [ ] actor-metadata | Actor Metadata Tests\n- [ ] [ ] actor-telemetry | Actor Telemetry\n- [ ] [ ] actor-onstatechange | Actor State Change Tests\n- [ ] [ ] actor-db | Actor Database\n- [ ] [ ] actor-db-raw | Actor Database Raw Tests\n- [ ] [ ] actor-db-init-order | Actor Db Init Order\n- [ ] [ ] actor-workflow | Actor Workflow Tests\n- [ ] [ ] actor-error-handling | Actor Error Handling Tests\n- [ ] [ ] actor-queue | Actor Queue Tests\n- [ ] [ ] actor-kv | Actor KV Tests\n- [ ] [ ] actor-stateless | Actor Stateless Tests\n- [ ] [ ] raw-http | raw http\n- [ ] [ ] raw-http-request-properties | raw http request properties\n- [ ] [ ] raw-websocket | raw websocket\n- [ ] [ ] actor-inspector | Actor Inspector Tests\n- [ ] [ ] gateway-query-url | Gateway Query URL Tests\n- [ ] [ ] actor-db-pragma-migration | Actor Database Pragma Migration\n- [ ] [ ] actor-state-zod-coercion | Actor State Zod Coercion\n- [ ] [ ] actor-conn-status | Connection Status Changes\n- [ ] [ ] gateway-routing | Gateway Routing\n- [ ] [ ] lifecycle-hooks | Lifecycle Hooks\n- [ ] [ ] serverless-handler | Serverless Handler Tests\n\n## Slow Tests\n\n- [ ] [ ] actor-state | Actor State Tests\n- [ ] [ ] actor-save-state | Actor Save State Tests\n- [ ] [ ] actor-schedule | Actor Schedule Tests\n- [ ] [ ] actor-sleep | Actor Sleep Tests\n- [ ] [ ] actor-sleep-db | Actor Sleep Database Tests\n- [ ] [ ] actor-lifecycle | Actor Lifecycle Tests\n- [ ] [ ] actor-conn-hibernation | Actor Connection Hibernation Tests\n- [ ] [ ] actor-run | Actor Run Tests\n- [ ] [ ] hibernatable-websocket-protocol | hibernatable websocket protocol\n- [ ] [ ] actor-db-stress | Actor Database Stress Tests\n\n## Log\n```\n\n### 4. Run tests file by file\n\nFor each unchecked row in order, run the runtimes selected by the `runtime` arg (default `both`). For each runtime:\n\n**a) Pick the runtime/sqlite pair:**\n\n| Runtime | SQLite backend |\n|---------|----------------|\n| native | local |\n| wasm | remote |\n\n**b) Build the filter command:**\n\nEach suite lives in its own file under `rivetkit-typescript/packages/rivetkit/tests/driver/.test.ts`. The describe block nesting is:\n\n```\n > static registry > runtime () / sqlite () / encoding () > \n```\n\nAlways use Vitest `-t` for driver matrix cells. Include runtime, SQLite backend, and encoding in the pattern so a partial match does not accidentally select another matrix cell.\n\nBase command (native):\n\n```bash\ncd rivetkit-typescript/packages/rivetkit && \\\n pnpm test tests/driver/.test.ts \\\n -t \"runtime \\(native\\) / sqlite \\(local\\) / encoding \\(bare\\)\" \\\n > /tmp/driver-test-current.log 2>&1\necho \"EXIT: $?\"\n```\n\nBase command (wasm):\n\n```bash\ncd rivetkit-typescript/packages/rivetkit && \\\n pnpm test tests/driver/.test.ts \\\n -t \"runtime \\(wasm\\) / sqlite \\(remote\\) / encoding \\(bare\\)\" \\\n > /tmp/driver-test-current.log 2>&1\necho \"EXIT: $?\"\n```\n\nReplace `` with the file name stem (part before the `|` in the progress file) and `` with the suite description (part after the `|`). Escape parentheses in the description if present. Forward slashes inside the describe path do not need to be escaped.\n\n**Important:** The suite description in the `-t` filter must match the inner `describe(...)` text in the test file exactly. Some mappings:\n\n| File | Suite Description Text |\n|------|----------------------|\n| manager-driver | Manager Driver Tests |\n| actor-conn | Actor Connection Tests |\n| actor-conn-state | Actor Connection State Tests |\n| conn-error-serialization | Connection Error Serialization Tests |\n| actor-destroy | Actor Destroy Tests |\n| request-access | Request Access in Lifecycle Hooks |\n| actor-handle | Actor Handle Tests |\n| action-features | Action Features Tests |\n| access-control | access control |\n| actor-vars | Actor Variables |\n| actor-metadata | Actor Metadata Tests |\n| actor-telemetry | Actor Telemetry |\n| actor-onstatechange | Actor State Change Tests |\n| actor-db | Actor Database |\n| actor-db-raw | Actor Database Raw Tests |\n| actor-db-init-order | Actor Db Init Order |\n| actor-workflow | Actor Workflow Tests |\n| actor-error-handling | Actor Error Handling Tests |\n| actor-queue | Actor Queue Tests |\n| actor-kv | Actor KV Tests |\n| actor-stateless | Actor Stateless Tests |\n| raw-http | raw http |\n| raw-http-request-properties | raw http request properties |\n| raw-websocket | raw websocket |\n| actor-inspector | Actor Inspector Tests |\n| gateway-query-url | Gateway Query URL Tests |\n| actor-db-pragma-migration | Actor Database Pragma Migration |\n| actor-state-zod-coercion | Actor State Zod Coercion |\n| actor-conn-status | Connection Status Changes |\n| gateway-routing | Gateway Routing |\n| lifecycle-hooks | Lifecycle Hooks |\n| serverless-handler | Serverless Handler Tests |\n| actor-state | Actor State Tests |\n| actor-save-state | Actor Save State Tests |\n| actor-schedule | Actor Schedule Tests |\n| actor-sleep | Actor Sleep Tests |\n| actor-sleep-db | Actor Sleep Database Tests |\n| actor-lifecycle | Actor Lifecycle Tests |\n| actor-conn-hibernation | Actor Connection Hibernation Tests |\n| actor-run | Actor Run Tests |\n| hibernatable-websocket-protocol | hibernatable websocket protocol |\n| actor-db-stress | Actor Database Stress Tests |\n\n**c) Pipe output to file and analyze:**\n\nAlways pipe test output to `/tmp/driver-test-current.log` so you can grep it afterward. Then analyze:\n\n```bash\ngrep -E \"Tests|FAIL|PASS|Error|✓|✗|×\" /tmp/driver-test-current.log | tail -30\n```\n\n**d) If all tests pass for that runtime:** Check off only that runtime's box in the progress file and append to the log:\n\n```\n- []: PASS ( tests, )\n```\n\nIf both runtime boxes are now checked, the file is fully done; advance to the next file.\n\n**e) If tests fail:**\n\n1. Do NOT move to the next runtime or file.\n2. Narrow down to the first failing test by adding enough test-name text to the same `-t` pattern.\n3. Read the error output to understand the failure.\n4. Append to the log:\n\n```\n- []: FAIL - \n```\n\n5. Report the failure to the user with:\n - Which test file group failed and on which runtime\n - Which specific test(s) failed\n - The error message\n - Whether the failure is runtime-specific (e.g. fails on `wasm` but passes on `native`)\n - Suggested next steps\n\n### 5. Narrowing scope on failure\n\nIf a file group fails, keep the full matrix selector and append enough test-name text to isolate the failing test:\n\n```bash\ncd rivetkit-typescript/packages/rivetkit && \\\n pnpm test tests/driver/.test.ts \\\n -t \"runtime \\(\\) / sqlite \\(\\) / encoding \\(bare\\).*\" \\\n > /tmp/driver-test-narrow.log 2>&1\n```\n\nDo not use `-t` as a flake workaround. It is only for selecting the intended matrix cell and, when needed, a specific failing test.\nIf the bug only appears on one runtime, that's a strong signal — focus the diff hunt on the corresponding runtime adapter (`napi-runtime.ts` / `wasm-runtime.ts`) and any wasm-feature-gated code in `rivetkit-core` and `rivetkit-typescript/packages/rivetkit-wasm`.\n\n### 6. Completion\n\nWhen all rows are fully checked (both runtime boxes), append to the log:\n\n```\n- ALL TESTS COMPLETE\n```\n\nReport summary:\n- Total files passing per runtime\n- Total files failing per runtime (with names)\n- Files where one runtime passes and the other fails (parity gaps)\n- Total duration\n\n## Rules\n\n1. **One file at a time.** Never run the full suite. The whole point is methodical, scoped testing.\n2. **Both runtimes per file before advancing** (when `runtime=both`). Run native, then wasm, on the same file. Check off each independently as it passes, but do not advance to the next file until both are checked.\n3. **Fix before advancing.** Do not skip a failing runtime/file to test the next one (unless the user says to skip).\n4. **Always pipe to file.** Never rely on inline terminal output for test results. Always write to `/tmp/driver-test-current.log` and grep afterward.\n5. **Track everything.** Every run gets logged in the progress file with its runtime tag.\n6. **Always use `-t` for matrix selection.** Include runtime, SQLite backend, and encoding in the selector. Do not scope the driver matrix with env vars.\n7. **Never pair `wasm` with `local` SQLite.** The harness throws on this combination. If a wasm run somehow needs local SQLite to repro a bug, that's a bug in the matrix, not a workaround to apply.\n8. **Respect timeouts.** Set a 600-second timeout for slow tests (sleep, lifecycle, stress). Use 120 seconds for fast tests. Wasm runs may be slower than native — extend timeouts proportionally if you see consistent timeouts on wasm only.\n",".claude/skills/create-launch-post/SKILL.md":"---\nname: create-launch-post\ndescription: Create and publish concise Rivet launch or changelog posts through an approval-gated workflow, including release research, a required user-selected hero variation, local HTML-rendered social and technical images, an R2 hero upload, MDX authoring, a reviewed draft GitHub PR for manual merge, and a scheduled and verified Buffer thread for @rivet_dev. Use when asked to launch, announce, ship, or prepare and schedule a Rivet feature or release announcement.\n---\n\n# Create Launch Post\n\nPrepare a complete, deliberately short launch. Keep the launch date, hero variation, social copy, Buffer schedule, and final GitHub merge as user-owned checkpoints. Opening the draft PR is not completion.\n\n## Workflow contract\n\nRun these phases in order:\n\n1. Accept the user's launch context, research the release, confirm the launch date, and ask the user which hero variation to use. Never silently choose the variation or the painting.\n2. Render the 2:1 blog hero and social image. Upload only the blog hero; keep social and technical assets local.\n3. Write and validate the blog post, upload the hero, and push an initial draft PR.\n4. Give the user one review packet containing the draft PR, social image, first technical-image draft, four Buffer main-post options, and the proposed reply thread. If the feature has meaningful Dashboard, Inspector, or other product UI, recommend adding a clean screenshot and ask the user to provide it or approve capturing it. Iterate on the post, PR, technical image, optional UI screenshot, and social copy until the user approves them. Push every approved blog revision to the same PR.\n5. After the user approves the copy, replies, launch date, and exact time, schedule the Buffer thread and reopen it to verify the account, content, image, order, date, time, and timezone. Leave the GitHub PR for the user to merge manually.\n\nDo not declare the launch ready until all three acceptance gates pass:\n\n- **Blog post:** The user has reviewed it, the latest approved revision is pushed to the draft PR, the hero resolves, and relevant checks pass or any external blocker is explicit.\n- **Technical image:** The user has reviewed and approved the current local `technical.png`.\n- **Buffer:** The approved thread is scheduled for `rivet_dev` and the scheduled item has been verified. If Buffer references a tunneled media URL, a reliable tunnel process and cleanup plan must remain active through publication.\n\n## Parallelize with subagents\n\nUse subagents in bounded waves when concurrency is available. Keep the main agent as the only user-facing orchestrator and the sole owner of tracked-file edits, asset uploads, `jj` operations, GitHub writes, Buffer mutations, and tunnel lifecycle. Give subagents read-only repository work or a unique output directory outside the repository; never let multiple agents edit the same worktree or perform the same external action.\n\nStart wave 1 while the main agent asks for the hero variation and confirms the date:\n\n1. **Release researcher:** Inspect the source PR, implementation, tests, examples, and docs. Return verified public API syntax, constraints, shipped terminology, and candidate documentation and GitHub links with file or URL evidence.\n2. **Post-format researcher:** Review at least three recent concise Rivet changelog posts. Return the shared structure, tone, frontmatter conventions, slug rules, and useful examples without editing files.\n\nAfter the hero variation and release facts are available, start wave 2 in parallel:\n\n1. **Visual worker:** Run the bundled renderer in a unique external output directory. Produce the hero, social image, and first technical-image draft; report paths, dimensions, checksums, and visual concerns. Never upload or commit them.\n2. **Blog-draft worker:** Return a concise MDX draft grounded in the verified API and generic launch structure. Do not write the tracked post file.\n3. **Distribution worker:** Draft four main Buffer options, the four link replies, and scripted character counts using the required Unicode-code and arrow formatting. Do not schedule anything.\n\nThe main agent must reconcile those outputs, verify facts against source, write the MDX, choose what to show the user, and own the approval loop. After integration, use one read-only **QA subagent** to inspect the final diff, post code, URLs, frontmatter/date, rendered images, Buffer payload, and `jj status`. Require it to report concrete defects only; the main agent applies any fixes and reruns focused checks.\n\nDo not delegate user checkpoints or final side effects. The main agent must personally confirm the hero variation, date, copy, thread, exact schedule, PR state, account/channel, media, and final verification.\n\n## 1. Work locally and research the release\n\n1. Read the repository `AGENTS.md` files that govern the files in scope.\n2. Work from the local checkout at `~/rivet`; never author repository files through GitHub's contents or object APIs. Reuse a user-provided isolated workspace, or create one before editing:\n\n```bash\njj -R ~/rivet git fetch\njj -R ~/rivet workspace add \\\n --name \"launch-\" \\\n --revision \"main@origin\" \\\n --message \"docs(website): launch \" \\\n \"$WORKSPACE_PATH\"\ncd \"$WORKSPACE_PATH\"\n```\n\n3. Run `jj status` and keep the launch revision isolated from unrelated work. Put generated and downloaded files outside the repository workspace.\n4. Read the source PR, changed docs, examples, tests, and public API. Treat implemented code and merged docs as authoritative; do not infer syntax from the PR title.\n5. Read at least three recent concise posts in `website/src/content/posts/`, preferring `category: changelog` posts for similar features.\n6. Resolve the canonical post URL, public docs route, GitHub repository, and Discord URL before drafting. The route preserves the complete dated post folder name. If the file is `website/src/content/posts/YYYY-MM-DD-/page.mdx`, its post ID is `YYYY-MM-DD-` and its URL is:\n\n```text\ncategory: changelog → https://rivet.dev/changelog/YYYY-MM-DD-/\nall other categories → https://rivet.dev/blog/YYYY-MM-DD-/\n```\n\nDo not remove the date prefix. The Astro routes derive the slug with `entry.id.replace(/\\/page$/, \"\")`, which removes only `/page` and preserves the full folder name.\n\n7. Propose the target launch date and get explicit user confirmation. Use that date consistently for the folder name, `published` frontmatter, asset key, canonical URL, and Buffer schedule.\n\n## 2. Render the launch images\n\nAsk the user which hero variation to use before rendering anything. This is a required creative checkpoint; never choose the variation silently. Both variations write `image.png` at `2048x1024` for the blog hero and `social.png` at `2048x1238` for distribution, so every later phase is identical regardless of which one is chosen. Use the repository renderers; do not use Figma.\n\n### Variation A — painting\n\nThe default editorial treatment: a full-bleed painting with the launch title beneath it. Best when the launch is a product or capability announcement with no natural logo lockup.\n\n1. Ask the user to choose and provide a painting. Ask for the source or confirm that it is safe to publish.\n2. Pass a short feature name such as `Cron Jobs` as the social title:\n\n```bash\npnpm --dir website render-launch-images -- \\\n --painting \"$PAINTING_PATH\" \\\n --title \"$SOCIAL_TITLE\" \\\n --output-dir \"$OUTPUT_DIR\"\n```\n\n3. If the source is already 2:1, preserve its composition and only normalize it to `2048x1024`. Otherwise, visually inspect both PNGs and rerun with `--focal-x <0..1>` and/or `--focal-y <0..1>` if the crop misses the subject. Do not hand-edit the output.\n\n### Variation B — logo tiles\n\nThe Rivet wordmark above the launch title, over two to four product logos in rotated rounded \"app tiles\" with the middle tile dominant. Best when the launch is an integration or a combination of named technologies, where the logo lockup states the story faster than prose. The tile treatment matches the agentOS launch graphics and the landing page's floating-agent tiles.\n\n1. Ask the user which logos belong in the lockup and in what order. Order is left to right, and with three tiles the middle one is the largest, so put the subject of the launch in the middle.\n2. Collect an SVG per logo. Reuse repository marks where they exist (`website/src/images/products/`, `website/public/images/registry/`), fall back to the vendored marks in `.claude/skills/create-launch-post/assets/logos/`, and vendor any new mark there. Marks authored white for dark UIs are recolored to the site ink automatically, so a white-on-transparent SVG is fine.\n3. Pass the full post title rather than a short feature name; this layout has room for a sentence-length title:\n\n```bash\npnpm --dir website render-tile-images -- \\\n --title \"$POST_TITLE\" \\\n --logos \"$LOGO_A,$LOGO_B,$LOGO_C\" \\\n --output-dir \"$OUTPUT_DIR\"\n```\n\n4. Inspect both PNGs. If a title wraps to a third line or a tile crowds the title, shorten the title rather than hand-editing the output. Tile geometry lives in `TILE_LAYOUTS` in the renderer; change it there if a lockup genuinely needs different placement.\n\nWhen short code demonstrations would help launch distribution, create a temporary JSON file outside the repository with one to four sections:\n\n```json\n[\n\t{\n\t\t\"title\": \"Crontab with timezone\",\n\t\t\"language\": \"ts\",\n\t\t\"code\": \"await c.cron.set({ /* ... */ });\"\n\t}\n]\n```\n\nRender the technical image directly without generating hero or social assets:\n\n```bash\npnpm --dir website render-technical-image -- \\\n --title \"Cron Jobs\" \\\n --technical-snippets \"$TECHNICAL_SNIPPETS_PATH\" \\\n --output \"$OUTPUT_DIR/technical.png\"\n```\n\nUse `--layout vertical` to stack every snippet at full width; the default `grid` layout uses the launch-image column rules. Pass `--browser /path/to/chromium` only when neither bundled nor common system Chromium installations are available automatically. Normally create the first technical draft immediately after opening the initial blog PR, once the code example is stable enough to summarize. The renderer writes the PNG and adjacent HTML at a fixed `2048px` width with content-driven height, so short examples produce a shorter image. The white technical image places the Perfectly Nineties launch title at top left and the Rivet logo at top right, with matching 132px side and bottom gutters. Section headings use Manrope; code uses four-space tabs plus the website's JetBrains Mono font, Shiki configuration, customized Ayu Dark theme, and code-block geometry. With three grid sections, the first section fills the left column while the other two stack on the right. Every dark code panel stretches to the full available section height so column bottoms align. Keep snippets brief enough to fit, show it to the user, and rerender until approved.\n\nWhen the feature has useful Dashboard, Inspector, or other visible product UI, proactively recommend a supporting screenshot. Ask the user to provide the screenshot or approve the exact authenticated view and state to capture. Use a clean launch-ready environment, crop away irrelevant browser chrome, and inspect the result for credentials, private names, IDs, tokens, customer data, or other sensitive information. Keep the screenshot local and show it to the user for approval. Confirm whether it should be attached to the first Buffer post or used in a dedicated reply; do not add it automatically.\n\nDo not add `image: true` to the post until the uploaded asset resolves successfully.\n\n## 3. Upload the hero\n\nUse the complete dated post folder name as `` and upload the blog hero:\n\n```bash\nAWS_ACCESS_KEY_ID='op://Engineering/rivet-assets R2 Upload/username' \\\nAWS_SECRET_ACCESS_KEY='op://Engineering/rivet-assets R2 Upload/password' \\\nop run -- aws s3 cp \"$IMAGE_PATH\" \\\n \"s3://rivet-assets/website/blog//image.png\" \\\n --endpoint-url https://2a94c6a0ced8d35ea63cddc86c2681e7.r2.cloudflarestorage.com\n```\n\nVerify `https://assets.rivet.dev/website/blog//image.png`, then add `image: true` to frontmatter. Never commit the exported hero to Git and never print resolved credentials.\n\nReturn `social.png`, optional `technical.png`, and any approved UI screenshot to the user as local launch-distribution assets. Never upload or commit distribution images, their HTML source, the technical-snippet JSON, the UI screenshot, or the painting source.\n\n## 4. Bootstrap the MDX\n\nRun the repository generator:\n\n```bash\npnpm --dir website new-post\n```\n\nFor a future launch date, bootstrap normally, then rename the generated folder and update `published` to `YYYY-MM-DD`. The final path is:\n\n```text\nwebsite/src/content/posts/YYYY-MM-DD-/page.mdx\n```\n\nUse `author: nathan-flurry` unless the user specifies another author, `category: changelog`, and targeted lowercase keywords.\n\n## 5. Write the generic launch format\n\nKeep the body brief and use this order:\n\n1. One short paragraph explaining what shipped and why it matters.\n2. Short capability-focused H2 sections with one small example each, copied from or checked against the release. Give distinct public APIs separate sections when that makes the launch easier to scan; for example: crontab with timezone, fixed intervals, run history, and one-off jobs.\n3. Use `## Show Me The Code` only when one cohesive example explains the feature better than separate API sections.\n4. `## More Links` with docs, the relevant GitHub repository, and `https://rivet.dev/discord`.\n\nAim for under 200 prose words excluding code. Include all TypeScript imports and referenced definitions. Avoid roadmap claims, implementation detail, a long feature inventory, or repeated calls to action.\n\n## 6. Validate\n\n1. Confirm the folder date, `published`, title, description, keywords, and image slug agree.\n2. Check the code against the source PR and current documentation.\n3. Run the narrowest available website formatting/type checks, then `pnpm --dir website build` when dependencies and checkout scope allow it.\n4. Review `jj diff` and `jj status`; keep unrelated changes out of the revision.\n5. Confirm the blog image URL returns successfully before leaving `image: true` enabled.\n6. Derive the canonical URL from the post file instead of rewriting the slug by hand:\n\n```bash\nPOST_FILE=\"website/src/content/posts/YYYY-MM-DD-/page.mdx\"\nPOST_ID=\"$(basename \"$(dirname \"$POST_FILE\")\")\"\nPOST_CATEGORY=\"$(awk '/^category:/ { print $2; exit }' \"$POST_FILE\")\"\nPOST_SECTION=\"blog\"\nif [ \"$POST_CATEGORY\" = \"changelog\" ]; then\n POST_SECTION=\"changelog\"\nfi\nCANONICAL_URL=\"https://rivet.dev/$POST_SECTION/$POST_ID/\"\nprintf '%s\\n' \"$CANONICAL_URL\"\n```\n\nCross-check the result against `website/src/pages/changelog/[...slug].astro` or `website/src/pages/blog/[...slug].astro`, and use the exact same URL in the Buffer reply. If the post is deployed, require the exact URL including its trailing slash to return HTTP 200. Also probe any shorter hand-written alternative; a 404 is evidence that it must not be used. For an unmerged future post, verify the source-derived route before scheduling and repeat the HTTP check after deployment but before publication.\n\n## 7. Open a draft PR and continue the review loop\n\nOnly push when the user has requested publishing to GitHub. Create an `agent/` bookmark for the revision, push that bookmark, and open a draft PR against `main`. Use a conventional PR title and a short bullet-list body covering the post, artwork, skill changes, and validation.\n\nReturn the PR URL and explicitly tell the user that they must review and merge it manually. Continue by drafting the technical image and Buffer options; do not treat PR creation as the end of the task. Apply the user's blog feedback locally, rerun relevant checks, and push the updated revision to the same PR. Never merge the launch PR on the user's behalf.\n\n## 8. Prepare the @rivet_dev Buffer thread\n\nDraft the Buffer options after the initial blog PR and technical image exist. Do not schedule anything until the user approves the blog post, technical image, main copy, reply thread, date, and exact time.\n\n1. Draft four distinct options for the main `@rivet_dev` post. Match the concise launch style: a direct opening line, the core value, and a few specific emoji-led points when useful. Do not put a URL in the main post.\n2. Prefer a code-first structure when the API surface is central to the launch. Surface the API bullets before supporting prose or secondary benefits so readers see the shipped interface immediately.\n3. Render short code identifiers with Unicode Mathematical Monospace characters instead of backticks. For example, render `c.cron.set` as `𝚌.𝚌𝚛𝚘𝚗.𝚜𝚎𝚝` and `c.schedule.after` as `𝚌.𝚜𝚌𝚑𝚎𝚍𝚞𝚕𝚎.𝚊𝚏𝚝𝚎𝚛`. Apply the treatment only to code fragments, preserve punctuation such as periods, and keep normal prose unstyled. Verify that Buffer renders every identifier legibly; fall back to ASCII if it does not.\n4. Format API bullets as ` → `. Use the right arrow, not an em dash, and keep the benefit lowercase unless it contains a proper noun.\n5. Keep every option strictly below X's 280-character limit. Target at most 250 Unicode code points and show the count beside each option. Before presenting any option, run this sanity check with the complete candidate text, including newlines and emoji; do not present or schedule text when the script exits nonzero:\n\n```bash\nLAUNCH_POST_TEXT=\"$CANDIDATE_TEXT\" node - <<'NODE'\nconst text = process.env.LAUNCH_POST_TEXT ?? \"\";\nconst count = Array.from(text).length;\nconsole.log(`${count} Unicode code points`);\nif (count >= 280) process.exit(1);\nNODE\n```\n\nTreat Buffer's composer counter as authoritative before scheduling because platform weighting can differ from the sanity check. Shorten any option Buffer reports as 280 or more.\n\n6. Draft these as four separate follow-up replies, using resolved URLs rather than placeholders:\n\n```text\nRead more: \nGitHub: \nDocumentation: \nDiscord: https://rivet.dev/discord\n```\n\n7. Ask the user to choose one main-post option or provide their own, edit or approve the four replies, and confirm the launch date. Once the user selects or supplies the copy, treat that version as canonical: stop proposing alternatives and change only the parts they request.\n8. Select a random whole-minute time from 7:30 through 8:30 AM in `America/Los_Angeles`, show the exact date, time, and timezone, and get explicit confirmation. The date must match the post's `published` date.\n\nAfter approval, prefer the Executor `buffer_mcp` integration and fall back to the authenticated Buffer web app only when the MCP lacks a required capability:\n\n1. Load the Executor `execute` guidance, search the `buffer_mcp` catalog, and use the exact connected tool paths returned by search. Do not guess paths or call Buffer's raw API.\n2. Call `get_account` first. If it returns multiple organizations, list them and get the user's choice; otherwise use the sole organization. Call `list_channels`, select the exact `rivet_dev` Twitter channel, then call `get_channel` and verify it is connected, unlocked, and configured for `America/Los_Angeles`.\n3. Call `list_posts` for that channel and launch date with `scheduled` and `sending` statuses. Stop if the same launch is already present instead of creating a duplicate.\n4. Call `create_post` with `schedulingType: \"automatic\"`, `mode: \"customScheduled\"`, and an ISO-8601 `dueAt` carrying the Pacific UTC offset. Put the approved main copy in both the outer `text` field and the first `metadata.twitter.thread` item; include all replies in that thread array. Put the approved `social.png` asset in both the outer `assets` array and the first `metadata.twitter.thread[0].assets` array, with no link in its text. Buffer may drop threaded media if it is supplied in only one location. Do not use `technical.png` instead or attach an optional dashboard screenshot unless the user explicitly approves that media and placement.\n5. Add the approved Read more, GitHub, Documentation, and Discord replies in that order. Do not collapse them into the main post.\n6. Call `get_post` and verify the post ID, `status: scheduled`, exact `rivet_dev` channel ID, complete text and reply order, due time, image source, dimensions and alt text, and `error: null`. Confirm the returned UTC time converts to the approved Pacific time.\n7. When changing a scheduled post, call `get_post` first and require `updatePost` in `allowedActions`. Buffer's `edit_post` is a whole-post replacement, not a patch: carry forward the scheduling mode, due time, all replies, metadata, and approved assets, then change only what the user requested. For a Twitter thread, include the existing image in both outer `assets` and `metadata.twitter.thread[0].assets`; immediately call `get_post` and repair the post before continuing if its returned `assets` array is empty. Run the character sanity check again and call `get_post` after editing.\n8. Return the Buffer post ID or URL and the verified schedule. Treat schedule-and-verify as the required Buffer publication gate.\n\nPrefer a direct media upload when the Buffer integration provides one. If the Executor Buffer MCP only accepts an image URL and has no upload tool, use this temporary single-file handoff instead of uploading the distribution image to Git or Rivet assets:\n\n1. Create a temporary directory outside the repository containing only the approved image, and serve it from a loopback-only HTTP server on an unused high port. Never expose the repository or the full output directory.\n2. Open a temporary public tunnel to that loopback server. Before scheduling, download the tunneled URL and confirm its SHA-256 checksum and dimensions match the local image.\n3. Pass the temporary image URL to Buffer with dimensions and descriptive alt text. Buffer retains this source URL; a successful `HEAD` or `GET` during creation does not prove that Buffer copied the image.\n4. Reopen the scheduled post through Buffer and verify `status: scheduled`, the channel, complete thread, due time, image URL, type and dimensions, and alt text. Load the image URL independently to confirm it still returns the approved file.\n5. Keep the loopback server and tunnel reachable until the post has published. After Buffer reports `status: sent` and the published post renders the image, stop both processes and delete the temporary directory. If reliable tunnel uptime through publication is not possible, do not use a quick tunnel; use Buffer's authenticated direct-upload UI or a user-approved stable host instead.\n\nNever commit the distribution image or tunnel URL, and never upload it to Rivet assets without explicit user approval.\n\nIf Buffer access, the verified company account, or threaded scheduling is unavailable, return the approved copy and exact schedule as a handoff. Never claim that the thread was scheduled.\n\nIf the hero variation, painting, logo marks, asset credentials, or release API is missing, complete the safe independent work and report the exact remaining checkpoint instead of fabricating it.\n",".opencode/skills/openspec-ff-change/SKILL.md":"---\nname: openspec-ff-change\ndescription: Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.1.1\"\n---\n\nFast-forward through artifact creation - generate everything needed to start implementation in one go.\n\n**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.\n\n**Steps**\n\n1. **If no clear input provided, ask what they want to build**\n\n Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:\n > \"What change do you want to work on? Describe what you want to build or fix.\"\n\n From their description, derive a kebab-case name (e.g., \"add user authentication\" → `add-user-auth`).\n\n **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.\n\n2. **Create the change directory**\n ```bash\n openspec new change \"\"\n ```\n This creates a scaffolded change at `openspec/changes//`.\n\n3. **Get the artifact build order**\n ```bash\n openspec status --change \"\" --json\n ```\n Parse the JSON to get:\n - `applyRequires`: array of artifact IDs needed before implementation (e.g., `[\"tasks\"]`)\n - `artifacts`: list of all artifacts with their status and dependencies\n\n4. **Create artifacts in sequence until apply-ready**\n\n Use the **TodoWrite tool** to track progress through the artifacts.\n\n Loop through artifacts in dependency order (artifacts with no pending dependencies first):\n\n a. **For each artifact that is `ready` (dependencies satisfied)**:\n - Get instructions:\n ```bash\n openspec instructions --change \"\" --json\n ```\n - The instructions JSON includes:\n - `context`: Project background (constraints for you - do NOT include in output)\n - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)\n - `template`: The structure to use for your output file\n - `instruction`: Schema-specific guidance for this artifact type\n - `outputPath`: Where to write the artifact\n - `dependencies`: Completed artifacts to read for context\n - Read any completed dependency files for context\n - Create the artifact file using `template` as the structure\n - Apply `context` and `rules` as constraints - but do NOT copy them into the file\n - Show brief progress: \"✓ Created \"\n\n b. **Continue until all `applyRequires` artifacts are complete**\n - After creating each artifact, re-run `openspec status --change \"\" --json`\n - Check if every artifact ID in `applyRequires` has `status: \"done\"` in the artifacts array\n - Stop when all `applyRequires` artifacts are done\n\n c. **If an artifact requires user input** (unclear context):\n - Use **AskUserQuestion tool** to clarify\n - Then continue with creation\n\n5. **Show final status**\n ```bash\n openspec status --change \"\"\n ```\n\n**Output**\n\nAfter completing all artifacts, summarize:\n- Change name and location\n- List of artifacts created with brief descriptions\n- What's ready: \"All artifacts created! Ready for implementation.\"\n- Prompt: \"Run `/opsx-apply` or ask me to implement to start working on the tasks.\"\n\n**Artifact Creation Guidelines**\n\n- Follow the `instruction` field from `openspec instructions` for each artifact type\n- The schema defines what each artifact should contain - follow it\n- Read dependency artifacts for context before creating new ones\n- Use `template` as the structure for your output file - fill in its sections\n- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file\n - Do NOT copy ``, ``, `` blocks into the artifact\n - These guide what you write, but should never appear in the output\n\n**Guardrails**\n- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)\n- Always read dependency artifacts before creating a new one\n- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum\n- If a change with that name already exists, suggest continuing that change instead\n- Verify each artifact file exists after writing before proceeding to next\n",".opencode/skills/openspec-archive-change/SKILL.md":"---\nname: openspec-archive-change\ndescription: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.1.1\"\n---\n\nArchive a completed change in the experimental workflow.\n\n**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.\n\n**Steps**\n\n1. **If no change name provided, prompt for selection**\n\n Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.\n\n Show only active changes (not already archived).\n Include the schema used for each change if available.\n\n **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.\n\n2. **Check artifact completion status**\n\n Run `openspec status --change \"\" --json` to check artifact completion.\n\n Parse the JSON to understand:\n - `schemaName`: The workflow being used\n - `artifacts`: List of artifacts with their status (`done` or other)\n\n **If any artifacts are not `done`:**\n - Display warning listing incomplete artifacts\n - Use **AskUserQuestion tool** to confirm user wants to proceed\n - Proceed if user confirms\n\n3. **Check task completion status**\n\n Read the tasks file (typically `tasks.md`) to check for incomplete tasks.\n\n Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).\n\n **If incomplete tasks found:**\n - Display warning showing count of incomplete tasks\n - Use **AskUserQuestion tool** to confirm user wants to proceed\n - Proceed if user confirms\n\n **If no tasks file exists:** Proceed without task-related warning.\n\n4. **Assess delta spec sync state**\n\n Check for delta specs at `openspec/changes//specs/`. If none exist, proceed without sync prompt.\n\n **If delta specs exist:**\n - Compare each delta spec with its corresponding main spec at `openspec/specs//spec.md`\n - Determine what changes would be applied (adds, modifications, removals, renames)\n - Show a combined summary before prompting\n\n **Prompt options:**\n - If changes needed: \"Sync now (recommended)\", \"Archive without syncing\"\n - If already synced: \"Archive now\", \"Sync anyway\", \"Cancel\"\n\n If user chooses sync, execute /opsx-sync logic (use the openspec-sync-specs skill). Proceed to archive regardless of choice.\n\n5. **Perform the archive**\n\n Create the archive directory if it doesn't exist:\n ```bash\n mkdir -p openspec/changes/archive\n ```\n\n Generate target name using current date: `YYYY-MM-DD-`\n\n **Check if target already exists:**\n - If yes: Fail with error, suggest renaming existing archive or using different date\n - If no: Move the change directory to archive\n\n ```bash\n mv openspec/changes/ openspec/changes/archive/YYYY-MM-DD-\n ```\n\n6. **Display summary**\n\n Show archive completion summary including:\n - Change name\n - Schema that was used\n - Archive location\n - Whether specs were synced (if applicable)\n - Note about any warnings (incomplete artifacts/tasks)\n\n**Output On Success**\n\n```\n## Archive Complete\n\n**Change:** \n**Schema:** \n**Archived to:** openspec/changes/archive/YYYY-MM-DD-/\n**Specs:** ✓ Synced to main specs (or \"No delta specs\" or \"Sync skipped\")\n\nAll artifacts complete. All tasks complete.\n```\n\n**Guardrails**\n- Always prompt for change selection if not provided\n- Use artifact graph (openspec status --json) for completion checking\n- Don't block archive on warnings - just inform and confirm\n- Preserve .openspec.yaml when moving to archive (it moves with the directory)\n- Show clear summary of what happened\n- If sync is requested, use openspec-sync-specs approach (agent-driven)\n- If delta specs exist, always run the sync assessment and show the combined summary before prompting\n",".opencode/skills/openspec-continue-change/SKILL.md":"---\nname: openspec-continue-change\ndescription: Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.1.1\"\n---\n\nContinue working on a change by creating the next artifact.\n\n**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.\n\n**Steps**\n\n1. **If no change name provided, prompt for selection**\n\n Run `openspec list --json` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.\n\n Present the top 3-4 most recently modified changes as options, showing:\n - Change name\n - Schema (from `schema` field if present, otherwise \"spec-driven\")\n - Status (e.g., \"0/5 tasks\", \"complete\", \"no tasks\")\n - How recently it was modified (from `lastModified` field)\n\n Mark the most recently modified change as \"(Recommended)\" since it's likely what the user wants to continue.\n\n **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.\n\n2. **Check current status**\n ```bash\n openspec status --change \"\" --json\n ```\n Parse the JSON to understand current state. The response includes:\n - `schemaName`: The workflow schema being used (e.g., \"spec-driven\")\n - `artifacts`: Array of artifacts with their status (\"done\", \"ready\", \"blocked\")\n - `isComplete`: Boolean indicating if all artifacts are complete\n\n3. **Act based on status**:\n\n ---\n\n **If all artifacts are complete (`isComplete: true`)**:\n - Congratulate the user\n - Show final status including the schema used\n - Suggest: \"All artifacts created! You can now implement this change or archive it.\"\n - STOP\n\n ---\n\n **If artifacts are ready to create** (status shows artifacts with `status: \"ready\"`):\n - Pick the FIRST artifact with `status: \"ready\"` from the status output\n - Get its instructions:\n ```bash\n openspec instructions --change \"\" --json\n ```\n - Parse the JSON. The key fields are:\n - `context`: Project background (constraints for you - do NOT include in output)\n - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)\n - `template`: The structure to use for your output file\n - `instruction`: Schema-specific guidance\n - `outputPath`: Where to write the artifact\n - `dependencies`: Completed artifacts to read for context\n - **Create the artifact file**:\n - Read any completed dependency files for context\n - Use `template` as the structure - fill in its sections\n - Apply `context` and `rules` as constraints when writing - but do NOT copy them into the file\n - Write to the output path specified in instructions\n - Show what was created and what's now unlocked\n - STOP after creating ONE artifact\n\n ---\n\n **If no artifacts are ready (all blocked)**:\n - This shouldn't happen with a valid schema\n - Show status and suggest checking for issues\n\n4. **After creating an artifact, show progress**\n ```bash\n openspec status --change \"\"\n ```\n\n**Output**\n\nAfter each invocation, show:\n- Which artifact was created\n- Schema workflow being used\n- Current progress (N/M complete)\n- What artifacts are now unlocked\n- Prompt: \"Want to continue? Just ask me to continue or tell me what to do next.\"\n\n**Artifact Creation Guidelines**\n\nThe artifact types and their purpose depend on the schema. Use the `instruction` field from the instructions output to understand what to create.\n\nCommon artifact patterns:\n\n**spec-driven schema** (proposal → specs → design → tasks):\n- **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.\n - The Capabilities section is critical - each capability listed will need a spec file.\n- **specs//spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).\n- **design.md**: Document technical decisions, architecture, and implementation approach.\n- **tasks.md**: Break down implementation into checkboxed tasks.\n\nFor other schemas, follow the `instruction` field from the CLI output.\n\n**Guardrails**\n- Create ONE artifact per invocation\n- Always read dependency artifacts before creating a new one\n- Never skip artifacts or create out of order\n- If context is unclear, ask the user before creating\n- Verify the artifact file exists after writing before marking progress\n- Use the schema's artifact sequence, don't assume specific artifact names\n- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file\n - Do NOT copy ``, ``, `` blocks into the artifact\n - These guide what you write, but should never appear in the output\n",".opencode/skills/graphite-is-being-a-piece-of-shit-just-merge-my-stack/SKILL.md":"../../../.codex/skills/graphite-is-being-a-piece-of-shit-just-merge-my-stack/SKILL.md",".opencode/skills/openspec-explore/SKILL.md":"---\nname: openspec-explore\ndescription: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.1.1\"\n---\n\nEnter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.\n\n**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first (e.g., start a change with `/opsx-new` or `/opsx-ff`). You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.\n\n**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.\n\n---\n\n## The Stance\n\n- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script\n- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.\n- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking\n- **Adaptive** - Follow interesting threads, pivot when new information emerges\n- **Patient** - Don't rush to conclusions, let the shape of the problem emerge\n- **Grounded** - Explore the actual codebase when relevant, don't just theorize\n\n---\n\n## What You Might Do\n\nDepending on what the user brings, you might:\n\n**Explore the problem space**\n- Ask clarifying questions that emerge from what they said\n- Challenge assumptions\n- Reframe the problem\n- Find analogies\n\n**Investigate the codebase**\n- Map existing architecture relevant to the discussion\n- Find integration points\n- Identify patterns already in use\n- Surface hidden complexity\n\n**Compare options**\n- Brainstorm multiple approaches\n- Build comparison tables\n- Sketch tradeoffs\n- Recommend a path (if asked)\n\n**Visualize**\n```\n┌─────────────────────────────────────────┐\n│ Use ASCII diagrams liberally │\n├─────────────────────────────────────────┤\n│ │\n│ ┌────────┐ ┌────────┐ │\n│ │ State │────────▶│ State │ │\n│ │ A │ │ B │ │\n│ └────────┘ └────────┘ │\n│ │\n│ System diagrams, state machines, │\n│ data flows, architecture sketches, │\n│ dependency graphs, comparison tables │\n│ │\n└─────────────────────────────────────────┘\n```\n\n**Surface risks and unknowns**\n- Identify what could go wrong\n- Find gaps in understanding\n- Suggest spikes or investigations\n\n---\n\n## OpenSpec Awareness\n\nYou have full context of the OpenSpec system. Use it naturally, don't force it.\n\n### Check for context\n\nAt the start, quickly check what exists:\n```bash\nopenspec list --json\n```\n\nThis tells you:\n- If there are active changes\n- Their names, schemas, and status\n- What the user might be working on\n\n### When no change exists\n\nThink freely. When insights crystallize, you might offer:\n\n- \"This feels solid enough to start a change. Want me to create one?\"\n → Can transition to `/opsx-new` or `/opsx-ff`\n- Or keep exploring - no pressure to formalize\n\n### When a change exists\n\nIf the user mentions a change or you detect one is relevant:\n\n1. **Read existing artifacts for context**\n - `openspec/changes//proposal.md`\n - `openspec/changes//design.md`\n - `openspec/changes//tasks.md`\n - etc.\n\n2. **Reference them naturally in conversation**\n - \"Your design mentions using Redis, but we just realized SQLite fits better...\"\n - \"The proposal scopes this to premium users, but we're now thinking everyone...\"\n\n3. **Offer to capture when decisions are made**\n\n | Insight Type | Where to Capture |\n |--------------|------------------|\n | New requirement discovered | `specs//spec.md` |\n | Requirement changed | `specs//spec.md` |\n | Design decision made | `design.md` |\n | Scope changed | `proposal.md` |\n | New work identified | `tasks.md` |\n | Assumption invalidated | Relevant artifact |\n\n Example offers:\n - \"That's a design decision. Capture it in design.md?\"\n - \"This is a new requirement. Add it to specs?\"\n - \"This changes scope. Update the proposal?\"\n\n4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.\n\n---\n\n## What You Don't Have To Do\n\n- Follow a script\n- Ask the same questions every time\n- Produce a specific artifact\n- Reach a conclusion\n- Stay on topic if a tangent is valuable\n- Be brief (this is thinking time)\n\n---\n\n## Handling Different Entry Points\n\n**User brings a vague idea:**\n```\nUser: I'm thinking about adding real-time collaboration\n\nYou: Real-time collab is a big space. Let me think about this...\n\n COLLABORATION SPECTRUM\n ════════════════════════════════════════════\n\n Awareness Coordination Sync\n │ │ │\n ▼ ▼ ▼\n ┌────────┐ ┌────────┐ ┌────────┐\n │Presence│ │Cursors │ │ CRDT │\n │ \"3 │ │ Multi │ │Conflict│\n │online\" │ │ select │ │ free │\n └────────┘ └────────┘ └────────┘\n │ │ │\n trivial moderate complex\n\n Where's your head at?\n```\n\n**User brings a specific problem:**\n```\nUser: The auth system is a mess\n\nYou: [reads codebase]\n\n ┌─────────────────────────────────────────────┐\n │ CURRENT AUTH FLOW │\n └─────────────────────────────────────────────┘\n │\n ┌─────────────┼─────────────┐\n ▼ ▼ ▼\n ┌─────────┐ ┌─────────┐ ┌─────────┐\n │ Google │ │ GitHub │ │ Email │\n │ OAuth │ │ OAuth │ │ Magic │\n └────┬────┘ └────┬────┘ └────┬────┘\n │ │ │\n └─────────────┼─────────────┘\n ▼\n ┌───────────┐\n │ Session │\n └─────┬─────┘\n │\n ▼\n ┌───────────┐\n │ Perms │\n └───────────┘\n\n I see three tangles. Which one's burning?\n```\n\n**User is stuck mid-implementation:**\n```\nUser: /opsx-explore add-auth-system\n The OAuth integration is more complex than expected\n\nYou: [reads change artifacts]\n\n You're on task 4: \"Implement OAuth flow\"\n\n Let me trace what's involved...\n\n [draws diagram, explores options, suggests paths]\n\n Want to update the design to reflect this?\n Or add a spike task to investigate?\n```\n\n**User wants to compare options:**\n```\nUser: Should we use Postgres or SQLite?\n\nYou: Generic answer is boring. What's the context?\n\nUser: A CLI tool that tracks local dev environments\n\nYou: That changes everything.\n\n ┌─────────────────────────────────────────────────┐\n │ CLI TOOL DATA STORAGE │\n └─────────────────────────────────────────────────┘\n\n Key constraints:\n • No daemon running\n • Must work offline\n • Single user\n\n SQLite Postgres\n Deployment embedded ✓ needs server ✗\n Offline yes ✓ no ✗\n Single file yes ✓ no ✗\n\n SQLite. Not even close.\n\n Unless... is there a sync component?\n```\n\n---\n\n## Ending Discovery\n\nThere's no required ending. Discovery might:\n\n- **Flow into action**: \"Ready to start? /opsx-new or /opsx-ff\"\n- **Result in artifact updates**: \"Updated design.md with these decisions\"\n- **Just provide clarity**: User has what they need, moves on\n- **Continue later**: \"We can pick this up anytime\"\n\nWhen it feels like things are crystallizing, you might summarize:\n\n```\n## What We Figured Out\n\n**The problem**: [crystallized understanding]\n\n**The approach**: [if one emerged]\n\n**Open questions**: [if any remain]\n\n**Next steps** (if ready):\n- Create a change: /opsx-new \n- Fast-forward to tasks: /opsx-ff \n- Keep exploring: just keep talking\n```\n\nBut this summary is optional. Sometimes the thinking IS the value.\n\n---\n\n## Guardrails\n\n- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.\n- **Don't fake understanding** - If something is unclear, dig deeper\n- **Don't rush** - Discovery is thinking time, not task time\n- **Don't force structure** - Let patterns emerge naturally\n- **Don't auto-capture** - Offer to save insights, don't just do it\n- **Do visualize** - A good diagram is worth many paragraphs\n- **Do explore the codebase** - Ground discussions in reality\n- **Do question assumptions** - Including the user's and your own\n",".opencode/skills/openspec-bulk-archive-change/SKILL.md":"---\nname: openspec-bulk-archive-change\ndescription: Archive multiple completed changes at once. Use when archiving several parallel changes.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.1.1\"\n---\n\nArchive multiple completed changes in a single operation.\n\nThis skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.\n\n**Input**: None required (prompts for selection)\n\n**Steps**\n\n1. **Get active changes**\n\n Run `openspec list --json` to get all active changes.\n\n If no active changes exist, inform user and stop.\n\n2. **Prompt for change selection**\n\n Use **AskUserQuestion tool** with multi-select to let user choose changes:\n - Show each change with its schema\n - Include an option for \"All changes\"\n - Allow any number of selections (1+ works, 2+ is the typical use case)\n\n **IMPORTANT**: Do NOT auto-select. Always let the user choose.\n\n3. **Batch validation - gather status for all selected changes**\n\n For each selected change, collect:\n\n a. **Artifact status** - Run `openspec status --change \"\" --json`\n - Parse `schemaName` and `artifacts` list\n - Note which artifacts are `done` vs other states\n\n b. **Task completion** - Read `openspec/changes//tasks.md`\n - Count `- [ ]` (incomplete) vs `- [x]` (complete)\n - If no tasks file exists, note as \"No tasks\"\n\n c. **Delta specs** - Check `openspec/changes//specs/` directory\n - List which capability specs exist\n - For each, extract requirement names (lines matching `### Requirement: `)\n\n4. **Detect spec conflicts**\n\n Build a map of `capability -> [changes that touch it]`:\n\n ```\n auth -> [change-a, change-b] <- CONFLICT (2+ changes)\n api -> [change-c] <- OK (only 1 change)\n ```\n\n A conflict exists when 2+ selected changes have delta specs for the same capability.\n\n5. **Resolve conflicts agentically**\n\n **For each conflict**, investigate the codebase:\n\n a. **Read the delta specs** from each conflicting change to understand what each claims to add/modify\n\n b. **Search the codebase** for implementation evidence:\n - Look for code implementing requirements from each delta spec\n - Check for related files, functions, or tests\n\n c. **Determine resolution**:\n - If only one change is actually implemented -> sync that one's specs\n - If both implemented -> apply in chronological order (older first, newer overwrites)\n - If neither implemented -> skip spec sync, warn user\n\n d. **Record resolution** for each conflict:\n - Which change's specs to apply\n - In what order (if both)\n - Rationale (what was found in codebase)\n\n6. **Show consolidated status table**\n\n Display a table summarizing all changes:\n\n ```\n | Change | Artifacts | Tasks | Specs | Conflicts | Status |\n |---------------------|-----------|-------|---------|-----------|--------|\n | schema-management | Done | 5/5 | 2 delta | None | Ready |\n | project-config | Done | 3/3 | 1 delta | None | Ready |\n | add-oauth | Done | 4/4 | 1 delta | auth (!) | Ready* |\n | add-verify-skill | 1 left | 2/5 | None | None | Warn |\n ```\n\n For conflicts, show the resolution:\n ```\n * Conflict resolution:\n - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)\n ```\n\n For incomplete changes, show warnings:\n ```\n Warnings:\n - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks\n ```\n\n7. **Confirm batch operation**\n\n Use **AskUserQuestion tool** with a single confirmation:\n\n - \"Archive N changes?\" with options based on status\n - Options might include:\n - \"Archive all N changes\"\n - \"Archive only N ready changes (skip incomplete)\"\n - \"Cancel\"\n\n If there are incomplete changes, make clear they'll be archived with warnings.\n\n8. **Execute archive for each confirmed change**\n\n Process changes in the determined order (respecting conflict resolution):\n\n a. **Sync specs** if delta specs exist:\n - Use the openspec-sync-specs approach (agent-driven intelligent merge)\n - For conflicts, apply in resolved order\n - Track if sync was done\n\n b. **Perform the archive**:\n ```bash\n mkdir -p openspec/changes/archive\n mv openspec/changes/ openspec/changes/archive/YYYY-MM-DD-\n ```\n\n c. **Track outcome** for each change:\n - Success: archived successfully\n - Failed: error during archive (record error)\n - Skipped: user chose not to archive (if applicable)\n\n9. **Display summary**\n\n Show final results:\n\n ```\n ## Bulk Archive Complete\n\n Archived 3 changes:\n - schema-management-cli -> archive/2026-01-19-schema-management-cli/\n - project-config -> archive/2026-01-19-project-config/\n - add-oauth -> archive/2026-01-19-add-oauth/\n\n Skipped 1 change:\n - add-verify-skill (user chose not to archive incomplete)\n\n Spec sync summary:\n - 4 delta specs synced to main specs\n - 1 conflict resolved (auth: applied both in chronological order)\n ```\n\n If any failures:\n ```\n Failed 1 change:\n - some-change: Archive directory already exists\n ```\n\n**Conflict Resolution Examples**\n\nExample 1: Only one implemented\n```\nConflict: specs/auth/spec.md touched by [add-oauth, add-jwt]\n\nChecking add-oauth:\n- Delta adds \"OAuth Provider Integration\" requirement\n- Searching codebase... found src/auth/oauth.ts implementing OAuth flow\n\nChecking add-jwt:\n- Delta adds \"JWT Token Handling\" requirement\n- Searching codebase... no JWT implementation found\n\nResolution: Only add-oauth is implemented. Will sync add-oauth specs only.\n```\n\nExample 2: Both implemented\n```\nConflict: specs/api/spec.md touched by [add-rest-api, add-graphql]\n\nChecking add-rest-api (created 2026-01-10):\n- Delta adds \"REST Endpoints\" requirement\n- Searching codebase... found src/api/rest.ts\n\nChecking add-graphql (created 2026-01-15):\n- Delta adds \"GraphQL Schema\" requirement\n- Searching codebase... found src/api/graphql.ts\n\nResolution: Both implemented. Will apply add-rest-api specs first,\nthen add-graphql specs (chronological order, newer takes precedence).\n```\n\n**Output On Success**\n\n```\n## Bulk Archive Complete\n\nArchived N changes:\n- -> archive/YYYY-MM-DD-/\n- -> archive/YYYY-MM-DD-/\n\nSpec sync summary:\n- N delta specs synced to main specs\n- No conflicts (or: M conflicts resolved)\n```\n\n**Output On Partial Success**\n\n```\n## Bulk Archive Complete (partial)\n\nArchived N changes:\n- -> archive/YYYY-MM-DD-/\n\nSkipped M changes:\n- (user chose not to archive incomplete)\n\nFailed K changes:\n- : Archive directory already exists\n```\n\n**Output When No Changes**\n\n```\n## No Changes to Archive\n\nNo active changes found. Use `/opsx-new` to create a new change.\n```\n\n**Guardrails**\n- Allow any number of changes (1+ is fine, 2+ is the typical use case)\n- Always prompt for selection, never auto-select\n- Detect spec conflicts early and resolve by checking codebase\n- When both changes are implemented, apply specs in chronological order\n- Skip spec sync only when implementation is missing (warn user)\n- Show clear per-change status before confirming\n- Use single confirmation for entire batch\n- Track and report all outcomes (success/skip/fail)\n- Preserve .openspec.yaml when moving to archive\n- Archive directory target uses current date: YYYY-MM-DD-\n- If archive target exists, fail that change but continue with others\n",".opencode/skills/openspec-apply-change/SKILL.md":"---\nname: openspec-apply-change\ndescription: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.\nlicense: MIT\ncompatibility: Requires openspec CLI.\nmetadata:\n author: openspec\n version: \"1.0\"\n generatedBy: \"1.1.1\"\n---\n\nImplement tasks from an OpenSpec change.\n\n**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.\n\n**Steps**\n\n1. **Select the change**\n\n If a name is provided, use it. Otherwise:\n - Infer from conversation context if the user mentioned a change\n - Auto-select if only one active change exists\n - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select\n\n Always announce: \"Using change: \" and how to override (e.g., `/opsx-apply `).\n\n2. **Check status to understand the schema**\n ```bash\n openspec status --change \"\" --json\n ```\n Parse the JSON to understand:\n - `schemaName`: The workflow being used (e.g., \"spec-driven\")\n - Which artifact contains the tasks (typically \"tasks\" for spec-driven, check status for others)\n\n3. **Get apply instructions**\n\n ```bash\n openspec instructions apply --change \"\" --json\n ```\n\n This returns:\n - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)\n - Progress (total, complete, remaining)\n - Task list with status\n - Dynamic instruction based on current state\n\n **Handle states:**\n - If `state: \"blocked\"` (missing artifacts): show message, suggest using openspec-continue-change\n - If `state: \"all_done\"`: congratulate, suggest archive\n - Otherwise: proceed to implementation\n\n4. **Read context files**\n\n Read the files listed in `contextFiles` from the apply instructions output.\n The files depend on the schema being used:\n - **spec-driven**: proposal, specs, design, tasks\n - Other schemas: follow the contextFiles from CLI output\n\n5. **Show current progress**\n\n Display:\n - Schema being used\n - Progress: \"N/M tasks complete\"\n - Remaining tasks overview\n - Dynamic instruction from CLI\n\n6. **Implement tasks (loop until done or blocked)**\n\n For each pending task:\n - Show which task is being worked on\n - Make the code changes required\n - Keep changes minimal and focused\n - Mark task complete in the tasks file: `- [ ]` → `- [x]`\n - Continue to next task\n\n **Pause if:**\n - Task is unclear → ask for clarification\n - Implementation reveals a design issue → suggest updating artifacts\n - Error or blocker encountered → report and wait for guidance\n - User interrupts\n\n7. **On completion or pause, show status**\n\n Display:\n - Tasks completed this session\n - Overall progress: \"N/M tasks complete\"\n - If all done: suggest archive\n - If paused: explain why and wait for guidance\n\n**Output During Implementation**\n\n```\n## Implementing: (schema: )\n\nWorking on task 3/7: \n[...implementation happening...]\n✓ Task complete\n\nWorking on task 4/7: \n[...implementation happening...]\n✓ Task complete\n```\n\n**Output On Completion**\n\n```\n## Implementation Complete\n\n**Change:** \n**Schema:** \n**Progress:** 7/7 tasks complete ✓\n\n### Completed This Session\n- [x] Task 1\n- [x] Task 2\n...\n\nAll tasks complete! Ready to archive this change.\n```\n\n**Output On Pause (Issue Encountered)**\n\n```\n## Implementation Paused\n\n**Change:** \n**Schema:** \n**Progress:** 4/7 tasks complete\n\n### Issue Encountered\n\n\n**Options:**\n1.