[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XCBFR925WJSWEYVHGSTT56":3,"skill-same:01M6XCBFR925WJSWEYVHGSTT56":78},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6XCBFR925WJSWEYVHGSTT56","setup-repo",null,"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.","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\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fsetup-repo\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,42,43],"setup","setup repo","repo","when","review","labels","for","canonical","初始化","new repo","issue","up","initialize","configure","SET","repository","dev","config","workflow","orchestration","2026-11-10 10:12:30",false,"---\nname: setup-repo\ndescription: \"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.\"\n---\n\n# Setup Repo\n\nInteractive skill that configures a GitHub repository for workbuddy agent orchestration.\nCreates all required labels, the two canonical agent definitions (dev + review), the\nstate-machine workflows, issue templates with a mandatory Acceptance Criteria section,\nand the `.github\u002Fworkbuddy\u002Fconfig.yaml`.\n\n## The 2-agent model (read this first)\n\nWorkbuddy's catalog is deliberately minimal: only `dev-agent` and `review-agent`.\nEverything the previous 9-agent catalog did — triage, docs-only work, dependency\nbumps, release prep, security audits, alternate runtime variants — collapses into\nthis contract:\n\n- **Humans write issues** with a mandatory `## Acceptance Criteria` section listing\n  verifiable criteria. This replaces the old `triage-agent` — a good issue template\n  is more reliable than an LLM reverse-engineering intent.\n- **`dev-agent`** (triggers on `status:developing`): reads the issue; if the\n  Acceptance Criteria section is missing it sets `status:blocked` and comments;\n  otherwise it produces whatever artifact the criteria demand — code, docs,\n  a dependency bump, a report, release notes — then flips to `status:reviewing`.\n- **`review-agent`** (triggers on `status:reviewing`): evaluates each criterion\n  against the artifact. All pass → `status:done`. Any fail → `status:developing`\n  with criterion-by-criterion feedback.\n- **Runtime (`claude-code` | `codex`)** is a field on the agent config, not a\n  separate agent. Switch runtimes via repo-level override, not by duplicating agents.\n- **Operational detail** (gh CLI recipes, PR reconciliation, dev-loop commands,\n  branch conventions) lives in the TARGET repo's own `CLAUDE.md` and optional\n  `.claude\u002Fskills\u002F`. Workbuddy's agent prompts are short contracts, not manuals.\n  See \"Step 6\" below.\n\nSee `docs\u002Fdecisions\u002F2026-04-15-agent-role-consolidation.md` in the workbuddy repo\nfor the first-principles rationale.\n\n## When to use\n\n- When onboarding a new repository for workbuddy\n- When the user wants to add workbuddy support to an existing project\n- When recreating or resetting workbuddy configuration\n\n## Arguments\n\nThe skill accepts one optional argument: the GitHub repository identifier (e.g., `owner\u002Frepo`).\nIf not provided, prompt the user or detect from the current git remote.\n\n## What to do\n\n### Step 1: Gather information\n\nDetermine:\n1. **Target repo** — from the argument, or detect via `gh repo view --json nameWithOwner -q .nameWithOwner`\n2. **Project language\u002Fstack** — scan the repo for `go.mod`, `package.json`, `pyproject.toml`, `Cargo.toml`, etc.\n3. **Existing labels** — run `gh label list --repo \u003Crepo> --json name -q '.[].name'`\n4. **Existing workbuddy config** — check if `.github\u002Fworkbuddy\u002F` already exists\n5. **Existing issue templates** — check if `.github\u002FISSUE_TEMPLATE\u002F` already has entries\n6. **Git remote protocol** — run `git remote -v`. If remote uses SSH (`git@github.com:...`)\n   but `gh auth status` shows HTTPS protocol, switch remote to HTTPS:\n   ```bash\n   git remote set-url origin https:\u002F\u002Fgithub.com\u002FOWNER\u002FREPO.git\n   ```\n   This prevents push failures when agents try to push branches.\n7. **Commit hooks** — check for lefthook\u002Fhusky\u002Fcommitlint. If the repo enforces\n   conventional commits, note this — agents need to use the right prefix format.\n\n### Step 2: Create labels\n\nWorkbuddy uses label-driven state machines. Create the required labels if they don't exist:\n\n```\nworkbuddy         — #5319E7 — Opt-in: this issue flows through the workbuddy state machine\ntype:feature      — #0E8A16 — Feature request (optional classification)\ntype:bug          — #D73A4A — Bug report (optional classification)\nstatus:developing — #1D76DB — Dev-agent is producing an artifact\nstatus:reviewing  — #D93F0B — Review-agent is verifying acceptance criteria\nstatus:blocked    — #E99695 — Needs human action (typically: missing Acceptance Criteria)\nstatus:done       — #0E8A16 — All acceptance criteria verified green\n```\n\nThe `workbuddy` label is the workflow trigger. Only issues carrying it\nenter the state machine; plain GitHub issues without it are ignored. This\nlets a team opt-in issue-by-issue rather than gating every new issue.\n\nNotes on what was dropped from prior versions and why:\n- `status:triage` — removed. Humans classify via issue template + type labels at\n  creation time. A triage state machine node added latency without adding signal.\n- `status:failed` + `needs-human` — merged into `status:blocked`. A single\n  \"waiting for human\" state is simpler and covers retry-exhaustion,\n  missing criteria, and dev-agent self-blocks uniformly.\n- `type:task` — removed. Every issue is either a `type:feature` or `type:bug`\n  (or the target repo can add its own custom type labels via Step 9 \"Customization\").\n\nUse `gh label create` for each label. Skip labels that already exist (check first).\n\n### Step 3: Create issue templates with Acceptance Criteria\n\nCreate `.github\u002FISSUE_TEMPLATE\u002Ffeature.md` and `.github\u002FISSUE_TEMPLATE\u002Fbug.md`.\nBoth MUST include a `## Acceptance Criteria` section — this is the contract\n`dev-agent` reads and `review-agent` verifies against.\n\n#### feature.md\n```markdown\n---\nname: Feature\nabout: Propose a new feature or enhancement\nlabels: [\"workbuddy\", \"type:feature\", \"status:developing\"]\n---\n\n## Context\n\u003C!-- What motivates this feature? What problem does it solve? -->\n\n## Proposed Change\n\u003C!-- Describe what should be built. -->\n\n## Acceptance Criteria\n\u003C!--\nEach criterion must be individually verifiable. dev-agent produces an artifact\nthat satisfies every one; review-agent evaluates each as pass \u002F fail \u002F cannot-judge.\nIf this section is empty or missing, dev-agent will set status:blocked.\n-->\n- [ ]\n- [ ]\n- [ ]\n\n## Additional Notes\n\u003C!-- Links, references, related issues. -->\n```\n\n#### bug.md\n```markdown\n---\nname: Bug Report\nabout: Report a defect\nlabels: [\"type:bug\", \"status:developing\"]\n---\n\n## Observed Behavior\n\u003C!-- What actually happens? Include reproduction steps. -->\n\n## Expected Behavior\n\u003C!-- What should happen instead? -->\n\n## Acceptance Criteria\n\u003C!--\nTypically: \"the reproduction steps above no longer produce the observed behavior\"\nplus any regression-test criterion. Each item must be individually verifiable.\n-->\n- [ ] Reproduction steps no longer reproduce the bug on \u003Cplatform\u002Fversion>\n- [ ] Regression test added at \u003Clocation>\n- [ ]\n\n## Environment\n\u003C!-- OS, versions, config. -->\n```\n\n### Step 4: Create agent definitions\n\nCreate `.github\u002Fworkbuddy\u002Fagents\u002F` and write these two files — and only these two.\nDo not create `triage-agent`, `docs-agent`, `dependency-bump-agent`, `release-agent`,\n`security-audit-agent`, or `codex-*` duplicates. Do not create a `schemas\u002F` directory —\nthe 2-agent catalog does not use `output_contract`.\n\n#### dev-agent.md\n```markdown\n---\nname: dev-agent\ndescription: Development agent — produces an artifact satisfying the issue's Acceptance Criteria\ntriggers:\n  - label: \"status:developing\"\n    event: labeled\nrole: dev\nruntime: claude-code\npolicy:\n  sandbox: danger-full-access\n  approval: never\n  timeout: 30m\nprompt: |\n  You are the dev agent for repo {{.Repo}}, working on issue #{{.Issue.Number}}.\n\n  Read the issue body and look for a `## Acceptance Criteria` section.\n\n  - If the section is missing or empty: remove label `status:developing`,\n    add label `status:blocked`, and post a comment explaining that the issue\n    needs verifiable acceptance criteria before dev work can start. Stop.\n  - Otherwise: produce the artifact that satisfies every criterion. The\n    artifact form depends on the criteria themselves — it may be code, docs,\n    a dependency bump, a report, release notes, or any combination. Include\n    tests or automated checks for every verifiable criterion.\n\n  When the artifact is linked to this issue, remove label `status:developing`\n  and add label `status:reviewing`.\n\n  Use this repo's own CLAUDE.md \u002F .claude\u002Fskills\u002F for project-specific\n  dev-loop commands, PR conventions, and tooling. Report the artifact link\n  when finished.\n\n  ## Issue\n  Title: {{.Issue.Title}}\n  Number: #{{.Issue.Number}}\n  Body:\n  {{.Issue.Body}}\ntimeout: 30m\n---\n\n## Dev Agent\n\nConsumes the issue's `## Acceptance Criteria` and produces an artifact that\nsatisfies every criterion. Transitions to `status:blocked` if criteria are\nmissing; otherwise transitions to `status:reviewing` when done.\n```\n\n#### review-agent.md\n```markdown\n---\nname: review-agent\ndescription: Review agent — verifies the artifact against the issue's Acceptance Criteria\ntriggers:\n  - label: \"status:reviewing\"\n    event: labeled\nrole: review\nruntime: claude-code\npolicy:\n  sandbox: danger-full-access\n  approval: never\n  timeout: 15m\nprompt: |\n  You are the review agent for repo {{.Repo}}, verifying the artifact\n  produced for issue #{{.Issue.Number}}.\n\n  Read the issue's `## Acceptance Criteria` section and the artifact\n  (PR, comment, or file) linked to this issue. For each criterion, evaluate\n  it as pass \u002F fail \u002F cannot-judge, citing concrete evidence — file:line,\n  test name, or a quoted excerpt.\n\n  - If every criterion passes: remove label `status:reviewing`, add label\n    `status:done`, and post a comment with the criterion-by-criterion verdict.\n  - If any criterion fails: remove label `status:reviewing`, add label\n    `status:developing`, and post a comment listing the failing criteria\n    plus what dev needs to address.\n\n  Use this repo's own CLAUDE.md \u002F .claude\u002Fskills\u002F for project-specific\n  review conventions.\n\n  ## Issue\n  Title: {{.Issue.Title}}\n  Number: #{{.Issue.Number}}\n  Body:\n  {{.Issue.Body}}\ntimeout: 15m\n---\n\n## Review Agent\n\nEvaluates each acceptance criterion against the produced artifact. All pass →\n`status:done`. Any fail → `status:developing` with feedback.\n```\n\n### Step 5: Create the workflow definition\n\nCreate `.github\u002Fworkbuddy\u002Fworkflows\u002Fdefault.md`. Exactly one workflow per\nrepo — bug vs feature use the same state machine, so they share this file.\nThe classification (`type:feature` \u002F `type:bug`) is a labeling convention\nfor humans browsing issues; it does not alter the execution path.\n\n````markdown\n---\nname: default\ndescription: Default 2-agent lifecycle for any workbuddy-tracked issue\ntrigger:\n  issue_label: \"workbuddy\"\nmax_retries: 3\n---\n\n## Default Workflow\n\nEvery issue labeled `workbuddy` flows through this state machine.\n\n```yaml\nstates:\n  developing:\n    enter_label: \"status:developing\"\n    agent: dev-agent\n    transitions:\n      - to: reviewing\n        when: labeled \"status:reviewing\"\n      - to: blocked\n        when: labeled \"status:blocked\"\n\n  reviewing:\n    enter_label: \"status:reviewing\"\n    agent: review-agent\n    transitions:\n      - to: done\n        when: labeled \"status:done\"\n      - to: developing\n        when: labeled \"status:developing\"\n\n  blocked:\n    enter_label: \"status:blocked\"\n    transitions:\n      - to: developing\n        when: labeled \"status:developing\"\n\n  done:\n    enter_label: \"status:done\"\n    action: close_issue\n```\n\n### State graph\n\n```\ndeveloping ⇄ reviewing → done\n   ↑             ↓\n   └─── blocked ─┘  (human edits issue, flips back to developing)\n\nAny revisit of a state — including developing↔blocked — counts toward\nmax_retries; exceeding the limit records retry\u002Ffailure intent. Label\nwriteback remains an agent\u002Fhuman action.\n```\n````\n\n### Step 6: Operational detail lives in the target repo\n\nWorkbuddy's agent prompts are intentionally minimal contracts. They do NOT\nencode gh CLI recipes, branch-switching commands, PR reconciliation rules,\nor dev-loop commands — because those differ per repo and are better maintained\nwhere they are used.\n\nRecommend to the user: the target repo should maintain its own `CLAUDE.md`\ndescribing:\n- Dev-loop commands (build, test, vet, lint) for the repo's stack\n- PR conventions (branch naming, draft vs ready, review gating, merge strategy)\n- Test strategy (mock\u002Freal boundary, fixtures, coverage targets)\n- Project-specific gh CLI patterns\n\nIf the target repo has no `CLAUDE.md`, offer to scaffold one — but only\nafter confirming with the user, since that's beyond \"workbuddy setup\".\n\n### Step 6b: Initialize agent runtime skills in the target repo\n\nAgent runtimes discover project-level skills from conventional directories\ninside the working directory. **This step is critical** — without it, agents\nonly have generic global skills and miss repo-specific development patterns.\n\nThe skill directories depend on the runtime configured in the agent definitions:\n\n| Runtime | Skill directory | Discovery |\n|---------|----------------|-----------|\n| `claude-code` | `.claude\u002Fskills\u002F\u003Cname>\u002FSKILL.md` | Auto-loaded when skill description matches context |\n| `codex` | `.codex\u002Fskills\u002F\u003Cname>\u002FSKILL.md` | Same — auto-loaded by description match |\n\n**Create skills for the runtime(s) used by this repo's agents.** If\n`runtime: codex` is set in the agent configs, create `.codex\u002Fskills\u002F`. If\n`runtime: claude-code`, create `.claude\u002Fskills\u002F`. If both runtimes are used\n(e.g., different agents use different runtimes), create both directories.\n\n#### Standard skills to initialize\n\nCreate these three skills — they are runtime-agnostic in content and give\nagents a solid operational foundation:\n\n**1. `dev-loop\u002FSKILL.md`** — Development cycle: implement → test → verify\n\n```yaml\n---\nname: dev-loop\ndescription: \"Run a complete development loop: implement, test, vibe-check,\n  review, and measure before keeping or discarding. Use when implementing\n  features, fixing bugs, writing code, or refactoring.\"\n---\n```\n\nBody should describe the repo's specific build\u002Ftest\u002Flint commands, the\nkeep\u002Fdiscard decision framework, and how to log progress. Detect the\nrepo's language\u002Fstack (from Step 1) and tailor the commands accordingly.\nFor example, a Go repo should mention `go build`, `go test`, `go vet`;\na Node repo should mention `npm test`, `npm run lint`, etc.\n\n**2. `long-horizon\u002FSKILL.md`** — Autonomous decision-making\n\n```yaml\n---\nname: long-horizon\ndescription: \"Framework for autonomous decision-making during extended tasks.\n  Use when working on complex multi-step tasks that require judgment calls\n  without human intervention.\"\n---\n```\n\nBody should describe the escalation ladder (convention check → codebase\nresearch → external research → north-star reasoning → ask human) and\ndecision logging conventions. This helps agents make good autonomous\ndecisions during dev and review cycles instead of getting stuck.\n\n**3. `index\u002FSKILL.md`** (optional, for repos with documentation) — Doc-code consistency\n\nOnly create this if the repo has existing documentation (`docs\u002F`, `README.md`,\ndesign docs, etc.). It helps agents keep documentation aligned with code changes.\n\n#### Codex-specific: agent metadata files\n\nFor codex skills, also create an `agents\u002Fopenai.yaml` alongside each\n`SKILL.md` with display metadata:\n\n```yaml\n# .codex\u002Fskills\u002Fdev-loop\u002Fagents\u002Fopenai.yaml\ninterface:\n  display_name: \"Dev Loop\"\n  short_description: \"Run a full implement-test-measure loop\"\n  default_prompt: \"Use $dev-loop to drive this task through implementation,\n    testing, and verification.\"\n```\n\n#### What to put in the skill body\n\nKeep skills **lean and repo-specific**:\n- Reference the repo's actual build\u002Ftest commands (detected in Step 1)\n- Reference the repo's CLAUDE.md for conventions\n- Do NOT duplicate generic methodology — link to it or summarize briefly\n- The goal is that when an agent reads the skill, it knows exactly how\n  to operate in THIS repo, not just in theory\n\n#### Commit the skills\n\nAdd the skills directory to the same commit as the workbuddy config:\n\n```bash\ngit add .codex\u002Fskills\u002F   # or .claude\u002Fskills\u002F depending on runtime\n```\n\nThe skills are version-controlled alongside the repo's code, so they\nevolve with the project.\n\n### Step 7: Create config.yaml\n\nCreate `.github\u002Fworkbuddy\u002Fconfig.yaml`:\n\n```yaml\n# Workbuddy configuration for \u003Crepo>\nenvironment: dev\nrepo: \u003Cowner\u002Frepo>\npoll_interval: 30s\nport: 8080\n```\n\n### Step 8: Create .workbuddy\u002F gitignore entry\n\nAdd `.workbuddy\u002F` to the repo's `.gitignore` if not already present.\nThis directory holds local runtime state (SQLite DB, session logs).\n\n### Step 9: Verify and report\n\nAfter creating all files:\n\n1. List what was created:\n   - Labels created (count)\n   - Agent configs created: dev-agent, review-agent (exactly 2)\n   - Issue templates created: feature.md, bug.md\n   - Workflow created: default (single state machine for all workbuddy issues)\n   - config.yaml location\n\n2. Show the state machine diagram:\n   ```\n   developing ⇄ reviewing → done\n      ↑             ↓\n      └─── blocked ─┘  (human edits issue, flips back to developing)\n\n   Reviewer evaluates each Acceptance Criterion from the issue body.\n   All pass → done. Any fail → back to developing. Max 3 retries.\n   ```\n\n3. Explain how to use:\n   - Start workbuddy: `workbuddy serve`\n   - Open an issue via the feature or bug template; fill the Acceptance Criteria\n   - The `workbuddy` label opts the issue into the state machine; the\n     `status:developing` label on creation triggers dev-agent automatically\n   - Labels flow: developing → reviewing → done (or blocked when criteria missing)\n   - Monitor progress on the GitHub issue\n\n### Step 10: Register with coordinator (distributed mode)\n\nIf the user is running workbuddy in distributed mode, register the repo\nafter committing and pushing the config:\n\n```bash\nexport WORKBUDDY_AUTH_TOKEN=\"\u003Ctoken>\"\nworkbuddy repo register \\\n  --coordinator http:\u002F\u002Fcoordinator-host:8081 \\\n  --token \"$WORKBUDDY_AUTH_TOKEN\"\n```\n\nThis must be run from the target repo's root directory. It serializes\nthe local `.github\u002Fworkbuddy\u002F` config and POSTs it to the coordinator.\n\nThen start a worker for the repo:\n\n```bash\nworkbuddy worker \\\n  --coordinator http:\u002F\u002Fcoordinator-host:8081 \\\n  --token \"$WORKBUDDY_AUTH_TOKEN\" \\\n  --runtime codex \\\n  --repo Owner\u002FRepo\n```\n\nThe worker must also be started from the repo root — it loads agent\nprompt templates from `.github\u002Fworkbuddy\u002Fagents\u002F` locally.\n\n## What NOT to do\n\n- Don't create agents beyond `dev-agent` and `review-agent`. If a user insists,\n  point them at the 2-agent decision record and suggest encoding the need as\n  an issue template + acceptance criteria instead.\n- Don't create `.github\u002Fworkbuddy\u002Fagents\u002Fschemas\u002F` — the 2-agent catalog has\n  no `output_contract`.\n- Don't re-introduce `status:triage`, `status:failed`, or `needs-human` labels —\n  use `status:blocked` for all human-handoff cases.\n- Don't overwrite existing agent\u002Fworkflow configs without asking.\n- Don't delete existing labels.\n- Don't modify code in the target repo.\n- Don't start workbuddy — just configure it.\n- Don't assume the repo uses a specific language — detect it.\n\n## Customization\n\nIf the user specifies custom requirements:\n- **Custom runtime** (`codex` instead of `claude-code`) — set `runtime: codex`\n  on the agent config. Runtime is a field, not a separate agent.\n- **Custom type labels** beyond feature\u002Fbug — add the label and a matching\n  issue template with the same `## Acceptance Criteria` contract. The\n  workflow still matches on `workbuddy`, so the type label is classification\n  only. If you genuinely need a different state machine for a particular\n  class of work, add a new workflow file with a distinct trigger label and\n  have the team apply that label explicitly.\n- **Custom acceptance criteria conventions** — the only hard contract is that\n  dev-agent reads a section literally titled `## Acceptance Criteria`. How the\n  team structures criteria within that section is up to the repo.\n- **Custom policy per label** (e.g. read-only sandbox for high-risk changes) —\n  this is planned as Coordinator-side dynamic dispatch keyed on issue labels.\n  Not yet implemented; for now every issue runs under the agent's default policy.\n","# Setup Repo\n\nInteractive skill that configures a GitHub repository for workbuddy agent orchestration.\nCreates all required labels, the two canonical agent definitions (dev + review), the\nstate-machine workflows, issue templates with a mandatory Acceptance Criteria section,\nand the `.github\u002Fworkbuddy\u002Fconfig.yaml`.\n\n## The 2-agent model (read this first)\n\nWorkbuddy's catalog is deliberately minimal: only `dev-agent` and `review-agent`.\nEverything the previous 9-agent catalog did — triage, docs-only work, dependency\nbumps, release prep, security audits, alternate runtime variants — collapses into\nthis contract:\n\n- **Humans write issues** with a mandatory `## Acceptance Criteria` section listing\n  verifiable criteria. This replaces the old `triage-agent` — a good issue template\n  is more reliable than an LLM reverse-engineering intent.\n- **`dev-agent`** (triggers on `status:developing`): reads the issue; if the\n  Acceptance Criteria section is missing it sets `status:blocked` and comments;\n  otherwise it produces whatever artifact the criteria demand — code, docs,\n  a dependency bump, a report, release notes — then flips to `status:reviewing`.\n- **`review-agent`** (triggers on `status:reviewing`): evaluates each criterion\n  against the artifact. All pass → `status:done`. Any fail → `status:developing`\n  with criterion-by-criterion feedback.\n- **Runtime (`claude-code` | `codex`)** is a field on the agent config, not a\n  separate agent. Switch runtimes via repo-level override, not by duplicating agents.\n- **Operational detail** (gh CLI recipes, PR reconciliation, dev-loop commands,\n  branch conventions) lives in the TARGET repo's own `CLAUDE.md` and optional\n  `.claude\u002Fskills\u002F`. Workbuddy's agent prompts are short contracts, not manuals.\n  See \"Step 6\" below.\n\nSee `docs\u002Fdecisions\u002F2026-04-15-agent-role-consolidation.md` in the workbuddy repo\nfor the first-principles rationale.\n\n## When to use\n\n- When onboarding a new repository for workbuddy\n- When the user wants to add workbuddy support to an existing project\n- When recreating or resetting workbuddy configuration\n\n## Arguments\n\nThe skill accepts one optional argument: the GitHub repository identifier (e.g., `owner\u002Frepo`).\nIf not provided, prompt the user or detect from the current git remote.\n\n## What to do\n\n### Step 1: Gather information\n\nDetermine:\n1. **Target repo** — from the argument, or detect via `gh repo view --json nameWithOwner -q .nameWithOwner`\n2. **Project language\u002Fstack** — scan the repo for `go.mod`, `package.json`, `pyproject.toml`, `Cargo.toml`, etc.\n3. **Existing labels** — run `gh label list --repo \u003Crepo> --json name -q '.[].name'`\n4. **Existing workbuddy config** — check if `.github\u002Fworkbuddy\u002F` already exists\n5. **Existing issue templates** — check if `.github\u002FISSUE_TEMPLATE\u002F` already has entries\n6. **Git remote protocol** — run `git remote -v`. If remote uses SSH (`git@github.com:...`)\n   but `gh auth status` shows HTTPS protocol, switch remote to HTTPS:\n   ```bash\n   git remote set-url origin https:\u002F\u002Fgithub.com\u002FOWNER\u002FREPO.git\n   ```\n   This prevents push failures when agents try to push branches.\n7. **Commit hooks** — check for lefthook\u002Fhusky\u002Fcommitlint. If the repo enforces\n   conventional commits, note this — agents need to use the right prefix format.\n\n### Step 2: Create labels\n\nWorkbuddy uses label-driven state machines. Create the required labels if they don't exist:\n\n```\nworkbuddy         — #5319E7 — Opt-in: this issue flows through the workbuddy state machine\ntype:feature      — #0E8A16 — Feature request (optional classification)\ntype:bug          — #D73A4A — Bug report (optional classification)\nstatus:developing — #1D76DB — Dev-agent is producing an artifact\nstatus:reviewing  — #D93F0B — Review-agent is verifying acceptance criteria\nstatus:blocked    — #E99695 — Needs human action (typically: missing Acceptance Criteria)\nstatus:done       — #0E8A16 — All acceptance criteria verified green\n```\n\nThe `workbuddy` label is the workflow trigger. Only issues carrying it\nenter the state machine; plain GitHub issues without it are ignored. This\nlets a team opt-in issue-by-issue rather than gating every new issue.\n\nNotes on what was dropped from prior versions and why:\n- `status:triage` — removed. Humans classify via issue template + type labels at\n  creation time. A triage state machine node added latency without adding signal.\n- `status:failed` + `needs-human` — merged into `status:blocked`. A single\n  \"waiting for human\" state is simpler and covers retry-exhaustion,\n  missing criteria, and dev-agent self-blocks uniformly.\n- `type:task` — removed. Every issue is either a `type:feature` or `type:bug`\n  (or the target repo can add its own custom type labels via Step 9 \"Customization\").\n\nUse `gh label create` for each label. Skip labels that already exist (check first).\n\n### Step 3: Create issue templates with Acceptance Criteria\n\nCreate `.github\u002FISSUE_TEMPLATE\u002Ffeature.md` and `.github\u002FISSUE_TEMPLATE\u002Fbug.md`.\nBoth MUST include a `## Acceptance Criteria` section — this is the contract\n`dev-agent` reads and `review-agent` verifies against.\n\n#### feature.md\n```markdown\n---\nname: Feature\nabout: Propose a new feature or enhancement\nlabels: [\"workbuddy\", \"type:feature\", \"status:developing\"]\n---\n\n## Context\n\u003C!-- What motivates this feature? What problem does it solve? -->\n\n## Proposed Change\n\u003C!-- Describe what should be built. -->\n\n## Acceptance Criteria\n\u003C!--\nEach criterion must be individually verifiable. dev-agent produces an artifact\nthat satisfies every one; review-agent evaluates each as pass \u002F fail \u002F cannot-judge.\nIf this section is empty or missing, dev-agent will set status:blocked.\n-->\n- [ ]\n- [ ]\n- [ ]\n\n## Additional Notes\n\u003C!-- Links, references, related issues. -->\n```\n\n#### bug.md\n```markdown\n---\nname: Bug Report\nabout: Report a defect\nlabels: [\"type:bug\", \"status:developing\"]\n---\n\n## Observed Behavior\n\u003C!-- What actually happens? Include reproduction steps. -->\n\n## Expected Behavior\n\u003C!-- What should happen instead? -->\n\n## Acceptance Criteria\n\u003C!--\nTypically: \"the reproduction steps above no longer produce the observed behavior\"\nplus any regression-test criterion. Each item must be individually verifiable.\n-->\n- [ ] Reproduction steps no longer reproduce the bug on \u003Cplatform\u002Fversion>\n- [ ] Regression test added at \u003Clocation>\n- [ ]\n\n## Environment\n\u003C!-- OS, versions, config. -->\n```\n\n### Step 4: Create agent definitions\n\nCreate `.github\u002Fworkbuddy\u002Fagents\u002F` and write these two files — and only these two.\nDo not create `triage-agent`, `docs-agent`, `dependency-bump-agent`, `release-agent`,\n`security-audit-agent`, or `codex-*` duplicates. Do not create a `schemas\u002F` directory —\nthe 2-agent catalog does not use `output_contract`.\n\n#### dev-agent.md\n```markdown\n---\nname: dev-agent\ndescription: Development agent — produces an artifact satisfying the issue's Acceptance Criteria\ntriggers:\n  - label: \"status:developing\"\n    event: labeled\nrole: dev\nruntime: claude-code\npolicy:\n  sandbox: danger-full-access\n  approval: never\n  timeout: 30m\nprompt: |\n  You are the dev agent for repo {{.Repo}}, working on issue #{{.Issue.Number}}.\n\n  Read the issue body and look for a `## Acceptance Criteria` section.\n\n  - If the section is missing or empty: remove label `status:developing`,\n    add label `status:blocked`, and post a comment explaining that the issue\n    needs verifiable acceptance criteria before dev work can start. Stop.\n  - Otherwise: produce the artifact that satisfies every criterion. The\n    artifact form depends on the criteria themselves — it may be code, docs,\n    a dependency bump, a report, release notes, or any combination. Include\n    tests or automated checks for every verifiable criterion.\n\n  When the artifact is linked to this issue, remove label `status:developing`\n  and add label `status:reviewing`.\n\n  Use this repo's own CLAUDE.md \u002F .claude\u002Fskills\u002F for project-specific\n  dev-loop commands, PR conventions, and tooling. Report the artifact link\n  when finished.\n\n  ## Issue\n  Title: {{.Issue.Title}}\n  Number: #{{.Issue.Number}}\n  Body:\n  {{.Issue.Body}}\ntimeout: 30m\n---\n\n## Dev Agent\n\nConsumes the issue's `## Acceptance Criteria` and produces an artifact that\nsatisfies every criterion. Transitions to `status:blocked` if criteria are\nmissing; otherwise transitions to `status:reviewing` when done.\n```\n\n#### review-agent.md\n```markdown\n---\nname: review-agent\ndescription: Review agent — verifies the artifact against the issue's Acceptance Criteria\ntriggers:\n  - label: \"status:reviewing\"\n    event: labeled\nrole: review\nruntime: claude-code\npolicy:\n  sandbox: danger-full-access\n  approval: never\n  timeout: 15m\nprompt: |\n  You are the review agent for repo {{.Repo}}, verifying the artifact\n  produced for issue #{{.Issue.Number}}.\n\n  Read the issue's `## Acceptance Criteria` section and the artifact\n  (PR, comment, or file) linked to this issue. For each criterion, evaluate\n  it as pass \u002F fail \u002F cannot-judge, citing concrete evidence — file:line,\n  test name, or a quoted excerpt.\n\n  - If every criterion passes: remove label `status:reviewing`, add label\n    `status:done`, and post a comment with the criterion-by-criterion verdict.\n  - If any criterion fails: remove label `status:reviewing`, add label\n    `status:developing`, and post a comment listing the failing criteria\n    plus what dev needs to address.\n\n  Use this repo's own CLAUDE.md \u002F .claude\u002Fskills\u002F for project-specific\n  review conventions.\n\n  ## Issue\n  Title: {{.Issue.Title}}\n  Number: #{{.Issue.Number}}\n  Body:\n  {{.Issue.Body}}\ntimeout: 15m\n---\n\n## Review Agent\n\nEvaluates each acceptance criterion against the produced artifact. All pass →\n`status:done`. Any fail → `status:developing` with feedback.\n```\n\n### Step 5: Create the workflow definition\n\nCreate `.github\u002Fworkbuddy\u002Fworkflows\u002Fdefault.md`. Exactly one workflow per\nrepo — bug vs feature use the same state machine, so they share this file.\nThe classification (`type:feature` \u002F `type:bug`) is a labeling convention\nfor humans browsing issues; it does not alter the execution path.\n\n````markdown\n---\nname: default\ndescription: Default 2-agent lifecycle for any workbuddy-tracked issue\ntrigger:\n  issue_label: \"workbuddy\"\nmax_retries: 3\n---\n\n## Default Workflow\n\nEvery issue labeled `workbuddy` flows through this state machine.\n\n```yaml\nstates:\n  developing:\n    enter_label: \"status:developing\"\n    agent: dev-agent\n    transitions:\n      - to: reviewing\n        when: labeled \"status:reviewing\"\n      - to: blocked\n        when: labeled \"status:blocked\"\n\n  reviewing:\n    enter_label: \"status:reviewing\"\n    agent: review-agent\n    transitions:\n      - to: done\n        when: labeled \"status:done\"\n      - to: developing\n        when: labeled \"status:developing\"\n\n  blocked:\n    enter_label: \"status:blocked\"\n    transitions:\n      - to: developing\n        when: labeled \"status:developing\"\n\n  done:\n    enter_label: \"status:done\"\n    action: close_issue\n```\n\n### State graph\n\n```\ndeveloping ⇄ reviewing → done\n   ↑             ↓\n   └─── blocked ─┘  (human edits issue, flips back to developing)\n\nAny revisit of a state — including developing↔blocked — counts toward\nmax_retries; exceeding the limit records retry\u002Ffailure intent. Label\nwriteback remains an agent\u002Fhuman action.\n```\n````\n\n### Step 6: Operational detail lives in the target repo\n\nWorkbuddy's agent prompts are intentionally minimal contracts. They do NOT\nencode gh CLI recipes, branch-switching commands, PR reconciliation rules,\nor dev-loop commands — because those differ per repo and are better maintained\nwhere they are used.\n\nRecommend to the user: the target repo should maintain its own `CLAUDE.md`\ndescribing:\n- Dev-loop commands (build, test, vet, lint) for the repo's stack\n- PR conventions (branch naming, draft vs ready, review gating, merge strategy)\n- Test strategy (mock\u002Freal boundary, fixtures, coverage targets)\n- Project-specific gh CLI patterns\n\nIf the target repo has no `CLAUDE.md`, offer to scaffold one — but only\nafter confirming with the user, since that's beyond \"workbuddy setup\".\n\n### Step 6b: Initialize agent runtime skills in the target repo\n\nAgent runtimes discover project-level skills from conventional directories\ninside the working directory. **This step is critical** — without it, agents\nonly have generic global skills and miss repo-specific development patterns.\n\nThe skill directories depend on the runtime configured in the agent definitions:\n\n| Runtime | Skill directory | Discovery |\n|---------|----------------|-----------|\n| `claude-code` | `.claude\u002Fskills\u002F\u003Cname>\u002FSKILL.md` | Auto-loaded when skill description matches context |\n| `codex` | `.codex\u002Fskills\u002F\u003Cname>\u002FSKILL.md` | Same — auto-loaded by description match |\n\n**Create skills for the runtime(s) used by this repo's agents.** If\n`runtime: codex` is set in the agent configs, create `.codex\u002Fskills\u002F`. If\n`runtime: claude-code`, create `.claude\u002Fskills\u002F`. If both runtimes are used\n(e.g., different agents use different runtimes), create both directories.\n\n#### Standard skills to initialize\n\nCreate these three skills — they are runtime-agnostic in content and give\nagents a solid operational foundation:\n\n**1. `dev-loop\u002FSKILL.md`** — Development cycle: implement → test → verify\n\n```yaml\n---\nname: dev-loop\ndescription: \"Run a complete development loop: implement, test, vibe-check,\n  review, and measure before keeping or discarding. Use when implementing\n  features, fixing bugs, writing code, or refactoring.\"\n---\n```\n\nBody should describe the repo's specific build\u002Ftest\u002Flint commands, the\nkeep\u002Fdiscard decision framework, and how to log progress. Detect the\nrepo's language\u002Fstack (from Step 1) and tailor the commands accordingly.\nFor example, a Go repo should mention `go build`, `go test`, `go vet`;\na Node repo should mention `npm test`, `npm run lint`, etc.\n\n**2. `long-horizon\u002FSKILL.md`** — Autonomous decision-making\n\n```yaml\n---\nname: long-horizon\ndescription: \"Framework for autonomous decision-making during extended tasks.\n  Use when working on complex multi-step tasks that require judgment calls\n  without human intervention.\"\n---\n```\n\nBody should describe the escalation ladder (convention check → codebase\nresearch → external research → north-star reasoning → ask human) and\ndecision logging conventions. This helps agents make good autonomous\ndecisions during dev and review cycles instead of getting stuck.\n\n**3. `index\u002FSKILL.md`** (optional, for repos with documentation) — Doc-code consistency\n\nOnly create this if the repo has existing documentation (`docs\u002F`, `README.md`,\ndesign docs, etc.). It helps agents keep documentation aligned with code changes.\n\n#### Codex-specific: agent metadata files\n\nFor codex skills, also create an `agents\u002Fopenai.yaml` alongside each\n`SKILL.md` with display metadata:\n\n```yaml\n# .codex\u002Fskills\u002Fdev-loop\u002Fagents\u002Fopenai.yaml\ninterface:\n  display_name: \"Dev Loop\"\n  short_description: \"Run a full implement-test-measure loop\"\n  default_prompt: \"Use $dev-loop to drive this task through implementation,\n    testing, and verification.\"\n```\n\n#### What to put in the skill body\n\nKeep skills **lean and repo-specific**:\n- Reference the repo's actual build\u002Ftest commands (detected in Step 1)\n- Reference the repo's CLAUDE.md for conventions\n- Do NOT duplicate generic methodology — link to it or summarize briefly\n- The goal is that when an agent reads the skill, it knows exactly how\n  to operate in THIS repo, not just in theory\n\n#### Commit the skills\n\nAdd the skills directory to the same commit as the workbuddy config:\n\n```bash\ngit add .codex\u002Fskills\u002F   # or .claude\u002Fskills\u002F depending on runtime\n```\n\nThe skills are version-controlled alongside the repo's code, so they\nevolve with the project.\n\n### Step 7: Create config.yaml\n\nCreate `.github\u002Fworkbuddy\u002Fconfig.yaml`:\n\n```yaml\n# Workbuddy configuration for \u003Crepo>\nenvironment: dev\nrepo: \u003Cowner\u002Frepo>\npoll_interval: 30s\nport: 8080\n```\n\n### Step 8: Create .workbuddy\u002F gitignore entry\n\nAdd `.workbuddy\u002F` to the repo's `.gitignore` if not already present.\nThis directory holds local runtime state (SQLite DB, session logs).\n\n### Step 9: Verify and report\n\nAfter creating all files:\n\n1. List what was created:\n   - Labels created (count)\n   - Agent configs created: dev-agent, review-agent (exactly 2)\n   - Issue templates created: feature.md, bug.md\n   - Workflow created: default (single state machine for all workbuddy issues)\n   - config.yaml location\n\n2. Show the state machine diagram:\n   ```\n   developing ⇄ reviewing → done\n      ↑             ↓\n      └─── blocked ─┘  (human edits issue, flips back to developing)\n\n   Reviewer evaluates each Acceptance Criterion from the issue body.\n   All pass → done. Any fail → back to developing. Max 3 retries.\n   ```\n\n3. Explain how to use:\n   - Start workbuddy: `workbuddy serve`\n   - Open an issue via the feature or bug template; fill the Acceptance Criteria\n   - The `workbuddy` label opts the issue into the state machine; the\n     `status:developing` label on creation triggers dev-agent automatically\n   - Labels flow: developing → reviewing → done (or blocked when criteria missing)\n   - Monitor progress on the GitHub issue\n\n### Step 10: Register with coordinator (distributed mode)\n\nIf the user is running workbuddy in distributed mode, register the repo\nafter committing and pushing the config:\n\n```bash\nexport WORKBUDDY_AUTH_TOKEN=\"\u003Ctoken>\"\nworkbuddy repo register \\\n  --coordinator http:\u002F\u002Fcoordinator-host:8081 \\\n  --token \"$WORKBUDDY_AUTH_TOKEN\"\n```\n\nThis must be run from the target repo's root directory. It serializes\nthe local `.github\u002Fworkbuddy\u002F` config and POSTs it to the coordinator.\n\nThen start a worker for the repo:\n\n```bash\nworkbuddy worker \\\n  --coordinator http:\u002F\u002Fcoordinator-host:8081 \\\n  --token \"$WORKBUDDY_AUTH_TOKEN\" \\\n  --runtime codex \\\n  --repo Owner\u002FRepo\n```\n\nThe worker must also be started from the repo root — it loads agent\nprompt templates from `.github\u002Fworkbuddy\u002Fagents\u002F` locally.\n\n## What NOT to do\n\n- Don't create agents beyond `dev-agent` and `review-agent`. If a user insists,\n  point them at the 2-agent decision record and suggest encoding the need as\n  an issue template + acceptance criteria instead.\n- Don't create `.github\u002Fworkbuddy\u002Fagents\u002Fschemas\u002F` — the 2-agent catalog has\n  no `output_contract`.\n- Don't re-introduce `status:triage`, `status:failed`, or `needs-human` labels —\n  use `status:blocked` for all human-handoff cases.\n- Don't overwrite existing agent\u002Fworkflow configs without asking.\n- Don't delete existing labels.\n- Don't modify code in the target repo.\n- Don't start workbuddy — just configure it.\n- Don't assume the repo uses a specific language — detect it.\n\n## Customization\n\nIf the user specifies custom requirements:\n- **Custom runtime** (`codex` instead of `claude-code`) — set `runtime: codex`\n  on the agent config. Runtime is a field, not a separate agent.\n- **Custom type labels** beyond feature\u002Fbug — add the label and a matching\n  issue template with the same `## Acceptance Criteria` contract. The\n  workflow still matches on `workbuddy`, so the type label is classification\n  only. If you genuinely need a different state machine for a particular\n  class of work, add a new workflow file with a distinct trigger label and\n  have the team apply that label explicitly.\n- **Custom acceptance criteria conventions** — the only hard contract is that\n  dev-agent reads a section literally titled `## Acceptance Criteria`. How the\n  team structures criteria within that section is up to the repo.\n- **Custom policy per label** (e.g. read-only sandbox for high-risk changes) —\n  this is planned as Coordinator-side dynamic dispatch keyed on issue labels.\n  Not yet implemented; for now every issue runs under the agent's default policy.\n",{"name":5,"description":7},"main","b9778c800f442939b879c9a556dfb8d6f4a40971","plugins\u002Fworkbuddy\u002Fskills\u002Fsetup-repo",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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add Lincyaw\u002Fworkbuddy --skill setup-repo",{"tool":64,"command":65},"bunx","bunx skills add Lincyaw\u002Fworkbuddy --skill setup-repo",{"tool":67,"command":68},"pnpm","pnpm dlx skills add Lincyaw\u002Fworkbuddy --skill setup-repo","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fsetup-repo\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"WHY-TWO-COPIES.md","REFERENCE","参考文档",668,"https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Fplugins\u002Fworkbuddy\u002Fskills\u002Fsetup-repo\u002FWHY-TWO-COPIES.md",[79,104,141,160,186,207],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":44},"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",[],[86,87,88,89,38,90,91,35,92,93,94,95,96,97,98,99,100,101,102,103],"guide","workbuddy guide","debugging","issues","model","pick","rollouts","deeper","worker","bind","how to","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":121,"publishedAt":44},"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":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,27],"web","debug","web debug","frontend","auth","browser","harness","api","check","use","webui","spa","end","machine","touch","loads","headless","browser-use","using browser",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":44},"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",[],[148,149,150,151,89,152,130,131,34,153,94,154,155,156,157,98,158,30,159,27],"monitor","pipeline","pipeline monitor","status","supervisor","missed","watch","progress","detect","unit","agent pipeline","single",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":169,"publishedAt":44},"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",[166],{"categoryNo":167,"categoryName":168,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[170,171,172,173,174,175,89,176,177,178,131,179,180,181,182,49,183,184,185,27],"merge","flow","merge flow","design","validate","report","batch","health","user","integrate","resolve conflicts","conflicts","intent","post","design intent","prs",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":195,"publishedAt":44},"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",[192],{"categoryNo":193,"categoryName":194,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[188,196,197,198,152,199,200,86,131,201,202,94,203,204,205,206,157,98,159,27],"deployment","topology","how","process","install","Legacy","switch","service","as","bundle","serve",{"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":213,"publishedAt":44},"01M6XCB0SEG4W4RTFHFGXS7D51","example-skill","This description is intentionally long enough to satisfy the validator reliably.","https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002Finternal\u002Fvalidatedocs\u002Ftestdata\u002Fl4-pass\u002F.codex\u002Fskills\u002Fexample-skill\u002FSKILL.md",[],[214,215,216,217],"example skill","example","long","validator"]