[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D3J4PS0PCSC6WT2D8VCHBY":3,"skill-same:01M6D3J4PS0PCSC6WT2D8VCHBY":69},{"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":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6D3J4PS0PCSC6WT2D8VCHBY","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.16\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35],"agentic","config","provision agentic config","orchestration","workflow","workflow orchestration","page","v0","ops","alignment","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.16\nrequired_conventions: [alignment-page, afps-2.0]\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.17 -->`. When replacing an existing block, update this comment to the current provision block 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.17 -->\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 non-primary GitHub branches per lane and include a consolidation\u002FPR review step before final integration.\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   ### Revision Hygiene\n   - When applying user revision feedback, classify the request as add, remove, replace, reweight, or verify.\n   - For remove, replace, or reweight requests, update the artifact toward the requested final state.\n   - Do not add new warnings, caveats, labels, or future-agent instructions that repeat rejected framing unless the user explicitly asks to preserve that context.\n\n   ### AFPS 2.0\n   - Ordinary product, research, design, specification, implementation, and task work follows the managed AFPS 2.0 convention: source checkouts read `docs\u002Fafps-2.0-convention.md`; packaged consumers read `.agents\u002Fskillpacks\u002Fdocs\u002Fafps-2.0-convention.md`.\n   - Infer intent, produce the smallest decision-revealing slice, evaluate evidence, then continue, adapt, checkpoint, or permission-stop.\n   - Proceed through reversible work without implicit alignment\u002Finterrogation pages or approval-only sidecars. Use a chat-first checkpoint only for a material decision and ask at most three decisions.\n   - A checkpoint never grants authority for destructive, irreversible, public, paid, legal, privacy, security, account-authenticated, or otherwise externally consequential action; those remain explicit permission stops.\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>` only when `\u002Fskills` is visible in the active session; otherwise recommend `npx skillpacks init` from the project shell to install base skills, or use `npx skillpacks which \u003Cskill-name>` for a direct package lookup.\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   ### Shipping Contract Convention\n\n   When a skill says \"Follow the shared shipping contract convention\", apply these rules:\n\n   - **Default next-step routing:** when reporting completion, include either `Recommended next skill: \u003Ccommand>` or the two-line pair `**Next work:** \u003Cspecific task or \"none\">` and `**Recommended next command:** \u003Cone command or route>` so the next caller has a concrete handoff.\n   - If this skill creates or modifies tracked repository files, reuse or create one GitHub Issue, work on a non-primary branch, and publish or update one ready pull request without merging it.\n   - Do not leave tracked changes or unpushed commits behind. If unrelated tracked work is already present, either include it in sensible commits too or stop and explain the blocker.\n   - This contract does not override stricter safety rules about secrets, destructive history changes, release publication\u002Ftag confirmation, or production deploy confirmation.\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   **Research vs implementation loops.** The `tasks\u002Froadmap.md` + `tasks\u002Ftodo.md` task tracking above is for implementation work. Pattern A research orchestrators (e.g. `customer-discovery`, `competitive-analysis`, `positioning`, `journey-map`) instead use the **Research Session Loop**: each invocation runs one heavy phase (interview, one framework, or synthesis) and stops, re-invoking itself to continue, with state in a run manifest plus the research artifacts. See `docs\u002Fresearch-session-loop-convention.md`.\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   - **Issue-Backed GitHub Delivery**: Every tracked mutation uses one GitHub Issue, a non-primary branch, and a ready pull request when GitHub is available. Never push tracked mutations directly to the primary branch. Merge remains a separate explicit review action.\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.17 -->\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 non-primary GitHub branches per lane and include a consolidation\u002FPR review step before final integration.\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   ### Revision Hygiene\n   - When applying user revision feedback, classify the request as add, remove, replace, reweight, or verify.\n   - For remove, replace, or reweight requests, update the artifact toward the requested final state.\n   - Do not add new warnings, caveats, labels, or future-agent instructions that repeat rejected framing unless the user explicitly asks to preserve that context.\n\n   ### AFPS 2.0\n   - Ordinary product, research, design, specification, implementation, and task work follows the managed AFPS 2.0 convention: source checkouts read `docs\u002Fafps-2.0-convention.md`; packaged consumers read `.agents\u002Fskillpacks\u002Fdocs\u002Fafps-2.0-convention.md`.\n   - Infer intent, produce the smallest decision-revealing slice, evaluate evidence, then continue, adapt, checkpoint, or permission-stop.\n   - Proceed through reversible work without implicit alignment\u002Finterrogation pages or approval-only sidecars. Use a chat-first checkpoint only for a material decision and ask at most three decisions.\n   - A checkpoint never grants authority for destructive, irreversible, public, paid, legal, privacy, security, account-authenticated, or otherwise externally consequential action; those remain explicit permission stops.\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 `$skills` or `$skills search \u003Ckeyword>` only when `$skills` is visible in the active session; otherwise recommend `npx skillpacks init` from the project shell to install base skills, or use `npx skillpacks which \u003Cskill-name>` for a direct package lookup.\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   ### Shipping Contract Convention\n\n   When a skill says \"Follow the shared shipping contract convention\", apply these rules:\n\n   - **Default next-step routing:** when reporting completion, include either `Recommended next skill: \u003Ccommand>` or the two-line pair `**Next work:** \u003Cspecific task or \"none\">` and `**Recommended next command:** \u003Cone command or route>` so the next caller has a concrete handoff.\n   - If this skill creates or modifies tracked repository files, reuse or create one GitHub Issue, work on a non-primary branch, and publish or update one ready pull request without merging it.\n   - Do not leave tracked changes or unpushed commits behind. If unrelated tracked work is already present, either include it in sensible commits too or stop and explain the blocker.\n   - This contract does not override stricter safety rules about secrets, destructive history changes, release publication\u002Ftag confirmation, or production deploy confirmation.\n\n   ### Alignment Page Convention\n   - The alignment-page convention is shared through the packaged convention resolver: source checkouts load `docs\u002Falignment-page-convention.md`, packaged installs load `assets\u002Falignment-page-convention.md`, and older installed skills may fall back to a sibling `ALIGNMENT-PAGE.md` if present.\n   - It is authored canonically in `docs\u002Falignment-page-convention.md` (between the `alignment-convention` markers) and validated by `scripts\u002Fupgrade-alignment-page.mjs`. Edit the convention there and re-run the generator; legacy sibling bundles are regenerated only with `--legacy-bundles`.\n   - A skill's `## Alignment Page` section is a short stub that names the shared resolver and output path; 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\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   **Research vs implementation loops.** The `tasks\u002Froadmap.md` + `tasks\u002Ftodo.md` task tracking above is for implementation work. Pattern A research orchestrators (e.g. `customer-discovery`, `competitive-analysis`, `positioning`, `journey-map`) instead use the **Research Session Loop**: each invocation runs one heavy phase (interview, one framework, or synthesis) and stops, re-invoking itself to continue, with state in a run manifest plus the research artifacts. See `docs\u002Fresearch-session-loop-convention.md`.\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   - **Issue-Backed GitHub Delivery**: Every tracked mutation uses one GitHub Issue, a non-primary branch, and a ready pull request when GitHub is available. Never push tracked mutations directly to the primary branch. Merge remains a separate explicit review action.\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\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## Alignment Page\n\nFollow the shared alignment-page convention via the packaged convention resolver; output path is `alignment\u002Fprovision-agentic-config-{topic}.html`. By default, report results inline and write only this skill's normal durable artifacts; create an alignment page only when explicitly requested or when a concrete clarification\u002Freview need cannot be handled cleanly inline.\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.17 -->`. When replacing an existing block, update this comment to the current provision block 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.17 -->\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 non-primary GitHub branches per lane and include a consolidation\u002FPR review step before final integration.\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   ### Revision Hygiene\n   - When applying user revision feedback, classify the request as add, remove, replace, reweight, or verify.\n   - For remove, replace, or reweight requests, update the artifact toward the requested final state.\n   - Do not add new warnings, caveats, labels, or future-agent instructions that repeat rejected framing unless the user explicitly asks to preserve that context.\n\n   ### AFPS 2.0\n   - Ordinary product, research, design, specification, implementation, and task work follows the managed AFPS 2.0 convention: source checkouts read `docs\u002Fafps-2.0-convention.md`; packaged consumers read `.agents\u002Fskillpacks\u002Fdocs\u002Fafps-2.0-convention.md`.\n   - Infer intent, produce the smallest decision-revealing slice, evaluate evidence, then continue, adapt, checkpoint, or permission-stop.\n   - Proceed through reversible work without implicit alignment\u002Finterrogation pages or approval-only sidecars. Use a chat-first checkpoint only for a material decision and ask at most three decisions.\n   - A checkpoint never grants authority for destructive, irreversible, public, paid, legal, privacy, security, account-authenticated, or otherwise externally consequential action; those remain explicit permission stops.\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>` only when `\u002Fskills` is visible in the active session; otherwise recommend `npx skillpacks init` from the project shell to install base skills, or use `npx skillpacks which \u003Cskill-name>` for a direct package lookup.\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   ### Shipping Contract Convention\n\n   When a skill says \"Follow the shared shipping contract convention\", apply these rules:\n\n   - **Default next-step routing:** when reporting completion, include either `Recommended next skill: \u003Ccommand>` or the two-line pair `**Next work:** \u003Cspecific task or \"none\">` and `**Recommended next command:** \u003Cone command or route>` so the next caller has a concrete handoff.\n   - If this skill creates or modifies tracked repository files, reuse or create one GitHub Issue, work on a non-primary branch, and publish or update one ready pull request without merging it.\n   - Do not leave tracked changes or unpushed commits behind. If unrelated tracked work is already present, either include it in sensible commits too or stop and explain the blocker.\n   - This contract does not override stricter safety rules about secrets, destructive history changes, release publication\u002Ftag confirmation, or production deploy confirmation.\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   **Research vs implementation loops.** The `tasks\u002Froadmap.md` + `tasks\u002Ftodo.md` task tracking above is for implementation work. Pattern A research orchestrators (e.g. `customer-discovery`, `competitive-analysis`, `positioning`, `journey-map`) instead use the **Research Session Loop**: each invocation runs one heavy phase (interview, one framework, or synthesis) and stops, re-invoking itself to continue, with state in a run manifest plus the research artifacts. See `docs\u002Fresearch-session-loop-convention.md`.\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   - **Issue-Backed GitHub Delivery**: Every tracked mutation uses one GitHub Issue, a non-primary branch, and a ready pull request when GitHub is available. Never push tracked mutations directly to the primary branch. Merge remains a separate explicit review action.\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.17 -->\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 non-primary GitHub branches per lane and include a consolidation\u002FPR review step before final integration.\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   ### Revision Hygiene\n   - When applying user revision feedback, classify the request as add, remove, replace, reweight, or verify.\n   - For remove, replace, or reweight requests, update the artifact toward the requested final state.\n   - Do not add new warnings, caveats, labels, or future-agent instructions that repeat rejected framing unless the user explicitly asks to preserve that context.\n\n   ### AFPS 2.0\n   - Ordinary product, research, design, specification, implementation, and task work follows the managed AFPS 2.0 convention: source checkouts read `docs\u002Fafps-2.0-convention.md`; packaged consumers read `.agents\u002Fskillpacks\u002Fdocs\u002Fafps-2.0-convention.md`.\n   - Infer intent, produce the smallest decision-revealing slice, evaluate evidence, then continue, adapt, checkpoint, or permission-stop.\n   - Proceed through reversible work without implicit alignment\u002Finterrogation pages or approval-only sidecars. Use a chat-first checkpoint only for a material decision and ask at most three decisions.\n   - A checkpoint never grants authority for destructive, irreversible, public, paid, legal, privacy, security, account-authenticated, or otherwise externally consequential action; those remain explicit permission stops.\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 `$skills` or `$skills search \u003Ckeyword>` only when `$skills` is visible in the active session; otherwise recommend `npx skillpacks init` from the project shell to install base skills, or use `npx skillpacks which \u003Cskill-name>` for a direct package lookup.\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   ### Shipping Contract Convention\n\n   When a skill says \"Follow the shared shipping contract convention\", apply these rules:\n\n   - **Default next-step routing:** when reporting completion, include either `Recommended next skill: \u003Ccommand>` or the two-line pair `**Next work:** \u003Cspecific task or \"none\">` and `**Recommended next command:** \u003Cone command or route>` so the next caller has a concrete handoff.\n   - If this skill creates or modifies tracked repository files, reuse or create one GitHub Issue, work on a non-primary branch, and publish or update one ready pull request without merging it.\n   - Do not leave tracked changes or unpushed commits behind. If unrelated tracked work is already present, either include it in sensible commits too or stop and explain the blocker.\n   - This contract does not override stricter safety rules about secrets, destructive history changes, release publication\u002Ftag confirmation, or production deploy confirmation.\n\n   ### Alignment Page Convention\n   - The alignment-page convention is shared through the packaged convention resolver: source checkouts load `docs\u002Falignment-page-convention.md`, packaged installs load `assets\u002Falignment-page-convention.md`, and older installed skills may fall back to a sibling `ALIGNMENT-PAGE.md` if present.\n   - It is authored canonically in `docs\u002Falignment-page-convention.md` (between the `alignment-convention` markers) and validated by `scripts\u002Fupgrade-alignment-page.mjs`. Edit the convention there and re-run the generator; legacy sibling bundles are regenerated only with `--legacy-bundles`.\n   - A skill's `## Alignment Page` section is a short stub that names the shared resolver and output path; 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\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   **Research vs implementation loops.** The `tasks\u002Froadmap.md` + `tasks\u002Ftodo.md` task tracking above is for implementation work. Pattern A research orchestrators (e.g. `customer-discovery`, `competitive-analysis`, `positioning`, `journey-map`) instead use the **Research Session Loop**: each invocation runs one heavy phase (interview, one framework, or synthesis) and stops, re-invoking itself to continue, with state in a run manifest plus the research artifacts. See `docs\u002Fresearch-session-loop-convention.md`.\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   - **Issue-Backed GitHub Delivery**: Every tracked mutation uses one GitHub Issue, a non-primary branch, and a ready pull request when GitHub is available. Never push tracked mutations directly to the primary branch. Merge remains a separate explicit review action.\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\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## Alignment Page\n\nFollow the shared alignment-page convention via the packaged convention resolver; output path is `alignment\u002Fprovision-agentic-config-{topic}.html`. By default, report results inline and write only this skill's normal durable artifacts; create an alignment page only when explicitly requested or when a concrete clarification\u002Freview need cannot be handled cleanly inline.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":32,"version":41,"description":7,"argument-hint":6,"required_conventions":42},"v0.16",[43,44],"alignment-page","afps-2.0","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fbase\u002Fclaude\u002Fprovision-agentic-config\u002Farchive\u002Fv0.16",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":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill provision-agentic-config",{"tool":61,"command":62},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill provision-agentic-config",{"tool":64,"command":65},"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.16\u002FSKILL.md",true,[],[70,82,92,104,115,126],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":36},"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",[],[77,78,79,80,31,81],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":36},"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",[],[89,90,91,81,79,31],"deck install valid","deck","install",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":36},"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",[],[99,100,101,81,102,103,79,31],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":111,"publishedAt":36},"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",[110],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[112,113,81,102,31,114,79],"codex missing skill valid","missing","fallback",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":122,"publishedAt":36},"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",[121],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[81,102,114,123,124,125,31,79],"base skill","codex base skill fallback valid","base",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":36},"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",[],[81,101,100,133,103,31,79],"claude pack guard valid"]