[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CHRPHJWQSHQD62KT3ASABB":3,"skill-same:01M6CHRPHJWQSHQD62KT3ASABB":81},{"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":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":6,"updatedAt":60,"install":61,"resources":74},"01M6CHRPHJWQSHQD62KT3ASABB","run-harness-capture",null,"Run a live capture sitting that records raw lifecycle-hook payloads from real Claude Code, Codex and OpenCode sessions through pasture's capture sink, so the bytes can be cleared into fixtures. Carries the kit rules (a binary and transports generated with the version roots moved), the three environment variables, the dry run, per-harness setup and trigger recipes with expected file names, the fault line that is expected, the report format for the clearance step, and the safety rules (live sessions only, never the live store, nothing committed before clearance, nothing pushed before the user's ACCEPT). Use when a pin bump or a coverage slice needs authentic host payloads, or when the user says to run the captures.","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\u002Frun-harness-capture\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"run","harness","capture","run harness capture","when","sessions","kit","Variables","line","recipes","host","dry","bump","harness setup","opencode","only","never","version","use","environment","payloads","generated","coverage","Rules","pin","lifecycle","Safety","file","code","2026-11-10 10:12:30",false,"---\nname: run-harness-capture\ndescription: Run a live capture sitting that records raw lifecycle-hook payloads from real Claude Code, Codex and OpenCode sessions through pasture's capture sink, so the bytes can be cleared into fixtures. Carries the kit rules (a binary and transports generated with the version roots moved), the three environment variables, the dry run, per-harness setup and trigger recipes with expected file names, the fault line that is expected, the report format for the clearance step, and the safety rules (live sessions only, never the live store, nothing committed before clearance, nothing pushed before the user's ACCEPT). Use when a pin bump or a coverage slice needs authentic host payloads, or when the user says to run the captures.\n---\n\n# Run a live harness capture sitting\n\npasture proves each hook event with a fixture captured from a real host session. A sitting is\nthe set of live sessions that produce those raw bytes. The sitting itself is short (about ten\nminutes per harness). Most of the work is in the setup, the proof that each step fired, and the\nreport the clearance step needs. Mechanics for driving the TUIs are in `tmux-capture-driver`.\n\n## What a capture is\n\nWhen `PASTURE_CAPTURE_DIR` is set, the pasture hook binary writes the raw host payload to\n`\u003Cdir>\u002F\u003Charness>_\u003Csnake_event>_\u003Chost_version>.\u003Cn>.json` before it evaluates anything, and prints\nonce on stderr: `pasture: capture mode is recording this session to \u003Cdir>`. The directory must be\nabsolute, must exist, and must be outside every git repository; pasture never creates it and\nrefuses with one warning otherwise. The version in the file name comes from the `--host-version`\nargument the transport passes; a wrong or missing value produces a false or `unknown` name.\n\n## Preconditions\n\n1. **A kit.** A pasture binary plus the generated transports (Claude `hooks\u002Fhooks.json`, Codex\n   `.codex\u002Fhooks.json` and `.codex\u002Fhooks\u002Fevents\u002F*.sh`, OpenCode\n   `.opencode\u002Fplugins\u002Fpasture-lifecycle.ts`) built in a throwaway archive copy of the branch head\n   with the version roots moved to the installed host versions, then `make generate`. Never\n   hand-edit a generated file; never build the kit in the live worktree. Record the head SHA, the\n   root edits, the diff of the transports against the head (version strings only), and the SHA-256\n   of the binary and every transport file. The clearance step proves the committed transports equal\n   these bytes.\n2. **Host versions probed now**: `claude --version`, `codex --version`, `opencode --version`.\n   Paste them into the report. A host that moved since the kit was built is a stop.\n3. **Directories outside every repository**, for example under\n   `~\u002F.local\u002Fshare\u002Fpasture-captures\u002F`: one capture dir per harness, `dryrun`, `scratch`, and one\n   throwaway project dir per harness. Copy the kit's transports into the project dirs and verify\n   their digests there.\n\n## Environment, in every capture shell\n\n```bash\nunset CLAUDECODE CLAUDE_CODE_ENTRYPOINT          # only when launched from inside an agent session\nexport PASTURE_BIN=\u003Ckit binary>                  # \"$PASTURE_BIN\" --version prints \"pasture version devel\"\nexport PASTURE_DB_PATH=\u003Cbase>\u002Fscratch\u002Fpasture.db  # a fresh database; the live store is never a test bed\nexport PASTURE_CAPTURE_DIR=\u003Cbase>\u002F\u003Charness>      # absolute, exists, outside any repository\n```\n\nSet these only in the shell that runs the capture session. Any other shell with them set would\nrecord its sessions too.\n\n**Expected fault line.** On a fresh database each hook prints one long fail-open fault ending in\n`Lifecycle ingress cannot resolve Pasture's persisted system identity`. That is the known identity\nbootstrap defect. The host proceeds and the capture is written before that step. It is not a\ncapture failure.\n\n## Dry run before the first session\n\n```bash\nprintf '%s' '{\"session_id\":\"dry-run\",\"hook_event_name\":\"SessionStart\",\"source\":\"startup\"}' \\\n  | PASTURE_CAPTURE_DIR=\u003Cbase>\u002Fdryrun \"$PASTURE_BIN\" hook lifecycle --harness claude-code --event SessionStart --host-version \u003Cclaude version>\nls \u003Cbase>\u002Fdryrun    # expect claude-code_session_start_\u003Cv>.1.json and the notice line once\n```\n\nDelete the dryrun directory's contents afterwards. Hand-piped bytes are never fixtures.\n\n## Per-harness recipes (measured at 2.1.261 \u002F 0.153.0 \u002F 1.18.29)\n\n**Claude Code, 8 events, about 10 minutes.** The transport reads\n`--host-version \"${CLAUDE_CODE_VERSION:-unknown}\"`, so export\n`CLAUDE_CODE_VERSION=\"$(claude --version | cut -d' ' -f1)\"` in the capture shell or every file is\nnamed `unknown`. Start `claude` in the project dir (which holds README.md and NOTES.md), accept\nthe folder trust. Then:\n\n| Step | Prompt or command | Files produced |\n|---|---|---|\n| launch | (none) | `session_start.1` |\n| read | `Read the file README.md in this directory and tell me its first line.` | `pre_tool_use`, `post_tool_use`, `post_tool_batch` |\n| fail | `Read the file does-not-exist.txt in this directory.` | `post_tool_use_failure` (plus pre\u002Fpost\u002Fbatch) |\n| compact | `\u002Fcompact` | `pre_compact`, `post_compact`, and a second `session_start` (source compact) |\n| exit | `\u002Fexit` | `session_end` |\n\nClaude may satisfy a \"Read\" prompt with a Bash call (`head`, `cat`); the payload is then a\nBash-tool payload. Say so in the report. One tool call also fires PostToolBatch, so no separate\nparallel-call prompt is needed for that event.\n\n**Codex, 2 events, about 10 minutes.** Start `codex` in the project dir holding the kit's\n`.codex\u002F`. Accept the directory trust, then choose \"Trust all and continue\" on the hooks review;\nhooks run only when trusted, and `codex exec` cannot grant trust. At 0.153.0 the SessionStart\nhook is queued at session construction and runs at the start of the FIRST TURN, not at process\nstartup (core\u002Fsrc\u002Fsession\u002Fsession.rs and core\u002Fsrc\u002Fsession\u002Fturn.rs at tag rust-v0.153.0), so no\nfile appears until the first prompt; do not relaunch waiting for one. Prompt\n``Run the shell command `ls -la` and tell me what you see.``: `session_start` appears about one\nsecond after Enter and `pre_tool_use` a few seconds later. No approval prompt appeared (the\nread-only sandbox ran `ls -la` without asking). `\u002Fquit`.\n\n**OpenCode, 2 events, about 10 minutes.** Start `opencode` in the project dir holding the kit's\n`.opencode\u002Fplugins\u002Fpasture-lifecycle.ts`. First start installs the plugin npm package into\n`.opencode\u002F`; wait. The first prompt creates the session (`session_created`); the prompt\n`Run ls -la in the shell and describe the output.` produces `tool_execute_before`. If the TUI shows\nno prompt after about ninety seconds, quit and relaunch in the same directory; if it stalls again,\n`opencode run '\u003Cprompt>'` in the same shell is a proven fallback. Record which path ran. One\nCtrl-C ends the TUI. Cosmetic: the hook's stderr (the notice and the fault line) is drawn inside\nthe TUI until the next redraw, because the plugin's child process inherits the TUI's stderr; the\ncapture is not affected.\n\n## Rules\n\n- **Live sessions only.** Real host binaries producing real payloads. No hand-piped JSON, no\n  copies from another tool's data directory.\n- **Never touch the live store** (`~\u002F.local\u002Fshare\u002Fpasture`). The scratch database exists for this.\n- **Nothing is committed before the clearance procedure**, and nothing captured reaches a remote\n  before the user's verbatim ACCEPT is written into CLEARANCE.md. Private first.\n- **Version re-check before every session.** A moved host is a stop and a report, not a capture.\n- **Who drives.** The plan default is that the user drives the sessions; an agent drives them only\n  when the user rules so, and the report says who drove.\n- **Extra files are expected** (`.2`, `.3` for repeated pre\u002Fpost events). Missing stems are the\n  finding. Never delete a numbered file; the clearance step selects. Where several authentic\n  files exist for one event, clearance prefers the smallest and records the sizes not chosen\n  (one OpenCode system-prompt capture was 99 KB, cleared into 99 KB of placeholder).\n- **A citation proves the code exists, not that a trigger reaches it.** One recipe inferred a\n  trigger from a publish site; a guard one layer up resolved the bad argument to a default and\n  the event never fired. Give every row a second trigger when one exists. A trigger that does\n  not fire is a measurement; nobody concludes an event is unreachable from one failed trigger.\n- **Pair events by the host's per-operation identifier** at the finest scope the event carries\n  (Claude prompt_id, Codex turn_id then tool_use_id, OpenCode session then call or message and\n  part id), never by field values or arrival order. An identifier that every file in the batch\n  shares pairs nothing. State the scope and value for every pair the record asserts.\n\n## Report, for the clearance step\n\nPost one comment on the capture task, per harness: the `--version` line taken immediately before\nthe session; who drove and how (TUI through tmux, or a non-interactive mode); the exact prompts\nand the trust or approval choices; `ls -la \u003Ccapture dir>` verbatim; anything unexpected (stalls,\nrelaunches, a Read satisfied by Bash, a missing stem). Then message the clearance owner. The\nclearance procedure (inventory, home-path and free-text substitution, digest recompute, secret\nscan, CLEARANCE.md) is documented in pasture's AGENTS.md under \"Capturing host payloads and\nclearing them into fixtures\"; it starts from this report.\n","# Run a live harness capture sitting\n\npasture proves each hook event with a fixture captured from a real host session. A sitting is\nthe set of live sessions that produce those raw bytes. The sitting itself is short (about ten\nminutes per harness). Most of the work is in the setup, the proof that each step fired, and the\nreport the clearance step needs. Mechanics for driving the TUIs are in `tmux-capture-driver`.\n\n## What a capture is\n\nWhen `PASTURE_CAPTURE_DIR` is set, the pasture hook binary writes the raw host payload to\n`\u003Cdir>\u002F\u003Charness>_\u003Csnake_event>_\u003Chost_version>.\u003Cn>.json` before it evaluates anything, and prints\nonce on stderr: `pasture: capture mode is recording this session to \u003Cdir>`. The directory must be\nabsolute, must exist, and must be outside every git repository; pasture never creates it and\nrefuses with one warning otherwise. The version in the file name comes from the `--host-version`\nargument the transport passes; a wrong or missing value produces a false or `unknown` name.\n\n## Preconditions\n\n1. **A kit.** A pasture binary plus the generated transports (Claude `hooks\u002Fhooks.json`, Codex\n   `.codex\u002Fhooks.json` and `.codex\u002Fhooks\u002Fevents\u002F*.sh`, OpenCode\n   `.opencode\u002Fplugins\u002Fpasture-lifecycle.ts`) built in a throwaway archive copy of the branch head\n   with the version roots moved to the installed host versions, then `make generate`. Never\n   hand-edit a generated file; never build the kit in the live worktree. Record the head SHA, the\n   root edits, the diff of the transports against the head (version strings only), and the SHA-256\n   of the binary and every transport file. The clearance step proves the committed transports equal\n   these bytes.\n2. **Host versions probed now**: `claude --version`, `codex --version`, `opencode --version`.\n   Paste them into the report. A host that moved since the kit was built is a stop.\n3. **Directories outside every repository**, for example under\n   `~\u002F.local\u002Fshare\u002Fpasture-captures\u002F`: one capture dir per harness, `dryrun`, `scratch`, and one\n   throwaway project dir per harness. Copy the kit's transports into the project dirs and verify\n   their digests there.\n\n## Environment, in every capture shell\n\n```bash\nunset CLAUDECODE CLAUDE_CODE_ENTRYPOINT          # only when launched from inside an agent session\nexport PASTURE_BIN=\u003Ckit binary>                  # \"$PASTURE_BIN\" --version prints \"pasture version devel\"\nexport PASTURE_DB_PATH=\u003Cbase>\u002Fscratch\u002Fpasture.db  # a fresh database; the live store is never a test bed\nexport PASTURE_CAPTURE_DIR=\u003Cbase>\u002F\u003Charness>      # absolute, exists, outside any repository\n```\n\nSet these only in the shell that runs the capture session. Any other shell with them set would\nrecord its sessions too.\n\n**Expected fault line.** On a fresh database each hook prints one long fail-open fault ending in\n`Lifecycle ingress cannot resolve Pasture's persisted system identity`. That is the known identity\nbootstrap defect. The host proceeds and the capture is written before that step. It is not a\ncapture failure.\n\n## Dry run before the first session\n\n```bash\nprintf '%s' '{\"session_id\":\"dry-run\",\"hook_event_name\":\"SessionStart\",\"source\":\"startup\"}' \\\n  | PASTURE_CAPTURE_DIR=\u003Cbase>\u002Fdryrun \"$PASTURE_BIN\" hook lifecycle --harness claude-code --event SessionStart --host-version \u003Cclaude version>\nls \u003Cbase>\u002Fdryrun    # expect claude-code_session_start_\u003Cv>.1.json and the notice line once\n```\n\nDelete the dryrun directory's contents afterwards. Hand-piped bytes are never fixtures.\n\n## Per-harness recipes (measured at 2.1.261 \u002F 0.153.0 \u002F 1.18.29)\n\n**Claude Code, 8 events, about 10 minutes.** The transport reads\n`--host-version \"${CLAUDE_CODE_VERSION:-unknown}\"`, so export\n`CLAUDE_CODE_VERSION=\"$(claude --version | cut -d' ' -f1)\"` in the capture shell or every file is\nnamed `unknown`. Start `claude` in the project dir (which holds README.md and NOTES.md), accept\nthe folder trust. Then:\n\n| Step | Prompt or command | Files produced |\n|---|---|---|\n| launch | (none) | `session_start.1` |\n| read | `Read the file README.md in this directory and tell me its first line.` | `pre_tool_use`, `post_tool_use`, `post_tool_batch` |\n| fail | `Read the file does-not-exist.txt in this directory.` | `post_tool_use_failure` (plus pre\u002Fpost\u002Fbatch) |\n| compact | `\u002Fcompact` | `pre_compact`, `post_compact`, and a second `session_start` (source compact) |\n| exit | `\u002Fexit` | `session_end` |\n\nClaude may satisfy a \"Read\" prompt with a Bash call (`head`, `cat`); the payload is then a\nBash-tool payload. Say so in the report. One tool call also fires PostToolBatch, so no separate\nparallel-call prompt is needed for that event.\n\n**Codex, 2 events, about 10 minutes.** Start `codex` in the project dir holding the kit's\n`.codex\u002F`. Accept the directory trust, then choose \"Trust all and continue\" on the hooks review;\nhooks run only when trusted, and `codex exec` cannot grant trust. At 0.153.0 the SessionStart\nhook is queued at session construction and runs at the start of the FIRST TURN, not at process\nstartup (core\u002Fsrc\u002Fsession\u002Fsession.rs and core\u002Fsrc\u002Fsession\u002Fturn.rs at tag rust-v0.153.0), so no\nfile appears until the first prompt; do not relaunch waiting for one. Prompt\n``Run the shell command `ls -la` and tell me what you see.``: `session_start` appears about one\nsecond after Enter and `pre_tool_use` a few seconds later. No approval prompt appeared (the\nread-only sandbox ran `ls -la` without asking). `\u002Fquit`.\n\n**OpenCode, 2 events, about 10 minutes.** Start `opencode` in the project dir holding the kit's\n`.opencode\u002Fplugins\u002Fpasture-lifecycle.ts`. First start installs the plugin npm package into\n`.opencode\u002F`; wait. The first prompt creates the session (`session_created`); the prompt\n`Run ls -la in the shell and describe the output.` produces `tool_execute_before`. If the TUI shows\nno prompt after about ninety seconds, quit and relaunch in the same directory; if it stalls again,\n`opencode run '\u003Cprompt>'` in the same shell is a proven fallback. Record which path ran. One\nCtrl-C ends the TUI. Cosmetic: the hook's stderr (the notice and the fault line) is drawn inside\nthe TUI until the next redraw, because the plugin's child process inherits the TUI's stderr; the\ncapture is not affected.\n\n## Rules\n\n- **Live sessions only.** Real host binaries producing real payloads. No hand-piped JSON, no\n  copies from another tool's data directory.\n- **Never touch the live store** (`~\u002F.local\u002Fshare\u002Fpasture`). The scratch database exists for this.\n- **Nothing is committed before the clearance procedure**, and nothing captured reaches a remote\n  before the user's verbatim ACCEPT is written into CLEARANCE.md. Private first.\n- **Version re-check before every session.** A moved host is a stop and a report, not a capture.\n- **Who drives.** The plan default is that the user drives the sessions; an agent drives them only\n  when the user rules so, and the report says who drove.\n- **Extra files are expected** (`.2`, `.3` for repeated pre\u002Fpost events). Missing stems are the\n  finding. Never delete a numbered file; the clearance step selects. Where several authentic\n  files exist for one event, clearance prefers the smallest and records the sizes not chosen\n  (one OpenCode system-prompt capture was 99 KB, cleared into 99 KB of placeholder).\n- **A citation proves the code exists, not that a trigger reaches it.** One recipe inferred a\n  trigger from a publish site; a guard one layer up resolved the bad argument to a default and\n  the event never fired. Give every row a second trigger when one exists. A trigger that does\n  not fire is a measurement; nobody concludes an event is unreachable from one failed trigger.\n- **Pair events by the host's per-operation identifier** at the finest scope the event carries\n  (Claude prompt_id, Codex turn_id then tool_use_id, OpenCode session then call or message and\n  part id), never by field values or arrival order. An identifier that every file in the batch\n  shares pairs nothing. State the scope and value for every pair the record asserts.\n\n## Report, for the clearance step\n\nPost one comment on the capture task, per harness: the `--version` line taken immediately before\nthe session; who drove and how (TUI through tmux, or a non-interactive mode); the exact prompts\nand the trust or approval choices; `ls -la \u003Ccapture dir>` verbatim; anything unexpected (stalls,\nrelaunches, a Read satisfied by Bash, a missing stem). Then message the clearance owner. The\nclearance procedure (inventory, home-path and free-text substitution, digest recompute, secret\nscan, CLEARANCE.md) is documented in pasture's AGENTS.md under \"Capturing host payloads and\nclearing them into fixtures\"; it starts from this report.\n",{"name":5,"description":7},"main","7fe8098d35c17a7d6497a81e4c08abb4c2d02735",".claude\u002Fskills\u002Frun-harness-capture",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":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add dayvidpham\u002Faura-plugins --skill run-harness-capture",{"tool":67,"command":68},"bunx","bunx skills add dayvidpham\u002Faura-plugins --skill run-harness-capture",{"tool":70,"command":71},"pnpm","pnpm dlx skills add dayvidpham\u002Faura-plugins --skill run-harness-capture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Frun-harness-capture\u002FSKILL.md",true,[75],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fsemantic-system-cases.md","REFERENCE","参考文档",3497,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fperception-and-hierarchy-principles\u002Fskills\u002Fcolor-semantic-systems\u002Freferences\u002Fsemantic-system-cases.md",[82,106,135,140,146,151],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":48},"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",[],[89,90,91,92,35,93,94,95,96,97,23,98,99,100,101,19,102,103,104,105],"implement","afk implement","pull","bed","scope","clean","branches","open","autonomous","review","pull requests","stack","me","merge","unattended","overnight","but",{"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":117,"publishedAt":48},"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",[112],{"categoryNo":113,"categoryName":114,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[108,118,119,120,121,122,123,124,125,126,127,128,23,129,130,131,132,133,134],"coding","standards","documentation","read","up","coding standards","reference","look","workflow","full","constraints","you","phase","roles","understand","conventions","aura",{"skillNo":136,"name":108,"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":137,"categories":138,"keywords":139,"publishedAt":48},"01M6CHSBJDVKGWAJWQCNQ22F9F","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002Fskills\u002Fprotocol\u002FSKILL.md",[],[108],{"skillNo":141,"name":142,"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":143,"categories":144,"keywords":145,"publishedAt":48},"01M6CHSAJY85M0W8NEAN4PRF82","example","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002Fskills\u002Fexample\u002FSKILL.md",[],[142],{"skillNo":147,"name":142,"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":148,"categories":149,"keywords":150,"publishedAt":48},"01M6CHS9KQJYCWR1C9F2GJDZYX","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002F.opencode\u002Fskill\u002Fexample\u002FSKILL.md",[],[142],{"skillNo":152,"name":142,"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":153,"categories":154,"keywords":155,"publishedAt":48},"01M6CHS8MSW2SDQ5Y05A3GZES4","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002F.agents\u002Fskills\u002Fexample\u002FSKILL.md",[],[142]]