com um clique
potion-yjs-dev-browser-test
Use when a Slate Yjs collaboration behavior is suspicious and Potion should be used as a live reference implementation through dev-browser, especially for offline/reconnect, selection, or history scenarios.
Menu
Use when a Slate Yjs collaboration behavior is suspicious and Potion should be used as a live reference implementation through dev-browser, especially for offline/reconnect, selection, or history scenarios.
Run a structured code review (Codex default, Claude optional) as a closeout check on a local or PR branch before commit or ship.
Clone shadcn implementation patterns with source-by-source parity. Use when the user says "shadcn parity", asks to mirror shadcn, copy shadcn UX/architecture/tests, or wants more than inspiration.
Autogoal-backed planning, status, review, dashboard, apply, and tracking for upstream shadcn docs syncs into Plate docs. Use when the user asks for `sync-shadcn`, `sync-shadcn status`, `sync-shadcn review`, `sync-shadcn dashboard`, `sync-shadcn apply`, a scoped `sync-shadcn <feature>` lane, to sync shadcn docs, audit newer shadcn docs changes, compare `../shadcn/apps/v4` with `apps/www`, update the shadcn sync baseline, or decide what to adopt, fork, defer, or exclude from upstream shadcn.
Work heavyweight framework or library tasks with planning-first research, selective deep analysis, and rigorous handoff
Constitutional source of truth for reusable Plate architecture and public API design. Use when introducing or changing reusable public APIs, runtime/service boundaries, builder or factory patterns, extension registration contracts, naming/layering rules, or performance-sensitive architecture.
Review performance lanes with GitHub-scale tactics not owned by Vercel React rules: cohort segmentation, repeated-unit budgets, interaction-level INP, memory tagging, degradation contracts, browser trace proof, and production dashboards.
| description | Use when a Slate Yjs collaboration behavior is suspicious and Potion should be used as a live reference implementation through dev-browser, especially for offline/reconnect, selection, or history scenarios. |
| name | potion-yjs-dev-browser-test |
| metadata | {"skiller":{"source":".agents/rules/potion-yjs-dev-browser-test.mdc"}} |
Use Potion as a live behavioral oracle, not as the product under test. The skill records how to isolate one Potion tab offline with dev-browser and then replay the current bug's repro steps. Do not bake one historical repro into the workflow.
127.0.0.1:9222.potion-yjs-reference-a and potion-yjs-reference-b, pointing at the same Potion URL.page.context().setOffline(true) for this workflow; it affects the whole browser context and usually disconnects both tabs.Do not keep a reusable script in this skill. Each collaboration bug has different setup, operations, waits, and assertions. A fixed script becomes stale fast and tempts agents to rerun yesterday's bug.
For each new case, write a small one-off dev-browser --connect http://127.0.0.1:9222 <<'EOF' script from the current repro steps. Keep it in the terminal or .tmp/ only if it needs iteration; do not promote it into the skill unless the user explicitly asks for a durable tool.
Use this shape inside the current repro script:
const pageA = await browser.getPage('potion-yjs-reference-a');
const pageB = await browser.getPage('potion-yjs-reference-b');
const cdpB = await pageB.context().newCDPSession(pageB);
await cdpB.send('Network.enable');
await cdpB.send('Network.emulateNetworkConditions', {
offline: true,
latency: 0,
downloadThroughput: 0,
uploadThroughput: 0,
});
// Run B-local offline repro steps here.
await cdpB.send('Network.emulateNetworkConditions', {
offline: false,
latency: 0,
downloadThroughput: -1,
uploadThroughput: -1,
});
Before editing, probe network isolation:
For each new case, write a small dev-browser script from the user's steps:
[data-slate-editor="true"].