[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XC9M1HSBBY6N4TY9G0HT7R":3,"skill-same:01M6XC9M1HSBBY6N4TY9G0HT7R":73},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6XC9M1HSBBY6N4TY9G0HT7R","long-horizon",null,"Use when the agent should operate autonomously for an extended task and make reasonable decisions without interrupting the user for every choice. Trigger when the user says to just do it, work independently, run for a long time, avoid asking constant questions, or when configuring autonomous sub-workflows. 中文触发：自主执行、别问我、自己做、长时间运行、自动跑、不用问我、自己决定、后台跑。","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\u002Flong-horizon\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"long horizon","horizon","long","task","when","for","operate","questions","trigger","time","workflows","do","use","autonomous","decisions","work","just","choice","中文","run","2026-11-10 10:12:30",false,"---\nname: long-horizon\ndescription: Use when the agent should operate autonomously for an extended task and make reasonable decisions without interrupting the user for every choice. Trigger when the user says to just do it, work independently, run for a long time, avoid asking constant questions, or when configuring autonomous sub-workflows. 中文触发：自主执行、别问我、自己做、长时间运行、自动跑、不用问我、自己决定、后台跑。\n---\n\n# Long Horizon\n\nFramework for autonomous decision-making during extended work. The core rule is:\n\n`exhaust your own judgment before consuming the user's attention`\n\nUse this skill when progress matters more than constant confirmation and the task can tolerate well-reasoned autonomous decisions.\n\n## The escalation ladder\n\nWork through uncertainty from lowest-cost resolution to highest-cost resolution. Only escalate when the current level does not resolve the issue.\n\n1. **Convention check** -> decide silently when the codebase already answers it\n2. **Codebase research** -> decide and log\n3. **External research** -> decide and log with reasoning\n4. **North-star reasoning** -> decide, log, and flag for later review\n5. **Ask the user** -> last resort; batch questions together\n\n## Level 1: Convention check\n\nFirst ask: does the repository already answer this?\n\nCheck:\n\n- project instruction files such as `AGENTS.md`, `CLAUDE.md`, or repo-specific docs\n- existing code in the same subsystem\n- config such as linters, formatters, CI, and generators\n- recent git history if it clarifies an established pattern\n\nIf a clear convention exists, follow it without stopping to discuss it.\n\nTypical examples:\n\n- quote style\n- test framework choice\n- file placement\n- naming conventions\n\n## Level 2: Codebase research\n\nIf the answer is not obvious, spend a short bounded period reading nearby files, related modules, READMEs, comments, or commit history.\n\nUse this level for questions like:\n\n- how errors are usually handled\n- how transactions or side effects are structured\n- what endpoint naming pattern is already in use\n\nAt this level and above, leave a decision trail the user can review later.\n\nExample log entry:\n\n`Used repository pattern for new data access (L2: consistent with adjacent modules)`\n\n## Level 3: External research\n\nIf the repository is not enough, research outside it:\n\n- official docs\n- primary library\u002Fframework docs\n- issue trackers\n- source code of dependencies\n- comparable open-source implementations\n\nUse this for technical choices where the answer is discoverable but not already encoded in the project.\n\nExample log entry:\n\n`Chose zod over joi (L3: better TypeScript inference, aligns with maintainability)`\n\n## Level 4: North-star reasoning\n\nWhen multiple options remain viable, use the project's objectives as the tie-breaker.\n\nFor each option, evaluate how it affects the project's top goals, such as:\n\n- maintainability\n- simplicity\n- reliability\n- performance\n- clarity\n\nThen choose the best trade-off, continue the work, and flag the decision for later review rather than blocking on approval.\n\nExample:\n\n`[flagged] Kept duplication over extracting a base class (L4: simpler and easier to maintain)`\n\n## Level 5: Ask the user\n\nOnly ask after exhausting Levels 1-4, and only when the user is genuinely required.\n\nLegitimate reasons include:\n\n- strategic scope or direction changes\n- missing access, secrets, or credentials\n- ambiguous requirements that research could not clarify\n- high-risk irreversible actions\n- conflicting signals that materially affect the outcome\n\nWhen you ask, batch all unresolved questions together and include the reasoning you already did so the user can answer quickly.\n\n## Decision logging\n\nFor any Level 2+ decision, keep a lightweight decision log in a repo-visible place such as `decisions.md` unless the project already has a preferred path.\n\nUseful fields:\n\n- date\n- decision\n- level (`L2`, `L3`, `L4`)\n- short reasoning\n- whether it was flagged for later review\n\nThe log helps with:\n\n- session continuity\n- user review\n- future calibration of autonomous behavior\n\n## Anti-patterns\n\nAvoid:\n\n- asking too early\n- making significant decisions with no trail\n- shallow \"research\" that never compared options\n- spending too long on low-level decisions\n- interrupting the user repeatedly instead of batching questions\n\n## Autonomy tuning\n\nDifferent tasks need different autonomy levels:\n\n- **High autonomy**: decide through L4 and only ask for credentials, irreversible actions, or major strategic changes\n- **Medium autonomy**: decide through L3, flag L4, ask for L5\n- **Low autonomy**: decide through L2, ask earlier on subjective trade-offs\n\nIf the project tracks autonomy preferences, respect them. Otherwise default to medium and bias toward progress.\n\n## Integration notes\n\n- `dev-loop` uses this skill for the non-metric decisions that happen during repeated iterations\n- `notify` can surface flagged L4 decisions asynchronously instead of blocking execution\n- any optional telemetry or correction logging is best-effort and should not interrupt delivery\n\n## Migration notes\n\nThis Codex version preserves the decision ladder from the Claude skill but removes Claude-specific frontmatter fields such as `category`. Logging paths and command details should be adapted to the current repository instead of assuming a Claude-specific runtime.\n","# Long Horizon\n\nFramework for autonomous decision-making during extended work. The core rule is:\n\n`exhaust your own judgment before consuming the user's attention`\n\nUse this skill when progress matters more than constant confirmation and the task can tolerate well-reasoned autonomous decisions.\n\n## The escalation ladder\n\nWork through uncertainty from lowest-cost resolution to highest-cost resolution. Only escalate when the current level does not resolve the issue.\n\n1. **Convention check** -> decide silently when the codebase already answers it\n2. **Codebase research** -> decide and log\n3. **External research** -> decide and log with reasoning\n4. **North-star reasoning** -> decide, log, and flag for later review\n5. **Ask the user** -> last resort; batch questions together\n\n## Level 1: Convention check\n\nFirst ask: does the repository already answer this?\n\nCheck:\n\n- project instruction files such as `AGENTS.md`, `CLAUDE.md`, or repo-specific docs\n- existing code in the same subsystem\n- config such as linters, formatters, CI, and generators\n- recent git history if it clarifies an established pattern\n\nIf a clear convention exists, follow it without stopping to discuss it.\n\nTypical examples:\n\n- quote style\n- test framework choice\n- file placement\n- naming conventions\n\n## Level 2: Codebase research\n\nIf the answer is not obvious, spend a short bounded period reading nearby files, related modules, READMEs, comments, or commit history.\n\nUse this level for questions like:\n\n- how errors are usually handled\n- how transactions or side effects are structured\n- what endpoint naming pattern is already in use\n\nAt this level and above, leave a decision trail the user can review later.\n\nExample log entry:\n\n`Used repository pattern for new data access (L2: consistent with adjacent modules)`\n\n## Level 3: External research\n\nIf the repository is not enough, research outside it:\n\n- official docs\n- primary library\u002Fframework docs\n- issue trackers\n- source code of dependencies\n- comparable open-source implementations\n\nUse this for technical choices where the answer is discoverable but not already encoded in the project.\n\nExample log entry:\n\n`Chose zod over joi (L3: better TypeScript inference, aligns with maintainability)`\n\n## Level 4: North-star reasoning\n\nWhen multiple options remain viable, use the project's objectives as the tie-breaker.\n\nFor each option, evaluate how it affects the project's top goals, such as:\n\n- maintainability\n- simplicity\n- reliability\n- performance\n- clarity\n\nThen choose the best trade-off, continue the work, and flag the decision for later review rather than blocking on approval.\n\nExample:\n\n`[flagged] Kept duplication over extracting a base class (L4: simpler and easier to maintain)`\n\n## Level 5: Ask the user\n\nOnly ask after exhausting Levels 1-4, and only when the user is genuinely required.\n\nLegitimate reasons include:\n\n- strategic scope or direction changes\n- missing access, secrets, or credentials\n- ambiguous requirements that research could not clarify\n- high-risk irreversible actions\n- conflicting signals that materially affect the outcome\n\nWhen you ask, batch all unresolved questions together and include the reasoning you already did so the user can answer quickly.\n\n## Decision logging\n\nFor any Level 2+ decision, keep a lightweight decision log in a repo-visible place such as `decisions.md` unless the project already has a preferred path.\n\nUseful fields:\n\n- date\n- decision\n- level (`L2`, `L3`, `L4`)\n- short reasoning\n- whether it was flagged for later review\n\nThe log helps with:\n\n- session continuity\n- user review\n- future calibration of autonomous behavior\n\n## Anti-patterns\n\nAvoid:\n\n- asking too early\n- making significant decisions with no trail\n- shallow \"research\" that never compared options\n- spending too long on low-level decisions\n- interrupting the user repeatedly instead of batching questions\n\n## Autonomy tuning\n\nDifferent tasks need different autonomy levels:\n\n- **High autonomy**: decide through L4 and only ask for credentials, irreversible actions, or major strategic changes\n- **Medium autonomy**: decide through L3, flag L4, ask for L5\n- **Low autonomy**: decide through L2, ask earlier on subjective trade-offs\n\nIf the project tracks autonomy preferences, respect them. Otherwise default to medium and bias toward progress.\n\n## Integration notes\n\n- `dev-loop` uses this skill for the non-metric decisions that happen during repeated iterations\n- `notify` can surface flagged L4 decisions asynchronously instead of blocking execution\n- any optional telemetry or correction logging is best-effort and should not interrupt delivery\n\n## Migration notes\n\nThis Codex version preserves the decision ladder from the Claude skill but removes Claude-specific frontmatter fields such as `category`. Logging paths and command details should be adapted to the current repository instead of assuming a Claude-specific runtime.\n",{"name":5,"description":7},"main","b9778c800f442939b879c9a556dfb8d6f4a40971",".codex\u002Fskills\u002Flong-horizon",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":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add Lincyaw\u002Fworkbuddy --skill long-horizon",{"tool":59,"command":60},"bunx","bunx skills add Lincyaw\u002Fworkbuddy --skill long-horizon",{"tool":62,"command":63},"pnpm","pnpm dlx skills add Lincyaw\u002Fworkbuddy --skill long-horizon","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Flong-horizon\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"agents\u002Fopenai.yaml","REFERENCE","参考文档",245,"https:\u002F\u002Fgithub.com\u002FLincyaw\u002Fworkbuddy\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Flong-horizon\u002Fagents\u002Fopenai.yaml",[74,100,138,164,183,209],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":39},"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",[],[81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,25,97,98,99],"guide","workbuddy guide","debugging","issues","SET","model","pick","up","rollouts","deeper","worker","bind","how to","operating","coordinator","re","which","scheduled","invoke",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":119,"publishedAt":39},"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",[106,111,114],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":112,"categoryName":113,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[120,121,122,123,124,125,126,127,128,31,129,130,131,132,133,134,135,136,137,23],"web","debug","web debug","frontend","auth","browser","harness","api","check","webui","spa","end","machine","touch","loads","headless","browser-use","using browser",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":147,"publishedAt":39},"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",[144],{"categoryNo":145,"categoryName":146,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000023","Skill与智能体开发",[148,149,150,151,152,153,154,155,156,85,157,158,88,159,160,161,162,24,163,23],"setup","setup repo","repo","review","orchestration","workflow","config","dev","repository","configure","initialize","issue","new repo","初始化","canonical","labels",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":39},"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",[],[171,172,173,174,84,175,128,31,159,176,91,177,178,179,180,95,181,24,182,23],"monitor","pipeline","pipeline monitor","status","supervisor","missed","watch","progress","detect","unit","agent pipeline","single",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":192,"publishedAt":39},"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",[189],{"categoryNo":190,"categoryName":191,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000015","视觉设计",[193,194,195,196,197,198,84,199,200,201,31,202,203,204,205,44,206,207,208,23],"merge","flow","merge flow","design","validate","report","batch","health","user","integrate","resolve conflicts","conflicts","intent","post","design intent","prs",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":218,"publishedAt":39},"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",[215],{"categoryNo":216,"categoryName":217,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000011","运维与部署",[211,219,220,221,175,222,223,81,31,224,225,91,226,227,228,229,180,95,182,23],"deployment","topology","how","process","install","Legacy","switch","service","as","bundle","serve"]