[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MGSAP39MRDNFM93RXXA270":3,"skill-same:01M6MGSAP39MRDNFM93RXXA270":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6MGSAP39MRDNFM93RXXA270","lab",null,"Build a Game Lab for one mechanic of a studio's game (the jump, a hit, a dash, a drift, a landing) and iterate on how it FEELS with the creator, side by side. The lab plays one short take in two builds at once, New (the working tree) and Today (the last commit), on one clock with the same seed and presses, slowed to a tenth or stepped a frame at a time, with a timeline of named phases, graphs of tracked values New against Today, the game's own onion skins and arcs, preset views, a phone-size view, and live sliders that write kept values back into the game's tunables.json. Use when someone says \"iterate on the jump\", \"make the hit feel punchier\", \"tune the drift\", \"the dash feels floaty\", \"the landing is stiff\", \"add juice\", \"hit-stop\", \"squash and stretch\", \"screen shake\", or asks for an animation or feel editor for their game.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1566,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fhomie-rocks\u002Fhomie\u002Fskills\u002Flab\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"time","new","when","dash","at","studio","make","add","screen","live","commit","seed","drift","back","stop","take","write","short","game","how","Animation","2026-11-10 10:12:30",false,"---\nname: lab\ndescription: Build a Game Lab for one mechanic of a studio's game (the jump, a hit, a dash, a drift, a landing) and iterate on how it FEELS with the creator, side by side. The lab plays one short take in two builds at once, New (the working tree) and Today (the last commit), on one clock with the same seed and presses, slowed to a tenth or stepped a frame at a time, with a timeline of named phases, graphs of tracked values New against Today, the game's own onion skins and arcs, preset views, a phone-size view, and live sliders that write kept values back into the game's tunables.json. Use when someone says \"iterate on the jump\", \"make the hit feel punchier\", \"tune the drift\", \"the dash feels floaty\", \"the landing is stiff\", \"add juice\", \"hit-stop\", \"squash and stretch\", \"screen shake\", or asks for an animation or feel editor for their game.\n---\n\n# The Game Lab: one mechanic, New against Today\n\nA studio is the folder with `studio.json`. The lab is `npx --no-install homie-studio lab \u003Cgame>` (from\n`@homie-rocks\u002Fstudio` 0.20.0): a page on this computer that plays a **take** (games\u002F\u003Cgame>\u002Flab.json) in **New** (the\nworking tree, rebuilt on every save) beside **Today** (HEAD, or `--today \u003Cref>`). Both run on the lab's clock: frame f\nis exactly f\u002Ffps seconds, the dice are seeded, the presses land on the same frames, so a take plays the same every\ntime and the two builds can be compared frame by frame. The page checks that too: \"Replays match\" (or where they\ndiffer). `homie-studio lab check \u003Cgame>` plays the same take headless and writes numbers, a contact sheet and a still.\n\nThe game opts in with a few calls from `@homie-rocks\u002Fstudio\u002Flab` (every one a no-op outside the lab, so they stay in\nthe game). `references\u002FAPI.md` has every call, the take format and the multiplayer rules; `references\u002FPRINCIPLES.md`\nhas the principles of feel this skill works from, with honest sources.\n\n## 0. Before anything\n\n- `df -h .`: keep 10 GB free. Commit or stash what the person is working on: Today is a commit, and the lab never\n  touches git beyond reading it (Today is built from git's own checkout of the ref, in `.studio\u002Flab\u002F`, git-ignored).\n- Name the mechanic in one line with the person (\"the bump in Gem Rush: you wave, a body near you flies\"), and find it\n  in the code: the input that starts it, the state it changes, where it is drawn. Say which numbers shape it.\n\n## 1. Instrument it, change nothing, commit\n\nMake the lab able to see the mechanic **without changing how it feels** (Today must be the game as it is):\n\n1. **tunables.json** next to game.json: move the numbers that shape the mechanic into it, at their current values,\n   each with a range, a unit, a group and a note in plain words. Read them with `const T = lab.tunables(tuning)`.\n2. **Phases** at its natural beats: `lab.phase('LAUNCH', 'Leaves at full speed, slows evenly')`, `lab.phase(null)`\n   when it is over. Short capital names; the note says what the phase is FOR. Name today's phases honestly: a\n   mechanic with no anticipation has no COIL.\n3. **Tracks** that show its motion: speed, height, distance, squash, a camera's offset (`lab.track(name, v, unit)`).\n   Speed from the position each frame (distance \u002F dt) is honest whatever the code does inside.\n4. **Poses and overlays**: `lab.pose('subject', { x, y, sx, sy, a })` each frame, and the game's own `onion` (ghosts\n   every few frames), `arcs` (the path with a dot a frame: spacing) and a `reach` or hit box (`lab.overlay`), drawn\n   by `lab.draw(ctx, scale)` in world space.\n5. **Views**: `lab.camera({ game: null, close: { zoom: 2.4 }, arena: { whole: true } })`; 3D: side, front, top, orbit.\n6. **Characters** (`@homie-rocks\u002Fstudio\u002Fanimate`): pass the lab's tunables to `loadCharacter(models, url, { tune: T })`\n   and copy its `ANIM_TUNING` (fade, walkSpeed, runSpeed, actSpeed, jumpStretch, landSquash, squashHz, lean, flinch,\n   lookAt, spring) into tunables.json's \"Motion\" group: the clips' blends, the squash and stretch and the lean become\n   sliders too. Report the character's own `state` (IDLE, RUN, JUMP, FALL, LAND, ATTACK, HIT) as phases when the move\n   is an animation. The `hero-rush-3d` starter's takes (\"jump\", \"swing\") show it; the `animate` skill has the rest.\n6. **A stage** when the mechanic needs a target (a dummy to hit, a ledge to jump from): `lab.stage === 'dummy'`\n   where the round starts. Only the lab ever sets it. Keep a real-play take too.\n7. **A take** in lab.json: a few seconds, a seed, the presses (`{ \"at\": 0.5, \"key\": \"Space\" }`), the view and track\n   to open on. Or record one: press REC in the lab and play it in NEW (both builds get the presses).\n\nGuard allocation: report from one `if (lab.on) labReport(dt)` a frame. Then:\n\n```sh\nnpx --no-install homie-studio lab check \u003Cgame>     # phases show, replays match, New = Today\ngit commit -m \"Lab: instrument \u003Cthe mechanic> (no change to how it feels)\"\n```\n\n## 2. Look for what it is missing, with the person\n\nOpen the lab (`npx --no-install homie-studio lab \u003Cgame>`, a background task; give the person the link; never open a\nbrowser yourself) and read the take at ¼ speed with the onion skin and arcs on. Say what you see in the terms of\n`references\u002FPRINCIPLES.md`: no anticipation, no impact moment (hit-stop), even spacing (no ease), a creep and a pop at\nthe end, no follow-through or overlap, a rigid body (no squash and stretch), a camera that never reacts.\n\nReferences: describe the principle and, if it helps, a well-known game where anyone can see it, in your own words.\nNever copy another game's art, code, sounds or frame data, and never state another game's exact numbers unless you\nmeasured them yourself from footage the person can see or a public source you name.\n\n## 3. Propose it as phases and tunables, then build New\n\nWrite the proposal as the phases the move will have and the number that shapes each one, for example:\n\n> HIT-STOP 70 ms (the body holds, white, squashed) → LAUNCH (leaves at 1500 px\u002Fs, stretched 30%) → SLIDE (eases into\n> the stop over 185 px, the same at 12 fps as at 60) → SETTLE 260 ms (squash, then a wobble: overlap).\n\nChange the game in the working tree; the lab rebuilds New on save and replays the take. Then:\n\n```sh\nnpx --no-install homie-studio lab check \u003Cgame>     # New against Today: phases, peaks, JavaScript per frame\n```\n\nRead REPORT.md and **look at sheet.png** (the lab at each phase's start, New beside Today) before you say anything\nabout it. Tell the person in a few lines: which phases New has that Today did not, the numbers that moved, and what\nto watch for in the lab. The person tunes with the sliders and presses **Keep in code** (written into\ntunables.json, one line a value), or tells you, and you run `npx --no-install homie-studio lab set \u003Cgame> name=value`.\n\n## 4. Multiplayer: every screen, the host's rules\n\nFor a rules game (`src\u002Frules.ts` plus `view.ts`), the Lab runs the same host runtime locally in each pane,\nincluding when the published game keeps `room.offline: false`. No Lab state reaches a room. Put gameplay\nnumbers in tunables.json; the runtime reads the sliders automatically, including `public.speed` for a value\nunder `public`. Keep them with `homie-studio lab set \u003Cgame> public.speed=7`. The take's stage reaches\n`world.stage` in the rules; use that for a target or a ledge, without importing the Lab into guarded rules.\nKeep `lab.phase`, `lab.track`, poses and overlays in the view. Both panes get the same seed and fixed clock.\n`lab check` must show actual gameplay tracks changing and the repeated take matching, not just an empty page.\n\n\nA studio game is played in a room. A feel change must look the same on every screen and keep the two-browser check\ngreen:\n\n- **Presentation from what every screen already has**: a declared rules effect (`world.emit` in rules, `room.on` in the view; `net.send` only in an unchanged older game)\n  or a change in the snapshot (a slime's hit points dropping). Flashes, squash, sparks and numbers are drawn locally.\n- **Gameplay on the host**: a hit-stop that holds a body, a push, a slide's curve. Make motion frame-rate independent\n  (a curve of time, not a per-frame multiply), so a 30 fps phone moves the same distance.\n- **Juice dice**: `lab.random()` for particles and shake, never Math.random() for lab presentation: the world's dice must be the same in\n  both builds for the lab to compare them, and lab.random() is Math.random() outside the lab.\n- A change that moves gameplay (a push that puts a target out of reach) shows in the lab's numbers: read them. One\n  push in this skill's own proof took a slime out of reach and the next two strikes missed; a lunge fixed it.\n\nThen the game's own check: `npm run dev` (background), `npx --no-install homie-studio check \u003Cgame> --url\nhttp:\u002F\u002F127.0.0.1:8787`. It must pass before anything is kept.\n\n## 5. When a feel change costs frames, say so with numbers\n\n`lab check` prints the game's JavaScript per frame, New against Today, on the same frames (the mean: Chrome times a\npage in steps of about 0.1 ms). It is a hint. For the real cost, the `perf` skill measures both builds in a room, on\nan emulated phone, in alternating pairs: `perf.mjs baseline \u003Cgame>` with games\u002F\u003Cgame>\u002F at Today (`git stash` the\nchange, or check out HEAD's copy of the folder), then the change back and `perf.mjs try \u003Cgame> --name \"\u003Cthe feel\nchange>\" --looks \"\u003Cwhat looks different>\" --plays \"\u003Cwhat plays different>\" --measure`. **--measure is required here**:\nwithout it `try` reverts anything that is not faster, and a feel change is kept for its feel, not its speed. Tell the\nperson the result in numbers: frames (p95), the main thread per frame, time to playable, against Today. In this\nskill's own proof the bump cost 0.09 ms of main thread a frame on the emulated phone (1.48 to 1.57 ms, +4.9%, within\nthe noise) with frames unchanged at 16.7 ms. Never say a feel change is free from the code.\n\n## 6. Keep what the person likes, then commit\n\nThe person decides. Revert what they did not like (only those lines, in games\u002F\u003Cgame>\u002F), keep the rest, run\n`lab check` and the two-browser check once more, then commit with the phases in the message:\n\n```sh\ngit add games\u002F\u003Cgame> && git commit -m \"\u003CGame>: the bump lands (hit-stop 70 ms), flies stretched, eases out, settles\"\n```\n\nRecord a side-by-side clip the person can share with the `video` skill's `record`, driving the lab page itself:\n`references\u002Frecord-lab.json` is a steps file (play at 1x, then ¼ with the onion skin, then step through the phases).\n`node \u003Cvideo.mjs> record lab-\u003Cgame> --steps \u003Csteps> --url http:\u002F\u002F127.0.0.1:8790`. Stop the lab when done:\n`npx --no-install homie-studio lab --stop` (this studio's only; it also removes the checkouts Today was built from).\n\n## Where people see it\n\n- **Claude Code**: the link `http:\u002F\u002F127.0.0.1:8790\u002F\u003Cgame>\u002F` (run the lab as a background task).\n- **Claude Desktop and claude.ai** (Homie Studio's local tools): the `game_lab` tool starts the lab and answers with\n  a card: a still of New beside Today at the take's busiest moment, the phases of each, the numbers, and Open.\n- **Anyone**: the recorded clip, and the commit, whose message names the phases.\n\n## Never\n\n- Never say it feels better from the code. Show the take; the person feels it.\n- Never change Today: instrumenting changes nothing a player feels, and is committed on its own first.\n- Never put a lab call where it allocates every frame outside the lab (`if (lab.on)` around reporting).\n- For view juice use lab.random() and the Lab clock. Rules use world.random and world.tick\u002Fdt; movement uses ctx.tick\u002Fdt\u002Fmath. Never import the Lab into rules.\n- Never edit a take to make New look better; record a new one and say why.\n- Never leave the lab running when the work is done (`lab --stop`), or open a browser for the person.\n","# The Game Lab: one mechanic, New against Today\n\nA studio is the folder with `studio.json`. The lab is `npx --no-install homie-studio lab \u003Cgame>` (from\n`@homie-rocks\u002Fstudio` 0.20.0): a page on this computer that plays a **take** (games\u002F\u003Cgame>\u002Flab.json) in **New** (the\nworking tree, rebuilt on every save) beside **Today** (HEAD, or `--today \u003Cref>`). Both run on the lab's clock: frame f\nis exactly f\u002Ffps seconds, the dice are seeded, the presses land on the same frames, so a take plays the same every\ntime and the two builds can be compared frame by frame. The page checks that too: \"Replays match\" (or where they\ndiffer). `homie-studio lab check \u003Cgame>` plays the same take headless and writes numbers, a contact sheet and a still.\n\nThe game opts in with a few calls from `@homie-rocks\u002Fstudio\u002Flab` (every one a no-op outside the lab, so they stay in\nthe game). `references\u002FAPI.md` has every call, the take format and the multiplayer rules; `references\u002FPRINCIPLES.md`\nhas the principles of feel this skill works from, with honest sources.\n\n## 0. Before anything\n\n- `df -h .`: keep 10 GB free. Commit or stash what the person is working on: Today is a commit, and the lab never\n  touches git beyond reading it (Today is built from git's own checkout of the ref, in `.studio\u002Flab\u002F`, git-ignored).\n- Name the mechanic in one line with the person (\"the bump in Gem Rush: you wave, a body near you flies\"), and find it\n  in the code: the input that starts it, the state it changes, where it is drawn. Say which numbers shape it.\n\n## 1. Instrument it, change nothing, commit\n\nMake the lab able to see the mechanic **without changing how it feels** (Today must be the game as it is):\n\n1. **tunables.json** next to game.json: move the numbers that shape the mechanic into it, at their current values,\n   each with a range, a unit, a group and a note in plain words. Read them with `const T = lab.tunables(tuning)`.\n2. **Phases** at its natural beats: `lab.phase('LAUNCH', 'Leaves at full speed, slows evenly')`, `lab.phase(null)`\n   when it is over. Short capital names; the note says what the phase is FOR. Name today's phases honestly: a\n   mechanic with no anticipation has no COIL.\n3. **Tracks** that show its motion: speed, height, distance, squash, a camera's offset (`lab.track(name, v, unit)`).\n   Speed from the position each frame (distance \u002F dt) is honest whatever the code does inside.\n4. **Poses and overlays**: `lab.pose('subject', { x, y, sx, sy, a })` each frame, and the game's own `onion` (ghosts\n   every few frames), `arcs` (the path with a dot a frame: spacing) and a `reach` or hit box (`lab.overlay`), drawn\n   by `lab.draw(ctx, scale)` in world space.\n5. **Views**: `lab.camera({ game: null, close: { zoom: 2.4 }, arena: { whole: true } })`; 3D: side, front, top, orbit.\n6. **Characters** (`@homie-rocks\u002Fstudio\u002Fanimate`): pass the lab's tunables to `loadCharacter(models, url, { tune: T })`\n   and copy its `ANIM_TUNING` (fade, walkSpeed, runSpeed, actSpeed, jumpStretch, landSquash, squashHz, lean, flinch,\n   lookAt, spring) into tunables.json's \"Motion\" group: the clips' blends, the squash and stretch and the lean become\n   sliders too. Report the character's own `state` (IDLE, RUN, JUMP, FALL, LAND, ATTACK, HIT) as phases when the move\n   is an animation. The `hero-rush-3d` starter's takes (\"jump\", \"swing\") show it; the `animate` skill has the rest.\n6. **A stage** when the mechanic needs a target (a dummy to hit, a ledge to jump from): `lab.stage === 'dummy'`\n   where the round starts. Only the lab ever sets it. Keep a real-play take too.\n7. **A take** in lab.json: a few seconds, a seed, the presses (`{ \"at\": 0.5, \"key\": \"Space\" }`), the view and track\n   to open on. Or record one: press REC in the lab and play it in NEW (both builds get the presses).\n\nGuard allocation: report from one `if (lab.on) labReport(dt)` a frame. Then:\n\n```sh\nnpx --no-install homie-studio lab check \u003Cgame>     # phases show, replays match, New = Today\ngit commit -m \"Lab: instrument \u003Cthe mechanic> (no change to how it feels)\"\n```\n\n## 2. Look for what it is missing, with the person\n\nOpen the lab (`npx --no-install homie-studio lab \u003Cgame>`, a background task; give the person the link; never open a\nbrowser yourself) and read the take at ¼ speed with the onion skin and arcs on. Say what you see in the terms of\n`references\u002FPRINCIPLES.md`: no anticipation, no impact moment (hit-stop), even spacing (no ease), a creep and a pop at\nthe end, no follow-through or overlap, a rigid body (no squash and stretch), a camera that never reacts.\n\nReferences: describe the principle and, if it helps, a well-known game where anyone can see it, in your own words.\nNever copy another game's art, code, sounds or frame data, and never state another game's exact numbers unless you\nmeasured them yourself from footage the person can see or a public source you name.\n\n## 3. Propose it as phases and tunables, then build New\n\nWrite the proposal as the phases the move will have and the number that shapes each one, for example:\n\n> HIT-STOP 70 ms (the body holds, white, squashed) → LAUNCH (leaves at 1500 px\u002Fs, stretched 30%) → SLIDE (eases into\n> the stop over 185 px, the same at 12 fps as at 60) → SETTLE 260 ms (squash, then a wobble: overlap).\n\nChange the game in the working tree; the lab rebuilds New on save and replays the take. Then:\n\n```sh\nnpx --no-install homie-studio lab check \u003Cgame>     # New against Today: phases, peaks, JavaScript per frame\n```\n\nRead REPORT.md and **look at sheet.png** (the lab at each phase's start, New beside Today) before you say anything\nabout it. Tell the person in a few lines: which phases New has that Today did not, the numbers that moved, and what\nto watch for in the lab. The person tunes with the sliders and presses **Keep in code** (written into\ntunables.json, one line a value), or tells you, and you run `npx --no-install homie-studio lab set \u003Cgame> name=value`.\n\n## 4. Multiplayer: every screen, the host's rules\n\nFor a rules game (`src\u002Frules.ts` plus `view.ts`), the Lab runs the same host runtime locally in each pane,\nincluding when the published game keeps `room.offline: false`. No Lab state reaches a room. Put gameplay\nnumbers in tunables.json; the runtime reads the sliders automatically, including `public.speed` for a value\nunder `public`. Keep them with `homie-studio lab set \u003Cgame> public.speed=7`. The take's stage reaches\n`world.stage` in the rules; use that for a target or a ledge, without importing the Lab into guarded rules.\nKeep `lab.phase`, `lab.track`, poses and overlays in the view. Both panes get the same seed and fixed clock.\n`lab check` must show actual gameplay tracks changing and the repeated take matching, not just an empty page.\n\n\nA studio game is played in a room. A feel change must look the same on every screen and keep the two-browser check\ngreen:\n\n- **Presentation from what every screen already has**: a declared rules effect (`world.emit` in rules, `room.on` in the view; `net.send` only in an unchanged older game)\n  or a change in the snapshot (a slime's hit points dropping). Flashes, squash, sparks and numbers are drawn locally.\n- **Gameplay on the host**: a hit-stop that holds a body, a push, a slide's curve. Make motion frame-rate independent\n  (a curve of time, not a per-frame multiply), so a 30 fps phone moves the same distance.\n- **Juice dice**: `lab.random()` for particles and shake, never Math.random() for lab presentation: the world's dice must be the same in\n  both builds for the lab to compare them, and lab.random() is Math.random() outside the lab.\n- A change that moves gameplay (a push that puts a target out of reach) shows in the lab's numbers: read them. One\n  push in this skill's own proof took a slime out of reach and the next two strikes missed; a lunge fixed it.\n\nThen the game's own check: `npm run dev` (background), `npx --no-install homie-studio check \u003Cgame> --url\nhttp:\u002F\u002F127.0.0.1:8787`. It must pass before anything is kept.\n\n## 5. When a feel change costs frames, say so with numbers\n\n`lab check` prints the game's JavaScript per frame, New against Today, on the same frames (the mean: Chrome times a\npage in steps of about 0.1 ms). It is a hint. For the real cost, the `perf` skill measures both builds in a room, on\nan emulated phone, in alternating pairs: `perf.mjs baseline \u003Cgame>` with games\u002F\u003Cgame>\u002F at Today (`git stash` the\nchange, or check out HEAD's copy of the folder), then the change back and `perf.mjs try \u003Cgame> --name \"\u003Cthe feel\nchange>\" --looks \"\u003Cwhat looks different>\" --plays \"\u003Cwhat plays different>\" --measure`. **--measure is required here**:\nwithout it `try` reverts anything that is not faster, and a feel change is kept for its feel, not its speed. Tell the\nperson the result in numbers: frames (p95), the main thread per frame, time to playable, against Today. In this\nskill's own proof the bump cost 0.09 ms of main thread a frame on the emulated phone (1.48 to 1.57 ms, +4.9%, within\nthe noise) with frames unchanged at 16.7 ms. Never say a feel change is free from the code.\n\n## 6. Keep what the person likes, then commit\n\nThe person decides. Revert what they did not like (only those lines, in games\u002F\u003Cgame>\u002F), keep the rest, run\n`lab check` and the two-browser check once more, then commit with the phases in the message:\n\n```sh\ngit add games\u002F\u003Cgame> && git commit -m \"\u003CGame>: the bump lands (hit-stop 70 ms), flies stretched, eases out, settles\"\n```\n\nRecord a side-by-side clip the person can share with the `video` skill's `record`, driving the lab page itself:\n`references\u002Frecord-lab.json` is a steps file (play at 1x, then ¼ with the onion skin, then step through the phases).\n`node \u003Cvideo.mjs> record lab-\u003Cgame> --steps \u003Csteps> --url http:\u002F\u002F127.0.0.1:8790`. Stop the lab when done:\n`npx --no-install homie-studio lab --stop` (this studio's only; it also removes the checkouts Today was built from).\n\n## Where people see it\n\n- **Claude Code**: the link `http:\u002F\u002F127.0.0.1:8790\u002F\u003Cgame>\u002F` (run the lab as a background task).\n- **Claude Desktop and claude.ai** (Homie Studio's local tools): the `game_lab` tool starts the lab and answers with\n  a card: a still of New beside Today at the take's busiest moment, the phases of each, the numbers, and Open.\n- **Anyone**: the recorded clip, and the commit, whose message names the phases.\n\n## Never\n\n- Never say it feels better from the code. Show the take; the person feels it.\n- Never change Today: instrumenting changes nothing a player feels, and is committed on its own first.\n- Never put a lab call where it allocates every frame outside the lab (`if (lab.on)` around reporting).\n- For view juice use lab.random() and the Lab clock. Rules use world.random and world.tick\u002Fdt; movement uses ctx.tick\u002Fdt\u002Fmath. Never import the Lab into rules.\n- Never edit a take to make New look better; record a new one and say why.\n- Never leave the lab running when the work is done (`lab --stop`), or open a browser for the person.\n",{"name":5,"description":7},"main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002Fhomie-rocks\u002Fhomie\u002Fskills\u002Flab",483,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-13 02:16:32",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill lab",{"tool":61,"command":62},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill lab",{"tool":64,"command":65},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill lab","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fhomie-rocks\u002Fhomie\u002Fskills\u002Flab\u002FSKILL.md",true,[69,75,79],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002FAPI.md","REFERENCE","参考文档",4785,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fhomie-rocks\u002Fhomie\u002Fskills\u002Flab\u002Freferences\u002FAPI.md",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002FPRINCIPLES.md",4080,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fhomie-rocks\u002Fhomie\u002Fskills\u002Flab\u002Freferences\u002FPRINCIPLES.md",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Frecord-lab.json",1017,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fhomie-rocks\u002Fhomie\u002Fskills\u002Flab\u002Freferences\u002Frecord-lab.json",[84,92,99,106,132,157],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":91},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":91},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":91},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":40},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[113,114,115,116,117,118,119,120,121,122,123,21,124,125,126,127,128,129,130,131],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":40},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[139,140,141,127,142,143,144,145,146,147,148,149,150,151,118,152,153,154,155,156],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":174,"publishedAt":40},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[163,168,171],{"categoryNo":164,"categoryName":165,"taxonomyType":166,"taxonomyTypeDesc":167},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":169,"categoryName":170,"taxonomyType":166,"taxonomyTypeDesc":167},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":172,"categoryName":173,"taxonomyType":166,"taxonomyTypeDesc":167},"01JBSEEDCAT000000000000010","后端与接口",[159,175,176,177,178,179,180,153,181,119,36,182,183,184,21,185,186,187,188,189],"URL","Video","short-form","standalone","PDF","viral","tiktok","social","MCP","song","image","mcp server","schedule","api","publish"]