[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XC9DRF98N6MFBWJH4ZRAS2":3,"skill-same:01M6XC9DRF98N6MFBWJH4ZRAS2":82},{"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":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6XC9DRF98N6MFBWJH4ZRAS2","index",null,"Audit repository documentation against the real codebase and reorganize docs into three buckets: implemented, planned, and mismatch. Use this whenever the user asks to review docs for correctness, compare docs with code or git diff, reconcile stale design docs, rewrite project documentation structure, or maintain `project-index.yaml` as the source of truth for doc-to-code mapping.","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\u002F.codex\u002Fskills\u002Findex\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"diff","project documentation","source","mapping","design docs","as","project","structure","three","maintain","design","reconcile","doc","repository","audit","git","code","documentation","review","2026-11-10 10:12:30",false,"---\nname: index\ndescription: \"Audit repository documentation against the real codebase and reorganize docs into three buckets: implemented, planned, and mismatch. Use this whenever the user asks to review docs for correctness, compare docs with code or git diff, reconcile stale design docs, rewrite project documentation structure, or maintain `project-index.yaml` as the source of truth for doc-to-code mapping.\"\n---\n\n# Doc Code Consistency\n\n## Overview\n\nUse this skill to keep repository documentation aligned with the implementation.\n\nTreat documentation maintenance as a code review task with three outputs:\n\n1. `implemented`: documents that already match the current code.\n2. `planned`: forward-looking design documents that intentionally describe a target state.\n3. `mismatch`: places where docs and code disagree and must be reconciled before the docs can guide development.\n\nAlways ground decisions in the current repository state, not in memory.\n\n## Core Rules\n\n- Read the code before trusting the docs.\n- Read `project-index.yaml` before reorganizing documentation.\n- Prefer classifying uncertain topics as `mismatch` rather than overstating implementation status.\n- Preserve user changes already in the worktree or index; never revert unrelated edits.\n- If old docs are being replaced, create the new canonical docs first, then delete or retire the superseded files.\n- Keep the three-bucket structure simple and explicit; avoid mixing current behavior and future design in the same file.\n\n## Required Inputs\n\nAt minimum, inspect these locations if they exist:\n\n- `docs\u002F`\n- `project-index.yaml`\n- relevant code paths referenced by the docs\n- `git diff` and `git diff --cached` when the user asks to include pending changes\n\nIf the repo uses a different documentation root or index file, adapt to that structure and record the choice in the rewritten docs.\n\n## Workflow\n\n### 1. Build the inventory\n\nDo the following first:\n\n- list the docs under `docs\u002F`\n- read `project-index.yaml`\n- scan old and new docs for code references\n- inspect the referenced code, not just filenames\n- include staged and unstaged changes when the user asks for a full consistency pass\n\nUse `scripts\u002Fdoc_inventory.py` to generate a baseline inventory and stale-reference report, then confirm the findings by reading the actual files.\n\n### 2. Classify each document or topic\n\nFor every meaningful topic, decide which bucket it belongs to:\n\n- `implemented`: behavior is already visible in the code and safe to treat as current truth\n- `planned`: intentionally future-state, not yet implemented, but still a valid target design\n- `mismatch`: docs and code diverge, or the doc mixes current truth with speculative behavior\n\nUse these heuristics:\n\n- if the code path exists and behavior is observable today, prefer `implemented`\n- if the doc explicitly defines a migration target or vNext shape, prefer `planned`\n- if the doc over-claims capability, references removed structure, or mixes old and new worlds, prefer `mismatch`\n\n### 3. Rewrite into canonical docs\n\nCreate or update:\n\n- `docs\u002Findex.md`\n- `docs\u002Fimplemented\u002Findex.md`\n- `docs\u002Fplanned\u002Findex.md`\n- `docs\u002Fmismatch\u002Findex.md`\n\nThen add focused docs under each bucket.\n\nKeep each file narrow and stable:\n\n- implemented docs should describe current behavior only\n- planned docs should describe target behavior only\n- mismatch docs should explain the exact drift and what needs to be reconciled\n\n### 4. Update the index source of truth\n\nUpdate the `documentation:` section in `project-index.yaml` so it maps:\n\n- bucket definitions\n- document paths\n- status\n- related code\n- notes\n\nIf the requirements section also points to docs, refresh those links too.\n\n### 5. Remove or retire superseded docs\n\nOnly after the new canonical docs exist:\n\n- delete obsolete top-level design docs if the user asked for a full migration\n- remove stale references to deleted docs\n- make sure the new bucket docs are the only authoritative doc set\n\n### 6. Validate the result\n\nBefore finishing, run these checks:\n\n- validate `project-index.yaml` parses cleanly\n- search for references to deleted doc paths\n- check that each bucket index only points to existing files\n- verify the main implementation claims against the code one more time\n\n## Output Expectations\n\nWhen you finish the task, report:\n\n- what moved into `implemented`\n- what moved into `planned`\n- what moved into `mismatch`\n- which old docs were removed\n- whether `project-index.yaml` was updated successfully\n- any residual ambiguity that still needs a product or engineering decision\n\n## Suggested Commands\n\nPrefer fast local inspection commands such as:\n\n```bash\nrg --files docs\nrg -n \"documentation:|requirements:\" project-index.yaml\nrg -n \"docs\u002F|internal\u002F|cmd\u002F|\\.github\u002Fworkbuddy\u002F\" docs project-index.yaml\npython .codex\u002Fskills\u002Fdoc-code-consistency\u002Fscripts\u002Fdoc_inventory.py --root .\n```\n\n## Reference Material\n\nRead `references\u002Fdoc-model.md` before a large rewrite to keep the bucket semantics and migration rules consistent.\n","# Doc Code Consistency\n\n## Overview\n\nUse this skill to keep repository documentation aligned with the implementation.\n\nTreat documentation maintenance as a code review task with three outputs:\n\n1. `implemented`: documents that already match the current code.\n2. `planned`: forward-looking design documents that intentionally describe a target state.\n3. `mismatch`: places where docs and code disagree and must be reconciled before the docs can guide development.\n\nAlways ground decisions in the current repository state, not in memory.\n\n## Core Rules\n\n- Read the code before trusting the docs.\n- Read `project-index.yaml` before reorganizing documentation.\n- Prefer classifying uncertain topics as `mismatch` rather than overstating implementation status.\n- Preserve user changes already in the worktree or index; never revert unrelated edits.\n- If old docs are being replaced, create the new canonical docs first, then delete or retire the superseded files.\n- Keep the three-bucket structure simple and explicit; avoid mixing current behavior and future design in the same file.\n\n## Required Inputs\n\nAt minimum, inspect these locations if they exist:\n\n- `docs\u002F`\n- `project-index.yaml`\n- relevant code paths referenced by the docs\n- `git diff` and `git diff --cached` when the user asks to include pending changes\n\nIf the repo uses a different documentation root or index file, adapt to that structure and record the choice in the rewritten docs.\n\n## Workflow\n\n### 1. Build the inventory\n\nDo the following first:\n\n- list the docs under `docs\u002F`\n- read `project-index.yaml`\n- scan old and new docs for code references\n- inspect the referenced code, not just filenames\n- include staged and unstaged changes when the user asks for a full consistency pass\n\nUse `scripts\u002Fdoc_inventory.py` to generate a baseline inventory and stale-reference report, then confirm the findings by reading the actual files.\n\n### 2. Classify each document or topic\n\nFor every meaningful topic, decide which bucket it belongs to:\n\n- `implemented`: behavior is already visible in the code and safe to treat as current truth\n- `planned`: intentionally future-state, not yet implemented, but still a valid target design\n- `mismatch`: docs and code diverge, or the doc mixes current truth with speculative behavior\n\nUse these heuristics:\n\n- if the code path exists and behavior is observable today, prefer `implemented`\n- if the doc explicitly defines a migration target or vNext shape, prefer `planned`\n- if the doc over-claims capability, references removed structure, or mixes old and new worlds, prefer `mismatch`\n\n### 3. Rewrite into canonical docs\n\nCreate or update:\n\n- `docs\u002Findex.md`\n- `docs\u002Fimplemented\u002Findex.md`\n- `docs\u002Fplanned\u002Findex.md`\n- `docs\u002Fmismatch\u002Findex.md`\n\nThen add focused docs under each bucket.\n\nKeep each file narrow and stable:\n\n- implemented docs should describe current behavior only\n- planned docs should describe target behavior only\n- mismatch docs should explain the exact drift and what needs to be reconciled\n\n### 4. Update the index source of truth\n\nUpdate the `documentation:` section in `project-index.yaml` so it maps:\n\n- bucket definitions\n- document paths\n- status\n- related code\n- notes\n\nIf the requirements section also points to docs, refresh those links too.\n\n### 5. Remove or retire superseded docs\n\nOnly after the new canonical docs exist:\n\n- delete obsolete top-level design docs if the user asked for a full migration\n- remove stale references to deleted docs\n- make sure the new bucket docs are the only authoritative doc set\n\n### 6. Validate the result\n\nBefore finishing, run these checks:\n\n- validate `project-index.yaml` parses cleanly\n- search for references to deleted doc paths\n- check that each bucket index only points to existing files\n- verify the main implementation claims against the code one more time\n\n## Output Expectations\n\nWhen you finish the task, report:\n\n- what moved into `implemented`\n- what moved into `planned`\n- what moved into `mismatch`\n- which old docs were removed\n- whether `project-index.yaml` was updated successfully\n- any residual ambiguity that still needs a product or engineering decision\n\n## Suggested Commands\n\nPrefer fast local inspection commands such as:\n\n```bash\nrg --files docs\nrg -n \"documentation:|requirements:\" project-index.yaml\nrg -n \"docs\u002F|internal\u002F|cmd\u002F|\\.github\u002Fworkbuddy\u002F\" docs project-index.yaml\npython .codex\u002Fskills\u002Fdoc-code-consistency\u002Fscripts\u002Fdoc_inventory.py --root .\n```\n\n## Reference Material\n\nRead `references\u002Fdoc-model.md` before a large rewrite to keep the bucket semantics and migration rules consistent.\n",{"name":5,"description":7},"main","b9778c800f442939b879c9a556dfb8d6f4a40971",".codex\u002Fskills\u002Findex",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":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add Lincyaw\u002Fworkbuddy --skill index",{"tool":58,"command":59},"bunx","bunx skills add Lincyaw\u002Fworkbuddy --skill index",{"tool":61,"command":62},"pnpm","pnpm dlx skills add Lincyaw\u002Fworkbuddy --skill index","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Findex\u002FSKILL.md",true,[66,72,76],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"agents\u002Fopenai.yaml","REFERENCE","参考文档",234,"https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Findex\u002Fagents\u002Fopenai.yaml",{"path":73,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fdoc-model.md",1345,"https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Findex\u002Freferences\u002Fdoc-model.md",{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"scripts\u002Fdoc_inventory.py","SCRIPT","脚本",2198,"https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Findex\u002Fscripts\u002Fdoc_inventory.py",[83,110,150,175,194,219],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":38},"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",[],[90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109],"guide","workbuddy guide","debugging","issues","SET","model","pick","up","rollouts","deeper","worker","bind","how to","operating","coordinator","re","operate","which","scheduled","invoke",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":129,"publishedAt":38},"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",[116,121,124],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":122,"categoryName":123,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149],"web","debug","web debug","frontend","auth","browser","harness","api","check","use","webui","spa","end","machine","touch","loads","headless","browser-use","using browser","when",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":159,"publishedAt":38},"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",[156],{"categoryNo":157,"categoryName":158,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000023","Skill与智能体开发",[160,161,162,37,163,164,165,166,32,94,167,168,97,169,170,171,172,173,174,149],"setup","setup repo","repo","orchestration","workflow","config","dev","configure","initialize","issue","new repo","初始化","canonical","for","labels",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":38},"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",[],[182,183,184,185,93,186,138,139,169,187,100,188,189,190,191,104,192,173,193,149],"monitor","pipeline","pipeline monitor","status","supervisor","missed","watch","progress","detect","unit","agent pipeline","single",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":203,"publishedAt":38},"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",[200],{"categoryNo":201,"categoryName":202,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000015","视觉设计",[204,205,206,29,207,208,93,209,210,211,139,212,213,214,215,43,216,217,218,149],"merge","flow","merge flow","validate","report","batch","health","user","integrate","resolve conflicts","conflicts","intent","post","design intent","prs",{"skillNo":220,"name":221,"nameZh":6,"description":222,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":223,"categories":224,"keywords":228,"publishedAt":38},"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",[225],{"categoryNo":226,"categoryName":227,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000011","运维与部署",[221,229,230,231,186,232,233,90,139,234,235,100,236,24,237,238,191,104,193,149],"deployment","topology","how","process","install","Legacy","switch","service","bundle","serve"]