[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D3JBNDT1YP310JHBV81ABK":3,"skill-same:01M6D3JBNDT1YP310JHBV81ABK":64},{"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},"01M6D3JBNDT1YP310JHBV81ABK","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\u002Fclaude\u002Fprovision-agentic-config\u002Farchive\u002Fv0.3\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.3\nargument-hint:\n---\n\n# Install Workflow Orchestration\n\nCreate or update the current repository's `CLAUDE.md` and `AGENTS.md` with workflow orchestration conventions.\n\n## Process\n\n1. **Check target files:**\n   - Ensure `.\u002FCLAUDE.md` exists. If not, create it.\n   - Ensure `.\u002FAGENTS.md` exists. If not, create it.\n\n2. **Insert the orchestration blocks:**\n   - Insert the Claude block below verbatim into `.\u002FCLAUDE.md`.\n   - Insert the AGENTS block below verbatim into `.\u002FAGENTS.md`.\n   - If the corresponding block already exists anywhere in either target file, replace it so it appears exactly once per file.\n   - Preserve any other existing content in `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`.\n   - 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.\n   - Each block begins with `\u003C!-- provision-agentic-config v0.3 -->`. When replacing an existing block, update this comment to the current version. The `\u002Fsync` skill uses this comment to detect stale provisioning.\n\n   The Claude block to insert into `.\u002FCLAUDE.md`:\n\n   ````markdown\n   \u003C!-- provision-agentic-config v0.3 -->\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   ### Missing Skill Fallback\n   - When a skill invocation fails because the skill is not found, run `scripts\u002Fpack.sh which \u003Cskill-name>` to check if the skill exists in an available pack.\n   - If found in an uninstalled pack, recommend `\u002Fpack install \u003Cpack>` and note that a new session is needed.\n   - If not found in any pack, suggest `\u002Fskills` or `\u002Fskills search \u003Ckeyword>`.\n\n   ## Task Management\n\n   1. **Plan First**: Write plan to `tasks\u002Froadmap.md` (full plan) and `tasks\u002Ftodo.md` (current phase) with checkable items\n   2. **Verify Plan**: Check in before starting implementation\n   3. **Track Progress**: Mark items complete as you go\n   4. **Explain Changes**: High-level summary at each step\n   5. **Document Results**: Add review section to `tasks\u002Ftodo.md`\n   6. **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. Exception (Claude only): `\u002Fexec` hands a dirty tracked tree to `\u002Fship`. After shipping, if `tasks\u002Ftodo.md` has remaining steps, run `\u002Fship` to handle planning and the approval cycle.\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\n   WIN_PATH=$(wslpath -w \"$FILE_PATH\")\n   cmd.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\n   DISTRO=${WSL_DISTRO_NAME:-Ubuntu}\n   URI=\"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\n   if grep -qi microsoft \u002Fproc\u002Fversion 2>\u002Fdev\u002Fnull; then\n     cmd.exe \u002Fc start \"\" \"$(wslpath -w \"$FILE_PATH\")\"\n   fi\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   The AGENTS block to insert into `.\u002FAGENTS.md`:\n\n   ````markdown\n   \u003C!-- provision-agentic-config v0.3 -->\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   ### Missing Skill Fallback\n   - When a skill invocation fails because the skill is not found, run `scripts\u002Fpack.sh which \u003Cskill-name>` to check if the skill exists in an available pack.\n   - If found in an uninstalled pack, recommend `\u002Fpack install \u003Cpack>` and note that a new session is needed.\n   - If not found in any pack, suggest `\u002Fskills` or `\u002Fskills search \u003Ckeyword>`.\n\n   ## Task Management\n\n   1. **Plan First**: Write plan to `tasks\u002Froadmap.md` (full plan) and `tasks\u002Ftodo.md` (current phase) with checkable items\n   2. **Verify Plan**: Check in before starting implementation\n   3. **Track Progress**: Mark items complete as you go\n   4. **Explain Changes**: High-level summary at each step\n   5. **Document Results**: Add review section to `tasks\u002Ftodo.md`\n   6. **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. Codex `$exec` ships by default (validates, commits, pushes, plans next) — use `$ship` only to package existing work or unpushed commits.\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\n   WIN_PATH=$(wslpath -w \"$FILE_PATH\")\n   cmd.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\n   DISTRO=${WSL_DISTRO_NAME:-Ubuntu}\n   URI=\"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\n   if grep -qi microsoft \u002Fproc\u002Fversion 2>\u002Fdev\u002Fnull; then\n     cmd.exe \u002Fc start \"\" \"$(wslpath -w \"$FILE_PATH\")\"\n   fi\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\n3. **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\n4. **Report result:**\n   - Print whether each target file was created or modified, using repo-relative paths exactly like `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`.\n   - Print where the block was inserted in each file (top\u002Fbottom\u002Fafter which heading).\n   - Print whether the monorepo block was included or skipped (and which heuristic matched, if any).\n   - Confirm that the final block appears exactly once in each target file.\n   - Print 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## Output Format\n\nDisplay confirmation directly to the user (the block itself is written to `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`):\n\n```\nInstalled workflow orchestration into .\u002FCLAUDE.md and .\u002FAGENTS.md\n- .\u002FCLAUDE.md: [created | updated], [top | bottom | after \"\u003Cheading>\"], block appears once\n- .\u002FAGENTS.md: [created | updated], [top | bottom | after \"\u003Cheading>\"], block appears once\n- Monorepo safety block: [included (matched: \u003Cheuristic>) | skipped (not a monorepo)]\n- Source\u002Fverification notes: [written | updated | preserved | skipped because existing unrelated content should not be changed]\n```\n\n## Constraints\n\n- Insert the block exactly once per target file — if it already exists, replace rather than duplicate.\n- Preserve all other existing content in `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`.\n- Do not modify any file other than `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`.\n\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","# Install Workflow Orchestration\n\nCreate or update the current repository's `CLAUDE.md` and `AGENTS.md` with workflow orchestration conventions.\n\n## Process\n\n1. **Check target files:**\n   - Ensure `.\u002FCLAUDE.md` exists. If not, create it.\n   - Ensure `.\u002FAGENTS.md` exists. If not, create it.\n\n2. **Insert the orchestration blocks:**\n   - Insert the Claude block below verbatim into `.\u002FCLAUDE.md`.\n   - Insert the AGENTS block below verbatim into `.\u002FAGENTS.md`.\n   - If the corresponding block already exists anywhere in either target file, replace it so it appears exactly once per file.\n   - Preserve any other existing content in `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`.\n   - 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.\n   - Each block begins with `\u003C!-- provision-agentic-config v0.3 -->`. When replacing an existing block, update this comment to the current version. The `\u002Fsync` skill uses this comment to detect stale provisioning.\n\n   The Claude block to insert into `.\u002FCLAUDE.md`:\n\n   ````markdown\n   \u003C!-- provision-agentic-config v0.3 -->\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   ### Missing Skill Fallback\n   - When a skill invocation fails because the skill is not found, run `scripts\u002Fpack.sh which \u003Cskill-name>` to check if the skill exists in an available pack.\n   - If found in an uninstalled pack, recommend `\u002Fpack install \u003Cpack>` and note that a new session is needed.\n   - If not found in any pack, suggest `\u002Fskills` or `\u002Fskills search \u003Ckeyword>`.\n\n   ## Task Management\n\n   1. **Plan First**: Write plan to `tasks\u002Froadmap.md` (full plan) and `tasks\u002Ftodo.md` (current phase) with checkable items\n   2. **Verify Plan**: Check in before starting implementation\n   3. **Track Progress**: Mark items complete as you go\n   4. **Explain Changes**: High-level summary at each step\n   5. **Document Results**: Add review section to `tasks\u002Ftodo.md`\n   6. **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. Exception (Claude only): `\u002Fexec` hands a dirty tracked tree to `\u002Fship`. After shipping, if `tasks\u002Ftodo.md` has remaining steps, run `\u002Fship` to handle planning and the approval cycle.\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\n   WIN_PATH=$(wslpath -w \"$FILE_PATH\")\n   cmd.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\n   DISTRO=${WSL_DISTRO_NAME:-Ubuntu}\n   URI=\"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\n   if grep -qi microsoft \u002Fproc\u002Fversion 2>\u002Fdev\u002Fnull; then\n     cmd.exe \u002Fc start \"\" \"$(wslpath -w \"$FILE_PATH\")\"\n   fi\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   The AGENTS block to insert into `.\u002FAGENTS.md`:\n\n   ````markdown\n   \u003C!-- provision-agentic-config v0.3 -->\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   ### Missing Skill Fallback\n   - When a skill invocation fails because the skill is not found, run `scripts\u002Fpack.sh which \u003Cskill-name>` to check if the skill exists in an available pack.\n   - If found in an uninstalled pack, recommend `\u002Fpack install \u003Cpack>` and note that a new session is needed.\n   - If not found in any pack, suggest `\u002Fskills` or `\u002Fskills search \u003Ckeyword>`.\n\n   ## Task Management\n\n   1. **Plan First**: Write plan to `tasks\u002Froadmap.md` (full plan) and `tasks\u002Ftodo.md` (current phase) with checkable items\n   2. **Verify Plan**: Check in before starting implementation\n   3. **Track Progress**: Mark items complete as you go\n   4. **Explain Changes**: High-level summary at each step\n   5. **Document Results**: Add review section to `tasks\u002Ftodo.md`\n   6. **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. Codex `$exec` ships by default (validates, commits, pushes, plans next) — use `$ship` only to package existing work or unpushed commits.\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\n   WIN_PATH=$(wslpath -w \"$FILE_PATH\")\n   cmd.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\n   DISTRO=${WSL_DISTRO_NAME:-Ubuntu}\n   URI=\"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\n   if grep -qi microsoft \u002Fproc\u002Fversion 2>\u002Fdev\u002Fnull; then\n     cmd.exe \u002Fc start \"\" \"$(wslpath -w \"$FILE_PATH\")\"\n   fi\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\n3. **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\n4. **Report result:**\n   - Print whether each target file was created or modified, using repo-relative paths exactly like `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`.\n   - Print where the block was inserted in each file (top\u002Fbottom\u002Fafter which heading).\n   - Print whether the monorepo block was included or skipped (and which heuristic matched, if any).\n   - Confirm that the final block appears exactly once in each target file.\n   - Print 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## Output Format\n\nDisplay confirmation directly to the user (the block itself is written to `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`):\n\n```\nInstalled workflow orchestration into .\u002FCLAUDE.md and .\u002FAGENTS.md\n- .\u002FCLAUDE.md: [created | updated], [top | bottom | after \"\u003Cheading>\"], block appears once\n- .\u002FAGENTS.md: [created | updated], [top | bottom | after \"\u003Cheading>\"], block appears once\n- Monorepo safety block: [included (matched: \u003Cheuristic>) | skipped (not a monorepo)]\n- Source\u002Fverification notes: [written | updated | preserved | skipped because existing unrelated content should not be changed]\n```\n\n## Constraints\n\n- Insert the block exactly once per target file — if it already exists, replace rather than duplicate.\n- Preserve all other existing content in `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`.\n- Do not modify any file other than `.\u002FCLAUDE.md` and `.\u002FAGENTS.md`.\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,"argument-hint":6},"v0.3","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fbase\u002Fclaude\u002Fprovision-agentic-config\u002Farchive\u002Fv0.3",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\u002Fclaude\u002Fprovision-agentic-config\u002Farchive\u002Fv0.3\u002FSKILL.md",true,[],[65,77,87,99,110,121],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"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",[],[72,73,74,75,30,76],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"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",[],[84,85,86,76,74,30],"deck install valid","deck","install",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"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",[],[94,95,96,76,97,98,74,30],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":106,"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",[105],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[107,108,76,97,30,109,74],"codex missing skill valid","missing","fallback",{"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":117,"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",[116],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[76,97,109,118,119,120,30,74],"base skill","codex base skill fallback valid","base",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"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",[],[76,96,95,128,98,30,74],"claude pack guard valid"]