[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CHRYVF1DDW8Z6RYNV0GYBN":3,"skill-same:01M6CHRYVF1DDW8Z6RYNV0GYBN":86},{"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":23,"publishedAt":53,"linkOnly":54,"markdownContent":55,"markdownBody":56,"frontMatter":57,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":6,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":6,"updatedAt":65,"install":66,"resources":79},"01M6CHRYVF1DDW8Z6RYNV0GYBN","tmux-capture-driver",null,"Drive an interactive terminal program (Claude Code, Codex, OpenCode, or any TUI) from an agent through tmux, step by step, and prove each step by an observable artefact. Carries the send-keys rules that were measured to work, the trust-prompt sequences per program, turn-completion detection, bounded condition waits, non-interactive fallbacks, and the failure modes seen in practice. Use when an agent must operate a TUI it cannot attach to, obtain files or output that only an interactive session produces, or hand a partly driven tmux session to another agent.","dayvidpham\u002Faura-plugins","dayvidpham","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F22456875?v=4","01M6CHR0F6J2M4QEHFR85XRNSR","David Huu Pham","01M6CHR0KQJ4DK5KSZ9TRTP7DW",2,"MIT","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftmux-capture-driver\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52],"tmux","capture","driver","tmux capture driver","program","terminal","when","prove","send","modes","operate","condition","step by step","attach","trust","files","drive","opencode","only","use","session","interactive","tui","prompt","work","Rules","detection","code","codex","2026-11-10 10:12:30",false,"---\nname: tmux-capture-driver\ndescription: Drive an interactive terminal program (Claude Code, Codex, OpenCode, or any TUI) from an agent through tmux, step by step, and prove each step by an observable artefact. Carries the send-keys rules that were measured to work, the trust-prompt sequences per program, turn-completion detection, bounded condition waits, non-interactive fallbacks, and the failure modes seen in practice. Use when an agent must operate a TUI it cannot attach to, obtain files or output that only an interactive session produces, or hand a partly driven tmux session to another agent.\n---\n\n# Drive a TUI through tmux and prove every step\n\nAn agent has no terminal of its own. tmux gives it one: a detached session that runs the\nprogram, accepts keystrokes, and shows its screen on request. The protocol below turns that into\nsomething reliable. Every rule here came from a failure that happened once.\n\n## The five rules\n\n1. **Read the pane before every keystroke.** `tmux capture-pane -p -t NAME` shows the screen.\n   Menus, trust prompts and spinners change what a key does. A key sent blind goes to the wrong\n   widget.\n2. **Send text and Enter as two calls.** `tmux send-keys -t NAME -l 'the text'`, pause about one\n   second, then `tmux send-keys -t NAME Enter`. Text and Enter in one call left the prompt typed\n   but unsent in Claude Code. `-l` sends the text literally, so backticks, semicolons and `$`\n   reach the program unchanged.\n3. **Wait on a condition, never on time alone.** The condition is the artefact the step must\n   produce: a file, or a pane line. Poll it in a bounded loop and report how long it took:\n   `n=0; until [ -e \"$FILE\" ] || [ $n -ge 90 ]; do sleep 1; n=$((n+1)); done; echo \"waited ${n}s\"`.\n   A step whose ceiling expired is a finding, not a retry.\n4. **One session per program, environment set in the launching shell.** Start a shell in the\n   session, export the variables there, then start the program. A hook or plugin the program\n   spawns inherits that shell's environment, not the agent's.\n5. **Record what you did.** After each session: the keys sent, the prompts sent, the menu choices\n   taken, the pane text at each decision, and the artefacts listed with `ls -la`. Another agent\n   or the user must be able to see what produced the artefacts.\n\n## Session lifecycle\n\n```bash\n# Start: detached, sized, in the working directory.\ntmux new-session -d -s NAME -x 180 -y 45 -c \u002Fpath\u002Fto\u002Fproject\n# Environment and program, one line, then Enter (a shell command, so one call is fine here).\ntmux send-keys -t NAME \"export A=1 B=2; program\" Enter\n# Look.\ntmux capture-pane -p -t NAME | grep -v '^\\s*$' | tail -30\n# Menus: move with Down\u002FUp or type the item number, then Enter as a separate call.\ntmux send-keys -t NAME Down; sleep 0.5; tmux send-keys -t NAME Enter\n# Prompts: literal text, pause, Enter.\ntmux send-keys -t NAME -l 'Run the shell command `ls -la` and tell me what you see.'; sleep 1\ntmux send-keys -t NAME Enter\n# End: the program's own quit command first, then remove the session.\ntmux kill-session -t NAME\n```\n\nSessions survive the agent's tool call, so a half-driven session can be handed to another agent\nby name. Give the receiver the session name, the exact pane text, and the next expected artefact.\n\n## Program-specific sequences (measured 2026-09-05)\n\n**Claude Code (`claude`, v2.1.261).** Nested launches need `unset CLAUDECODE CLAUDE_CODE_ENTRYPOINT`\nin the launching shell. First screen in a new directory is the folder-trust prompt with \"No, exit\"\nselected: `Down`, then `Enter`. A turn is running while the status line shows `esc to interrupt`;\nwait for that text to disappear before the next prompt. Slash commands (`\u002Fcompact`, `\u002Fexit`) are\ntyped like prompts: literal text, pause, Enter. `\u002Fcompact` produces a summary and a fresh\nsession start; `\u002Fexit` ends the session and prints a resume line.\n\n**Codex (`codex`, codex-cli 0.153.0).** First screen is the directory-trust prompt with \"1. Yes,\ncontinue\" selected: `Enter`. If the project carries `.codex\u002Fhooks.json`, the next screen is\n\"Hooks need review\" with three items; hooks run only after \"2. Trust all and continue\" (type `2`,\nwhich moves the highlight, then `Enter`). Trust is written to `~\u002F.codex\u002Fconfig.toml` per project\nand persists. Hooks registered for startup run at the start of the first turn, not at process\nstart, so expect their artefacts after the first prompt. Command approvals appear as menus; read\nthe pane. Quit with `\u002Fquit`.\n\n**OpenCode (`opencode`, 1.18.29).** No trust prompt. On first start in a directory with\n`.opencode\u002Fplugins\u002F`, it installs its plugin npm package into `.opencode\u002F` before the prompt\nappears; in practice about eight seconds. Non-interactive runs were seen to stall at \"init\"\ntwice for unknown reasons; a relaunch in the same directory recovered. Child processes the plugin\nspawns inherit the TUI's stderr and draw over the screen until the next redraw. One Ctrl-C ends\nthe TUI and prints a resume line.\n\n## Non-interactive fallbacks\n\nThese fire the same lifecycle hooks and are easier to script when no TUI-only step is needed:\n`claude -p 'prompt'`, `codex exec 'prompt'` (only after the directory's hooks were trusted once\nin the TUI; `exec` cannot grant trust), `opencode run 'prompt'`. They cannot do `\u002Fcompact`, and\nthey cannot answer trust prompts.\n\n## The screen is never the evidence\n\nA TUI screen is an unreliable observable: a corrupted or starved redraw can show a sent\ncommand as still typed (which invites a second Enter and a doubled event), or hide a finished\nturn. The durable observables are the artefact file and the host's own log. When the screen and\na durable observable disagree, trust the durable one: check the capture directory or grep the\nhost log (filtered to your own run or project) before repeating any key.\n\n## Failure modes seen\n\n- Text typed but not submitted: text and Enter were in one `send-keys` call. Send `Enter` alone.\n- Program refused to start inside an agent session: inherited `CLAUDECODE`; unset it.\n- A long background poll was killed by the harness's low-memory guard. Keep waits short and\n  bounded inside the tool call; do not rely on a detached poller to wake you.\n- Two agents typing into one session interleave keystrokes. One driver per session; announce\n  the handoff before the other agent touches it.\n- A stalled program was recovered with `pkill -f \u003Cprogram>`, which killed EVERY instance of that\n  program on the machine, including two other agents' live sessions mid-sitting (2026-09-05).\n  Never kill by program name or pattern (`pkill -f`, `killall`). Read the pane, then kill only\n  your own session (`tmux kill-session -t NAME`) or your own pane's process\n  (`tmux list-panes -t NAME -F '#{pane_pid}'`, then `kill \u003Cpid>`).\n- Several sittings at once share the host's log file and the live store's fault file. Filter\n  every log line by your own project directory before drawing a conclusion. Judge \"live store\n  untouched\" by a byte digest of its database before and after, never by the fault file, which\n  grows from the surrounding agent session's own hooks.\n- A capture listing taken while the host could still emit undercounted (717 listed, 720 on\n  disk; the host had been killed while bootstrap events were still arriving). You cannot tell\n  from outside whether emission has stopped, and stopping the host is not by itself the\n  guarantee. Stop the host, then list, then count a second time; two agreeing reads of a\n  stopped directory are the evidence. Three of four re-counts did not move, which is what a\n  discriminating check looks like.\n- Several live hosts at once starved the terminal redraw (hook stderr drawn into the screen)\n  and the redraw never recovered. Run one capture sitting of ours at a time: another sitting is\n  identified by the campaign's project directories and by PASTURE variables in the process\n  environment, never by the program name alone. A host that is not ours (the user's own editor\n  session) is never a reason to stop, wait on or touch it; the load check is the only thing that\n  measures it. Check the load average before starting and wait, bounded, if it is high.\n\n## Helper\n\n`scripts\u002Ftmux-step.sh NAME 'text' \u002Fpath\u002Fexpected-file [ceiling-seconds]` sends the text and Enter\nas two calls, waits on the file with a bounded loop, then prints the wait and the pane tail.\n","# Drive a TUI through tmux and prove every step\n\nAn agent has no terminal of its own. tmux gives it one: a detached session that runs the\nprogram, accepts keystrokes, and shows its screen on request. The protocol below turns that into\nsomething reliable. Every rule here came from a failure that happened once.\n\n## The five rules\n\n1. **Read the pane before every keystroke.** `tmux capture-pane -p -t NAME` shows the screen.\n   Menus, trust prompts and spinners change what a key does. A key sent blind goes to the wrong\n   widget.\n2. **Send text and Enter as two calls.** `tmux send-keys -t NAME -l 'the text'`, pause about one\n   second, then `tmux send-keys -t NAME Enter`. Text and Enter in one call left the prompt typed\n   but unsent in Claude Code. `-l` sends the text literally, so backticks, semicolons and `$`\n   reach the program unchanged.\n3. **Wait on a condition, never on time alone.** The condition is the artefact the step must\n   produce: a file, or a pane line. Poll it in a bounded loop and report how long it took:\n   `n=0; until [ -e \"$FILE\" ] || [ $n -ge 90 ]; do sleep 1; n=$((n+1)); done; echo \"waited ${n}s\"`.\n   A step whose ceiling expired is a finding, not a retry.\n4. **One session per program, environment set in the launching shell.** Start a shell in the\n   session, export the variables there, then start the program. A hook or plugin the program\n   spawns inherits that shell's environment, not the agent's.\n5. **Record what you did.** After each session: the keys sent, the prompts sent, the menu choices\n   taken, the pane text at each decision, and the artefacts listed with `ls -la`. Another agent\n   or the user must be able to see what produced the artefacts.\n\n## Session lifecycle\n\n```bash\n# Start: detached, sized, in the working directory.\ntmux new-session -d -s NAME -x 180 -y 45 -c \u002Fpath\u002Fto\u002Fproject\n# Environment and program, one line, then Enter (a shell command, so one call is fine here).\ntmux send-keys -t NAME \"export A=1 B=2; program\" Enter\n# Look.\ntmux capture-pane -p -t NAME | grep -v '^\\s*$' | tail -30\n# Menus: move with Down\u002FUp or type the item number, then Enter as a separate call.\ntmux send-keys -t NAME Down; sleep 0.5; tmux send-keys -t NAME Enter\n# Prompts: literal text, pause, Enter.\ntmux send-keys -t NAME -l 'Run the shell command `ls -la` and tell me what you see.'; sleep 1\ntmux send-keys -t NAME Enter\n# End: the program's own quit command first, then remove the session.\ntmux kill-session -t NAME\n```\n\nSessions survive the agent's tool call, so a half-driven session can be handed to another agent\nby name. Give the receiver the session name, the exact pane text, and the next expected artefact.\n\n## Program-specific sequences (measured 2026-09-05)\n\n**Claude Code (`claude`, v2.1.261).** Nested launches need `unset CLAUDECODE CLAUDE_CODE_ENTRYPOINT`\nin the launching shell. First screen in a new directory is the folder-trust prompt with \"No, exit\"\nselected: `Down`, then `Enter`. A turn is running while the status line shows `esc to interrupt`;\nwait for that text to disappear before the next prompt. Slash commands (`\u002Fcompact`, `\u002Fexit`) are\ntyped like prompts: literal text, pause, Enter. `\u002Fcompact` produces a summary and a fresh\nsession start; `\u002Fexit` ends the session and prints a resume line.\n\n**Codex (`codex`, codex-cli 0.153.0).** First screen is the directory-trust prompt with \"1. Yes,\ncontinue\" selected: `Enter`. If the project carries `.codex\u002Fhooks.json`, the next screen is\n\"Hooks need review\" with three items; hooks run only after \"2. Trust all and continue\" (type `2`,\nwhich moves the highlight, then `Enter`). Trust is written to `~\u002F.codex\u002Fconfig.toml` per project\nand persists. Hooks registered for startup run at the start of the first turn, not at process\nstart, so expect their artefacts after the first prompt. Command approvals appear as menus; read\nthe pane. Quit with `\u002Fquit`.\n\n**OpenCode (`opencode`, 1.18.29).** No trust prompt. On first start in a directory with\n`.opencode\u002Fplugins\u002F`, it installs its plugin npm package into `.opencode\u002F` before the prompt\nappears; in practice about eight seconds. Non-interactive runs were seen to stall at \"init\"\ntwice for unknown reasons; a relaunch in the same directory recovered. Child processes the plugin\nspawns inherit the TUI's stderr and draw over the screen until the next redraw. One Ctrl-C ends\nthe TUI and prints a resume line.\n\n## Non-interactive fallbacks\n\nThese fire the same lifecycle hooks and are easier to script when no TUI-only step is needed:\n`claude -p 'prompt'`, `codex exec 'prompt'` (only after the directory's hooks were trusted once\nin the TUI; `exec` cannot grant trust), `opencode run 'prompt'`. They cannot do `\u002Fcompact`, and\nthey cannot answer trust prompts.\n\n## The screen is never the evidence\n\nA TUI screen is an unreliable observable: a corrupted or starved redraw can show a sent\ncommand as still typed (which invites a second Enter and a doubled event), or hide a finished\nturn. The durable observables are the artefact file and the host's own log. When the screen and\na durable observable disagree, trust the durable one: check the capture directory or grep the\nhost log (filtered to your own run or project) before repeating any key.\n\n## Failure modes seen\n\n- Text typed but not submitted: text and Enter were in one `send-keys` call. Send `Enter` alone.\n- Program refused to start inside an agent session: inherited `CLAUDECODE`; unset it.\n- A long background poll was killed by the harness's low-memory guard. Keep waits short and\n  bounded inside the tool call; do not rely on a detached poller to wake you.\n- Two agents typing into one session interleave keystrokes. One driver per session; announce\n  the handoff before the other agent touches it.\n- A stalled program was recovered with `pkill -f \u003Cprogram>`, which killed EVERY instance of that\n  program on the machine, including two other agents' live sessions mid-sitting (2026-09-05).\n  Never kill by program name or pattern (`pkill -f`, `killall`). Read the pane, then kill only\n  your own session (`tmux kill-session -t NAME`) or your own pane's process\n  (`tmux list-panes -t NAME -F '#{pane_pid}'`, then `kill \u003Cpid>`).\n- Several sittings at once share the host's log file and the live store's fault file. Filter\n  every log line by your own project directory before drawing a conclusion. Judge \"live store\n  untouched\" by a byte digest of its database before and after, never by the fault file, which\n  grows from the surrounding agent session's own hooks.\n- A capture listing taken while the host could still emit undercounted (717 listed, 720 on\n  disk; the host had been killed while bootstrap events were still arriving). You cannot tell\n  from outside whether emission has stopped, and stopping the host is not by itself the\n  guarantee. Stop the host, then list, then count a second time; two agreeing reads of a\n  stopped directory are the evidence. Three of four re-counts did not move, which is what a\n  discriminating check looks like.\n- Several live hosts at once starved the terminal redraw (hook stderr drawn into the screen)\n  and the redraw never recovered. Run one capture sitting of ours at a time: another sitting is\n  identified by the campaign's project directories and by PASTURE variables in the process\n  environment, never by the program name alone. A host that is not ours (the user's own editor\n  session) is never a reason to stop, wait on or touch it; the load check is the only thing that\n  measures it. Check the load average before starting and wait, bounded, if it is high.\n\n## Helper\n\n`scripts\u002Ftmux-step.sh NAME 'text' \u002Fpath\u002Fexpected-file [ceiling-seconds]` sends the text and Enter\nas two calls, waits on the file with a bounded loop, then prints the wait and the pane tail.\n",{"name":5,"description":7},"main","7fe8098d35c17a7d6497a81e4c08abb4c2d02735",".claude\u002Fskills\u002Ftmux-capture-driver",0,"https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins","https:\u002F\u002Fgithub.com\u002Fdayvidpham","dhpham.com","2026-11-11 16:48:56",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add dayvidpham\u002Faura-plugins --skill tmux-capture-driver",{"tool":72,"command":73},"bunx","bunx skills add dayvidpham\u002Faura-plugins --skill tmux-capture-driver",{"tool":75,"command":76},"pnpm","pnpm dlx skills add dayvidpham\u002Faura-plugins --skill tmux-capture-driver","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftmux-capture-driver\u002FSKILL.md",true,[80],{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"scripts\u002Ftmux-step.sh","SCRIPT","脚本",854,"https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftmux-capture-driver\u002Fscripts\u002Ftmux-step.sh",[87,113,138,143,149,154],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":53},"01M70PPVS3CW9RYWGZ4KSNV7MV","afk-implement","Run an unattended (\"AFK\") implementation session as the supervisor — scope small progressive iterations, push feature branches, open pull requests, drive review waves to clean, and never merge. Use when the user says they are going AFK or to bed, asks for overnight autonomous implementation, says \"don't block on me\", \"open PRs but don't merge\", \"progressive adoption\", or \"stack changes\".","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fafk-implement\u002FSKILL.md",[],[94,95,96,97,98,99,100,101,102,103,30,104,105,106,107,108,109,110,111,112],"implement","afk implement","pull","bed","never","scope","clean","branches","open","autonomous","review","pull requests","stack","me","run","merge","unattended","overnight","but",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":53},"01M6CHSCKDTSV05385SJ05XWW6","protocol","Aura protocol reference documentation — 12-phase workflow, agent roles, constraints, and coding standards. Read when you need to understand the full workflow or look up conventions.","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fskills\u002Fprotocol\u002FSKILL.md",[119],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[115,121,122,123,124,125,126,127,128,129,130,131,30,132,133,134,135,136,137],"coding","standards","documentation","read","up","coding standards","reference","look","workflow","full","constraints","you","phase","roles","understand","conventions","aura",{"skillNo":139,"name":115,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":53},"01M6CHSBJDVKGWAJWQCNQ22F9F","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002Fskills\u002Fprotocol\u002FSKILL.md",[],[115],{"skillNo":144,"name":145,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":53},"01M6CHSAJY85M0W8NEAN4PRF82","example","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002Fskills\u002Fexample\u002FSKILL.md",[],[145],{"skillNo":150,"name":145,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":53},"01M6CHS9KQJYCWR1C9F2GJDZYX","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002F.opencode\u002Fskill\u002Fexample\u002FSKILL.md",[],[145],{"skillNo":155,"name":145,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":53},"01M6CHS8MSW2SDQ5Y05A3GZES4","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002F.agents\u002Fskills\u002Fexample\u002FSKILL.md",[],[145]]