[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAZD21TWH2ET70V9FF75CQ":3,"skill-same:01M6DAZD21TWH2ET70V9FF75CQ":92},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":13,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M6DAZD21TWH2ET70V9FF75CQ","user-run",null,"Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable \u002Fhome\u002Forca\u002F.tmp\u002F\u003Cslug>\u002Frun.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: \"I'll run it for you\", \"permission denied on docker.sock\", \"needs sudo\", \"sudo: a password is required\", \"run as tze\", \"\u002Fuser-run\".","tzeusy-org\u002Fai-bootstrap","tzeusy-org","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141543652?v=4","01M6DAM1AP09H27BYGFY9QCNPB","01M6DAM1F4R187EK11XDN9JZKH",0,"MIT","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"run","user run","user","use","docker","host","as","triggers","permission","active","time","log","logs","session","artifacts","password","access","secrets","risk","brief","2026-11-10 10:12:30",false,"---\nname: user-run\ndescription: 'Use when a step needs privileges this session lacks (docker, sudo, another user''s checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable \u002Fhome\u002Forca\u002F.tmp\u002F\u003Cslug>\u002Frun.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: \"I''ll run it for you\", \"permission denied on docker.sock\", \"needs sudo\", \"sudo: a password is required\", \"run as tze\", \"\u002Fuser-run\".'\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Opus 5.5\n  status: active\n  last_reviewed: \"2026-10-09\"\n---\n\n# User Run\n\nA handoff protocol for commands only the owner can run. Claude writes one\nscript per session, the owner runs it, and Claude reads its logs and carries\non without being told what happened.\n\n## Use When\n\n- A command fails for lack of privilege the session does not have: the\n  docker socket, `\u002Fsecrets\u002F*`, another user's home, sudo.\n- The owner offers to run something as `tze`, or asks for a `\u002Fuser-run`.\n\nDo not use it to get around a permission rule or a denied tool call. If the\nowner did not offer to run it, ask first.\n\n## Layout (fixed)\n\n`\u003Cbase>` is `$HOME\u002F.tmp` of the Claude session user (`$USER_RUN_BASE`\noverrides): **`\u002Fhome\u002Forca\u002F.tmp`** for orca. Always write absolute paths in\nthe payload; never `~`, which expands to `\u002Fhome\u002Ftze` there.\n\n```\n\u003Cbase>\u002F\u003Cslug>\u002F\n  run.sh                   harness + PAYLOAD heredoc\n  .lock                    held while a run is in progress (one run at a time)\n  \u003CRUN_ID>.log             full stdout+stderr of one run (RUN_ID = YYYYmmddHHMMSS)\n  \u003CRUN_ID>.exit            exit code; absent if the run died\n  \u003CRUN_ID>.started         written once su succeeded and the payload began\n  payload.\u003CRUN_ID>.sh      the payload exactly as executed\n  latest.log, latest.exit  symlinks to the newest run (latest.exit absent while running)\n  artifacts\u002F\u003CRUN_ID>\u002F      $ARTIFACTS for that run; artifacts\u002Flatest -> newest\n```\n\nThe slug dir is mode 2770 and shares the session user's group (`orca`); tze\nis in that group and the payload runs with umask 002, so both users can read\nand write everything. Earlier runs' artifacts stay readable under\n`artifacts\u002F\u003CRUN_ID>\u002F` for a later payload to use.\n\n## Procedure\n\n1. **Pick the slug once per session**: `\u003Ctopic>-\u003CYYYYmmdd>`, e.g.\n   `dev-rollout-20261009`. Reuse it for every later step in the session.\n2. **[Scaffold](scripts\u002Fscaffold.sh)**: `bash \u003Cskill-dir>\u002Fscripts\u002Fscaffold.sh \u003Cslug>`. It is\n   idempotent, never overwrites `run.sh`, and first prunes user-run state\n   older than 7 days ([cleanup](#cleanup)).\n3. **Write the payload.** Edit only the `PAYLOAD` heredoc in `run.sh`:\n   - Keep the `set -euo pipefail` and `shopt -s inherit_errexit` lines (the\n     latter makes `set -e` apply inside `$(…)`).\n   - Use absolute paths and `cd` explicitly first: the starting directory is\n     the owner's cwd when run directly, `\u002Fhome\u002Ftze` under `su -`. Use\n     `\u002Fhome\u002Ftze\u002F...` for tze's checkouts. No line may be exactly `PAYLOAD`;\n     it ends the heredoc.\n   - Stdin is `\u002Fdev\u002Fnull`: nothing may wait for typed input except `sudo`,\n     which prompts on the terminal. Use `--yes`\u002F`-y` style flags. Pagers and\n     colour are off (`PAGER=cat`, `GIT_PAGER=cat`, `SYSTEMD_PAGER=cat`,\n     `NO_COLOR=1`); stdout may still be a terminal, so pass `--no-pager` or\n     `--quiet` to tools that ignore those.\n   - Write machine-readable results (tags, SHAs, JSON) to `\"$ARTIFACTS\u002F…\"`, and\n     `echo` a one-line `RESULT key=value` summary at the end.\n   - Never print secrets. Load them with `set -a; . \u003Cenvfile>; set +a` or\n     `bws run`, and never echo them. The log is read back into Claude's context.\n   - Don't leave background jobs attached to the output: the run does not end\n     until they close it. Detach them with redirected output (`nohup … >file 2>&1 &`).\n   - Make it rerunnable. On later steps, replace or extend the payload; earlier\n     payloads stay as `payload.\u003CRUN_ID>.sh`.\n4. **Validate**: `bash -n run.sh`, and re-read the payload once.\n5. **Present it** to the owner using the brief below, then stop and wait.\n6. **When the owner says it ran**, run [`bash \u003Cskill-dir>\u002Fscripts\u002Fstatus.sh \u003Cslug>`](scripts\u002Fstatus.sh):\n   it reports the state, the `RESULT` lines, the artifacts and the log tail.\n   Read more of the log only if that is not enough. States:\n   - `done exit=N`: the payload ran; N is its exit code (130 = Ctrl-C).\n   - `not-started`: `su` failed (wrong password); the payload never ran.\n   - `died`: no exit code (killed, or the terminal closed mid-run).\n   - `running`: wait, or ask the owner.\n\n   Then continue the task on your own. On failure, diagnose from the log,\n   fix the payload, and present the delta. Re-present the whole brief only\n   if the risk changed.\n\n## Presentation brief (every time)\n\nLead with the command, then:\n\n- **Command**: `bash \u003Cbase>\u002F\u003Cslug>\u002Frun.sh`, from the owner's own terminal.\n  Running it as tze directly needs no password. Run as anyone else, it calls\n  `su`, which needs a real terminal (the harness refuses without one).\n  Claude Code's `!` prefix won't work: it runs as the session user, with no terminal.\n  Mention when the payload calls `sudo`: expect a sudo password prompt too.\n- **What it does, end to end**: each step in order, in plain words.\n- **Side effects**: what changes outside `\u003Cbase>\u002F\u003Cslug>`: git state,\n  registry pushes, cluster or DB writes, files in tze's home, system changes\n  via sudo.\n- **Risk**: low \u002F medium \u002F high, with one reason. Low means read-only or\n  rerunnable and local. High means anything destructive, outward-facing or\n  hard to undo; most `sudo` changes to the system are at least medium.\n- **Time**: an estimate, plus what dominates it.\n- **Rollback**: how to undo it, or \"nothing to undo\".\n- **What I'll do next**: what Claude reads from the log and does after.\n\n## Harness behaviour\n\n- It impersonates `${USER_TO_IMPERSONATE:-tze}`. If the invoking user already\n  is that user, it runs directly without a prompt. Otherwise it runs\n  `su --pty - \u003Cuser>`, which prompts on the terminal; Claude never sees the\n  password. `--pty` matters: plain `su -c` starts a session without a\n  controlling terminal, so `sudo` inside the payload could not prompt.\n- The payload runs under that user's interactive shell (`$SHELL -ic`), so PATH\n  from `~\u002F.zshrc` applies (`(eval): can't change option: zle` lines in the log\n  are harmless). A plain `su -c` misses it, which is how `bws` went missing on\n  2026-10-09.\n- One `tee` captures everything, including the payload's stderr, with start\n  and end markers and the exit code. Ctrl-C, TERM and hangup are noted in the\n  log and the payload's own exit code is recorded (130 unless the payload\n  traps the signal). Under `su --pty` the log has CRLF line endings;\n  `status.sh` strips them.\n- A second run of the same slug while one is in progress is refused. The\n  whole harness is parsed before it runs, so editing `run.sh` mid-run is\n  safe and takes effect on the next run.\n- It refuses early, with a reason, when the slug dir is not writable by the\n  invoker, the target user does not exist, `su` would have no terminal, the\n  payload can't be written in full (disk full), or the payload has a syntax\n  error.\n\n## Cleanup\n\n[`scripts\u002Fcleanup.sh [--days N] [--dry-run]`](scripts\u002Fcleanup.sh) (scaffold runs it with the\ndefault 7 days) removes, under `\u003Cbase>`, slug dirs with no file modified in N\ndays, and older runs (log, exit, payload copy, artifacts) inside live slug\ndirs, always keeping the latest run. It touches only dirs whose `run.sh`\ncarries the `# user-run:` header, and holds each slug's lock while pruning\nit: it skips a run in progress, and a run started meanwhile is refused. Files the\npayload left without group write permission can't be removed; it reports\nthem, keeps `run.sh` so the next cleanup retries, and carries on.\n\n## Tests\n\n`tests\u002Fharness.sh` runs the harness end to end in a throwaway dir (direct\nbranch only; `su --pty` needs a password). Run it after changing the\ntemplate or scripts.\n\n## Template\n\n[`assets\u002Frun.sh.template`](assets\u002Frun.sh.template) is the harness. Change the\ntemplate, not individual run scripts, when the harness itself needs to change.\nExisting `run.sh` files keep the harness they were scaffolded with.\n","# User Run\n\nA handoff protocol for commands only the owner can run. Claude writes one\nscript per session, the owner runs it, and Claude reads its logs and carries\non without being told what happened.\n\n## Use When\n\n- A command fails for lack of privilege the session does not have: the\n  docker socket, `\u002Fsecrets\u002F*`, another user's home, sudo.\n- The owner offers to run something as `tze`, or asks for a `\u002Fuser-run`.\n\nDo not use it to get around a permission rule or a denied tool call. If the\nowner did not offer to run it, ask first.\n\n## Layout (fixed)\n\n`\u003Cbase>` is `$HOME\u002F.tmp` of the Claude session user (`$USER_RUN_BASE`\noverrides): **`\u002Fhome\u002Forca\u002F.tmp`** for orca. Always write absolute paths in\nthe payload; never `~`, which expands to `\u002Fhome\u002Ftze` there.\n\n```\n\u003Cbase>\u002F\u003Cslug>\u002F\n  run.sh                   harness + PAYLOAD heredoc\n  .lock                    held while a run is in progress (one run at a time)\n  \u003CRUN_ID>.log             full stdout+stderr of one run (RUN_ID = YYYYmmddHHMMSS)\n  \u003CRUN_ID>.exit            exit code; absent if the run died\n  \u003CRUN_ID>.started         written once su succeeded and the payload began\n  payload.\u003CRUN_ID>.sh      the payload exactly as executed\n  latest.log, latest.exit  symlinks to the newest run (latest.exit absent while running)\n  artifacts\u002F\u003CRUN_ID>\u002F      $ARTIFACTS for that run; artifacts\u002Flatest -> newest\n```\n\nThe slug dir is mode 2770 and shares the session user's group (`orca`); tze\nis in that group and the payload runs with umask 002, so both users can read\nand write everything. Earlier runs' artifacts stay readable under\n`artifacts\u002F\u003CRUN_ID>\u002F` for a later payload to use.\n\n## Procedure\n\n1. **Pick the slug once per session**: `\u003Ctopic>-\u003CYYYYmmdd>`, e.g.\n   `dev-rollout-20261009`. Reuse it for every later step in the session.\n2. **[Scaffold](scripts\u002Fscaffold.sh)**: `bash \u003Cskill-dir>\u002Fscripts\u002Fscaffold.sh \u003Cslug>`. It is\n   idempotent, never overwrites `run.sh`, and first prunes user-run state\n   older than 7 days ([cleanup](#cleanup)).\n3. **Write the payload.** Edit only the `PAYLOAD` heredoc in `run.sh`:\n   - Keep the `set -euo pipefail` and `shopt -s inherit_errexit` lines (the\n     latter makes `set -e` apply inside `$(…)`).\n   - Use absolute paths and `cd` explicitly first: the starting directory is\n     the owner's cwd when run directly, `\u002Fhome\u002Ftze` under `su -`. Use\n     `\u002Fhome\u002Ftze\u002F...` for tze's checkouts. No line may be exactly `PAYLOAD`;\n     it ends the heredoc.\n   - Stdin is `\u002Fdev\u002Fnull`: nothing may wait for typed input except `sudo`,\n     which prompts on the terminal. Use `--yes`\u002F`-y` style flags. Pagers and\n     colour are off (`PAGER=cat`, `GIT_PAGER=cat`, `SYSTEMD_PAGER=cat`,\n     `NO_COLOR=1`); stdout may still be a terminal, so pass `--no-pager` or\n     `--quiet` to tools that ignore those.\n   - Write machine-readable results (tags, SHAs, JSON) to `\"$ARTIFACTS\u002F…\"`, and\n     `echo` a one-line `RESULT key=value` summary at the end.\n   - Never print secrets. Load them with `set -a; . \u003Cenvfile>; set +a` or\n     `bws run`, and never echo them. The log is read back into Claude's context.\n   - Don't leave background jobs attached to the output: the run does not end\n     until they close it. Detach them with redirected output (`nohup … >file 2>&1 &`).\n   - Make it rerunnable. On later steps, replace or extend the payload; earlier\n     payloads stay as `payload.\u003CRUN_ID>.sh`.\n4. **Validate**: `bash -n run.sh`, and re-read the payload once.\n5. **Present it** to the owner using the brief below, then stop and wait.\n6. **When the owner says it ran**, run [`bash \u003Cskill-dir>\u002Fscripts\u002Fstatus.sh \u003Cslug>`](scripts\u002Fstatus.sh):\n   it reports the state, the `RESULT` lines, the artifacts and the log tail.\n   Read more of the log only if that is not enough. States:\n   - `done exit=N`: the payload ran; N is its exit code (130 = Ctrl-C).\n   - `not-started`: `su` failed (wrong password); the payload never ran.\n   - `died`: no exit code (killed, or the terminal closed mid-run).\n   - `running`: wait, or ask the owner.\n\n   Then continue the task on your own. On failure, diagnose from the log,\n   fix the payload, and present the delta. Re-present the whole brief only\n   if the risk changed.\n\n## Presentation brief (every time)\n\nLead with the command, then:\n\n- **Command**: `bash \u003Cbase>\u002F\u003Cslug>\u002Frun.sh`, from the owner's own terminal.\n  Running it as tze directly needs no password. Run as anyone else, it calls\n  `su`, which needs a real terminal (the harness refuses without one).\n  Claude Code's `!` prefix won't work: it runs as the session user, with no terminal.\n  Mention when the payload calls `sudo`: expect a sudo password prompt too.\n- **What it does, end to end**: each step in order, in plain words.\n- **Side effects**: what changes outside `\u003Cbase>\u002F\u003Cslug>`: git state,\n  registry pushes, cluster or DB writes, files in tze's home, system changes\n  via sudo.\n- **Risk**: low \u002F medium \u002F high, with one reason. Low means read-only or\n  rerunnable and local. High means anything destructive, outward-facing or\n  hard to undo; most `sudo` changes to the system are at least medium.\n- **Time**: an estimate, plus what dominates it.\n- **Rollback**: how to undo it, or \"nothing to undo\".\n- **What I'll do next**: what Claude reads from the log and does after.\n\n## Harness behaviour\n\n- It impersonates `${USER_TO_IMPERSONATE:-tze}`. If the invoking user already\n  is that user, it runs directly without a prompt. Otherwise it runs\n  `su --pty - \u003Cuser>`, which prompts on the terminal; Claude never sees the\n  password. `--pty` matters: plain `su -c` starts a session without a\n  controlling terminal, so `sudo` inside the payload could not prompt.\n- The payload runs under that user's interactive shell (`$SHELL -ic`), so PATH\n  from `~\u002F.zshrc` applies (`(eval): can't change option: zle` lines in the log\n  are harmless). A plain `su -c` misses it, which is how `bws` went missing on\n  2026-10-09.\n- One `tee` captures everything, including the payload's stderr, with start\n  and end markers and the exit code. Ctrl-C, TERM and hangup are noted in the\n  log and the payload's own exit code is recorded (130 unless the payload\n  traps the signal). Under `su --pty` the log has CRLF line endings;\n  `status.sh` strips them.\n- A second run of the same slug while one is in progress is refused. The\n  whole harness is parsed before it runs, so editing `run.sh` mid-run is\n  safe and takes effect on the next run.\n- It refuses early, with a reason, when the slug dir is not writable by the\n  invoker, the target user does not exist, `su` would have no terminal, the\n  payload can't be written in full (disk full), or the payload has a syntax\n  error.\n\n## Cleanup\n\n[`scripts\u002Fcleanup.sh [--days N] [--dry-run]`](scripts\u002Fcleanup.sh) (scaffold runs it with the\ndefault 7 days) removes, under `\u003Cbase>`, slug dirs with no file modified in N\ndays, and older runs (log, exit, payload copy, artifacts) inside live slug\ndirs, always keeping the latest run. It touches only dirs whose `run.sh`\ncarries the `# user-run:` header, and holds each slug's lock while pruning\nit: it skips a run in progress, and a run started meanwhile is refused. Files the\npayload left without group write permission can't be removed; it reports\nthem, keeps `run.sh` so the next cleanup retries, and carries on.\n\n## Tests\n\n`tests\u002Fharness.sh` runs the harness end to end in a throwaway dir (direct\nbranch only; `su --pty` needs a password). Run it after changing the\ntemplate or scripts.\n\n## Template\n\n[`assets\u002Frun.sh.template`](assets\u002Frun.sh.template) is the harness. Change the\ntemplate, not individual run scripts, when the harness itself needs to change.\nExisting `run.sh` files keep the harness they were scaffolded with.\n",{"name":5,"metadata":43,"description":7},{"owner":44,"status":27,"authors":45,"last_reviewed":47},"tze",[44,46],"Claude Opus 5.5","2026-10-09","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fuser-run","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap","https:\u002F\u002Fgithub.com\u002Ftzeusy-org","2026-11-10 23:17:25",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill user-run",{"tool":60,"command":61},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill user-run",{"tool":63,"command":64},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill user-run","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002FSKILL.md",true,[68,74,80,84,88],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"assets\u002Frun.sh.template","ASSET","资产文件",4217,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002Fassets\u002Frun.sh.template",{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"scripts\u002Fcleanup.sh","SCRIPT","脚本",2979,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002Fscripts\u002Fcleanup.sh",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"scripts\u002Fscaffold.sh",1147,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002Fscripts\u002Fscaffold.sh",{"path":85,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":86,"sourceHtmlUrl":87},"scripts\u002Fstatus.sh",1412,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002Fscripts\u002Fstatus.sh",{"path":89,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":90,"sourceHtmlUrl":91},"tests\u002Fharness.sh",7550,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002Ftests\u002Fharness.sh",[93,120,135,154,165,178],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":109,"publishedAt":38},"01M6DAZAHTCBAD2WF0GAHWPST8","requesting-code-review","Use when completing tasks, implementing major features, or before merging to verify work meets requirements","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Frequesting-code-review\u002FSKILL.md",[99,104],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[110,111,112,113,114,27,115,116,21,117,118,119],"code review","review","code","requesting code review","requirements","upstream","superpowers","work","verify","tasks",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":128,"publishedAt":38},"01M6DAZ7CJ82D81XZB2YHVVY48","receiving-code-review","Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Freceiving-code-review\u002FSKILL.md",[126,127],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},[129,112,111,110,130,27,131,115,132,116,21,133,134],"receiving code review","code review feedback","verification","implementation","technical","feedback",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":38},"01M6DAZ4ER76ADXJ9KRFP7V3Q9","finishing-a-development-branch","Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Ffinishing-a-development-branch\u002FSKILL.md",[],[142,143,144,115,27,145,146,147,132,148,21,149,116,150,151,152,153,117],"branch","development","finishing a development branch","structured","options","integrate","tests","decide","pr","how","cleanup","merge",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":38},"01M6DAYZFWWW2YPKP89QNQR96H","executing-plans","Use when you have a written implementation plan to execute in a separate session with review checkpoints","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fexecuting-plans\u002FSKILL.md",[],[161,162,21,27,115,132,116,31,163,164,111],"executing plans","plans","execute","plan",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":38},"01M6DAYWM2YQHYCK7C35K1D29J","dispatching-parallel-agents","Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fdispatching-parallel-agents\u002FSKILL.md",[],[172,173,174,21,175,119,116,176,27,177,115],"parallel","parallel agents","dispatching parallel agents","state","shared","dependencies",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":187,"publishedAt":38},"01M6DAYS2A0RN688GYXBB4JRWF","brainstorming","Use before creative work — creating features, building components, adding functionality, or modifying behavior — to explore user intent, requirements, and design before implementation. One question at a time; 2–3 approaches; design validated in sections.","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fbrainstorming\u002FSKILL.md",[184],{"categoryNo":185,"categoryName":186,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000015","视觉设计",[180,188,114,27,28,115,189,132,116,21,20,190,191,117,192,193,194],"creative","intent","behavior","question","explore","components","design"]