[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DATKCG6ZDKJS341RR2H419":3,"skill-same:01M6DATKCG6ZDKJS341RR2H419":80},{"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":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":13,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":59,"install":60,"resources":73},"01M6DATKCG6ZDKJS341RR2H419","ci-discipline",null,"Use when designing, auditing, or speeding up a CI\u002FCD pipeline, or when deciding where a check should run — gate placement by cost tier, computing each verdict once per tree, affected-only selection, merge-queue topology, queue-wait vs execution diagnosis, runtime budgets, and agent push\u002Frun habits that multiply CI runs. Complements test-rigor (what a test is worth) with where and how often checks 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\u002Fth-engineering\u002Fsubskills\u002Fci-discipline\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"discipline","ci discipline","ci","only","merge","runtime","active","selection","gate","cost","queue","up","push","test","use","check","how","execution","pipeline","run","2026-11-10 10:12:30",false,"---\nname: ci-discipline\ndescription: >\n  Use when designing, auditing, or speeding up a CI\u002FCD pipeline, or when\n  deciding where a check should run — gate placement by cost tier, computing\n  each verdict once per tree, affected-only selection, merge-queue topology,\n  queue-wait vs execution diagnosis, runtime budgets, and agent push\u002Frun\n  habits that multiply CI runs. Complements test-rigor (what a test is\n  worth) with where and how often checks run.\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Opus 5.5\n  status: active\n  last_reviewed: \"2026-11-01\"\n---\n\n# CI Discipline\n\nA pipeline's job: give a trustworthy merge verdict on the exact tree that\nlands, as early and as cheaply as possible, and never compute the same verdict\ntwice. Slow CI is usually placement and duplication, not test count; test\ncount is the last lever, not the first.\n\n## Use This Skill When\n\n- CI is slow, clogged, or queues; PRs wait on runs that repeat work\n- Deciding where a new check runs (editor loop, pre-commit, PR, merge\n  queue, nightly)\n- Auditing CI triggers, required checks, sharding, caching, or a merge queue\n- Writing or reviewing guidance that tells agents when to run tests or push\n\n## Do Not Use This Skill For\n\n- Whether an individual test is worth keeping, or suite tiers and\n  condensation — [test-rigor](..\u002Ftest-rigor\u002FSKILL.md)\n- Why a specific run is red or flaky — [diagnosis](..\u002Fdiagnosis\u002FSKILL.md)\n- Release readiness for one deploy — `\u002Fengineering:deploy-checklist`\n\n## Core Rule\n\n**Each verdict is computed once per tree, in the cheapest tier that can give\nit, and reused until the tree changes.** A run whose result was already known\nfor this tree is waste, whoever ran it. A tree is the content being judged,\nnot the actor, branch, or session. For merge evidence it is the tree that\n**lands** (the merge result), not the branch head\n(`git rev-parse HEAD^{tree}` names a head's tree).\n\n## Gate Tiers\n\nEvery check lives in exactly one tier. Promote a check only with a reason; a\ncheck present in two tiers for the same tree is a finding.\n\n| Tier | Runs | Budget | Holds |\n|---|---|---|---|\n| **Edit loop** (local) | Exact node, then its file or package | Seconds | The tests covering the change |\n| **Pre-commit \u002F pre-push** (local) | Deterministic, diff-scoped | ≤ ~10 s | Format, lint changed files, cheap guards |\n| **PR** (hosted) | Affected-only selection plus guards | Minutes | Content signal: does this diff pass |\n| **Terminal gate** (merge queue or exact-base gate) | Full broad suite on the exact tree that lands | Once per landing tree | Merge evidence |\n| **Scheduled** (nightly) | Exhaustive, slow, quarantined, mutation, long e2e | Off the merge path | Drift detection; files issues, does not block |\n\n- With a terminal gate, the PR tier never runs the full suite. Uncertainty in\n  the affected-test planner widens the **selection** (add the lane, package,\n  or dependent), not the whole run.\n- Without a terminal gate, the PR's full run is the best gate available, not\n  exact landing-tree evidence: it tests the merge with the base as it was when\n  the run started. Nothing else recomputes it (not a local pre-PR copy, not a\n  reviewer), and a post-merge run on the base branch catches the drift.\n- **Skip a local broad run only when both hold**: the repo assigns broad lanes\n  to hosted CI or a merge queue, and a required hosted check covers the tree\n  that lands. Otherwise (no hosted CI, CI not required, a direct push to the\n  base) the local broad run is the gate and is mandatory, once, on the head\n  that will land. Reproducing a hosted failure locally is always fine.\n\n## The Bar\n\nReviewable expectations; cite the one violated with file:line evidence.\n\n1. **One placement policy, written down** — The repo states which tier owns\n   which check (`AGENTS.md`, `docs\u002Ftesting\u002Fci.md`). Skills and agents defer\n   to it; when it is missing, writing it is the first fix.\n2. **No duplicate triggers** — One event per state change: `push` on every\n   branch plus `pull_request` runs everything twice. Draft PRs and pre-PR\n   branch pushes get the cheap tiers only. Superseded PR runs cancel\n   (concurrency group per PR).\n3. **Verdict reuse is explicit** — Evidence names the commit and tree it\n   judged. Nobody re-runs a passing check on an unchanged tree for\n   reassurance (engineering-bar bias 8). Independent review reads the hosted\n   result on the exact head; it does not recompute it.\n4. **Rebase only for a reason** — Conflicts, or an exact-base gate that\n   requires it. A rebase of a green PR discards a paid run. With a merge\n   queue, the queue integrates; nothing rebases to freshen.\n5. **Budget the clock, not the count** — Track time-to-green p50\u002Fp95 split\n   into queue wait, setup, and execution; the critical-path shard; and runs\n   per merged PR. A test-count ratchet is a tripwire that prompts this\n   measurement, not the budget itself.\n6. **Diagnose before cutting** — Attribute the slow path, then take the fix\n   ladder below in order. Condensing tests to fix runner queueing is a\n   category error.\n7. **Required checks are few and stable** — One aggregate verdict job is the\n   required check, asserting which jobs each routing mode must run, so\n   skipped jobs neither block nor silently pass.\n   Changing the required set is a deliberate, reviewed change.\n8. **Flakes leave the blocking path** — Quarantine with an owner and an\n   expiry, measured on the scheduled tier. Retries in the blocking path are\n   counted and reported, never silent (test-rigor bar 6).\n9. **The pipeline is code under greenfield parity** — CI config has an\n   owner and a size proportional to what it guards. A guard duplicating a\n   test or lint rule is residue (one gate species per behavior). Frequent\n   churn in the pipeline is itself a cost signal\n   ([greenfield-parity](..\u002Fgreenfield-parity\u002FSKILL.md) \"tooling sprawl\").\n\n## Fix Ladder\n\nTake the first rung that addresses the measured cause; re-measure before the\nnext.\n\n1. **Remove duplicate runs** — triggers, local broad runs, reviewer re-runs,\n   needless rebases, superseded runs not cancelled.\n2. **Select, don't exhaust** — affected-only at the PR tier; the full suite\n   once at the terminal gate.\n3. **Cut setup** — dependency and build caches, reused databases, containers\n   and migrations instead of per-test bootstrap.\n4. **Balance the critical path** — shard by recorded duration so the slowest\n   shard is not the floor.\n5. **Fix capacity** — when queue wait dominates: runner pool size versus\n   peak demand (jobs per run × concurrent runs), merge-queue build\n   concurrency, fewer larger jobs.\n6. **Condense the suite** — test-rigor's condensation pass, last.\n\n## Agent Habits\n\nAutonomous lanes multiply every waste above; agent guidance holds these:\n\n- Iterate on the edit-loop tier; run the broad gate where the policy puts it.\n- If pushes trigger CI, push when ready for review, not to back up WIP.\n- Implementer and reviewer do not both recompute the hosted verdict; the\n  reviewer reads it for the exact head and runs only targeted checks it has a\n  specific reason for.\n- Without a merge queue, keep one PR at the train head with fresh CI;\n  hold overlapping PRs until it lands, then rebase the next only if it\n  conflicts or the base requires up-to-date branches.\n- Size watch deadlines from each job's observed p95; read the workflow's\n  triggers and `run:` lines before claiming what CI covers.\n\n## Workflow (pipeline audit)\n\n1. **Inventory**: event × job matrix; tag each job with its tier. Mark\n   duplicates (same verdict, same tree, two tiers or two actors), including\n   local runs prescribed by agent guidance.\n2. **Measure** a dated cohort: time-to-green split by queue, setup, and\n   execution per job; runs per merged PR. Commands for GitHub Actions:\n   [github-actions](references\u002Fgithub-actions.md).\n3. **Attribute** the critical path, then pick the fix ladder rung.\n4. **Write the placement policy** into the repo docs, in the same change as\n   the pipeline edit.\n5. **Verify**: re-measure on a comparable cohort; state before and after.\n\n## Trigger Sanity Check\n\n- Should trigger: \"CI is too slow\", \"why does CI run twice\", \"pre-commit or\n  CI?\", \"do we need a merge queue\", \"agents keep re-running the full suite\".\n- Should not trigger: \"why is this test red\" (diagnosis), \"are these tests\n  meaningful\" (test-rigor), \"cut a release\" (deploy-checklist).\n","# CI Discipline\n\nA pipeline's job: give a trustworthy merge verdict on the exact tree that\nlands, as early and as cheaply as possible, and never compute the same verdict\ntwice. Slow CI is usually placement and duplication, not test count; test\ncount is the last lever, not the first.\n\n## Use This Skill When\n\n- CI is slow, clogged, or queues; PRs wait on runs that repeat work\n- Deciding where a new check runs (editor loop, pre-commit, PR, merge\n  queue, nightly)\n- Auditing CI triggers, required checks, sharding, caching, or a merge queue\n- Writing or reviewing guidance that tells agents when to run tests or push\n\n## Do Not Use This Skill For\n\n- Whether an individual test is worth keeping, or suite tiers and\n  condensation — [test-rigor](..\u002Ftest-rigor\u002FSKILL.md)\n- Why a specific run is red or flaky — [diagnosis](..\u002Fdiagnosis\u002FSKILL.md)\n- Release readiness for one deploy — `\u002Fengineering:deploy-checklist`\n\n## Core Rule\n\n**Each verdict is computed once per tree, in the cheapest tier that can give\nit, and reused until the tree changes.** A run whose result was already known\nfor this tree is waste, whoever ran it. A tree is the content being judged,\nnot the actor, branch, or session. For merge evidence it is the tree that\n**lands** (the merge result), not the branch head\n(`git rev-parse HEAD^{tree}` names a head's tree).\n\n## Gate Tiers\n\nEvery check lives in exactly one tier. Promote a check only with a reason; a\ncheck present in two tiers for the same tree is a finding.\n\n| Tier | Runs | Budget | Holds |\n|---|---|---|---|\n| **Edit loop** (local) | Exact node, then its file or package | Seconds | The tests covering the change |\n| **Pre-commit \u002F pre-push** (local) | Deterministic, diff-scoped | ≤ ~10 s | Format, lint changed files, cheap guards |\n| **PR** (hosted) | Affected-only selection plus guards | Minutes | Content signal: does this diff pass |\n| **Terminal gate** (merge queue or exact-base gate) | Full broad suite on the exact tree that lands | Once per landing tree | Merge evidence |\n| **Scheduled** (nightly) | Exhaustive, slow, quarantined, mutation, long e2e | Off the merge path | Drift detection; files issues, does not block |\n\n- With a terminal gate, the PR tier never runs the full suite. Uncertainty in\n  the affected-test planner widens the **selection** (add the lane, package,\n  or dependent), not the whole run.\n- Without a terminal gate, the PR's full run is the best gate available, not\n  exact landing-tree evidence: it tests the merge with the base as it was when\n  the run started. Nothing else recomputes it (not a local pre-PR copy, not a\n  reviewer), and a post-merge run on the base branch catches the drift.\n- **Skip a local broad run only when both hold**: the repo assigns broad lanes\n  to hosted CI or a merge queue, and a required hosted check covers the tree\n  that lands. Otherwise (no hosted CI, CI not required, a direct push to the\n  base) the local broad run is the gate and is mandatory, once, on the head\n  that will land. Reproducing a hosted failure locally is always fine.\n\n## The Bar\n\nReviewable expectations; cite the one violated with file:line evidence.\n\n1. **One placement policy, written down** — The repo states which tier owns\n   which check (`AGENTS.md`, `docs\u002Ftesting\u002Fci.md`). Skills and agents defer\n   to it; when it is missing, writing it is the first fix.\n2. **No duplicate triggers** — One event per state change: `push` on every\n   branch plus `pull_request` runs everything twice. Draft PRs and pre-PR\n   branch pushes get the cheap tiers only. Superseded PR runs cancel\n   (concurrency group per PR).\n3. **Verdict reuse is explicit** — Evidence names the commit and tree it\n   judged. Nobody re-runs a passing check on an unchanged tree for\n   reassurance (engineering-bar bias 8). Independent review reads the hosted\n   result on the exact head; it does not recompute it.\n4. **Rebase only for a reason** — Conflicts, or an exact-base gate that\n   requires it. A rebase of a green PR discards a paid run. With a merge\n   queue, the queue integrates; nothing rebases to freshen.\n5. **Budget the clock, not the count** — Track time-to-green p50\u002Fp95 split\n   into queue wait, setup, and execution; the critical-path shard; and runs\n   per merged PR. A test-count ratchet is a tripwire that prompts this\n   measurement, not the budget itself.\n6. **Diagnose before cutting** — Attribute the slow path, then take the fix\n   ladder below in order. Condensing tests to fix runner queueing is a\n   category error.\n7. **Required checks are few and stable** — One aggregate verdict job is the\n   required check, asserting which jobs each routing mode must run, so\n   skipped jobs neither block nor silently pass.\n   Changing the required set is a deliberate, reviewed change.\n8. **Flakes leave the blocking path** — Quarantine with an owner and an\n   expiry, measured on the scheduled tier. Retries in the blocking path are\n   counted and reported, never silent (test-rigor bar 6).\n9. **The pipeline is code under greenfield parity** — CI config has an\n   owner and a size proportional to what it guards. A guard duplicating a\n   test or lint rule is residue (one gate species per behavior). Frequent\n   churn in the pipeline is itself a cost signal\n   ([greenfield-parity](..\u002Fgreenfield-parity\u002FSKILL.md) \"tooling sprawl\").\n\n## Fix Ladder\n\nTake the first rung that addresses the measured cause; re-measure before the\nnext.\n\n1. **Remove duplicate runs** — triggers, local broad runs, reviewer re-runs,\n   needless rebases, superseded runs not cancelled.\n2. **Select, don't exhaust** — affected-only at the PR tier; the full suite\n   once at the terminal gate.\n3. **Cut setup** — dependency and build caches, reused databases, containers\n   and migrations instead of per-test bootstrap.\n4. **Balance the critical path** — shard by recorded duration so the slowest\n   shard is not the floor.\n5. **Fix capacity** — when queue wait dominates: runner pool size versus\n   peak demand (jobs per run × concurrent runs), merge-queue build\n   concurrency, fewer larger jobs.\n6. **Condense the suite** — test-rigor's condensation pass, last.\n\n## Agent Habits\n\nAutonomous lanes multiply every waste above; agent guidance holds these:\n\n- Iterate on the edit-loop tier; run the broad gate where the policy puts it.\n- If pushes trigger CI, push when ready for review, not to back up WIP.\n- Implementer and reviewer do not both recompute the hosted verdict; the\n  reviewer reads it for the exact head and runs only targeted checks it has a\n  specific reason for.\n- Without a merge queue, keep one PR at the train head with fresh CI;\n  hold overlapping PRs until it lands, then rebase the next only if it\n  conflicts or the base requires up-to-date branches.\n- Size watch deadlines from each job's observed p95; read the workflow's\n  triggers and `run:` lines before claiming what CI covers.\n\n## Workflow (pipeline audit)\n\n1. **Inventory**: event × job matrix; tag each job with its tier. Mark\n   duplicates (same verdict, same tree, two tiers or two actors), including\n   local runs prescribed by agent guidance.\n2. **Measure** a dated cohort: time-to-green split by queue, setup, and\n   execution per job; runs per merged PR. Commands for GitHub Actions:\n   [github-actions](references\u002Fgithub-actions.md).\n3. **Attribute** the critical path, then pick the fix ladder rung.\n4. **Write the placement policy** into the repo docs, in the same change as\n   the pipeline edit.\n5. **Verify**: re-measure on a comparable cohort; state before and after.\n\n## Trigger Sanity Check\n\n- Should trigger: \"CI is too slow\", \"why does CI run twice\", \"pre-commit or\n  CI?\", \"do we need a merge queue\", \"agents keep re-running the full suite\".\n- Should not trigger: \"why is this test red\" (diagnosis), \"are these tests\n  meaningful\" (test-rigor), \"cut a release\" (deploy-checklist).\n",{"name":5,"metadata":48,"description":53},{"owner":49,"status":29,"authors":50,"last_reviewed":52},"tze",[49,51],"Claude Opus 5.5","2026-11-01","Use when designing, auditing, or speeding up a CI\u002FCD pipeline, or when deciding where a check should run — gate placement by cost tier, computing each verdict once per tree, affected-only selection, merge-queue topology, queue-wait vs execution diagnosis, runtime budgets, and agent push\u002Frun habits that multiply CI runs. Complements test-rigor (what a test is worth) with where and how often checks run.\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fci-discipline","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":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill ci-discipline",{"tool":66,"command":67},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill ci-discipline",{"tool":69,"command":70},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill ci-discipline","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fci-discipline\u002FSKILL.md",true,[74],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fgithub-actions.md","REFERENCE","参考文档",6659,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fci-discipline\u002Freferences\u002Fgithub-actions.md",[81,105,130,145,162,173],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":43},"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",[],[88,89,42,90,91,37,92,93,94,95,29,96,97,98,99,100,101,102,103,104],"user run","user","docker","logs","host","as","triggers","permission","time","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":119,"publishedAt":43},"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",[111,114],{"categoryNo":112,"categoryName":113,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[120,121,122,123,124,125,29,126,127,37,128,129],"requesting code review","code","review","code review","work","requirements","upstream","superpowers","verify","tasks",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":138,"publishedAt":43},"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",[136,137],{"categoryNo":112,"categoryName":113,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},[139,121,122,123,29,126,140,127,37,141,142,143,144],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":43},"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",[],[152,153,154,155,37,156,124,39,157,158,127,27,159,160,29,126,161,140],"branch","development","finishing a development branch","integrate","decide","cleanup","pr","tests","structured","options",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":43},"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",[],[169,170,171,122,172,29,126,140,127,37,99],"plans","executing plans","plan","execute",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":43},"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",[],[180,181,182,37,127,126,183,29,184,129,185],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]