[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D3YVG7CTCAYWTZGPYKB543":3,"skill-same:01M6D3YVG7CTCAYWTZGPYKB543":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":45,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M6D3YVG7CTCAYWTZGPYKB543","provision-agentic-config",null,"Provision workflow orchestration and agent conventions into project CLAUDE.md and AGENTS.md","GeorgeQLe\u002Fagentic-skills","GeorgeQLe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F21134126?v=4","01M6D2JP418S0VGJGF8M93EC3H","George Le","01M6D2JPBAKYD82TA5FS6HKQ3D",1,"MIT","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fbase\u002Fcodex\u002Fprovision-agentic-config\u002Farchive\u002Fv0.2\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33],"agentic","config","provision agentic config","orchestration","workflow","workflow orchestration","v0","ops","conventions","project","2026-11-10 10:12:30",false,"---\nname: provision-agentic-config\ndescription: Provision workflow orchestration and agent conventions into project CLAUDE.md and AGENTS.md\ntype: ops\nversion: v0.2\n---\n\n# Install Workflow Orchestration\n\nInvoke as `$provision-agentic-config`.\n\nUse this skill when the user wants the repository's `CLAUDE.md` and `AGENTS.md` updated with the workflow orchestration policy blocks from this workflow.\n\n## Target\n\n- Current repository files: `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`\n\n## Workflow\n\n1. Ensure `.\u002FCLAUDE.md` and `.\u002FAGENTS.md` exist.\n2. Insert the Claude policy block below verbatim into `CLAUDE.md`.\n3. Insert the AGENTS policy block below verbatim into `AGENTS.md`.\n4. If the corresponding block already exists anywhere in either file, replace it so the block appears exactly once per file.\n5. Preserve any unrelated content already in `CLAUDE.md` and `AGENTS.md`.\n6. When a target file is newly created, or when it already has a provisioning\u002Fsource note from this skill, include or update a concise repo-relative note outside the inserted block:\n   - `CLAUDE.md`: `Provisioned artifact: .\u002FCLAUDE.md. Source: workflow.md. Verification: block appears exactly once.`\n   - `AGENTS.md`: `Provisioned artifact: .\u002FAGENTS.md. Source: workflow.md. Verification: block appears exactly once.`\n   - If `workflow.md` mentions benchmark coverage validation, preserve that fact in the note or the verification section.\n   - Do not add temp directory paths such as `\u002Ftmp`, `\u002Fprivate\u002Fvar`, or `\u002Fvar\u002Ffolders` to either target file.\n7. Each block begins with `\u003C!-- provision-agentic-config v0.2 -->`. When replacing an existing block, update this comment to the current version. The `\u002Fsync` skill uses this comment to detect stale provisioning.\n\n## Required Claude Block\n\n````md\n\u003C!-- provision-agentic-config v0.2 -->\n## Workflow Orchestration\n\n### 1. Plan Mode Default\n- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)\n- If something goes sideways, STOP and re-plan immediately - don't keep pushing\n- Verification is mandatory, but routine no-op verification runs inside the active execution\u002Fshipping step. Enter plan mode for non-trivial remediation or new work discovered by verification, not for validation that already has clear commands and no expected source changes.\n- Write detailed specs upfront to reduce ambiguity\n- In Codex: use `update_plan` in Default mode and `request_user_input` only when already in Plan mode\n- Do not assume a Claude-style clear-context-on-accept flow or related JSON setting exists\n\n### 2. Subagent Strategy\n- Use subagents liberally to keep main context window clean\n- Offload research, exploration, and parallel analysis to subagents\n- For complex problems, throw more compute at it via subagents\n- One task per subagent for focused execution\n- For `agent-team` parallel write lanes, require separate GitHub branches per lane and include a consolidation\u002FPR review step before final integration. This is the explicit exception to direct-to-primary work.\n\n### 3. Self-Improvement Loop\n- After ANY correction from the user: update `tasks\u002Flessons.md` with the pattern\n- Write rules for yourself that prevent the same mistake\n- Ruthlessly iterate on these lessons until mistake rate drops\n- Review lessons at session start for relevant project\n\n### 4. Verification Before Done\n- Never mark a task complete without proving it works\n- Diff your behavior between main and your changes when relevant\n- Ask yourself: \"Would a staff engineer approve this?\"\n- Run tests, check logs, demonstrate correctness\n\n### 5. Demand Elegance (Balanced)\n- For non-trivial changes: pause and ask \"is there a more elegant way?\"\n- If a fix feels hacky: \"Knowing everything I know now, implement the elegant solution\"\n- Skip this for simple, obvious fixes - don't over-engineer\n- Challenge your own work before presenting it\n\n### 6. Autonomous Bug Fixing\n- When given a bug report: just fix it. Don't ask for hand-holding\n- Point at logs, errors, failing tests - then resolve them\n- Zero context switching required from the user\n- Go fix failing tests without being told how\n\n## Task Management\n\n1. **Plan First**: Write plan to `tasks\u002Froadmap.md` (full plan) and `tasks\u002Ftodo.md` (current phase) with checkable items\n2. **Verify Plan**: Check in before starting implementation\n3. **Track Progress**: Mark items complete as you go\n4. **Explain Changes**: High-level summary at each step\n5. **Document Results**: Add review section to `tasks\u002Ftodo.md`\n6. **Capture Lessons**: Update `tasks\u002Flessons.md` after corrections\n\n## Core Principles\n- **Simplicity First**: Make every change as simple as possible. Impact minimal code.\n- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.\n- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.\n- **Direct-To-Primary Git Flow**: Default to committing and pushing sequential work on the repository primary branch (`main` when present, otherwise `master`). Do not introduce or continue feature-branch workflows unless the user explicitly asks for them, except for `agent-team` parallel write lanes, which must use separate GitHub branches and pass consolidation\u002FPR review before landing.\n- **Always Ship Mutations**: If a task creates or modifies tracked files, finish by committing and pushing all intended changes before stopping unless the user explicitly says not to. Do not leave a dirty tracked tree or unpushed commits behind.\n- **No GitHub Actions**: Do not create, modify, or suggest GitHub Actions workflows unless the user explicitly asks for GitHub Actions. This project does not use GitHub Actions for CI\u002FCD by default.\n\n## Windows\u002FWSL File Opening\n- On Windows machines running WSL, convert Linux paths before opening files from shell commands:\n\n```bash\nWIN_PATH=$(wslpath -w \"$FILE_PATH\")\ncmd.exe \u002Fc start \"\" \"$WIN_PATH\"\n```\n\n- For HTML files that should open in the Windows browser, prefer a WSL file URI through the Windows PowerShell binary when `cmd.exe \u002Fc start` or UNC paths fail:\n\n```bash\nDISTRO=${WSL_DISTRO_NAME:-Ubuntu}\nURI=\"file:\u002F\u002Fwsl.localhost\u002F${DISTRO}${FILE_PATH}\"\n\u002Fmnt\u002Fc\u002FWINDOWS\u002FSystem32\u002FWindowsPowerShell\u002Fv1.0\u002Fpowershell.exe -NoProfile -Command \"Start-Process '$URI'\"\n```\n\n- Use WSL detection so this path only runs inside WSL:\n\n```bash\nif grep -qi microsoft \u002Fproc\u002Fversion 2>\u002Fdev\u002Fnull; then\n  cmd.exe \u002Fc start \"\" \"$(wslpath -w \"$FILE_PATH\")\"\nfi\n```\n\n- The `cmd.exe` UNC warning (`UNC paths are not supported. Defaulting to Windows directory.`) is cosmetic; the file still opens correctly.\n- The `UtilBindVsockAnyPort: socket failed 1` failure can happen before Windows opens a UNC path. For browser-targeted HTML pages, retry with the `file:\u002F\u002Fwsl.localhost\u002F\u003Cdistro>\u002F...` PowerShell URI before using editor fallbacks.\n````\n\n## Required AGENTS Block\n\n````md\n\u003C!-- provision-agentic-config v0.2 -->\n## Workflow Orchestration\n\n### 1. Plan Mode Default\n- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)\n- If something goes sideways, STOP and re-plan immediately - don't keep pushing\n- Verification is mandatory, but routine no-op verification runs inside the active execution\u002Fshipping step. Enter plan mode for non-trivial remediation or new work discovered by verification, not for validation that already has clear commands and no expected source changes.\n- Write detailed specs upfront to reduce ambiguity\n- In Codex: use `update_plan` in Default mode and `request_user_input` only when already in Plan mode\n- Do not assume a Claude-style clear-context-on-accept flow or related JSON setting exists\n\n### 2. Subagent Strategy\n- Use subagents only when the active Codex tool instructions allow them.\n- When subagents are available and permitted, delegate independent research, exploration, or execution lanes with non-overlapping scopes.\n- One task per subagent for focused execution.\n- Do not override Codex's current subagent permission, tool availability, or parallel-work rules.\n- For `agent-team` parallel write lanes, require separate GitHub branches per lane and include a consolidation\u002FPR review step before final integration. This is the explicit exception to direct-to-primary work.\n\n### 3. Self-Improvement Loop\n- After ANY correction from the user: update `tasks\u002Flessons.md` with the pattern\n- Write rules for yourself that prevent the same mistake\n- Ruthlessly iterate on these lessons until mistake rate drops\n- Review lessons at session start for relevant project\n\n### 4. Verification Before Done\n- Never mark a task complete without proving it works\n- Diff your behavior between main and your changes when relevant\n- Ask yourself: \"Would a staff engineer approve this?\"\n- Run tests, check logs, demonstrate correctness\n\n### 5. Demand Elegance (Balanced)\n- For non-trivial changes: pause and ask \"is there a more elegant way?\"\n- If a fix feels hacky: \"Knowing everything I know now, implement the elegant solution\"\n- Skip this for simple, obvious fixes - don't over-engineer\n- Challenge your own work before presenting it\n\n### 6. Autonomous Bug Fixing\n- When given a bug report: just fix it. Don't ask for hand-holding\n- Point at logs, errors, failing tests - then resolve them\n- Zero context switching required from the user\n- Go fix failing tests without being told how\n\n## Task Management\n\n1. **Plan First**: Write plan to `tasks\u002Froadmap.md` (full plan) and `tasks\u002Ftodo.md` (current phase) with checkable items\n2. **Verify Plan**: Check in before starting implementation\n3. **Track Progress**: Mark items complete as you go\n4. **Explain Changes**: High-level summary at each step\n5. **Document Results**: Add review section to `tasks\u002Ftodo.md`\n6. **Capture Lessons**: Update `tasks\u002Flessons.md` after corrections\n\n## Core Principles\n- **Simplicity First**: Make every change as simple as possible. Impact minimal code.\n- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.\n- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.\n- **Direct-To-Primary Git Flow**: Default to committing and pushing sequential work on the repository primary branch (`main` when present, otherwise `master`). Do not introduce or continue feature-branch workflows unless the user explicitly asks for them, except for `agent-team` parallel write lanes, which must use separate GitHub branches and pass consolidation\u002FPR review before landing.\n- **Always Ship Mutations**: If a task creates or modifies tracked files, finish by committing and pushing all intended changes before stopping unless the user explicitly says not to. Do not leave a dirty tracked tree or unpushed commits behind.\n- **No GitHub Actions**: Do not create, modify, or suggest GitHub Actions workflows unless the user explicitly asks for GitHub Actions. This project does not use GitHub Actions for CI\u002FCD by default.\n\n## Windows\u002FWSL File Opening\n- On Windows machines running WSL, convert Linux paths before opening files from shell commands:\n\n```bash\nWIN_PATH=$(wslpath -w \"$FILE_PATH\")\ncmd.exe \u002Fc start \"\" \"$WIN_PATH\"\n```\n\n- For HTML files that should open in the Windows browser, prefer a WSL file URI through the Windows PowerShell binary when `cmd.exe \u002Fc start` or UNC paths fail:\n\n```bash\nDISTRO=${WSL_DISTRO_NAME:-Ubuntu}\nURI=\"file:\u002F\u002Fwsl.localhost\u002F${DISTRO}${FILE_PATH}\"\n\u002Fmnt\u002Fc\u002FWINDOWS\u002FSystem32\u002FWindowsPowerShell\u002Fv1.0\u002Fpowershell.exe -NoProfile -Command \"Start-Process '$URI'\"\n```\n\n- Use WSL detection so this path only runs inside WSL:\n\n```bash\nif grep -qi microsoft \u002Fproc\u002Fversion 2>\u002Fdev\u002Fnull; then\n  cmd.exe \u002Fc start \"\" \"$(wslpath -w \"$FILE_PATH\")\"\nfi\n```\n\n- The `cmd.exe` UNC warning (`UNC paths are not supported. Defaulting to Windows directory.`) is cosmetic; the file still opens correctly.\n- The `UtilBindVsockAnyPort: socket failed 1` failure can happen before Windows opens a UNC path. For browser-targeted HTML pages, retry with the `file:\u002F\u002Fwsl.localhost\u002F\u003Cdistro>\u002F...` PowerShell URI before using editor fallbacks.\n````\n\n5. **Conditionally add Monorepo Parallel-Work Safety:**\n\n   Detect whether the target repo is a monorepo by checking these heuristics (any match = monorepo):\n   1. `pnpm-workspace.yaml` exists at repo root\n   2. `package.json` at repo root has a `workspaces` field\n   3. `lerna.json` exists at repo root\n   4. A `packages\u002F` or `apps\u002F` directory exists at repo root with 2+ subdirectories that each contain a `package.json`\n\n   **If monorepo detected:** append the following section after `### 6. Autonomous Bug Fixing` and before `## Task Management` in both target files:\n\n   ```markdown\n   ### 7. Monorepo Parallel-Work Safety\n   - NEVER run `pnpm install`, `pnpm add`, `npm install`, `yarn add`, or any command that modifies a shared lockfile (`pnpm-lock.yaml`, `package-lock.json`, `yarn.lock`) when running as one of multiple parallel agents in a monorepo\n   - All dependency changes must be pre-staged in a single serial session before parallel work begins\n   - Parallel agents must only write files within their own package directory (e.g. `packages\u002F\u003Cname>\u002Fsrc\u002F`)\n   - Before launching parallel agents, verify their planned work scopes do not overlap on any shared files\n   - Parallel `agent-team` write lanes must use separate GitHub branches with deterministic names, push those branches, and return branch\u002Fcommit\u002FPR evidence for consolidation review\n   - If you need a new dependency mid-task, stop and request it be added centrally rather than running the package manager yourself\n   ```\n\n   **If not a monorepo:** ensure that `### 7. Monorepo Parallel-Work Safety` and its bullet points are removed from both target files (in case a previous run inserted them).\n\n## Output\n\nAfter updating the files, report:\n\n- Whether `.\u002FCLAUDE.md` and `.\u002FAGENTS.md` were created or modified, using repo-relative paths exactly like `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`\n- Where the block was inserted in each file\n- Whether the monorepo block was included or skipped (and which heuristic matched, if any)\n- Confirmation that the corresponding final block appears exactly once in each file\n- The source\u002Fverification note status for each target file when a note was written or updated\n- Never present benchmark harness temp paths such as `\u002Ftmp`, `\u002Fprivate\u002Fvar`, or `\u002Fvar\u002Ffolders` as the user-facing artifact location; convert them to repo-relative target paths.\n\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","# Install Workflow Orchestration\n\nInvoke as `$provision-agentic-config`.\n\nUse this skill when the user wants the repository's `CLAUDE.md` and `AGENTS.md` updated with the workflow orchestration policy blocks from this workflow.\n\n## Target\n\n- Current repository files: `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`\n\n## Workflow\n\n1. Ensure `.\u002FCLAUDE.md` and `.\u002FAGENTS.md` exist.\n2. Insert the Claude policy block below verbatim into `CLAUDE.md`.\n3. Insert the AGENTS policy block below verbatim into `AGENTS.md`.\n4. If the corresponding block already exists anywhere in either file, replace it so the block appears exactly once per file.\n5. Preserve any unrelated content already in `CLAUDE.md` and `AGENTS.md`.\n6. When a target file is newly created, or when it already has a provisioning\u002Fsource note from this skill, include or update a concise repo-relative note outside the inserted block:\n   - `CLAUDE.md`: `Provisioned artifact: .\u002FCLAUDE.md. Source: workflow.md. Verification: block appears exactly once.`\n   - `AGENTS.md`: `Provisioned artifact: .\u002FAGENTS.md. Source: workflow.md. Verification: block appears exactly once.`\n   - If `workflow.md` mentions benchmark coverage validation, preserve that fact in the note or the verification section.\n   - Do not add temp directory paths such as `\u002Ftmp`, `\u002Fprivate\u002Fvar`, or `\u002Fvar\u002Ffolders` to either target file.\n7. Each block begins with `\u003C!-- provision-agentic-config v0.2 -->`. When replacing an existing block, update this comment to the current version. The `\u002Fsync` skill uses this comment to detect stale provisioning.\n\n## Required Claude Block\n\n````md\n\u003C!-- provision-agentic-config v0.2 -->\n## Workflow Orchestration\n\n### 1. Plan Mode Default\n- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)\n- If something goes sideways, STOP and re-plan immediately - don't keep pushing\n- Verification is mandatory, but routine no-op verification runs inside the active execution\u002Fshipping step. Enter plan mode for non-trivial remediation or new work discovered by verification, not for validation that already has clear commands and no expected source changes.\n- Write detailed specs upfront to reduce ambiguity\n- In Codex: use `update_plan` in Default mode and `request_user_input` only when already in Plan mode\n- Do not assume a Claude-style clear-context-on-accept flow or related JSON setting exists\n\n### 2. Subagent Strategy\n- Use subagents liberally to keep main context window clean\n- Offload research, exploration, and parallel analysis to subagents\n- For complex problems, throw more compute at it via subagents\n- One task per subagent for focused execution\n- For `agent-team` parallel write lanes, require separate GitHub branches per lane and include a consolidation\u002FPR review step before final integration. This is the explicit exception to direct-to-primary work.\n\n### 3. Self-Improvement Loop\n- After ANY correction from the user: update `tasks\u002Flessons.md` with the pattern\n- Write rules for yourself that prevent the same mistake\n- Ruthlessly iterate on these lessons until mistake rate drops\n- Review lessons at session start for relevant project\n\n### 4. Verification Before Done\n- Never mark a task complete without proving it works\n- Diff your behavior between main and your changes when relevant\n- Ask yourself: \"Would a staff engineer approve this?\"\n- Run tests, check logs, demonstrate correctness\n\n### 5. Demand Elegance (Balanced)\n- For non-trivial changes: pause and ask \"is there a more elegant way?\"\n- If a fix feels hacky: \"Knowing everything I know now, implement the elegant solution\"\n- Skip this for simple, obvious fixes - don't over-engineer\n- Challenge your own work before presenting it\n\n### 6. Autonomous Bug Fixing\n- When given a bug report: just fix it. Don't ask for hand-holding\n- Point at logs, errors, failing tests - then resolve them\n- Zero context switching required from the user\n- Go fix failing tests without being told how\n\n## Task Management\n\n1. **Plan First**: Write plan to `tasks\u002Froadmap.md` (full plan) and `tasks\u002Ftodo.md` (current phase) with checkable items\n2. **Verify Plan**: Check in before starting implementation\n3. **Track Progress**: Mark items complete as you go\n4. **Explain Changes**: High-level summary at each step\n5. **Document Results**: Add review section to `tasks\u002Ftodo.md`\n6. **Capture Lessons**: Update `tasks\u002Flessons.md` after corrections\n\n## Core Principles\n- **Simplicity First**: Make every change as simple as possible. Impact minimal code.\n- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.\n- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.\n- **Direct-To-Primary Git Flow**: Default to committing and pushing sequential work on the repository primary branch (`main` when present, otherwise `master`). Do not introduce or continue feature-branch workflows unless the user explicitly asks for them, except for `agent-team` parallel write lanes, which must use separate GitHub branches and pass consolidation\u002FPR review before landing.\n- **Always Ship Mutations**: If a task creates or modifies tracked files, finish by committing and pushing all intended changes before stopping unless the user explicitly says not to. Do not leave a dirty tracked tree or unpushed commits behind.\n- **No GitHub Actions**: Do not create, modify, or suggest GitHub Actions workflows unless the user explicitly asks for GitHub Actions. This project does not use GitHub Actions for CI\u002FCD by default.\n\n## Windows\u002FWSL File Opening\n- On Windows machines running WSL, convert Linux paths before opening files from shell commands:\n\n```bash\nWIN_PATH=$(wslpath -w \"$FILE_PATH\")\ncmd.exe \u002Fc start \"\" \"$WIN_PATH\"\n```\n\n- For HTML files that should open in the Windows browser, prefer a WSL file URI through the Windows PowerShell binary when `cmd.exe \u002Fc start` or UNC paths fail:\n\n```bash\nDISTRO=${WSL_DISTRO_NAME:-Ubuntu}\nURI=\"file:\u002F\u002Fwsl.localhost\u002F${DISTRO}${FILE_PATH}\"\n\u002Fmnt\u002Fc\u002FWINDOWS\u002FSystem32\u002FWindowsPowerShell\u002Fv1.0\u002Fpowershell.exe -NoProfile -Command \"Start-Process '$URI'\"\n```\n\n- Use WSL detection so this path only runs inside WSL:\n\n```bash\nif grep -qi microsoft \u002Fproc\u002Fversion 2>\u002Fdev\u002Fnull; then\n  cmd.exe \u002Fc start \"\" \"$(wslpath -w \"$FILE_PATH\")\"\nfi\n```\n\n- The `cmd.exe` UNC warning (`UNC paths are not supported. Defaulting to Windows directory.`) is cosmetic; the file still opens correctly.\n- The `UtilBindVsockAnyPort: socket failed 1` failure can happen before Windows opens a UNC path. For browser-targeted HTML pages, retry with the `file:\u002F\u002Fwsl.localhost\u002F\u003Cdistro>\u002F...` PowerShell URI before using editor fallbacks.\n````\n\n## Required AGENTS Block\n\n````md\n\u003C!-- provision-agentic-config v0.2 -->\n## Workflow Orchestration\n\n### 1. Plan Mode Default\n- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)\n- If something goes sideways, STOP and re-plan immediately - don't keep pushing\n- Verification is mandatory, but routine no-op verification runs inside the active execution\u002Fshipping step. Enter plan mode for non-trivial remediation or new work discovered by verification, not for validation that already has clear commands and no expected source changes.\n- Write detailed specs upfront to reduce ambiguity\n- In Codex: use `update_plan` in Default mode and `request_user_input` only when already in Plan mode\n- Do not assume a Claude-style clear-context-on-accept flow or related JSON setting exists\n\n### 2. Subagent Strategy\n- Use subagents only when the active Codex tool instructions allow them.\n- When subagents are available and permitted, delegate independent research, exploration, or execution lanes with non-overlapping scopes.\n- One task per subagent for focused execution.\n- Do not override Codex's current subagent permission, tool availability, or parallel-work rules.\n- For `agent-team` parallel write lanes, require separate GitHub branches per lane and include a consolidation\u002FPR review step before final integration. This is the explicit exception to direct-to-primary work.\n\n### 3. Self-Improvement Loop\n- After ANY correction from the user: update `tasks\u002Flessons.md` with the pattern\n- Write rules for yourself that prevent the same mistake\n- Ruthlessly iterate on these lessons until mistake rate drops\n- Review lessons at session start for relevant project\n\n### 4. Verification Before Done\n- Never mark a task complete without proving it works\n- Diff your behavior between main and your changes when relevant\n- Ask yourself: \"Would a staff engineer approve this?\"\n- Run tests, check logs, demonstrate correctness\n\n### 5. Demand Elegance (Balanced)\n- For non-trivial changes: pause and ask \"is there a more elegant way?\"\n- If a fix feels hacky: \"Knowing everything I know now, implement the elegant solution\"\n- Skip this for simple, obvious fixes - don't over-engineer\n- Challenge your own work before presenting it\n\n### 6. Autonomous Bug Fixing\n- When given a bug report: just fix it. Don't ask for hand-holding\n- Point at logs, errors, failing tests - then resolve them\n- Zero context switching required from the user\n- Go fix failing tests without being told how\n\n## Task Management\n\n1. **Plan First**: Write plan to `tasks\u002Froadmap.md` (full plan) and `tasks\u002Ftodo.md` (current phase) with checkable items\n2. **Verify Plan**: Check in before starting implementation\n3. **Track Progress**: Mark items complete as you go\n4. **Explain Changes**: High-level summary at each step\n5. **Document Results**: Add review section to `tasks\u002Ftodo.md`\n6. **Capture Lessons**: Update `tasks\u002Flessons.md` after corrections\n\n## Core Principles\n- **Simplicity First**: Make every change as simple as possible. Impact minimal code.\n- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.\n- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.\n- **Direct-To-Primary Git Flow**: Default to committing and pushing sequential work on the repository primary branch (`main` when present, otherwise `master`). Do not introduce or continue feature-branch workflows unless the user explicitly asks for them, except for `agent-team` parallel write lanes, which must use separate GitHub branches and pass consolidation\u002FPR review before landing.\n- **Always Ship Mutations**: If a task creates or modifies tracked files, finish by committing and pushing all intended changes before stopping unless the user explicitly says not to. Do not leave a dirty tracked tree or unpushed commits behind.\n- **No GitHub Actions**: Do not create, modify, or suggest GitHub Actions workflows unless the user explicitly asks for GitHub Actions. This project does not use GitHub Actions for CI\u002FCD by default.\n\n## Windows\u002FWSL File Opening\n- On Windows machines running WSL, convert Linux paths before opening files from shell commands:\n\n```bash\nWIN_PATH=$(wslpath -w \"$FILE_PATH\")\ncmd.exe \u002Fc start \"\" \"$WIN_PATH\"\n```\n\n- For HTML files that should open in the Windows browser, prefer a WSL file URI through the Windows PowerShell binary when `cmd.exe \u002Fc start` or UNC paths fail:\n\n```bash\nDISTRO=${WSL_DISTRO_NAME:-Ubuntu}\nURI=\"file:\u002F\u002Fwsl.localhost\u002F${DISTRO}${FILE_PATH}\"\n\u002Fmnt\u002Fc\u002FWINDOWS\u002FSystem32\u002FWindowsPowerShell\u002Fv1.0\u002Fpowershell.exe -NoProfile -Command \"Start-Process '$URI'\"\n```\n\n- Use WSL detection so this path only runs inside WSL:\n\n```bash\nif grep -qi microsoft \u002Fproc\u002Fversion 2>\u002Fdev\u002Fnull; then\n  cmd.exe \u002Fc start \"\" \"$(wslpath -w \"$FILE_PATH\")\"\nfi\n```\n\n- The `cmd.exe` UNC warning (`UNC paths are not supported. Defaulting to Windows directory.`) is cosmetic; the file still opens correctly.\n- The `UtilBindVsockAnyPort: socket failed 1` failure can happen before Windows opens a UNC path. For browser-targeted HTML pages, retry with the `file:\u002F\u002Fwsl.localhost\u002F\u003Cdistro>\u002F...` PowerShell URI before using editor fallbacks.\n````\n\n5. **Conditionally add Monorepo Parallel-Work Safety:**\n\n   Detect whether the target repo is a monorepo by checking these heuristics (any match = monorepo):\n   1. `pnpm-workspace.yaml` exists at repo root\n   2. `package.json` at repo root has a `workspaces` field\n   3. `lerna.json` exists at repo root\n   4. A `packages\u002F` or `apps\u002F` directory exists at repo root with 2+ subdirectories that each contain a `package.json`\n\n   **If monorepo detected:** append the following section after `### 6. Autonomous Bug Fixing` and before `## Task Management` in both target files:\n\n   ```markdown\n   ### 7. Monorepo Parallel-Work Safety\n   - NEVER run `pnpm install`, `pnpm add`, `npm install`, `yarn add`, or any command that modifies a shared lockfile (`pnpm-lock.yaml`, `package-lock.json`, `yarn.lock`) when running as one of multiple parallel agents in a monorepo\n   - All dependency changes must be pre-staged in a single serial session before parallel work begins\n   - Parallel agents must only write files within their own package directory (e.g. `packages\u002F\u003Cname>\u002Fsrc\u002F`)\n   - Before launching parallel agents, verify their planned work scopes do not overlap on any shared files\n   - Parallel `agent-team` write lanes must use separate GitHub branches with deterministic names, push those branches, and return branch\u002Fcommit\u002FPR evidence for consolidation review\n   - If you need a new dependency mid-task, stop and request it be added centrally rather than running the package manager yourself\n   ```\n\n   **If not a monorepo:** ensure that `### 7. Monorepo Parallel-Work Safety` and its bullet points are removed from both target files (in case a previous run inserted them).\n\n## Output\n\nAfter updating the files, report:\n\n- Whether `.\u002FCLAUDE.md` and `.\u002FAGENTS.md` were created or modified, using repo-relative paths exactly like `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`\n- Where the block was inserted in each file\n- Whether the monorepo block was included or skipped (and which heuristic matched, if any)\n- Confirmation that the corresponding final block appears exactly once in each file\n- The source\u002Fverification note status for each target file when a note was written or updated\n- Never present benchmark harness temp paths such as `\u002Ftmp`, `\u002Fprivate\u002Fvar`, or `\u002Fvar\u002Ffolders` as the user-facing artifact location; convert them to repo-relative target paths.\n\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":31,"version":39,"description":7},"v0.2","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fbase\u002Fcodex\u002Fprovision-agentic-config\u002Farchive\u002Fv0.2",0,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills","https:\u002F\u002Fagentic-skills-blush.vercel.app","https:\u002F\u002Fgithub.com\u002FGeorgeQLe","georgeqle.com","George Le is a futurist and serial tech entrepreneur who wants to work toward a world where humanity is free from robotic tasks.","2026-11-10 04:07:24",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill provision-agentic-config",{"tool":56,"command":57},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill provision-agentic-config",{"tool":59,"command":60},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill provision-agentic-config","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fbase\u002Fcodex\u002Fprovision-agentic-config\u002Farchive\u002Fv0.2\u002FSKILL.md",true,[64],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Ftypes.md","REFERENCE","参考文档",1432,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FConsumptionCentral-for-Microsoft-Copilot\u002Fblob\u002Fmain\u002Ffabric-app\u002F.agents\u002Fskills\u002Ffabric-sdk\u002Freferences\u002Ftypes.md",[71,83,93,105,116,127],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":34},"01M6G0NJES15RJKZE6YZ0TSYGF","source-checkout-allowed","Valid source-checkout-only fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fsource-checkout-allowed\u002FSKILL.md",[],[78,79,80,81,30,82],"source checkout allowed","checkout","fixture","only","valid",{"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":34},"01M6G0NFZ3R1MNB1E3DVTM0WB7","deck-install-valid","Valid deck install fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fdeck-install\u002FSKILL.md",[],[90,91,92,82,80,30],"deck install valid","deck","install",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":34},"01M6G0ND3QZQC4MDZ9NVB97PT2","codex-pack-guard-valid","Valid Codex Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-pack-guard\u002FSKILL.md",[],[100,101,102,82,103,104,80,30],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":112,"publishedAt":34},"01M6G0NA9YB3NKGZKD3S96JMNB","codex-missing-skill-valid","Valid Codex missing skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-missing-skill-fallback\u002FSKILL.md",[111],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[113,114,82,103,30,115,80],"codex missing skill valid","missing","fallback",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":123,"publishedAt":34},"01M6G0N7PC0EKFD40ZWQAXSAQ9","codex-base-skill-fallback-valid","Valid Codex base skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-base-skill-fallback\u002FSKILL.md",[122],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[82,103,115,124,125,126,30,80],"base skill","codex base skill fallback valid","base",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":34},"01M6G0N4VRR2YKZQ6N3Y6S2BQA","claude-pack-guard-valid","Valid Claude Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fclaude-pack-guard\u002FSKILL.md",[],[82,102,101,134,104,30,80],"claude pack guard valid"]