[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XCA1CTD2WPW20F1GE99AS6":3,"skill-same:01M6XCA1CTD2WPW20F1GE99AS6":77},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6XCA1CTD2WPW20F1GE99AS6","code-review-standards",null,"How to review code against a spec with structured per-AC verdicts. Use when reviewing a PR, verifying code fulfills acceptance criteria, or selecting between multiple parallel implementations. Trigger on: code review, review standards, PR review, 代码审查, 代码评审, review agent, per-AC verdict, structured review.","Lincyaw\u002Fworkbuddy","Lincyaw","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F53161583?v=4","01M6XC87YTNETZ3AARKMHXJYJR","Aoyang Fang","01M6XC882ZSY5XBX2W6S88AGNH",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fdeploy\u002Fagentm\u002Fskills\u002Fcode-review-standards\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"review","code review","review standards","code","code review standards","standards","when","with","verdict","how to","trigger","acceptance criteria","use","parallel","review code","how","review agent","acceptance","pr","pr review","2026-11-10 10:12:30",false,"---\nname: code-review-standards\ndescription: >\n  How to review code against a spec with structured per-AC verdicts.\n  Use when reviewing a PR, verifying code fulfills acceptance criteria,\n  or selecting between multiple parallel implementations. Trigger on:\n  code review, review standards, PR review, 代码审查, 代码评审,\n  review agent, per-AC verdict, structured review.\n---\n\n# Code Review Standards\n\nReview verifies two things: the code fulfills the spec, and the code\nis maintainable. In that order — correct but messy beats clean but wrong.\n\n## Review process\n\n### Step 1: Run the tests\n\nBefore reading any code, run the test suite (specifically the tests\ngenerated from the spec):\n\n```bash\npytest tests\u002Ftest_\u003Cfeature>.py -v\n```\n\nRecord per-test pass\u002Ffail. This is the ground truth — everything\nelse in the review is judgment layered on top.\n\nIf tests don't exist (test-gen agent didn't run, or spec didn't\nhave ACs), flag this immediately: review cannot verify correctness\nwithout tests. Send back to the developing state.\n\n### Step 2: Per-AC verdict\n\nFor each acceptance criterion, produce a structured verdict:\n\n| AC | Test Result | Code Inspection | Verdict |\n|----|-------------|-----------------|---------|\n| AC-1 | test_ac1 PASS | Implementation matches spec interface | **PASS** |\n| AC-2 | test_ac2 PASS | Edge case handled correctly | **PASS** |\n| AC-3 | test_ac3 FAIL | Time handling uses `time.time()` not injected clock | **FAIL** |\n| AC-4 | test_ac4 PASS | Reset clears counter dict | **PASS** |\n| AC-5 | (no test) | Concurrent access not addressed | **CANNOT JUDGE** |\n\nThree verdicts:\n- **PASS**: test passes AND code inspection confirms the AC is met\n  (not just the test — the test might have gaps)\n- **FAIL**: test fails, OR test passes but code inspection reveals\n  the implementation doesn't actually satisfy the AC (test gap)\n- **CANNOT JUDGE**: no test exists for this AC, or the AC requires\n  manual verification (e.g., UI appearance)\n\n### Step 3: Code quality findings\n\nAfter the per-AC verdict, note code quality issues. Categorize by\nseverity:\n\n**Critical** — must fix before merge:\n- Security vulnerabilities (injection, auth bypass, secret exposure)\n- Data corruption risks (race conditions on shared state, missing\n  transactions)\n- Correctness bugs not caught by existing tests\n\n**Major** — should fix, but doesn't block merge if ACs pass:\n- Missing error handling for documented error cases\n- Performance issues in hot paths (unbounded allocations, O(n²)\n  where O(n) is straightforward)\n- Breaking changes to existing public interfaces without migration\n\n**Minor** — nice to fix, never blocks merge:\n- Naming inconsistencies with project conventions\n- Missing docstrings on public functions\n- Unused imports or variables\n\n### Step 4: Verdict decision\n\n- **All ACs PASS, no critical findings** → approve, transition\n  to done\n- **Any AC FAIL** → reject, transition to developing. The verdict\n  comment must list every failing AC with:\n  - What the AC requires\n  - What the implementation does instead\n  - The specific test failure message (if available)\n  - A suggestion for how to fix (optional but helpful)\n- **CANNOT JUDGE on any AC** → flag but don't block if all\n  testable ACs pass. Note what couldn't be verified and why.\n\n## Selecting between parallel implementations\n\nWhen multiple dev sessions produce implementations that all pass\ntests, rank by:\n\n1. **Correctness** — any AC FAIL disqualifies\n2. **Simplicity** — fewer lines of code, fewer abstractions, fewer\n   dependencies. The implementation that a new contributor would\n   understand fastest.\n3. **Idiomaticity** — follows the project's existing patterns.\n   If the codebase uses dataclasses, don't introduce attrs. If it\n   uses `fmt.Errorf`, don't introduce a custom error package.\n4. **Test coverage beyond spec** — did the dev agent add extra\n   tests for edge cases not in the ACs? Bonus, not required.\n5. **Performance** — only as a tiebreaker, and only if measured.\n   \"Looks faster\" is not a valid criterion.\n\nWhen selecting, name the winner and briefly explain why:\n\n```\nSelected: rollout-2\nReason: All 7 ACs pass. Rollout-2 implements the rate limiter as\na single function with a dict + timestamp, while rollout-1 uses a\nclass hierarchy with 3 abstract base classes. Rollout-2 is 40 lines\nvs 120 lines with identical behavior. Rollout-3 fails AC-3.\n```\n\n## Structured verdict format\n\nThe review comment MUST follow this format so the orchestrator can\nparse it and provide structured feedback to the dev agent:\n\n```markdown\n\u003C!-- workbuddy:review-verdict -->\n## Review Verdict\n\n### Test Results\n- Total: 7 | Pass: 5 | Fail: 2\n- Failing: test_ac3_window_expiry, test_ac6_zero_max_requests\n\n### Per-AC Verdict\n| AC | Verdict | Evidence |\n|----|---------|----------|\n| AC-1 | PASS | test_ac1 passes; implementation uses counter dict |\n| AC-2 | PASS | test_ac2 passes; boundary check correct |\n| AC-3 | FAIL | test_ac3 fails: time.time() not mockable, flaky |\n| AC-4 | PASS | test_ac4 passes; reset clears entry |\n| AC-5 | PASS | test_ac5 passes; separate dict entries per client |\n| AC-6 | FAIL | test_ac6 fails: ValueError not raised for 0 |\n| AC-7 | PASS | test_ac7 passes; ValueError raised for negative |\n\n### Code Quality\n- [critical] AC-6: constructor accepts max_requests=0 without\n  raising ValueError (missing validation)\n- [minor] rate_limiter.py: unused import `collections`\n\n### Decision\nREJECTED — 2 ACs fail. See failing ACs above for required fixes.\n```\n\nThe `\u003C!-- workbuddy:review-verdict -->` marker is required on the\nfirst line. The orchestrator uses it to locate the most recent\nverdict when assembling the next dev cycle's prompt.\n\n## Common review mistakes\n\n**Reviewing style when correctness is unclear.** Don't bikeshed\nvariable names while tests are failing. Fix correctness first.\n\n**Trusting tests blindly.** Tests pass ≠ implementation is correct.\nTests can have gaps. A test that checks `assert result is not None`\npasses even if the result is wrong. Read the code.\n\n**Rejecting for style alone.** If all ACs pass and there are no\ncritical findings, the implementation is acceptable. Style issues\nare minor findings, not rejection reasons.\n\n**Vague rejection.** \"Needs work\" is not actionable. The dev agent\nneeds: which AC fails, what error message, what's wrong with the\nimplementation, what would fix it.\n\n**Reviewing without test results.** If you haven't run the tests,\nyou're guessing at correctness. Run them first. Always.\n","# Code Review Standards\n\nReview verifies two things: the code fulfills the spec, and the code\nis maintainable. In that order — correct but messy beats clean but wrong.\n\n## Review process\n\n### Step 1: Run the tests\n\nBefore reading any code, run the test suite (specifically the tests\ngenerated from the spec):\n\n```bash\npytest tests\u002Ftest_\u003Cfeature>.py -v\n```\n\nRecord per-test pass\u002Ffail. This is the ground truth — everything\nelse in the review is judgment layered on top.\n\nIf tests don't exist (test-gen agent didn't run, or spec didn't\nhave ACs), flag this immediately: review cannot verify correctness\nwithout tests. Send back to the developing state.\n\n### Step 2: Per-AC verdict\n\nFor each acceptance criterion, produce a structured verdict:\n\n| AC | Test Result | Code Inspection | Verdict |\n|----|-------------|-----------------|---------|\n| AC-1 | test_ac1 PASS | Implementation matches spec interface | **PASS** |\n| AC-2 | test_ac2 PASS | Edge case handled correctly | **PASS** |\n| AC-3 | test_ac3 FAIL | Time handling uses `time.time()` not injected clock | **FAIL** |\n| AC-4 | test_ac4 PASS | Reset clears counter dict | **PASS** |\n| AC-5 | (no test) | Concurrent access not addressed | **CANNOT JUDGE** |\n\nThree verdicts:\n- **PASS**: test passes AND code inspection confirms the AC is met\n  (not just the test — the test might have gaps)\n- **FAIL**: test fails, OR test passes but code inspection reveals\n  the implementation doesn't actually satisfy the AC (test gap)\n- **CANNOT JUDGE**: no test exists for this AC, or the AC requires\n  manual verification (e.g., UI appearance)\n\n### Step 3: Code quality findings\n\nAfter the per-AC verdict, note code quality issues. Categorize by\nseverity:\n\n**Critical** — must fix before merge:\n- Security vulnerabilities (injection, auth bypass, secret exposure)\n- Data corruption risks (race conditions on shared state, missing\n  transactions)\n- Correctness bugs not caught by existing tests\n\n**Major** — should fix, but doesn't block merge if ACs pass:\n- Missing error handling for documented error cases\n- Performance issues in hot paths (unbounded allocations, O(n²)\n  where O(n) is straightforward)\n- Breaking changes to existing public interfaces without migration\n\n**Minor** — nice to fix, never blocks merge:\n- Naming inconsistencies with project conventions\n- Missing docstrings on public functions\n- Unused imports or variables\n\n### Step 4: Verdict decision\n\n- **All ACs PASS, no critical findings** → approve, transition\n  to done\n- **Any AC FAIL** → reject, transition to developing. The verdict\n  comment must list every failing AC with:\n  - What the AC requires\n  - What the implementation does instead\n  - The specific test failure message (if available)\n  - A suggestion for how to fix (optional but helpful)\n- **CANNOT JUDGE on any AC** → flag but don't block if all\n  testable ACs pass. Note what couldn't be verified and why.\n\n## Selecting between parallel implementations\n\nWhen multiple dev sessions produce implementations that all pass\ntests, rank by:\n\n1. **Correctness** — any AC FAIL disqualifies\n2. **Simplicity** — fewer lines of code, fewer abstractions, fewer\n   dependencies. The implementation that a new contributor would\n   understand fastest.\n3. **Idiomaticity** — follows the project's existing patterns.\n   If the codebase uses dataclasses, don't introduce attrs. If it\n   uses `fmt.Errorf`, don't introduce a custom error package.\n4. **Test coverage beyond spec** — did the dev agent add extra\n   tests for edge cases not in the ACs? Bonus, not required.\n5. **Performance** — only as a tiebreaker, and only if measured.\n   \"Looks faster\" is not a valid criterion.\n\nWhen selecting, name the winner and briefly explain why:\n\n```\nSelected: rollout-2\nReason: All 7 ACs pass. Rollout-2 implements the rate limiter as\na single function with a dict + timestamp, while rollout-1 uses a\nclass hierarchy with 3 abstract base classes. Rollout-2 is 40 lines\nvs 120 lines with identical behavior. Rollout-3 fails AC-3.\n```\n\n## Structured verdict format\n\nThe review comment MUST follow this format so the orchestrator can\nparse it and provide structured feedback to the dev agent:\n\n```markdown\n\u003C!-- workbuddy:review-verdict -->\n## Review Verdict\n\n### Test Results\n- Total: 7 | Pass: 5 | Fail: 2\n- Failing: test_ac3_window_expiry, test_ac6_zero_max_requests\n\n### Per-AC Verdict\n| AC | Verdict | Evidence |\n|----|---------|----------|\n| AC-1 | PASS | test_ac1 passes; implementation uses counter dict |\n| AC-2 | PASS | test_ac2 passes; boundary check correct |\n| AC-3 | FAIL | test_ac3 fails: time.time() not mockable, flaky |\n| AC-4 | PASS | test_ac4 passes; reset clears entry |\n| AC-5 | PASS | test_ac5 passes; separate dict entries per client |\n| AC-6 | FAIL | test_ac6 fails: ValueError not raised for 0 |\n| AC-7 | PASS | test_ac7 passes; ValueError raised for negative |\n\n### Code Quality\n- [critical] AC-6: constructor accepts max_requests=0 without\n  raising ValueError (missing validation)\n- [minor] rate_limiter.py: unused import `collections`\n\n### Decision\nREJECTED — 2 ACs fail. See failing ACs above for required fixes.\n```\n\nThe `\u003C!-- workbuddy:review-verdict -->` marker is required on the\nfirst line. The orchestrator uses it to locate the most recent\nverdict when assembling the next dev cycle's prompt.\n\n## Common review mistakes\n\n**Reviewing style when correctness is unclear.** Don't bikeshed\nvariable names while tests are failing. Fix correctness first.\n\n**Trusting tests blindly.** Tests pass ≠ implementation is correct.\nTests can have gaps. A test that checks `assert result is not None`\npasses even if the result is wrong. Read the code.\n\n**Rejecting for style alone.** If all ACs pass and there are no\ncritical findings, the implementation is acceptable. Style issues\nare minor findings, not rejection reasons.\n\n**Vague rejection.** \"Needs work\" is not actionable. The dev agent\nneeds: which AC fails, what error message, what's wrong with the\nimplementation, what would fix it.\n\n**Reviewing without test results.** If you haven't run the tests,\nyou're guessing at correctness. Run them first. Always.\n",{"name":5,"description":7},"main","b9778c800f442939b879c9a556dfb8d6f4a40971","deploy\u002Fagentm\u002Fskills\u002Fcode-review-standards",1,"https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy","https:\u002F\u002Fgithub.com\u002FLincyaw","http:\u002F\u002Fprofile.aoyangfang.top\u002F","Student in The Chinese University of Hong Kong, Shenzhen","2026-06-08 13:33:51",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add Lincyaw\u002Fworkbuddy --skill code-review-standards",{"tool":69,"command":70},"bunx","bunx skills add Lincyaw\u002Fworkbuddy --skill code-review-standards",{"tool":72,"command":73},"pnpm","pnpm dlx skills add Lincyaw\u002Fworkbuddy --skill code-review-standards","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fdeploy\u002Fagentm\u002Fskills\u002Fcode-review-standards\u002FSKILL.md",true,[],[78,104,136,162,181,207],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":49},"01M6XCBSW1MMEAWEF38VX9NH3E","workbuddy-guide","Explain and operate workbuddy: what it is, which command to reach for, and where to find deeper references. **Trigger whenever the user mentions 'workbuddy' in any context** — including operational requests (register\u002Fonboard a repo, add\u002Fbind a worker, 注册仓库, 加仓库, 接入新仓库, onboard repo, set up worker), explanatory questions (how to use workbuddy, workbuddy guide, teach me workbuddy, 怎么用workbuddy, 使用指南), deployment\u002Frunning\u002Foperating\u002Fdebugging workbuddy, and questions about how issues\u002Ftasks are scheduled or how dependencies between issues work (depends_on, blocked, dependency gate, 依赖, 调度, 排队, '为什么没派发'), and questions about parallel-development workflows (rollouts:N fan-out, synthesize\u002Fsynthesis reduce step, cherry-pick, '并行开发', '多个方案', 'rollout'). Invoke this skill before running workbuddy CLI commands so the documented onboarding flow (coordinator register + worker repos add) and the dependency\u002Fscheduling model aren't re-derived from scratch.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fworkbuddy-guide\u002FSKILL.md",[],[85,86,87,88,89,90,91,92,93,94,95,96,38,97,98,99,100,101,102,103],"guide","workbuddy guide","debugging","issues","SET","model","pick","up","rollouts","deeper","worker","bind","operating","coordinator","re","operate","which","scheduled","invoke",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":117,"publishedAt":49},"01M6XCBM7B95PB3Q6PHZ3TCM7F","web-debug","Validate the workbuddy webui (SPA + auth + JSON API) end-to-end on the same machine workbuddy runs on, using browser-use's headless harness. Use when the user says 'verify the frontend', 'test the SPA', 'check dashboard loads', '前端验证', '验下 webui', or after merging changes that touch internal\u002Fwebui, web\u002F, or the auth\u002Fcookie path.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fweb-debug\u002FSKILL.md",[110,113,116],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":114,"categoryName":115,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[118,119,120,121,122,123,124,125,126,41,127,128,129,130,131,132,133,134,135,35],"web","debug","web debug","frontend","auth","browser","harness","api","check","webui","spa","end","machine","touch","loads","headless","browser-use","using browser",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":145,"publishedAt":49},"01M6XCBFR925WJSWEYVHGSTT56","setup-repo","Configure a GitHub repository for workbuddy orchestration — creates labels, the two canonical agent configs (dev + review), workflow definitions, issue templates, and config.yaml. Use when the user says 'set up repo', 'configure repo for workbuddy', 'initialize workbuddy', '配置仓库', '初始化workbuddy', or wants to onboard a new repo.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fsetup-repo\u002FSKILL.md",[142],{"categoryNo":143,"categoryName":144,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[146,147,148,29,149,150,151,152,153,89,154,155,92,156,157,158,159,160,161,35],"setup","setup repo","repo","orchestration","workflow","config","dev","repository","configure","initialize","issue","new repo","初始化","canonical","for","labels",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":49},"01M6XCBAEPZQTAS5FZYCPDEGAG","pipeline-monitor","Monitor the workbuddy agent pipeline, detect stuck issues, zombie processes, and missed redispatches. Works for both the 3-unit bundle (supervisor + coordinator + worker) and single-process `serve`. Use when the user says 'monitor the pipeline', 'check workbuddy status', '监工', '看看跑完了没', or asks to watch issue progress.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fpipeline-monitor\u002FSKILL.md",[],[169,170,171,172,88,173,126,41,156,174,95,175,176,177,178,98,179,160,180,35],"monitor","pipeline","pipeline monitor","status","supervisor","missed","watch","progress","detect","unit","agent pipeline","single",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":190,"publishedAt":49},"01M6XCB5RTYNH7QK9RQ5Z4B6NK","merge-flow","Merge a batch of approved workbuddy PRs into main: order them, resolve conflicts against design intent, validate post-merge health, and report. Use when the user asks to 'merge the batch', 'merge approved PRs', 'integrate finished issues', '批量合并', '处理冲突'; or when the merge-agent is invoked.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fmerge-flow\u002FSKILL.md",[187],{"categoryNo":188,"categoryName":189,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[191,192,193,194,195,196,88,197,198,199,41,200,201,202,203,54,204,205,206,35],"merge","flow","merge flow","design","validate","report","batch","health","user","integrate","resolve conflicts","conflicts","intent","post","design intent","prs",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":216,"publishedAt":49},"01M6XCB29F96RJ02Z3BXTAVYSB","deploy","Workbuddy deployment topology guide — explains the 3-unit bundle (supervisor + coordinator + worker), the rolling-restart property, and the cutover from the legacy single-process `serve` install. Use when the user says 'how should I deploy workbuddy', 'install workbuddy as a service', 'switch to bundle', 'rolling restart', '部署 workbuddy', '升级到 bundle'.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fdeploy\u002FSKILL.md",[213],{"categoryNo":214,"categoryName":215,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[209,217,218,44,173,219,220,85,41,221,222,95,223,224,225,226,178,98,180,35],"deployment","topology","process","install","Legacy","switch","service","as","bundle","serve"]