[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XCA56ZTFD3156D0BG39CFE":3,"skill-same:01M6XCA56ZTFD3156D0BG39CFE":70},{"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":23,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6XCA56ZTFD3156D0BG39CFE","engineering-workflow",null,"Overview of the engineering pipeline and how each stage connects. Use when an agent is confused about what stage it's in, what it should do next, or how its output feeds into the next stage. Trigger on: engineering workflow, pipeline, what stage am I in, what comes next, workflow overview, 工程流程, 开发流程, pipeline stage, stage transition.","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\u002Fengineering-workflow\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"engineering","engineering workflow","workflow","pipeline","feeds","how","overview","use","do","next","pipeline stage","stage","trigger","it","output","about","transition","when","2026-11-10 10:12:30",false,"---\nname: engineering-workflow\ndescription: >\n  Overview of the engineering pipeline and how each stage connects.\n  Use when an agent is confused about what stage it's in, what it\n  should do next, or how its output feeds into the next stage.\n  Trigger on: engineering workflow, pipeline, what stage am I in,\n  what comes next, workflow overview, 工程流程, 开发流程,\n  pipeline stage, stage transition.\n---\n\n# Engineering Workflow Overview\n\nThe engineering pipeline runs from requirement to merged code. Each\nstage has a specific agent, clear entry\u002Fexit conditions, and a\nfeedback loop that sends work back upstream when quality gates fail.\n\n## Pipeline\n\n```\n   ┌─────────────┐\n   │ Requirement  │  (human writes issue with goal description)\n   └──────┬───────┘\n          │ label: engineering\n          ▼\n   ┌─────────────┐     reject: spec incomplete\n   │  Specifying  │◄────────────────────────────┐\n   │ (spec-agent) │                             │\n   └──────┬───────┘                             │\n          │ label: status:spec-review           │\n          ▼                                     │\n   ┌─────────────┐                              │\n   │ Spec Review  │─────────────────────────────┘\n   │(spec-review) │\n   └──────┬───────┘\n          │ label: status:developing\n          ▼\n   ┌─────────────────────────────────────┐\n   │          Developing                  │\n   │                                      │\n   │  ┌──────────────┐ ┌──────────────┐  │\n   │  │ test-gen     │ │ dev-agent    │  │  reject: tests fail\n   │  │ (writes      │ │ (implements  │  │  or review rejects\n   │  │  tests from  │ │  code from   │◄─┤\n   │  │  spec)       │ │  spec)       │  │\n   │  └──────────────┘ └──────────────┘  │\n   │       both run in parallel           │\n   └──────┬──────────────────────────────┘\n          │ both complete, label: status:reviewing\n          ▼\n   ┌─────────────┐                       │\n   │  Reviewing   │──────────────────────┘\n   │(review-agent)│     reject: AC fails\n   └──────┬───────┘\n          │ all ACs pass\n          │ label: status:done\n          ▼\n   ┌─────────────┐\n   │    Done      │  (merge to main, close issue)\n   └─────────────┘\n```\n\n## Stage responsibilities\n\n### Specifying (spec-agent)\n\n**Input**: Issue with a goal description (possibly vague).\n**Output**: Structured spec comment with Interface, Acceptance\nCriteria (AC-1..N), and Design Notes.\n**Exit condition**: Spec posted on issue, label → spec-review.\n**Feedback on rejection**: Spec-review tells you which ACs are\nuntestable and which interfaces are underspecified. Fix those\nspecific items.\n\nRead the `spec-writing` skill for detailed guidance on what\nmakes a good spec.\n\n### Spec Review (spec-review-agent)\n\n**Input**: Issue with spec in body or comments.\n**Output**: Per-AC testability verdict table.\n**Exit condition**: All ACs testable → label → developing.\nOr: specific ACs untestable → label → specifying with feedback.\n\nRead the `acceptance-criteria` skill for testability rules.\n\n### Developing (test-gen-agent + dev-agent, parallel)\n\nTwo agents run simultaneously on the same branch:\n\n**test-gen-agent**:\n- Reads the spec's ACs\n- Writes integration tests (one per AC minimum)\n- Verifies tests FAIL without implementation\n- Does NOT write any implementation code\n\n**dev-agent**:\n- Reads the spec's Interface and ACs\n- Implements the code\n- Does NOT write the AC-derived tests (test-gen handles that)\n- May write additional unit tests for internal logic\n\nBoth push to the same branch. When both complete, the state\nadvances.\n\nRead the `test-design` skill for test writing conventions.\n\n**Exit condition**: Both agents complete, label → reviewing.\n\n### Reviewing (review-agent)\n\n**Input**: Branch with implementation + pre-generated tests.\n**Output**: Per-AC verdict (PASS\u002FFAIL\u002FCANNOT JUDGE) + code\nquality findings.\n**Exit condition**: All ACs PASS → label → done.\nOr: any AC FAIL → label → developing with per-AC feedback.\n\nRead the `code-review-standards` skill for review process and\nverdict format.\n\n### Done\n\nMerge the PR, close the issue. This stage is mechanical — no\nagent judgment required.\n\n## Feedback loops\n\nThree feedback loops operate at different timescales:\n\n### 1. Spec loop (specifying ↔ spec-review)\n\n**What it catches**: Untestable ACs, missing interfaces, vague\nrequirements.\n**Cost of a rejection**: One spec-agent session (~minutes).\n**Why it matters**: A bad spec that escapes to developing costs\nN parallel dev sessions + test-gen + review cycles, all producing\nthe wrong thing. This is the highest-leverage gate.\n\n### 2. Dev-review loop (developing ↔ reviewing)\n\n**What it catches**: Code that doesn't satisfy ACs, quality issues.\n**Cost of a rejection**: One dev-agent session (potentially\nexpensive with parallel rollouts).\n**Feedback format**: Per-AC verdict with specific failing tests\nand error messages. The dev agent on the next round sees exactly\nwhich ACs to fix.\n**Cap**: max_review_cycles (default 3). After 3 dev→review\nround-trips, the issue is blocked for human intervention.\n\n### 3. Turn-level loop (inside each agent session)\n\n**What it catches**: Agent stuck (repeating same failed command),\nagent idle (no productive actions for N turns).\n**Mechanism**: Behavioral observation by the agent runtime (AgentM\natoms or session-level control loop).\n**Feedback**: Injected message: \"You've tried the same approach\n3 times without progress. Try a different approach.\"\n\n## Parallel development\n\nWhen the issue specifies `rollouts: N` (via label `rollouts:N`),\nthe developing state dispatches N copies of the dev-agent alongside\none test-gen-agent. All N+1 sessions run in parallel.\n\nAt review time, the reviewer:\n1. Runs the test-gen tests against each dev branch\n2. Eliminates branches where tests fail\n3. Selects the best passing branch based on code quality\n\nThis is multi-sampling: run N implementations, select the best.\nStrictly better than sequential retries when budget allows.\n\n## Labels\n\n| Label | Meaning |\n|---|---|\n| `engineering` | Issue enters the engineering workflow |\n| `status:specifying` | Spec-agent is writing\u002Frevising the spec |\n| `status:spec-review` | Spec-review-agent is validating the spec |\n| `status:developing` | Test-gen + dev agents are working in parallel |\n| `status:reviewing` | Review-agent is running tests and reviewing |\n| `status:done` | All ACs pass, PR merged |\n| `status:blocked` | Waiting for human intervention |\n| `rollouts:N` | Request N parallel dev sessions |\n\n## When to use this workflow vs default\n\n| Use engineering workflow when | Use default workflow when |\n|---|---|\n| The task involves new interfaces or APIs | The task is a simple bug fix with obvious scope |\n| Multiple acceptance criteria need verification | One clear criterion: \"this test should pass\" |\n| You want test-gen before implementation | Tests already exist or aren't needed |\n| Parallel development is worth the cost | A single dev session is sufficient |\n| Spec quality matters (long-lived code) | Quick fix, throwaway, or experiment |\n","# Engineering Workflow Overview\n\nThe engineering pipeline runs from requirement to merged code. Each\nstage has a specific agent, clear entry\u002Fexit conditions, and a\nfeedback loop that sends work back upstream when quality gates fail.\n\n## Pipeline\n\n```\n   ┌─────────────┐\n   │ Requirement  │  (human writes issue with goal description)\n   └──────┬───────┘\n          │ label: engineering\n          ▼\n   ┌─────────────┐     reject: spec incomplete\n   │  Specifying  │◄────────────────────────────┐\n   │ (spec-agent) │                             │\n   └──────┬───────┘                             │\n          │ label: status:spec-review           │\n          ▼                                     │\n   ┌─────────────┐                              │\n   │ Spec Review  │─────────────────────────────┘\n   │(spec-review) │\n   └──────┬───────┘\n          │ label: status:developing\n          ▼\n   ┌─────────────────────────────────────┐\n   │          Developing                  │\n   │                                      │\n   │  ┌──────────────┐ ┌──────────────┐  │\n   │  │ test-gen     │ │ dev-agent    │  │  reject: tests fail\n   │  │ (writes      │ │ (implements  │  │  or review rejects\n   │  │  tests from  │ │  code from   │◄─┤\n   │  │  spec)       │ │  spec)       │  │\n   │  └──────────────┘ └──────────────┘  │\n   │       both run in parallel           │\n   └──────┬──────────────────────────────┘\n          │ both complete, label: status:reviewing\n          ▼\n   ┌─────────────┐                       │\n   │  Reviewing   │──────────────────────┘\n   │(review-agent)│     reject: AC fails\n   └──────┬───────┘\n          │ all ACs pass\n          │ label: status:done\n          ▼\n   ┌─────────────┐\n   │    Done      │  (merge to main, close issue)\n   └─────────────┘\n```\n\n## Stage responsibilities\n\n### Specifying (spec-agent)\n\n**Input**: Issue with a goal description (possibly vague).\n**Output**: Structured spec comment with Interface, Acceptance\nCriteria (AC-1..N), and Design Notes.\n**Exit condition**: Spec posted on issue, label → spec-review.\n**Feedback on rejection**: Spec-review tells you which ACs are\nuntestable and which interfaces are underspecified. Fix those\nspecific items.\n\nRead the `spec-writing` skill for detailed guidance on what\nmakes a good spec.\n\n### Spec Review (spec-review-agent)\n\n**Input**: Issue with spec in body or comments.\n**Output**: Per-AC testability verdict table.\n**Exit condition**: All ACs testable → label → developing.\nOr: specific ACs untestable → label → specifying with feedback.\n\nRead the `acceptance-criteria` skill for testability rules.\n\n### Developing (test-gen-agent + dev-agent, parallel)\n\nTwo agents run simultaneously on the same branch:\n\n**test-gen-agent**:\n- Reads the spec's ACs\n- Writes integration tests (one per AC minimum)\n- Verifies tests FAIL without implementation\n- Does NOT write any implementation code\n\n**dev-agent**:\n- Reads the spec's Interface and ACs\n- Implements the code\n- Does NOT write the AC-derived tests (test-gen handles that)\n- May write additional unit tests for internal logic\n\nBoth push to the same branch. When both complete, the state\nadvances.\n\nRead the `test-design` skill for test writing conventions.\n\n**Exit condition**: Both agents complete, label → reviewing.\n\n### Reviewing (review-agent)\n\n**Input**: Branch with implementation + pre-generated tests.\n**Output**: Per-AC verdict (PASS\u002FFAIL\u002FCANNOT JUDGE) + code\nquality findings.\n**Exit condition**: All ACs PASS → label → done.\nOr: any AC FAIL → label → developing with per-AC feedback.\n\nRead the `code-review-standards` skill for review process and\nverdict format.\n\n### Done\n\nMerge the PR, close the issue. This stage is mechanical — no\nagent judgment required.\n\n## Feedback loops\n\nThree feedback loops operate at different timescales:\n\n### 1. Spec loop (specifying ↔ spec-review)\n\n**What it catches**: Untestable ACs, missing interfaces, vague\nrequirements.\n**Cost of a rejection**: One spec-agent session (~minutes).\n**Why it matters**: A bad spec that escapes to developing costs\nN parallel dev sessions + test-gen + review cycles, all producing\nthe wrong thing. This is the highest-leverage gate.\n\n### 2. Dev-review loop (developing ↔ reviewing)\n\n**What it catches**: Code that doesn't satisfy ACs, quality issues.\n**Cost of a rejection**: One dev-agent session (potentially\nexpensive with parallel rollouts).\n**Feedback format**: Per-AC verdict with specific failing tests\nand error messages. The dev agent on the next round sees exactly\nwhich ACs to fix.\n**Cap**: max_review_cycles (default 3). After 3 dev→review\nround-trips, the issue is blocked for human intervention.\n\n### 3. Turn-level loop (inside each agent session)\n\n**What it catches**: Agent stuck (repeating same failed command),\nagent idle (no productive actions for N turns).\n**Mechanism**: Behavioral observation by the agent runtime (AgentM\natoms or session-level control loop).\n**Feedback**: Injected message: \"You've tried the same approach\n3 times without progress. Try a different approach.\"\n\n## Parallel development\n\nWhen the issue specifies `rollouts: N` (via label `rollouts:N`),\nthe developing state dispatches N copies of the dev-agent alongside\none test-gen-agent. All N+1 sessions run in parallel.\n\nAt review time, the reviewer:\n1. Runs the test-gen tests against each dev branch\n2. Eliminates branches where tests fail\n3. Selects the best passing branch based on code quality\n\nThis is multi-sampling: run N implementations, select the best.\nStrictly better than sequential retries when budget allows.\n\n## Labels\n\n| Label | Meaning |\n|---|---|\n| `engineering` | Issue enters the engineering workflow |\n| `status:specifying` | Spec-agent is writing\u002Frevising the spec |\n| `status:spec-review` | Spec-review-agent is validating the spec |\n| `status:developing` | Test-gen + dev agents are working in parallel |\n| `status:reviewing` | Review-agent is running tests and reviewing |\n| `status:done` | All ACs pass, PR merged |\n| `status:blocked` | Waiting for human intervention |\n| `rollouts:N` | Request N parallel dev sessions |\n\n## When to use this workflow vs default\n\n| Use engineering workflow when | Use default workflow when |\n|---|---|\n| The task involves new interfaces or APIs | The task is a simple bug fix with obvious scope |\n| Multiple acceptance criteria need verification | One clear criterion: \"this test should pass\" |\n| You want test-gen before implementation | Tests already exist or aren't needed |\n| Parallel development is worth the cost | A single dev session is sufficient |\n| Spec quality matters (long-lived code) | Quick fix, throwaway, or experiment |\n",{"name":5,"description":7},"main","b9778c800f442939b879c9a556dfb8d6f4a40971","deploy\u002Fagentm\u002Fskills\u002Fengineering-workflow",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":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add Lincyaw\u002Fworkbuddy --skill engineering-workflow",{"tool":62,"command":63},"bunx","bunx skills add Lincyaw\u002Fworkbuddy --skill engineering-workflow",{"tool":65,"command":66},"pnpm","pnpm dlx skills add Lincyaw\u002Fworkbuddy --skill engineering-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fdeploy\u002Fagentm\u002Fskills\u002Fengineering-workflow\u002FSKILL.md",true,[],[71,98,134,158,176,202],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":42},"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",[],[78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97],"guide","workbuddy guide","debugging","issues","SET","model","pick","up","rollouts","deeper","worker","bind","how to","operating","coordinator","re","operate","which","scheduled","invoke",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":115,"publishedAt":42},"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",[104,107,110],{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":108,"categoryName":109,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[116,117,118,119,120,121,122,123,124,31,125,126,127,128,129,130,131,132,133,41],"web","debug","web debug","frontend","auth","browser","harness","api","check","webui","spa","end","machine","touch","loads","headless","browser-use","using browser",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":141,"publishedAt":42},"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",[140],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[142,143,144,145,146,26,147,148,149,82,150,151,85,152,153,154,155,156,157,41],"setup","setup repo","repo","review","orchestration","config","dev","repository","configure","initialize","issue","new repo","初始化","canonical","for","labels",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":42},"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",[],[165,27,166,167,81,168,124,31,152,169,88,170,171,172,173,92,174,156,175,41],"monitor","pipeline monitor","status","supervisor","missed","watch","progress","detect","unit","agent pipeline","single",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":185,"publishedAt":42},"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",[182],{"categoryNo":183,"categoryName":184,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[186,187,188,189,190,191,81,192,193,194,31,195,196,197,198,47,199,200,201,41],"merge","flow","merge flow","design","validate","report","batch","health","user","integrate","resolve conflicts","conflicts","intent","post","design intent","prs",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":211,"publishedAt":42},"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",[208],{"categoryNo":209,"categoryName":210,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[204,212,213,29,168,214,215,78,31,216,217,88,218,219,220,221,173,92,175,41],"deployment","topology","process","install","Legacy","switch","service","as","bundle","serve"]