[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAYNQZE8QC7JD6FJX9DZ7H":3,"skill-same:01M6DAYNQZE8QC7JD6FJX9DZ7H":79},{"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":25,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":13,"repositoryHtmlUrl":62,"repositoryHomepageUrl":6,"ownerHtmlUrl":63,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":64,"install":65,"resources":78},"01M6DAYNQZE8QC7JD6FJX9DZ7H","th-workflow",null,"Use for the day-to-day development workflow around a change, idea to merged branch: brainstorming intent and design before building or modifying a feature; executing a written implementation plan in checkpointed batches; dispatching parallel subagents for independent problems; requesting a code review before merge; verifying review feedback before acting on it; finishing a branch (merge, PR, keep, discard). Triggers: \"brainstorm this feature\", \"design before building\", \"execute this plan\", \"these failures look independent\", \"request a review\", \"the reviewer says\", \"merge or PR?\", \"clean up this branch\".","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\u002Fth-workflow\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"th workflow","workflow","before building","triggers","feature","upstream","clean","development workflow","superpowers","up","use","code review","branch","brainstorm","parallel","feedback","code","development","pr","design","2026-11-10 10:12:30",false,"---\nname: th-workflow\ndescription: >\n  Use for the day-to-day development workflow around a change, idea to\n  merged branch: brainstorming intent and design before building or\n  modifying a feature; executing a written implementation plan in\n  checkpointed batches; dispatching parallel subagents for independent\n  problems; requesting a code review before merge; verifying review\n  feedback before acting on it; finishing a branch (merge, PR, keep,\n  discard). Triggers: \"brainstorm this feature\", \"design before building\",\n  \"execute this plan\", \"these failures look independent\", \"request a\n  review\", \"the reviewer says\", \"merge or PR?\", \"clean up this branch\".\nmetadata:\n  owner: tze\n  authors:\n    - obra\u002Fsuperpowers (upstream)\n    - tze\n    - Claude Fable 5.1\n  status: active\n  last_reviewed: \"2026-09-02\"\n---\n\n# TH Workflow\n\nSuperskill router for the change lifecycle: design → plan execution →\nreview → integration. Six subskills live under `subskills\u002F`, each a complete\nskill package (maintained forks of `obra\u002Fsuperpowers`), discovered lazily —\nload **at most one** subskill body per step.\n\nThis superskill governs *procedure* around a change. The *quality* of the\ncode is `\u002Fth-engineering`; project-level specs and prioritization are\n`\u002Fth-projects`; unattended Beads issue execution has its own worker flows in\n`\u002Fbeads-orchestration` and does not route here.\n\n## Routing table\n\n| Task intent | Subskill | Typical trigger |\n|---|---|---|\n| Turn an idea into a validated design before implementation: one question at a time, 2–3 approaches, design presented in sections. | [subskills\u002Fbrainstorming\u002FSKILL.md](subskills\u002Fbrainstorming\u002FSKILL.md) | \"brainstorm this feature\", \"design this before we build\", \"what should this look like\" |\n| Execute a written plan in batches with review checkpoints; stop on blockers instead of guessing. | [subskills\u002Fexecuting-plans\u002FSKILL.md](subskills\u002Fexecuting-plans\u002FSKILL.md) | \"execute this plan\", \"work through docs\u002Fplans\u002F…\" |\n| Two or more independent problems (different test files, subsystems, bugs): one subagent per domain, run concurrently, integrate results. | [subskills\u002Fdispatching-parallel-agents\u002FSKILL.md](subskills\u002Fdispatching-parallel-agents\u002FSKILL.md) | \"these failures are unrelated\", \"investigate these in parallel\" |\n| Dispatch a reviewer subagent over a git range with the bundled prompt template; act on findings by severity. | [subskills\u002Frequesting-code-review\u002FSKILL.md](subskills\u002Frequesting-code-review\u002FSKILL.md) | \"request a review\", \"review before I merge\" |\n| Handle incoming review feedback: verify before implementing, push back with evidence, no performative agreement. | [subskills\u002Freceiving-code-review\u002FSKILL.md](subskills\u002Freceiving-code-review\u002FSKILL.md) | \"the reviewer says…\", \"should I apply this suggestion\" |\n| Implementation complete and tests green: verify, present merge \u002F PR \u002F keep \u002F discard, execute the choice, clean up the worktree. | [subskills\u002Ffinishing-a-development-branch\u002FSKILL.md](subskills\u002Ffinishing-a-development-branch\u002FSKILL.md) | \"I'm done, what now\", \"merge or PR\", \"clean up this branch\" |\n\n## Routing rules\n\n- **Lifecycle order**: brainstorming → executing-plans → requesting-code-review\n  (↔ receiving-code-review) → finishing-a-development-branch. Each subskill\n  names its successor; load the successor only when that step arrives.\n- **Design depth**: a repo with `about\u002F` shape docs and an OpenSpec surface\n  takes feature design through `\u002Fth-projects` (project-feature-request);\n  brainstorming here is the lightweight path for repos without one.\n- **Review substance vs. review procedure**: *what* to check (readability,\n  tests, dependencies, engineering bar) → `\u002Fth-engineering`; *how* to\n  dispatch a reviewer or respond to one → here.\n- **Parallelism**: dispatching-parallel-agents covers ad-hoc fan-out on\n  independent problems. Beads-tracked work fans out through\n  `\u002Fbeads-orchestration` (beads-coordinator) instead.\n- **Fallback**: workflow-adjacent but no row fits (writing the plan itself,\n  git mechanics) → proceed with router-level guidance; do not load a\n  subskill to browse.\n\n## Discover subskills\n\nThe routing table above is the primary index. Verify frontmatter only if the\ntable seems stale:\n\n```bash\nPKG=\"$(dirname \"\u003Cabsolute-path-to-this-SKILL.md>\")\"\nrg -n \"^name:|^description:\" \"$PKG\"\u002Fsubskills\u002F*\u002FSKILL.md\n```\n","# TH Workflow\n\nSuperskill router for the change lifecycle: design → plan execution →\nreview → integration. Six subskills live under `subskills\u002F`, each a complete\nskill package (maintained forks of `obra\u002Fsuperpowers`), discovered lazily —\nload **at most one** subskill body per step.\n\nThis superskill governs *procedure* around a change. The *quality* of the\ncode is `\u002Fth-engineering`; project-level specs and prioritization are\n`\u002Fth-projects`; unattended Beads issue execution has its own worker flows in\n`\u002Fbeads-orchestration` and does not route here.\n\n## Routing table\n\n| Task intent | Subskill | Typical trigger |\n|---|---|---|\n| Turn an idea into a validated design before implementation: one question at a time, 2–3 approaches, design presented in sections. | [subskills\u002Fbrainstorming\u002FSKILL.md](subskills\u002Fbrainstorming\u002FSKILL.md) | \"brainstorm this feature\", \"design this before we build\", \"what should this look like\" |\n| Execute a written plan in batches with review checkpoints; stop on blockers instead of guessing. | [subskills\u002Fexecuting-plans\u002FSKILL.md](subskills\u002Fexecuting-plans\u002FSKILL.md) | \"execute this plan\", \"work through docs\u002Fplans\u002F…\" |\n| Two or more independent problems (different test files, subsystems, bugs): one subagent per domain, run concurrently, integrate results. | [subskills\u002Fdispatching-parallel-agents\u002FSKILL.md](subskills\u002Fdispatching-parallel-agents\u002FSKILL.md) | \"these failures are unrelated\", \"investigate these in parallel\" |\n| Dispatch a reviewer subagent over a git range with the bundled prompt template; act on findings by severity. | [subskills\u002Frequesting-code-review\u002FSKILL.md](subskills\u002Frequesting-code-review\u002FSKILL.md) | \"request a review\", \"review before I merge\" |\n| Handle incoming review feedback: verify before implementing, push back with evidence, no performative agreement. | [subskills\u002Freceiving-code-review\u002FSKILL.md](subskills\u002Freceiving-code-review\u002FSKILL.md) | \"the reviewer says…\", \"should I apply this suggestion\" |\n| Implementation complete and tests green: verify, present merge \u002F PR \u002F keep \u002F discard, execute the choice, clean up the worktree. | [subskills\u002Ffinishing-a-development-branch\u002FSKILL.md](subskills\u002Ffinishing-a-development-branch\u002FSKILL.md) | \"I'm done, what now\", \"merge or PR\", \"clean up this branch\" |\n\n## Routing rules\n\n- **Lifecycle order**: brainstorming → executing-plans → requesting-code-review\n  (↔ receiving-code-review) → finishing-a-development-branch. Each subskill\n  names its successor; load the successor only when that step arrives.\n- **Design depth**: a repo with `about\u002F` shape docs and an OpenSpec surface\n  takes feature design through `\u002Fth-projects` (project-feature-request);\n  brainstorming here is the lightweight path for repos without one.\n- **Review substance vs. review procedure**: *what* to check (readability,\n  tests, dependencies, engineering bar) → `\u002Fth-engineering`; *how* to\n  dispatch a reviewer or respond to one → here.\n- **Parallelism**: dispatching-parallel-agents covers ad-hoc fan-out on\n  independent problems. Beads-tracked work fans out through\n  `\u002Fbeads-orchestration` (beads-coordinator) instead.\n- **Fallback**: workflow-adjacent but no row fits (writing the plan itself,\n  git mechanics) → proceed with router-level guidance; do not load a\n  subskill to browse.\n\n## Discover subskills\n\nThe routing table above is the primary index. Verify frontmatter only if the\ntable seems stale:\n\n```bash\nPKG=\"$(dirname \"\u003Cabsolute-path-to-this-SKILL.md>\")\"\nrg -n \"^name:|^description:\" \"$PKG\"\u002Fsubskills\u002F*\u002FSKILL.md\n```\n",{"name":5,"metadata":51,"description":58},{"owner":52,"status":53,"authors":54,"last_reviewed":57},"tze","active",[55,52,56],"obra\u002Fsuperpowers (upstream)","Claude Fable 5.1","2026-09-02","Use for the day-to-day development workflow around a change, idea to merged branch: brainstorming intent and design before building or modifying a feature; executing a written implementation plan in checkpointed batches; dispatching parallel subagents for independent problems; requesting a code review before merge; verifying review feedback before acting on it; finishing a branch (merge, PR, keep, discard). Triggers: \"brainstorm this feature\", \"design before building\", \"execute this plan\", \"these failures look independent\", \"request a review\", \"the reviewer says\", \"merge or PR?\", \"clean up this branch\".\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-workflow","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":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill th-workflow",{"tool":71,"command":72},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill th-workflow",{"tool":74,"command":75},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill th-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002FSKILL.md",true,[],[80,104,123,137,153,164],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":46},"01M6DAZD21TWH2ET70V9FF75CQ","user-run","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\".","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002FSKILL.md",[],[87,88,89,90,91,36,92,93,29,94,53,95,96,97,98,99,100,101,102,103],"user run","user","run","docker","logs","host","as","permission","time","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":116,"publishedAt":46},"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",[110,111],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[117,42,118,37,119,120,53,31,34,36,121,122],"requesting code review","review","work","requirements","verify","tasks",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":131,"publishedAt":46},"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",[129,130],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},[132,42,118,37,53,31,133,34,36,134,135,41,136],"receiving code review","implementation","code review feedback","technical","verification",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":46},"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",[],[38,43,144,145,36,146,119,147,148,44,34,149,150,151,53,31,152,133],"finishing a development branch","integrate","decide","how","cleanup","merge","tests","structured","options",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":46},"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",[],[160,161,162,118,163,53,31,133,34,36,98],"plans","executing plans","plan","execute",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":46},"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",[],[171,40,172,36,34,31,173,53,174,122,175],"parallel agents","dispatching parallel agents","state","dependencies","shared"]