setup-repo
Configure a GitHub repository for workbuddy orchestration. Use when the user wants to set up repo automation, initialize workbuddy, create workbuddy labels/agents/workflows, onboard a new repository, or says phrases like "set up repo", "configure repo for workbuddy", "initialize workbuddy", "配置仓库", or "初始化workbuddy".
- License 许可
- Apache-2.0
- 最近更新
- 2026-06-08
- Stars
- ★ 2
- Forks
- 1
01 前言 Front Matter
- name
- setup-repo
- description
- Configure a GitHub repository for workbuddy orchestration. Use when the user wants to set up repo automation, initialize workbuddy, create workbuddy labels/agents/workflows, onboard a new repository, or says phrases like "set up repo", "configure repo for workbuddy", "initialize workbuddy", "配置仓库", or "初始化workbuddy".
02 资源文件 3
- 参考文档agents/openai.yaml190 B
- 参考文档references/templates.md4.3 KB
- 参考文档WHY-TWO-COPIES.md668 B
03 SKILL.md 正文
Setup Repo
Bootstrap a repository so workbuddy can drive issue-based orchestration with GitHub labels, agent definitions, workflow files, and local runtime config.
This is a workflow skill. Use it when Codex should inspect a target repo, create or update .github/workbuddy/ files, add .workbuddy/ to .gitignore, and optionally create missing GitHub labels via gh.
Quick workflow
- Resolve the target repository.
- Prefer an explicit
owner/repoargument from the user. - Otherwise detect it with
gh repo view --json nameWithOwner -q .nameWithOwner.
- Prefer an explicit
- Inspect the current repo state.
- Detect the stack from files such as
go.mod,package.json,pyproject.toml, orCargo.toml. - Check whether
.github/workbuddy/already exists. - Read
.gitignorebefore editing it. - Query existing labels with
gh label list --repo <repo> --json name -q '.[].name'.
- Detect the stack from files such as
- Create or update the local workbuddy files.
- Add agent definitions under
.github/workbuddy/agents/. - Add workflow definitions under
.github/workbuddy/workflows/. - Add
.github/workbuddy/config.yaml. - Add
.workbuddy/to.gitignoreif it is missing.
- Add agent definitions under
- Create missing labels in GitHub only when
ghis authenticated and the user wants the remote repo configured now. - Report exactly what changed locally and remotely, plus any skipped items.
Decision rules
- Prefer updating existing workbuddy files over overwriting them blindly.
- Keep stack-specific guidance minimal in
SKILL.md; readreferences/templates.mdfor the exact label list and starter templates. - When the repo already contains agent definitions, preserve project-specific commands and only adjust the parts needed for workbuddy compatibility.
- If
ghauth or repo access is missing, still prepare the local files and clearly note the remote label step was not completed. - If the user asks about migrating Claude settings, explain that Codex skills cover reusable instructions, but Claude-style
hooksfrom.claude/settings*.jsondo not have a direct per-skill equivalent in the Codex skill format used here.
Claude-to-Codex migration notes
Migrate the Claude skill itself into this Codex skill format:
- keep only
nameanddescriptionin frontmatter - move the procedural guidance into the Markdown body
- move detailed templates into
references/ - add
agents/openai.yamlfor Codex UI metadata
Do not try to migrate .claude/settings.json or .claude/settings.local.json verbatim:
- the permission allowlists are Claude-specific runtime configuration, not skill content
- the
PostToolUsehook forSkillis not part of the CodexSKILL.mdcontract - if that hook behavior still matters, re-express it as explicit instructions, a helper script, or a plugin outside the skill itself
Reference map
Read only what you need:
references/templates.md-> required labels, agent templates, workflow templates, and config skeleton
Output checklist
Before finishing, make sure the response includes:
- target repo used
- detected stack
- files created or updated
- labels created or skipped
- any manual follow-up needed, especially for remote GitHub steps
04 同仓库更多 Skills
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/onboard a repo, add/bind a worker, 注册仓库, 加仓库, 接入新仓库, onboard repo, set up worker), explanatory questions (how to use workbuddy, workbuddy guide, teach me workbuddy, 怎么用workbuddy, 使用指南), deployment/running/operating/debugging workbuddy, and questions about how issues/tasks are scheduled or how dependencies between issues work (depends_on, blocked, dependency gate, 依赖, 调度, 排队, '为什么没派发'), and questions about parallel-development workflows (rollouts:N fan-out, synthesize/synthesis 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/scheduling model aren't re-derived from scratch.
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/webui, web/, or the auth/cookie path.
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.
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.
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.
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'.