[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D3ZDFVDK4M2SZSD76VV9TP":3,"skill-same:01M6D3ZDFVDK4M2SZSD76VV9TP":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},"01M6D3ZDFVDK4M2SZSD76VV9TP","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.8\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.8\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## Process\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.8 -->`. 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.8 -->\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\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 `npx skillpacks install \u003Cpack-or-skill>` from the project shell for either the skill or the full pack, and note the post-install reload path: Claude Code `\u002Freload-skills` first, `\u002Fclear` can pick up the refreshed registry, restart if the top-level `.claude\u002Fskills` directory did not exist at session start or the skill is still invisible; Codex should start a fresh Codex CLI session if the `$` skill list remains stale.\n- If found in an installed pack, suggest the same reload path to pick up the local skill roots.\n- If not found in any pack, suggest `\u002Fskills` or `\u002Fskills search \u003Ckeyword>`.\n\n### Project Pack Command Resolution\n- If a user invokes a command-like skill such as `\u002Fbenchmark-test-skill design-system` and the leading command is not in the injected session skill list, search project-local packs before falling back to the trailing argument as the active skill.\n- Check `packs\u002F*\u002Fclaude\u002F\u003Ccommand>\u002FSKILL.md` and pack metadata such as `packs\u002F*\u002FPACK.md`; project-local pack skills may exist in this repository even when they are not visible in the active session list.\n- In this repository, `\u002Fbenchmark-test-skill` lives under `packs\u002Fagentic-skills-bench\u002Fclaude\u002Fbenchmark-test-skill\u002FSKILL.md`, and `design-system` is its target skill argument.\n\n### Prompt History\n- On every skill invocation, before substantive work, create `prompts\u002F\u003Cskill-slug>\u002F` if it does not exist.\n- Write the exact visible user invocation message and any directly attached or pasted visible context to `prompts\u002F\u003Cskill-slug>\u002Fskill-prompt-YYYYMMDD-HHMMSS-\u003Cshort-topic>.md`.\n- Include YAML frontmatter with `skill`, `agent` (`claude` or `codex`), `captured_at`, `source`, and `prompt_scope: visible-user-invocation`.\n- Use `source: user-invocation` unless a more specific visible source label is needed.\n- Treat prompt history files as tracked repo artifacts by default; commit them with the work unless the user explicitly asks for local-only logs.\n- Capture only visible user invocation content; hidden system\u002Fdeveloper instructions and unavailable model context are out of scope.\n- Do not summarize, redact, or truncate the prompt log. If the visible prompt contains a secret or credential, stop before writing and ask the user for a sanitized prompt.\n\n### Skill Versioning\n- Every SKILL.md must include a `version:` field in its YAML frontmatter\n- New skills start at `version: v0.0`\n- Bump the decimal (e.g. `v0.0` → `v0.1`) for non-refactor changes — adjustments, tweaks, behavioral updates\n- Refactors or full overhauls of a skill do NOT bump the version; only substantive behavior\u002Foutput changes do\n- When bumping a version, archive the current SKILL.md to `archive\u002F\u003Cold-version>\u002FSKILL.md` in the same commit\n- Maintain a `CHANGELOG.md` in the skill directory listing what changed for each version\n- Use `scripts\u002Fskill-archive.sh \u003Cskill-dir>` to automate the archive step before bumping\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.8 -->\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\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- If a user invokes a command-like skill such as `$benchmark-test-skill design-system` and the leading command is not in the injected session skill list, search project-local packs before falling back to the trailing argument as the active skill.\n- Check `packs\u002F*\u002Fcodex\u002F*\u002FSKILL.md` and pack metadata such as `packs\u002F*\u002FPACK.md`; project-local pack skills may exist in this repository even when they are not visible in the active session list.\n- For any missing skill, run `scripts\u002Fpack.sh which \u003Cskill-name>` to locate the providing pack. If found in an uninstalled pack, recommend `npx skillpacks install \u003Cpack-or-skill>` from the project shell for either the skill or the full pack, and note the post-install reload path: Claude Code `\u002Freload-skills` first, `\u002Fclear` can pick up the refreshed registry, restart if the top-level `.claude\u002Fskills` directory did not exist at session start or the skill is still invisible; Codex should start a fresh Codex CLI session if the `$` skill list remains stale. If found in an installed pack, suggest the same reload path. If not found in any pack, suggest `$skills` or `$skills search \u003Ckeyword>`.\n\n### Prompt History\n- On every skill invocation, before substantive work, create `prompts\u002F\u003Cskill-slug>\u002F` if it does not exist.\n- Write the exact visible user invocation message and any directly attached or pasted visible context to `prompts\u002F\u003Cskill-slug>\u002Fskill-prompt-YYYYMMDD-HHMMSS-\u003Cshort-topic>.md`.\n- Include YAML frontmatter with `skill`, `agent` (`claude` or `codex`), `captured_at`, `source`, and `prompt_scope: visible-user-invocation`.\n- Use `source: user-invocation` unless a more specific visible source label is needed.\n- Treat prompt history files as tracked repo artifacts by default; commit them with the work unless the user explicitly asks for local-only logs.\n- Capture only visible user invocation content; hidden system\u002Fdeveloper instructions and unavailable model context are out of scope.\n- Do not summarize, redact, or truncate the prompt log. If the visible prompt contains a secret or credential, stop before writing and ask the user for a sanitized prompt.\n\n### Skill Versioning\n- Every SKILL.md must include a `version:` field in its YAML frontmatter\n- New skills start at `version: v0.0`\n- Bump the decimal (e.g. `v0.0` → `v0.1`) for non-refactor changes — adjustments, tweaks, behavioral updates\n- Refactors or full overhauls of a skill do NOT bump the version; only substantive behavior\u002Foutput changes do\n- When bumping a version, archive the current SKILL.md to `archive\u002F\u003Cold-version>\u002FSKILL.md` in the same commit\n- Maintain a `CHANGELOG.md` in the skill directory listing what changed for each version\n- Use `scripts\u002Fskill-archive.sh \u003Cskill-dir>` to automate the archive step before bumping\n\n### Alignment Page Convention\n- The alignment-page convention is **bundled per-skill** as `ALIGNMENT-PAGE.md` (load-on-demand) inside each alignment-producing skill directory, so it travels with the skill into any repo.\n- It is authored canonically in `docs\u002Falignment-page-convention.md` (between the `alignment-convention` markers) and propagated by `scripts\u002Fupgrade-alignment-page.mjs`. Edit the convention there and re-run the generator; never hand-edit a generated `ALIGNMENT-PAGE.md`.\n- A skill's `## Alignment Page` section is a short stub that points at the sibling `ALIGNMENT-PAGE.md`; codex bundled files use the same content as claude.\n- Direct edits to active `alignment\u002F*.html` pages made without invoking a skill must pass `node scripts\u002Faudit-alignment-pages.mjs` (exit 0) before commit. TTS-include diagnostics route to `node scripts\u002Finject-tts.mjs`; all other diagnostics are manual fixes. Archived pages under `docs\u002Fhistory\u002Farchive\u002F` are out of scope.\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## Alignment Page\n\nBy default, this skill reports results inline and writes only its normal durable artifacts (for example `tasks\u002F*.md`, reports, queues, benchmark notes, status docs, or other skill-specific files). Do not build an alignment page automatically. Create `alignment\u002Fprovision-agentic-config-{topic}.html` only when the user explicitly requests an alignment page or when you explicitly identify a concrete clarification\u002Freview need that cannot be handled cleanly inline; when you create one, follow `ALIGNMENT-PAGE.md` in this skill's directory.\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## Process\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.8 -->`. 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.8 -->\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\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 `npx skillpacks install \u003Cpack-or-skill>` from the project shell for either the skill or the full pack, and note the post-install reload path: Claude Code `\u002Freload-skills` first, `\u002Fclear` can pick up the refreshed registry, restart if the top-level `.claude\u002Fskills` directory did not exist at session start or the skill is still invisible; Codex should start a fresh Codex CLI session if the `$` skill list remains stale.\n- If found in an installed pack, suggest the same reload path to pick up the local skill roots.\n- If not found in any pack, suggest `\u002Fskills` or `\u002Fskills search \u003Ckeyword>`.\n\n### Project Pack Command Resolution\n- If a user invokes a command-like skill such as `\u002Fbenchmark-test-skill design-system` and the leading command is not in the injected session skill list, search project-local packs before falling back to the trailing argument as the active skill.\n- Check `packs\u002F*\u002Fclaude\u002F\u003Ccommand>\u002FSKILL.md` and pack metadata such as `packs\u002F*\u002FPACK.md`; project-local pack skills may exist in this repository even when they are not visible in the active session list.\n- In this repository, `\u002Fbenchmark-test-skill` lives under `packs\u002Fagentic-skills-bench\u002Fclaude\u002Fbenchmark-test-skill\u002FSKILL.md`, and `design-system` is its target skill argument.\n\n### Prompt History\n- On every skill invocation, before substantive work, create `prompts\u002F\u003Cskill-slug>\u002F` if it does not exist.\n- Write the exact visible user invocation message and any directly attached or pasted visible context to `prompts\u002F\u003Cskill-slug>\u002Fskill-prompt-YYYYMMDD-HHMMSS-\u003Cshort-topic>.md`.\n- Include YAML frontmatter with `skill`, `agent` (`claude` or `codex`), `captured_at`, `source`, and `prompt_scope: visible-user-invocation`.\n- Use `source: user-invocation` unless a more specific visible source label is needed.\n- Treat prompt history files as tracked repo artifacts by default; commit them with the work unless the user explicitly asks for local-only logs.\n- Capture only visible user invocation content; hidden system\u002Fdeveloper instructions and unavailable model context are out of scope.\n- Do not summarize, redact, or truncate the prompt log. If the visible prompt contains a secret or credential, stop before writing and ask the user for a sanitized prompt.\n\n### Skill Versioning\n- Every SKILL.md must include a `version:` field in its YAML frontmatter\n- New skills start at `version: v0.0`\n- Bump the decimal (e.g. `v0.0` → `v0.1`) for non-refactor changes — adjustments, tweaks, behavioral updates\n- Refactors or full overhauls of a skill do NOT bump the version; only substantive behavior\u002Foutput changes do\n- When bumping a version, archive the current SKILL.md to `archive\u002F\u003Cold-version>\u002FSKILL.md` in the same commit\n- Maintain a `CHANGELOG.md` in the skill directory listing what changed for each version\n- Use `scripts\u002Fskill-archive.sh \u003Cskill-dir>` to automate the archive step before bumping\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.8 -->\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\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- If a user invokes a command-like skill such as `$benchmark-test-skill design-system` and the leading command is not in the injected session skill list, search project-local packs before falling back to the trailing argument as the active skill.\n- Check `packs\u002F*\u002Fcodex\u002F*\u002FSKILL.md` and pack metadata such as `packs\u002F*\u002FPACK.md`; project-local pack skills may exist in this repository even when they are not visible in the active session list.\n- For any missing skill, run `scripts\u002Fpack.sh which \u003Cskill-name>` to locate the providing pack. If found in an uninstalled pack, recommend `npx skillpacks install \u003Cpack-or-skill>` from the project shell for either the skill or the full pack, and note the post-install reload path: Claude Code `\u002Freload-skills` first, `\u002Fclear` can pick up the refreshed registry, restart if the top-level `.claude\u002Fskills` directory did not exist at session start or the skill is still invisible; Codex should start a fresh Codex CLI session if the `$` skill list remains stale. If found in an installed pack, suggest the same reload path. If not found in any pack, suggest `$skills` or `$skills search \u003Ckeyword>`.\n\n### Prompt History\n- On every skill invocation, before substantive work, create `prompts\u002F\u003Cskill-slug>\u002F` if it does not exist.\n- Write the exact visible user invocation message and any directly attached or pasted visible context to `prompts\u002F\u003Cskill-slug>\u002Fskill-prompt-YYYYMMDD-HHMMSS-\u003Cshort-topic>.md`.\n- Include YAML frontmatter with `skill`, `agent` (`claude` or `codex`), `captured_at`, `source`, and `prompt_scope: visible-user-invocation`.\n- Use `source: user-invocation` unless a more specific visible source label is needed.\n- Treat prompt history files as tracked repo artifacts by default; commit them with the work unless the user explicitly asks for local-only logs.\n- Capture only visible user invocation content; hidden system\u002Fdeveloper instructions and unavailable model context are out of scope.\n- Do not summarize, redact, or truncate the prompt log. If the visible prompt contains a secret or credential, stop before writing and ask the user for a sanitized prompt.\n\n### Skill Versioning\n- Every SKILL.md must include a `version:` field in its YAML frontmatter\n- New skills start at `version: v0.0`\n- Bump the decimal (e.g. `v0.0` → `v0.1`) for non-refactor changes — adjustments, tweaks, behavioral updates\n- Refactors or full overhauls of a skill do NOT bump the version; only substantive behavior\u002Foutput changes do\n- When bumping a version, archive the current SKILL.md to `archive\u002F\u003Cold-version>\u002FSKILL.md` in the same commit\n- Maintain a `CHANGELOG.md` in the skill directory listing what changed for each version\n- Use `scripts\u002Fskill-archive.sh \u003Cskill-dir>` to automate the archive step before bumping\n\n### Alignment Page Convention\n- The alignment-page convention is **bundled per-skill** as `ALIGNMENT-PAGE.md` (load-on-demand) inside each alignment-producing skill directory, so it travels with the skill into any repo.\n- It is authored canonically in `docs\u002Falignment-page-convention.md` (between the `alignment-convention` markers) and propagated by `scripts\u002Fupgrade-alignment-page.mjs`. Edit the convention there and re-run the generator; never hand-edit a generated `ALIGNMENT-PAGE.md`.\n- A skill's `## Alignment Page` section is a short stub that points at the sibling `ALIGNMENT-PAGE.md`; codex bundled files use the same content as claude.\n- Direct edits to active `alignment\u002F*.html` pages made without invoking a skill must pass `node scripts\u002Faudit-alignment-pages.mjs` (exit 0) before commit. TTS-include diagnostics route to `node scripts\u002Finject-tts.mjs`; all other diagnostics are manual fixes. Archived pages under `docs\u002Fhistory\u002Farchive\u002F` are out of scope.\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## Alignment Page\n\nBy default, this skill reports results inline and writes only its normal durable artifacts (for example `tasks\u002F*.md`, reports, queues, benchmark notes, status docs, or other skill-specific files). Do not build an alignment page automatically. Create `alignment\u002Fprovision-agentic-config-{topic}.html` only when the user explicitly requests an alignment page or when you explicitly identify a concrete clarification\u002Freview need that cannot be handled cleanly inline; when you create one, follow `ALIGNMENT-PAGE.md` in this skill's directory.\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.8","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fbase\u002Fcodex\u002Fprovision-agentic-config\u002Farchive\u002Fv0.8",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.8\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"]