[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M698RG2BSWD0P2MA05DA8X6R":3,"skill-same:01M698RG2BSWD0P2MA05DA8X6R":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":44,"ownerHtmlUrl":45,"ownerBlogUrl":44,"ownerDescription":46,"updatedAt":47,"install":48,"resources":60},"01M698RG2BSWD0P2MA05DA8X6R","openclaw-test-heap-leaks",null,"Investigate OpenClaw pnpm test memory growth, Vitest OOMs, RSS spikes, and heap snapshot deltas.","openclaw\u002Fopenclaw","openclaw","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F252820863?v=4","01M698P3FSAZ6B4R928ZF19KPT","01M698PDMDRVH56MV30D253NFP",394302,"MIT","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[9,23,24,25,26,27,28,29,30,31,32,33],"openclaw test heap leaks","test","heap","memory","investigate","vitest","rss","growth","snapshot","deltas","pnpm","2026-11-10 10:12:30",false,"---\nname: openclaw-test-heap-leaks\ndescription: Investigate OpenClaw pnpm test memory growth, Vitest OOMs, RSS spikes, and heap snapshot deltas.\n---\n\n# OpenClaw Test Heap Leaks\n\nUse this skill for test-memory investigations. Do not guess from RSS alone when heap snapshots are available. Treat snapshot-name deltas as triage evidence, not proof, until retainers or dominators support the call.\n\nRead `..\u002Fopenclaw-test-performance\u002FSKILL.md` first for the current test-performance commands and proof routing.\n\nFor **runtime fixes** (e.g., closure leaks in long-running services like the gateway), see [Validating runtime fixes](#validating-runtime-fixes-not-test-memory) below — that uses a dedicated harness rather than the unit-test profiling workflow.\n\n## Workflow\n\n1. Reproduce the failing shape first.\n   - Match the real entrypoint and worker budget. For a broad unit-fast baseline with per-config max RSS and top-file timing, start with:\n\n     ```bash\n     pnpm test:perf:groups \\\n       --config test\u002Fvitest\u002Fvitest.unit-fast.config.ts \\\n       --allow-failures \\\n       --output .artifacts\u002Ftest-perf\u002Funit-fast-memory.json\n     ```\n\n   - For a suspected file, rerun that file with one worker and collect wall\u002FRSS evidence: `\u002Fusr\u002Fbin\u002Ftime -l pnpm test \u003Cfile> --maxWorkers=1 --reporter=verbose`.\n   - Current `pnpm test` execution is planned by `scripts\u002Ftest-projects.mts`. Record the printed Vitest config or shard and preserve that shape when the report is configuration- or worker-budget-specific.\n\n2. Collect the strongest available heap evidence.\n   - Run `pnpm test:perf:profile:runner -- --output-dir .artifacts\u002Ftest-perf\u002Fvitest-runner-profile -- \u003Cfile>` for a CPU profile plus a sampling heap profile of the unit runner. Open the heap profile in DevTools and inspect the largest allocation families.\n   - Sampling `.heapprofile` output is not a `.heapsnapshot`; do not pass it to the snapshot delta helper.\n   - When a dedicated harness or another known producer emits repeated `.heapsnapshot` files, compare snapshots from the same PID with `.agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002Fscripts\u002Fheapsnapshot-delta.mjs`.\n   - If no snapshot or heap profile is available, RSS growth is useful triage evidence, but keep the leak classification inconclusive.\n\n3. Classify the growth before choosing a fix.\n   - If growth is dominated by Vite\u002FVitest transformed source strings, `Module`, `system \u002F Context`, bytecode, descriptor arrays, or property maps, treat it as likely retained module graph growth in long-lived workers.\n   - If growth is dominated by app objects, caches, buffers, server handles, timers, mock state, sqlite state, or similar runtime objects, treat it as a likely cleanup or lifecycle leak.\n   - If the names are ambiguous, stop short of a confident label and inspect retainers\u002Fdominators in DevTools for the top deltas.\n\n4. Fix the right layer.\n   - For likely retained transformed-module growth in shared workers:\n   - Inspect the owning Vitest config and the process chunking in `scripts\u002Ftest-projects.test-support.mjs`. Fix process lifetime or project ownership there only when the same-shape evidence shows that shared-worker retention is the cause.\n   - `test\u002Fvitest\u002Fvitest.unit-fast-isolated.config.ts` is for audited stateful tests that need a fresh module graph. Do not use it as a generic memory-hotspot list.\n   - For real leaks:\n   - Patch the implicated test or runtime cleanup path.\n   - Look for missing `afterEach`\u002F`afterAll`, module-reset gaps, retained global state, unreleased DB handles, or listeners\u002Ftimers that survive the file.\n\n5. Verify with the most direct proof.\n   - Re-run the same grouped or scoped command and confirm the max-RSS trend or OOM is reduced.\n   - When a dedicated producer emits heap profiles or snapshots, repeat the same producer and compare equivalent artifacts.\n   - For routing or config changes, verify the expected Vitest config or shard starts and the affected tests complete.\n\n## Heuristics\n\n- Do not call everything a leak. Growth in a non-isolated shared Vitest project can be a worker-lifetime problem rather than an application object leak.\n- `scripts\u002Ftest-projects.mts`, `scripts\u002Ftest-group-report.mts`, and `scripts\u002Frun-vitest-profile.mts` are the current execution, grouped-RSS, and profile entrypoints.\n- The `[test] starting ...` lines identify the Vitest config or shard to reproduce.\n- `.artifacts\u002Fvitest-shard-timings.json` stores config\u002Fshard durations for scheduling. It is not a file-level memory-hotspot or behavior manifest.\n- When the same retained object families grow across multiple intervals in the same worker PID, trust the snapshots over intuition, then confirm ambiguous calls with retainer evidence.\n\n## Snapshot Comparison\n\n- Direct comparison:\n  - `node .agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002Fscripts\u002Fheapsnapshot-delta.mjs before.heapsnapshot after.heapsnapshot`\n- Auto-select earliest\u002Flatest snapshots per PID within one lane:\n  - `node .agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002Fscripts\u002Fheapsnapshot-delta.mjs --lane-dir \u003Csnapshot-directory>`\n- Useful flags:\n  - `--top 40`\n  - `--min-kb 32`\n  - `--pid 16133`\n\nRead the top positive deltas first. Large positive growth in module-transform artifacts points to shared-process lifetime or project ownership; large positive growth in runtime objects suggests a real leak. If the names alone do not settle it, open the same snapshot pair in DevTools and inspect retainers\u002Fdominators for the top rows before declaring root cause.\n\n## Validating runtime fixes (not test-memory)\n\nThe workflow above is for diagnosing Vitest worker memory growth. For\nvalidating that a runtime\u002Fclosure fix actually releases captured state, use the\ndedicated harness:\n\n- `pnpm leak:embedded-run` — runs `scripts\u002Fembedded-run-abort-leak.ts`. Loops N\n  aborted runs in a function-shaped scope mimicking `runEmbeddedAttempt`,\n  writes heap snapshots, and reports a PASS\u002FFAIL verdict on retention growth\n  using `FinalizationRegistry` for tracked-instance counting plus RSS delta.\n\nModes:\n\n- `closure-extracted` (default) — production fix shape (helper at module scope).\n- `closure-inline` — pre-fix shape (closure inside the runner scope). Use as a\n  sensitivity check: if it passes you've broken the harness, not fixed a bug.\n- `synthetic-leak` — deliberately retains via a module-level bucket. Use to\n  confirm the harness can detect leaks before trusting a PASS on a real fix.\n\nSnapshots land in `.tmp\u002Fembedded-run-abort-leak\u002F`. Diff with the same script\nas above:\n\n```\nnode .agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002Fscripts\u002Fheapsnapshot-delta.mjs \\\n  .tmp\u002Fembedded-run-abort-leak\u002Fbaseline-*.heapsnapshot \\\n  .tmp\u002Fembedded-run-abort-leak\u002Fbatch-N-*.heapsnapshot --top 30\n```\n\nWhen fixing a different runtime leak, add a new harness alongside this one\nrather than retrofitting it. The fixture function should mimic the lexical\nscope of the function where the leak lives, not be a generic abort-loop.\n\n## Output Expectations\n\nWhen using this skill, report:\n\n- The exact reproduce command.\n- Which Vitest config or target was reproduced, and which PID was compared when snapshots were available.\n- The dominant retained object families from the heap profile or snapshot delta, when available.\n- Whether the issue is a likely real leak or likely shared-worker retained module growth, plus whether retainers\u002Fdominators confirmed it.\n- The concrete fix or impact-reduction patch.\n- What you verified, and what snapshot overhead prevented you from verifying.\n","# OpenClaw Test Heap Leaks\n\nUse this skill for test-memory investigations. Do not guess from RSS alone when heap snapshots are available. Treat snapshot-name deltas as triage evidence, not proof, until retainers or dominators support the call.\n\nRead `..\u002Fopenclaw-test-performance\u002FSKILL.md` first for the current test-performance commands and proof routing.\n\nFor **runtime fixes** (e.g., closure leaks in long-running services like the gateway), see [Validating runtime fixes](#validating-runtime-fixes-not-test-memory) below — that uses a dedicated harness rather than the unit-test profiling workflow.\n\n## Workflow\n\n1. Reproduce the failing shape first.\n   - Match the real entrypoint and worker budget. For a broad unit-fast baseline with per-config max RSS and top-file timing, start with:\n\n     ```bash\n     pnpm test:perf:groups \\\n       --config test\u002Fvitest\u002Fvitest.unit-fast.config.ts \\\n       --allow-failures \\\n       --output .artifacts\u002Ftest-perf\u002Funit-fast-memory.json\n     ```\n\n   - For a suspected file, rerun that file with one worker and collect wall\u002FRSS evidence: `\u002Fusr\u002Fbin\u002Ftime -l pnpm test \u003Cfile> --maxWorkers=1 --reporter=verbose`.\n   - Current `pnpm test` execution is planned by `scripts\u002Ftest-projects.mts`. Record the printed Vitest config or shard and preserve that shape when the report is configuration- or worker-budget-specific.\n\n2. Collect the strongest available heap evidence.\n   - Run `pnpm test:perf:profile:runner -- --output-dir .artifacts\u002Ftest-perf\u002Fvitest-runner-profile -- \u003Cfile>` for a CPU profile plus a sampling heap profile of the unit runner. Open the heap profile in DevTools and inspect the largest allocation families.\n   - Sampling `.heapprofile` output is not a `.heapsnapshot`; do not pass it to the snapshot delta helper.\n   - When a dedicated harness or another known producer emits repeated `.heapsnapshot` files, compare snapshots from the same PID with `.agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002Fscripts\u002Fheapsnapshot-delta.mjs`.\n   - If no snapshot or heap profile is available, RSS growth is useful triage evidence, but keep the leak classification inconclusive.\n\n3. Classify the growth before choosing a fix.\n   - If growth is dominated by Vite\u002FVitest transformed source strings, `Module`, `system \u002F Context`, bytecode, descriptor arrays, or property maps, treat it as likely retained module graph growth in long-lived workers.\n   - If growth is dominated by app objects, caches, buffers, server handles, timers, mock state, sqlite state, or similar runtime objects, treat it as a likely cleanup or lifecycle leak.\n   - If the names are ambiguous, stop short of a confident label and inspect retainers\u002Fdominators in DevTools for the top deltas.\n\n4. Fix the right layer.\n   - For likely retained transformed-module growth in shared workers:\n   - Inspect the owning Vitest config and the process chunking in `scripts\u002Ftest-projects.test-support.mjs`. Fix process lifetime or project ownership there only when the same-shape evidence shows that shared-worker retention is the cause.\n   - `test\u002Fvitest\u002Fvitest.unit-fast-isolated.config.ts` is for audited stateful tests that need a fresh module graph. Do not use it as a generic memory-hotspot list.\n   - For real leaks:\n   - Patch the implicated test or runtime cleanup path.\n   - Look for missing `afterEach`\u002F`afterAll`, module-reset gaps, retained global state, unreleased DB handles, or listeners\u002Ftimers that survive the file.\n\n5. Verify with the most direct proof.\n   - Re-run the same grouped or scoped command and confirm the max-RSS trend or OOM is reduced.\n   - When a dedicated producer emits heap profiles or snapshots, repeat the same producer and compare equivalent artifacts.\n   - For routing or config changes, verify the expected Vitest config or shard starts and the affected tests complete.\n\n## Heuristics\n\n- Do not call everything a leak. Growth in a non-isolated shared Vitest project can be a worker-lifetime problem rather than an application object leak.\n- `scripts\u002Ftest-projects.mts`, `scripts\u002Ftest-group-report.mts`, and `scripts\u002Frun-vitest-profile.mts` are the current execution, grouped-RSS, and profile entrypoints.\n- The `[test] starting ...` lines identify the Vitest config or shard to reproduce.\n- `.artifacts\u002Fvitest-shard-timings.json` stores config\u002Fshard durations for scheduling. It is not a file-level memory-hotspot or behavior manifest.\n- When the same retained object families grow across multiple intervals in the same worker PID, trust the snapshots over intuition, then confirm ambiguous calls with retainer evidence.\n\n## Snapshot Comparison\n\n- Direct comparison:\n  - `node .agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002Fscripts\u002Fheapsnapshot-delta.mjs before.heapsnapshot after.heapsnapshot`\n- Auto-select earliest\u002Flatest snapshots per PID within one lane:\n  - `node .agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002Fscripts\u002Fheapsnapshot-delta.mjs --lane-dir \u003Csnapshot-directory>`\n- Useful flags:\n  - `--top 40`\n  - `--min-kb 32`\n  - `--pid 16133`\n\nRead the top positive deltas first. Large positive growth in module-transform artifacts points to shared-process lifetime or project ownership; large positive growth in runtime objects suggests a real leak. If the names alone do not settle it, open the same snapshot pair in DevTools and inspect retainers\u002Fdominators for the top rows before declaring root cause.\n\n## Validating runtime fixes (not test-memory)\n\nThe workflow above is for diagnosing Vitest worker memory growth. For\nvalidating that a runtime\u002Fclosure fix actually releases captured state, use the\ndedicated harness:\n\n- `pnpm leak:embedded-run` — runs `scripts\u002Fembedded-run-abort-leak.ts`. Loops N\n  aborted runs in a function-shaped scope mimicking `runEmbeddedAttempt`,\n  writes heap snapshots, and reports a PASS\u002FFAIL verdict on retention growth\n  using `FinalizationRegistry` for tracked-instance counting plus RSS delta.\n\nModes:\n\n- `closure-extracted` (default) — production fix shape (helper at module scope).\n- `closure-inline` — pre-fix shape (closure inside the runner scope). Use as a\n  sensitivity check: if it passes you've broken the harness, not fixed a bug.\n- `synthetic-leak` — deliberately retains via a module-level bucket. Use to\n  confirm the harness can detect leaks before trusting a PASS on a real fix.\n\nSnapshots land in `.tmp\u002Fembedded-run-abort-leak\u002F`. Diff with the same script\nas above:\n\n```\nnode .agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002Fscripts\u002Fheapsnapshot-delta.mjs \\\n  .tmp\u002Fembedded-run-abort-leak\u002Fbaseline-*.heapsnapshot \\\n  .tmp\u002Fembedded-run-abort-leak\u002Fbatch-N-*.heapsnapshot --top 30\n```\n\nWhen fixing a different runtime leak, add a new harness alongside this one\nrather than retrofitting it. The fixture function should mimic the lexical\nscope of the function where the leak lives, not be a generic abort-loop.\n\n## Output Expectations\n\nWhen using this skill, report:\n\n- The exact reproduce command.\n- Which Vitest config or target was reproduced, and which PID was compared when snapshots were available.\n- The dominant retained object families from the heap profile or snapshot delta, when available.\n- Whether the issue is a likely real leak or likely shared-worker retained module growth, plus whether retainers\u002Fdominators confirmed it.\n- The concrete fix or impact-reduction patch.\n- What you verified, and what snapshot overhead prevented you from verifying.\n",{"name":5,"description":7},"main","f1c93577085244aa96aa87b53a2df9b59d293bd7",".agents\u002Fskills\u002Fopenclaw-test-heap-leaks",82862,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw","https:\u002F\u002Fopenclaw.ai","https:\u002F\u002Fgithub.com\u002Fopenclaw","Your personal, open source AI assistant.","2026-11-11 08:46:30",{"source":8,"skillName":5,"commands":49,"prompt":58,"zipAvailable":59},[50,53,56],{"tool":51,"command":52},"npx","npx skills add openclaw\u002Fopenclaw --skill openclaw-test-heap-leaks",{"tool":54,"command":55},"bunx","bunx skills add openclaw\u002Fopenclaw --skill openclaw-test-heap-leaks",{"tool":33,"command":57},"pnpm dlx skills add openclaw\u002Fopenclaw --skill openclaw-test-heap-leaks","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002FSKILL.md",true,[61,67],{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},"agents\u002Fopenai.yaml","REFERENCE","参考文档",237,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002Fagents\u002Fopenai.yaml",{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"scripts\u002Fheapsnapshot-delta.mjs","SCRIPT","脚本",14225,"https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenclaw-test-heap-leaks\u002Fscripts\u002Fheapsnapshot-delta.mjs",[74,80,103,121,143,165],{"skillNo":75,"name":76,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":34},"01M698VP84FNM6G9MR1HPX7MF7","lobster","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fextensions\u002Flobster\u002FSKILL.md",[],[76],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":34},"01M698YY8QGQ7S8TJNKJG6VTPH","xurl","xurl CLI for authenticated X posts, replies, reads\u002Fsearch, DMs, media upload, followers, auth status, or raw v2 API calls.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fxurl\u002FSKILL.md",[],[82,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102],"for","api","calls","replies","posts","upload","tap","install","brew","node","Media","search","npm","status","auth","cli",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":34},"01M698YWT1CJ0WK88WB909R9RT","weather","Current weather and forecasts with web_fetch, falling back to wttr.in curl for locations, rain, temperature, travel planning.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fweather\u002FSKILL.md",[],[105,110,111,94,112,95,113,114,115,116,117,118,87,119,120],"travel planning","travel","fetch","curl","https","help","planning","web","back","temperature","with",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":132,"publishedAt":34},"01M698YV2Q0R0JJKAWGFS21K0N","visualize","Create inline visuals for code and explanations, or author persistent OpenClaw dashboard widgets with show_widget.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Fvisualize\u002FSKILL.md",[127],{"categoryNo":128,"categoryName":129,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[123,133,134,135,136,87,120,137,138,139,140,141,9,142],"widgets","openclaw dashboard","author","inline","show","code","create","visuals","dashboard","widget",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":155,"publishedAt":34},"01M698YS2TRJH9ENG28HD9CD87","trello","Manage Trello boards, lists, and cards via the Trello REST API.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Ftrello\u002FSKILL.md",[149,152],{"categoryNo":150,"categoryName":151,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":153,"categoryName":154,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000030","开发工程师",[145,114,156,157,158,159,160,161,94,95,162,113,88,163,164],"cloud","manage","via","rest api","token","atlassian","jq","REST","developer",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":34},"01M698YQ9Q3M4W78EWV2KSCSVW","tmux","Control tmux sessions\u002Fpanes for interactive CLIs: list, capture output, send keys, paste text, monitor prompts.","https:\u002F\u002Fgithub.com\u002Fopenclaw\u002Fopenclaw\u002Fblob\u002Fmain\u002Fskills\u002Ftmux\u002FSKILL.md",[],[167,94,172,173,87,174,175,176,177,178,179,180,95,181,182,183,184,185,186],"send","darwin","keys","paste","output","control","prompts","interactive","list","capture","panes","text","monitor","sessions","linux"]