[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71P0BWWP9HB0V567CK03WR9":3,"skill-same:01M71P0BWWP9HB0V567CK03WR9":107},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M71P0BWWP9HB0V567CK03WR9","verify-pi-setup",null,"Drive this repository's Pi configuration (extensions, skills, prompts, SYSTEM.md, keybindings) in an isolated Pi TUI under tmux and capture proof. Use before reporting a change to an extension, a setting, or resource loading as working, and to reproduce a TUI bug in this repo.","drsh4dow\u002Fpi-setup","drsh4dow","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F45247070?v=4","01M71P068NASGHSWS11VWW416N","Daniel Moretti","01M71P0698BH81N65NP04X9NVN",10,"MIT","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-pi-setup\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"verify pi setup","verify","setup","pi","prompts","reproduce","capture","proof","bug","extension","repository","reporting","change","extensions","use","system","repo","loading","as","setting","2026-11-10 10:56:23",false,"---\nname: verify-pi-setup\ndescription: Drive this repository's Pi configuration (extensions, skills, prompts, SYSTEM.md, keybindings) in an isolated Pi TUI under tmux and capture proof. Use before reporting a change to an extension, a setting, or resource loading as working, and to reproduce a TUI bug in this repo.\n---\n\n# Verify pi-setup\n\nThe product is Pi as this checkout configures it. A user touches the Pi TUI: slash commands, keybindings, the header and footer, and the tools the model calls. `scripts\u002Fcontrol-pi` starts that TUI in tmux against a scratch agent directory, so a run never reads or writes the live `~\u002F.pi\u002Fagent` beyond one credential refresh. Run every command from the checkout root:\n\n```bash\nCP=.agents\u002Fskills\u002Fverify-pi-setup\u002Fscripts\u002Fcontrol-pi\n```\n\nShell variables do not survive between tool calls: Pi starts each bash call in a new shell, so a `$CP` step in a later call runs as `send RUN …` and fails with `command not found`. Set `CP` at the top of every call that uses it, ending the assignment with `;` or a newline, as in `CP=.agents\u002Fskills\u002Fverify-pi-setup\u002Fscripts\u002Fcontrol-pi; $CP doctor RUN_ID`. On one line without the `;`, the shell expands `$CP` before it assigns it. Every `$CP` in this skill and its feature files sits under this rule.\n\nThe helper drives the checkout it lives in, so a git worktree verifies its own branch. Read [`features\u002FREADME.md`](features\u002FREADME.md) before driving, then follow the matching feature file.\n\n## Launch\n\n1. Run `vp install` once per checkout. Extensions load from the checkout and need its `node_modules` and `.build\u002Fbin`.\n2. Run `$CP launch [RUN_ID]`. It prints `run=`, `scratch=`, `evidence=`, and an `attach=` command for a human. Ready means the footer context gauge (`0.0%\u002F1.0M`) has rendered, at which point the header, banner, and every extension have loaded.\n\nLaunch builds the scratch state from the checkout every time:\n\n- `settings.json` is `agent\u002Fdefault.settings.json` plus an `extensions` entry pointing at the checkout's `agent\u002Fextensions`. The live `agent\u002Fsettings.json` is never read.\n- `SYSTEM.md`, `keybindings.json`, `skills\u002F`, `prompts\u002F`, and `themes\u002F` are copies. Edit the checkout and relaunch to pick up a change. Extensions load in place, but Pi reads them at startup, so relaunch after editing them too.\n- Pi runs with `--no-skills --skill \u003Cscratch>\u002Fagent\u002Fskills`, which keeps out `~\u002F.agents\u002Fskills` and any project skills.\n- `auth.json` is a copy of the live one. Launch first refreshes each OAuth token with less than 30 minutes left, in the live directory under Pi's lock, so the scratch copy does not refresh and rotate a token the live session still holds.\n- `PI_*` and `HERDR_*` variables from the caller are dropped, and `HERDR_ENV=0` keeps the instance out of Herdr.\n\nRuns are isolated by run ID and can run side by side. A run ID uses only letters, digits, `_`, and `-`, because tmux reads `.` and `:` in a target as separators. Each uses its own tmux session `vps-\u003CRUN_ID>` on the dedicated tmux socket `verify-pi-setup`. Drive only runs you launched. Never attach to or send keys to the user's own Pi.\n\n## Doctor\n\nRun `$CP doctor RUN_ID` before the first drive and again after anything surprising. It is read-only and exits non-zero on any `FAIL` line. It checks that the scratch directory exists, the tmux pane is alive, the `pi` process uses the scratch agent directory with `HERDR_ENV=0`, extensions point at this checkout, the stderr log has no errors, and the footer is rendered. Its `info` lines give the checkout commit (and whether `agent\u002F` has uncommitted changes), the Pi version, and the minutes left on each OAuth token.\n\nA `FAIL` on stderr usually means an extension failed to load. Read `$($CP path RUN_ID scratch)\u002Fpi.stderr.log`, then stop the run and relaunch after the fix.\n\n## Drive\n\n| Command                                              | Effect                                                                                                                                                                                   |\n| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `$CP send RUN_ID 'TEXT'`                             | Type `TEXT` literally into the editor, then press Enter. Use it for prompts, slash commands, and `!` shell commands. It records the session file's length, which `wait-turn` scans from. |\n| `$CP keys RUN_ID KEY...`                             | Send tmux key names, such as `C-o`, `Escape`, `Enter`, `Down`, `C-u`, or `C-M-m` for Ctrl-Alt-M. `-l TEXT` types without Enter.                                                          |\n| `$CP wait-turn RUN_ID [SECS]`                        | Wait until the turn of the prompt last sent with `send` ends, even when it ended before the wait started (60 s default).                                                                 |\n| `$CP wait-idle RUN_ID [SECS]`                        | Wait until no turn runs, no sent prompt is unread, no background job or subagent of the run is left, and the session file has not changed, all for 2 s (60 s default).                   |\n| `$CP wait RUN_ID 'ERE' [SECS]`                       | Poll the visible pane until it matches the extended regex (60 s default).                                                                                                                |\n| `$CP capture RUN_ID`                                 | Print the visible pane.                                                                                                                                                                  |\n| `$CP snap RUN_ID NAME`                               | Save the visible pane to `EVIDENCE\u002FNAME.txt` and print the path.                                                                                                                         |\n| `$CP path RUN_ID scratch\\|agent\\|evidence\\|sessions` | Print a run directory, such as the scratch `agent\u002F` that holds `settings.json`, or `sessions`, which holds the run's session `.jsonl` files.                                             |\n| `$CP list`                                           | List runs that still have scratch state, and the tmux sessions of run ids `stop` refuses, with the commands that end them.                                                               |\n\nAfter a prompt, wait on its turn end with `wait-turn`. The previous turn's footer, such as `TPS`, stays on screen while the next turn runs, so a `wait` on footer text returns at once. Use `wait-idle` when the turn starts a background job or a subagent and the drive must wait through the turn that the job's result starts. Use `wait` for a string an action puts on screen, such as a notice. Never wait on a fixed sleep.\n\n`wait-turn` follows the `send` that was last when the wait started, so send the next prompt only after the wait returns. A `send` while a turn runs queues the text as steering, so the TUI shows `Steering: TEXT` and Pi delivers the text after the model's current response finishes, before the next model request. In the one case observed, a turn running a single `sleep 20` tool call, Pi delivered the text right after that call's result and the model answered both prompts in one reply. After a `send` that starts no turn, such as `\u002Ffast`, `wait-turn` times out with `no turn started since the last send`, and `wait-idle` waits out its timeout too, so follow such a send with `wait` on the notice it shows. Every wait fails at once on a run that does not exist, or that has scratch state but no tmux session, because it is still launching or its session was killed (wait for `launch` to print `run=`, or stop and relaunch it). A wait fails with Pi's stderr when Pi exits.\n\nThe TUI is fullscreen, so `capture` shows only the visible screen. Snap each state before the next action pushes it away.\n\nA prompt to the model is a real request on the user's subscription. Keep prompts short, name the exact tool calls, and forbid others, as the feature files do.\n\n## Evidence\n\nEvidence lives in `~\u002F.local\u002Fstate\u002Fpi-agent\u002Fverify-pi-setup\u002F\u003CRUN_ID>\u002F` and survives `stop`. A proof holds:\n\n- A snap of the state before the action, and a snap after it.\n- The side effect read from its real location, copied into the evidence directory. Examples are `settings.json` in the scratch `agent\u002F`, a scratch `SKILL.md`, or a process listing.\n- The doctor output from the start of the run.\n- `pi.stderr.log`, which `stop` copies in.\n\nDrive the user path, meaning keys, slash commands, and model prompts. Do not call extension functions or edit scratch files to fake a state. A notice alone is not proof when the feature has a side effect, so read the side effect too.\n\n## Cleanup\n\nRun `$CP stop RUN_ID` after the last drive, and after every failed launch or drive. It is idempotent. It copies the stderr log into the evidence directory, kills the tmux session, kills every process that carries the run's `VERIFY_PI_SETUP_RUN` marker (background jobs included), and deletes the scratch directory. It never touches the evidence directory or another run. If it warns that the run refreshed a credential, tell the user, because the live session may need `\u002Flogin`.\n\nA failed launch saves `launch-failure.pane.txt` and `launch-failure.stderr.log` to the evidence directory and stops itself.\n","# Verify pi-setup\n\nThe product is Pi as this checkout configures it. A user touches the Pi TUI: slash commands, keybindings, the header and footer, and the tools the model calls. `scripts\u002Fcontrol-pi` starts that TUI in tmux against a scratch agent directory, so a run never reads or writes the live `~\u002F.pi\u002Fagent` beyond one credential refresh. Run every command from the checkout root:\n\n```bash\nCP=.agents\u002Fskills\u002Fverify-pi-setup\u002Fscripts\u002Fcontrol-pi\n```\n\nShell variables do not survive between tool calls: Pi starts each bash call in a new shell, so a `$CP` step in a later call runs as `send RUN …` and fails with `command not found`. Set `CP` at the top of every call that uses it, ending the assignment with `;` or a newline, as in `CP=.agents\u002Fskills\u002Fverify-pi-setup\u002Fscripts\u002Fcontrol-pi; $CP doctor RUN_ID`. On one line without the `;`, the shell expands `$CP` before it assigns it. Every `$CP` in this skill and its feature files sits under this rule.\n\nThe helper drives the checkout it lives in, so a git worktree verifies its own branch. Read [`features\u002FREADME.md`](features\u002FREADME.md) before driving, then follow the matching feature file.\n\n## Launch\n\n1. Run `vp install` once per checkout. Extensions load from the checkout and need its `node_modules` and `.build\u002Fbin`.\n2. Run `$CP launch [RUN_ID]`. It prints `run=`, `scratch=`, `evidence=`, and an `attach=` command for a human. Ready means the footer context gauge (`0.0%\u002F1.0M`) has rendered, at which point the header, banner, and every extension have loaded.\n\nLaunch builds the scratch state from the checkout every time:\n\n- `settings.json` is `agent\u002Fdefault.settings.json` plus an `extensions` entry pointing at the checkout's `agent\u002Fextensions`. The live `agent\u002Fsettings.json` is never read.\n- `SYSTEM.md`, `keybindings.json`, `skills\u002F`, `prompts\u002F`, and `themes\u002F` are copies. Edit the checkout and relaunch to pick up a change. Extensions load in place, but Pi reads them at startup, so relaunch after editing them too.\n- Pi runs with `--no-skills --skill \u003Cscratch>\u002Fagent\u002Fskills`, which keeps out `~\u002F.agents\u002Fskills` and any project skills.\n- `auth.json` is a copy of the live one. Launch first refreshes each OAuth token with less than 30 minutes left, in the live directory under Pi's lock, so the scratch copy does not refresh and rotate a token the live session still holds.\n- `PI_*` and `HERDR_*` variables from the caller are dropped, and `HERDR_ENV=0` keeps the instance out of Herdr.\n\nRuns are isolated by run ID and can run side by side. A run ID uses only letters, digits, `_`, and `-`, because tmux reads `.` and `:` in a target as separators. Each uses its own tmux session `vps-\u003CRUN_ID>` on the dedicated tmux socket `verify-pi-setup`. Drive only runs you launched. Never attach to or send keys to the user's own Pi.\n\n## Doctor\n\nRun `$CP doctor RUN_ID` before the first drive and again after anything surprising. It is read-only and exits non-zero on any `FAIL` line. It checks that the scratch directory exists, the tmux pane is alive, the `pi` process uses the scratch agent directory with `HERDR_ENV=0`, extensions point at this checkout, the stderr log has no errors, and the footer is rendered. Its `info` lines give the checkout commit (and whether `agent\u002F` has uncommitted changes), the Pi version, and the minutes left on each OAuth token.\n\nA `FAIL` on stderr usually means an extension failed to load. Read `$($CP path RUN_ID scratch)\u002Fpi.stderr.log`, then stop the run and relaunch after the fix.\n\n## Drive\n\n| Command                                              | Effect                                                                                                                                                                                   |\n| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `$CP send RUN_ID 'TEXT'`                             | Type `TEXT` literally into the editor, then press Enter. Use it for prompts, slash commands, and `!` shell commands. It records the session file's length, which `wait-turn` scans from. |\n| `$CP keys RUN_ID KEY...`                             | Send tmux key names, such as `C-o`, `Escape`, `Enter`, `Down`, `C-u`, or `C-M-m` for Ctrl-Alt-M. `-l TEXT` types without Enter.                                                          |\n| `$CP wait-turn RUN_ID [SECS]`                        | Wait until the turn of the prompt last sent with `send` ends, even when it ended before the wait started (60 s default).                                                                 |\n| `$CP wait-idle RUN_ID [SECS]`                        | Wait until no turn runs, no sent prompt is unread, no background job or subagent of the run is left, and the session file has not changed, all for 2 s (60 s default).                   |\n| `$CP wait RUN_ID 'ERE' [SECS]`                       | Poll the visible pane until it matches the extended regex (60 s default).                                                                                                                |\n| `$CP capture RUN_ID`                                 | Print the visible pane.                                                                                                                                                                  |\n| `$CP snap RUN_ID NAME`                               | Save the visible pane to `EVIDENCE\u002FNAME.txt` and print the path.                                                                                                                         |\n| `$CP path RUN_ID scratch\\|agent\\|evidence\\|sessions` | Print a run directory, such as the scratch `agent\u002F` that holds `settings.json`, or `sessions`, which holds the run's session `.jsonl` files.                                             |\n| `$CP list`                                           | List runs that still have scratch state, and the tmux sessions of run ids `stop` refuses, with the commands that end them.                                                               |\n\nAfter a prompt, wait on its turn end with `wait-turn`. The previous turn's footer, such as `TPS`, stays on screen while the next turn runs, so a `wait` on footer text returns at once. Use `wait-idle` when the turn starts a background job or a subagent and the drive must wait through the turn that the job's result starts. Use `wait` for a string an action puts on screen, such as a notice. Never wait on a fixed sleep.\n\n`wait-turn` follows the `send` that was last when the wait started, so send the next prompt only after the wait returns. A `send` while a turn runs queues the text as steering, so the TUI shows `Steering: TEXT` and Pi delivers the text after the model's current response finishes, before the next model request. In the one case observed, a turn running a single `sleep 20` tool call, Pi delivered the text right after that call's result and the model answered both prompts in one reply. After a `send` that starts no turn, such as `\u002Ffast`, `wait-turn` times out with `no turn started since the last send`, and `wait-idle` waits out its timeout too, so follow such a send with `wait` on the notice it shows. Every wait fails at once on a run that does not exist, or that has scratch state but no tmux session, because it is still launching or its session was killed (wait for `launch` to print `run=`, or stop and relaunch it). A wait fails with Pi's stderr when Pi exits.\n\nThe TUI is fullscreen, so `capture` shows only the visible screen. Snap each state before the next action pushes it away.\n\nA prompt to the model is a real request on the user's subscription. Keep prompts short, name the exact tool calls, and forbid others, as the feature files do.\n\n## Evidence\n\nEvidence lives in `~\u002F.local\u002Fstate\u002Fpi-agent\u002Fverify-pi-setup\u002F\u003CRUN_ID>\u002F` and survives `stop`. A proof holds:\n\n- A snap of the state before the action, and a snap after it.\n- The side effect read from its real location, copied into the evidence directory. Examples are `settings.json` in the scratch `agent\u002F`, a scratch `SKILL.md`, or a process listing.\n- The doctor output from the start of the run.\n- `pi.stderr.log`, which `stop` copies in.\n\nDrive the user path, meaning keys, slash commands, and model prompts. Do not call extension functions or edit scratch files to fake a state. A notice alone is not proof when the feature has a side effect, so read the side effect too.\n\n## Cleanup\n\nRun `$CP stop RUN_ID` after the last drive, and after every failed launch or drive. It is idempotent. It copies the stderr log into the evidence directory, kills the tmux session, kills every process that carries the run's `VERIFY_PI_SETUP_RUN` marker (background jobs included), and deletes the scratch directory. It never touches the evidence directory or another run. If it warns that the run refreshed a credential, tell the user, because the live session may need `\u002Flogin`.\n\nA failed launch saves `launch-failure.pane.txt` and `launch-failure.stderr.log` to the evidence directory and stops itself.\n",{"name":5,"description":7},"main","f7936596c1ba2e1472dadccc3f111b9d517fa96c",".agents\u002Fskills\u002Fverify-pi-setup",2,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup","https:\u002F\u002Fgithub.com\u002Fdrsh4dow","https:\u002F\u002Fdanielmoretti.com\u002F","Toss A Coin To Your Witcher :pirate_flag: ","2026-11-03 22:13:53",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add drsh4dow\u002Fpi-setup --skill verify-pi-setup",{"tool":59,"command":60},"bunx","bunx skills add drsh4dow\u002Fpi-setup --skill verify-pi-setup",{"tool":62,"command":63},"pnpm","pnpm dlx skills add drsh4dow\u002Fpi-setup --skill verify-pi-setup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-pi-setup\u002FSKILL.md",true,[67,73,77,81,85,89,93,97,101],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"features\u002Farchitecture-review.md","REFERENCE","参考文档",4373,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-pi-setup\u002Ffeatures\u002Farchitecture-review.md",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"features\u002Fbackground-terminals.md",2331,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-pi-setup\u002Ffeatures\u002Fbackground-terminals.md",{"path":78,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":79,"sourceHtmlUrl":80},"features\u002Ffast-mode.md",2940,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-pi-setup\u002Ffeatures\u002Ffast-mode.md",{"path":82,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":83,"sourceHtmlUrl":84},"features\u002Fprocess-status.md",2130,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-pi-setup\u002Ffeatures\u002Fprocess-status.md",{"path":86,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":87,"sourceHtmlUrl":88},"features\u002FREADME.md",3700,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-pi-setup\u002Ffeatures\u002FREADME.md",{"path":90,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":91,"sourceHtmlUrl":92},"features\u002Fsession-chrome.md",1886,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-pi-setup\u002Ffeatures\u002Fsession-chrome.md",{"path":94,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":95,"sourceHtmlUrl":96},"features\u002Fskill-visibility.md",3136,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-pi-setup\u002Ffeatures\u002Fskill-visibility.md",{"path":98,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":99,"sourceHtmlUrl":100},"features\u002Ftool-call-guards.md",7044,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-pi-setup\u002Ffeatures\u002Ftool-call-guards.md",{"path":102,"resourceType":103,"resourceTypeDesc":104,"sizeBytes":105,"sourceHtmlUrl":106},"scripts\u002Fcontrol-pi","SCRIPT","脚本",16748,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify-pi-setup\u002Fscripts\u002Fcontrol-pi",[108,130,161,178,199,210],{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":39},"01M71P4GPJMBK21BTZBKY9T8EE","changelog","Write the changelog entry for a pull request. Use when a PR changes behavior that users, operators, or integrators can notice.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fevals\u002Fharness-lessons\u002Ffixtures\u002Fchangelog-skill\u002FSKILL.md",[],[110,115,116,117,118,119,120,121,122,123,124,125,126,33,127,128,129],"users","pull","notice","changes","operators","pr","pull request","for","request","behavior","entry","write","when","can","changelog entry",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":146,"publishedAt":39},"01M71P4E9AZM56JBY227P2G1SC","writing-good-tickets","Write, file, or update an issue or ticket that an agent or a developer can take to one PR. Use when filing a bug or feature, updating an issue, or breaking a plan into tickets.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-tickets\u002FSKILL.md",[136,141],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[147,148,149,150,120,151,152,153,33,154,127,155,156,128,157,158,126,27,159,160],"good","writing","tickets","writing good tickets","feature","filing","ticket","false","file","one","plan","update","take","issue",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":169,"publishedAt":39},"01M71P4C0B0DXTRRSG9RA6Y687","writing-good-prs","Write or update a pull request title and body that a reviewer can trust and own. Use when opening a PR or editing its description.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-prs\u002FSKILL.md",[167,168],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},[147,170,148,171,116,172,120,173,33,154,127,128,174,175,121,123,158,126,176,177],"prs","writing good prs","trust","editing","reviewer","title","opening a pr","body",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":186,"publishedAt":39},"01M71P49D1AG2MR6AYNPMMT34Z","writing-good-commits","Write or reword a git commit message and size the commit it describes. Use when committing, or when reshaping commits during a rebase.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-commits\u002FSKILL.md",[184,185],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},[187,147,148,188,189,190,126,191,192,193,33,154,194,195,127,196,197,198],"commits","writing good commits","message","size","git commit message","git","git commit","rebase","commit message","committing","commit","it",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":207,"publishedAt":39},"01M71P480BDE55JMPVVEBCFS7P","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[205,206],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},[208,122,148,173,33,154,209,127],"writing for agents","documents",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":216,"publishedAt":39},"01M71P45SNCD7DDSA6FRVCPA17","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwizard\u002FSKILL.md",[],[212,217,38,122,218,219,220,221,33,222,154,127,223,156,224,128,225,226,227,228],"running","up","ci","provisioning infrastructure","only","invoke","Bash","interactive","credentials","dashboard","generate","human"]