skillpacks 0.1.0 → 0.1.1

package/global/codex/pack/SKILL.md

@@ -2,7 +2,7 @@
 name: pack
 description: Manage project-local skill packs, individual pack skill roots, and project designation without installing domain skills globally
 type: ops
-version: v0.6
+version: v0.7
 argument-hint: "[list|status|recommend|install <pack-or-skill>|remove <pack-or-skill>|refresh|which <skill>] or no args for guided setup"
 ---
 
@@ -27,13 +27,13 @@ Use this skill when the user wants to inspect, recommend, install, remove, or re
      - Present a concise recommendation with evidence.
      - Present a plain-text **Pack Decision Checkpoint**: show 2-4 numbered choices, mark the recommended choice, explain the tradeoff for each, and ask the user to reply with a number, exact pack list, `status`, or `cancel`.
      - Stop after the checkpoint. Do not install anything until the user explicitly confirms a choice in a later message.
-     - After the user confirms, run `scripts/pack.sh install <pack...>`.
+     - After the user confirms, run the source-checkout helper `scripts/pack.sh install <pack...>`. For package consumers outside this checkout, the equivalent project-shell route is `npx skillpacks install <pack...>`.
    - If `.agents/project.json` exists but `refresh` fails, report the failure and the exact command the user can retry.
 3. Run the matching helper command from this skill library's bundled launcher for explicit commands:
    - `scripts/pack.sh list`
    - `scripts/pack.sh status`
    - `scripts/pack.sh recommend`
-   - `scripts/pack.sh install <pack-or-skill>`
+   - `scripts/pack.sh install <pack-or-skill>` (source checkout) or `npx skillpacks install <pack-or-skill>` (published package from the project shell)
    - `scripts/pack.sh remove <pack-or-skill>`
    - `scripts/pack.sh refresh`
    - `scripts/pack.sh which <skill>`
@@ -58,7 +58,7 @@ Use this skill when the user wants to inspect, recommend, install, remove, or re
 - Pack installs use repo-managed skill roots that point back to this skill-library repository and exclude archived skill snapshots by default.
 - The bundled launcher resolves copied managed installs through `.agentic-skills-managed` provenance before delegating to the repository-level pack manager.
 - `scripts/pack.sh install`, `remove`, `refresh`, and `set-mode` preserve existing `project_scopes` and `notes` fields when `jq` is available.
-- `scripts/pack.sh install <name>` treats `<name>` as a pack first, then as an individual skill provided by a pack.
+- `scripts/pack.sh install <name>` treats `<name>` as a pack first, then as an individual skill provided by a pack. Package consumers use `npx skillpacks install <name>` for the same pack-or-skill resolution from the project shell.
 - Pack writes use `.agents/.pack.lock` with owner metadata (`pid`, `started_at`, `command`); if a recorded owner process is gone, the next pack command removes that stale lock automatically.
 - `scripts/pack.sh refresh` recreates project-local skill roots from `.agents/project.json`; it does not by itself force an active CLI skill registry to reload.
 - Claude Code watches skill files under existing `.claude/skills` roots and supports `/reload-skills` to rescan skills and commands during a session. If a newly installed skill is not visible, run `/reload-skills`; `/clear` starts a new empty-context conversation and can also pick up the refreshed registry. Restart Claude Code if the top-level `.claude/skills` directory did not exist when the session started or the skill is still invisible.
@@ -68,8 +68,8 @@ Use this skill when the user wants to inspect, recommend, install, remove, or re
 
 When a name passed to `install` or `remove` does not match a pack, the system checks whether it matches a skill inside any pack. If it does, only that single skill root is installed, not the entire pack.
 
-- `$pack install design-system` installs only the `design-system` skill from `product-design`, not the whole pack.
-- `$pack install code-review customer-discovery` installs the `code-review` pack plus the individual `customer-discovery` skill.
+- `$pack install design-system` inside Codex, or `npx skillpacks install design-system` from the project shell, installs only the `design-system` skill from `product-design`, not the whole pack.
+- `$pack install code-review customer-discovery` inside Codex, or `npx skillpacks install code-review customer-discovery` from the project shell, installs the `code-review` pack plus the individual `customer-discovery` skill.
 - `$pack remove customer-discovery` removes only the `customer-discovery` skill root and its `enabled_skills` entry.
 - `$pack which design-system` shows the source pack and whether the skill is installed.
 
@@ -156,7 +156,7 @@ Reply with a number or an exact pack list to install.
 When a user invokes a skill that is not found in the current session:
 
 1. Run `scripts/pack.sh which <skill-name>` to check if the skill exists in any pack.
-2. If found in an uninstalled pack: tell the user which pack provides the skill, recommend `$pack install <skill>` for just that skill or `$pack install <pack>` for the full pack, and note the post-install reload path: Claude Code `/reload-skills` first, `/clear` or restart if needed; Codex fresh session if the `$` list stays stale.
+2. If found in an uninstalled pack: tell the user which pack provides the skill, recommend `$pack install <skill>` for just that skill, `$pack install <pack>` for the full pack, or `npx skillpacks install <pack-or-skill>` from the project shell, and note the post-install reload path: Claude Code `/reload-skills` first, `/clear` or restart if needed; Codex fresh session if the `$` list stays stale.
 3. If found in an installed pack: the skill should already be available, so suggest the same reload path to pick up the local skill roots.
 4. If not found in any pack: suggest `$skills` to browse available skills or `$skills search <keyword>` to search.
 

package/global/codex/pack/archive/v0.6/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: pack
+description: Manage project-local skill packs, individual pack skill roots, and project designation without installing domain skills globally
+type: ops
+version: v0.6
+argument-hint: "[list|status|recommend|install <pack-or-skill>|remove <pack-or-skill>|refresh|which <skill>] or no args for guided setup"
+---
+
+# Pack
+
+Invoke as `$pack`.
+
+Use this skill when the user wants to inspect, recommend, install, remove, or refresh project-local skill packs or individual skills from those packs.
+
+## Process
+
+1. Parse `$ARGUMENTS`.
+   - Treat commas as separators.
+   - Treat `business` as `business-app`.
+   - Ignore filler words such as `pack` or `packs`.
+2. If no arguments were provided, run guided setup:
+   - If `.agents/project.json` exists, run `scripts/pack.sh refresh` to recreate local pack skill roots from committed project state, then report the project type, enabled packs, and installed skills.
+   - If `.agents/project.json` is missing, inspect the repository before asking the user:
+     - Run `scripts/pack.sh recommend`.
+     - Check top-level files and directories, package manifests, app/framework configs, source layout, docs, existing `research/`, `specs/`, and `tasks/` files.
+     - Classify likely packs using the pack selection rules below.
+     - Present a concise recommendation with evidence.
+     - Present a plain-text **Pack Decision Checkpoint**: show 2-4 numbered choices, mark the recommended choice, explain the tradeoff for each, and ask the user to reply with a number, exact pack list, `status`, or `cancel`.
+     - Stop after the checkpoint. Do not install anything until the user explicitly confirms a choice in a later message.
+     - After the user confirms, run `scripts/pack.sh install <pack...>`.
+   - If `.agents/project.json` exists but `refresh` fails, report the failure and the exact command the user can retry.
+3. Run the matching helper command from this skill library's bundled launcher for explicit commands:
+   - `scripts/pack.sh list`
+   - `scripts/pack.sh status`
+   - `scripts/pack.sh recommend`
+   - `scripts/pack.sh install <pack-or-skill>`
+   - `scripts/pack.sh remove <pack-or-skill>`
+   - `scripts/pack.sh refresh`
+   - `scripts/pack.sh which <skill>`
+   The launcher is intentionally located at `scripts/pack.sh` under this skill directory and forwards to the repository-level pack manager.
+4. For `install`, `remove`, `refresh`, and guided setup installs, report:
+   - `.agents/project.json` project type and enabled packs
+   - any `enabled_skills` entries when present, including the skill name and source pack
+   - any `project_scopes` entries when present, including the path, `project_type`, packs, and purpose
+   - local skill roots created or removed under `.claude/skills` and `.codex/skills`
+   - any skipped roots caused by non-repo-managed targets
+   - shipping guidance: `.agents/project.json` is the committed project designation and should be committed when pack configuration changed; `.claude/skills/**` and `.codex/skills/**` are generated local skill roots recreated by `/pack`, `$pack`, or `scripts/pack.sh refresh`, and generated skill roots must not be staged or committed
+   - skill-visibility reload guidance: Claude Code watches existing `.claude/skills` roots and supports `/reload-skills`; `/clear` starts a new conversation and can pick up the refreshed registry, while a full restart remains the fallback if the top-level skills directory did not exist at session start or the skill remains invisible. Codex users should start a fresh Codex CLI session if the active session does not show the changed skills.
+
+## Pack Model
+
+- Global skills are domain-neutral and initialized by `init.sh`.
+- Domain workflows live in project-local packs.
+- Project designation is stored in `.agents/project.json`.
+- `.agents/project.json` is the committed project designation. `.claude/skills/**` and `.codex/skills/**` are generated local skill roots and must not be staged or committed; recreate them with `/pack`, `$pack`, or `scripts/pack.sh refresh`.
+- Mixed monorepos may keep a coarse default `project_type` and add `project_scopes` entries for subtrees that need different domain routing.
+- `enabled_packs` is the union of packs available to the repository; `project_scopes[].packs` explains which packs are appropriate for a specific path or glob.
+- Pack installs use repo-managed skill roots that point back to this skill-library repository and exclude archived skill snapshots by default.
+- The bundled launcher resolves copied managed installs through `.agentic-skills-managed` provenance before delegating to the repository-level pack manager.
+- `scripts/pack.sh install`, `remove`, `refresh`, and `set-mode` preserve existing `project_scopes` and `notes` fields when `jq` is available.
+- `scripts/pack.sh install <name>` treats `<name>` as a pack first, then as an individual skill provided by a pack.
+- Pack writes use `.agents/.pack.lock` with owner metadata (`pid`, `started_at`, `command`); if a recorded owner process is gone, the next pack command removes that stale lock automatically.
+- `scripts/pack.sh refresh` recreates project-local skill roots from `.agents/project.json`; it does not by itself force an active CLI skill registry to reload.
+- Claude Code watches skill files under existing `.claude/skills` roots and supports `/reload-skills` to rescan skills and commands during a session. If a newly installed skill is not visible, run `/reload-skills`; `/clear` starts a new empty-context conversation and can also pick up the refreshed registry. Restart Claude Code if the top-level `.claude/skills` directory did not exist when the session started or the skill is still invisible.
+- Codex may keep the `$` skill list loaded from session start. This pack workflow has no supported in-session Codex CLI skill refresh command, so start a fresh Codex CLI session if changed skills are not visible.
+
+## Individual Skill Installation
+
+When a name passed to `install` or `remove` does not match a pack, the system checks whether it matches a skill inside any pack. If it does, only that single skill root is installed, not the entire pack.
+
+- `$pack install design-system` installs only the `design-system` skill from `product-design`, not the whole pack.
+- `$pack install code-review customer-discovery` installs the `code-review` pack plus the individual `customer-discovery` skill.
+- `$pack remove customer-discovery` removes only the `customer-discovery` skill root and its `enabled_skills` entry.
+- `$pack which design-system` shows the source pack and whether the skill is installed.
+
+Individual skills are tracked in `enabled_skills` in `.agents/project.json`:
+
+```json
+{
+  "enabled_skills": {"customer-discovery": "business-discovery", "positioning": "business-discovery"}
+}
+```
+
+The `{skill: pack}` format tracks provenance so `refresh` knows where to rebuild from. When a name matches both a pack and a skill, the pack takes precedence.
+
+## Pack Selection
+
+- Use `business-discovery`, `customer-lifecycle`, `business-growth`, or `business-ops` for SaaS, marketplaces, productivity apps, internal/admin tools, business workflows, and enterprise applications. `business-app` is a compatibility alias for all four.
+- Use `creator-foundation`, `youtube-ops`, and `remotion` separately for creator-media work; `creator-media` is a compatibility alias for foundation plus YouTube operations.
+- Use `project-fleet` for control repositories that manage downstream repos, spec-store portfolios, or spin-offs.
+- Use `code-quality` as an additive pack for behavior-preserving refactors, type hygiene, import honesty, dependency-boundary cleanup, and module organization.
+- Use `alignment-loop` for lightweight operator-agent calibration before committing to a full spec-interview pipeline.
+- Use `game` for video games, prototypes, playable entertainment, game engines, store pages, playtest loops, and game assets.
+- Use `devtool` for SDKs, CLIs, APIs, libraries, infrastructure products, developer platforms, and documentation-first developer workflows.
+- PoketoWork kanban packs (`business-app-kanban`, `devtool-kanban`, `game-kanban`, and `poketowork-kanban`) are hibernated while Poketo.work is being rebuilt. Do not recommend or install kanban packs until they are reactivated.
+- Treat `monorepo` and `code-quality` as overlays. Pair overlays with a domain pack unless the user explicitly wants only the overlay behavior.
+- For workflow ordering, lead-in recommendations, and overlay dependencies, read `docs/pack-workflow-matrix.md`.
+
+## Mixed Monorepos
+
+Use one repo-level `.agents/project.json` with a primary default plus scoped overrides:
+
+```json
+{
+  "project_type": "devtool",
+  "enabled_packs": ["devtool", "business-discovery", "customer-lifecycle", "business-growth"],
+  "skill_pack_version": 1,
+  "project_scopes": [
+    {
+      "path": "apps/pitwall-local",
+      "project_type": "devtool",
+      "packs": ["devtool"],
+      "purpose": "Pitwall Local / OSS developer utility work."
+    },
+    {
+      "path": "apps/pitwall-calcllm",
+      "project_type": "business-app",
+      "packs": ["business-discovery", "customer-lifecycle", "business-growth"],
+      "purpose": "CalcLLM-powered connected edition research, GTM, monetization, and SaaS product work."
+    },
+    {
+      "path": "packages/calcllm-sync",
+      "project_type": "business-app",
+      "packs": ["business-discovery", "customer-lifecycle", "business-growth"],
+      "purpose": "Connected-edition sync and SaaS integration work."
+    }
+  ]
+}
+```
+
+When a task clearly names a scoped path, route to that scope's `project_type` and packs. When no scope matches, use the top-level `project_type` as the default.
+
+## Pack Decision Checkpoint
+
+Use this format when Codex needs user confirmation and `request_user_input` is unavailable:
+
+```
+## Pack Decision Checkpoint
+
+Detected:
+- [evidence]
+
+Recommendation: `<pack>` because [reason].
+
+Choose one:
+1. `<pack>` (Recommended) — [impact/tradeoff]
+2. `<alternate-pack>` — [impact/tradeoff]
+3. `<pack> <matching-kanban-pack>` — [impact/tradeoff]
+4. `cancel` — leave the project unconfigured
+
+Reply with a number or an exact pack list to install.
+```
+
+## Missing Skill Resolution
+
+When a user invokes a skill that is not found in the current session:
+
+1. Run `scripts/pack.sh which <skill-name>` to check if the skill exists in any pack.
+2. If found in an uninstalled pack: tell the user which pack provides the skill, recommend `$pack install <skill>` for just that skill or `$pack install <pack>` for the full pack, and note the post-install reload path: Claude Code `/reload-skills` first, `/clear` or restart if needed; Codex fresh session if the `$` list stays stale.
+3. If found in an installed pack: the skill should already be available, so suggest the same reload path to pick up the local skill roots.
+4. If not found in any pack: suggest `$skills` to browse available skills or `$skills search <keyword>` to search.
+
+## Constraints
+
+- Never install `packs/*` into `~/.claude/skills` or `~/.codex/skills`.
+- Do not overwrite real directories or files in `.claude/skills` or `.codex/skills`; skip them with a warning.
+- If local skill discovery is not available in the active assistant, treat `pack` as the launcher and read the project-local pack files directly.
+- Do not create `.agents/project.json` without user confirmation during guided setup.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/global/codex/provision-agentic-config/CHANGELOG.md

@@ -1,5 +1,9 @@
 # provision-agentic-config Changelog
 
+## v0.6 - 2026-06-11
+
+- Updated generated missing-skill fallback blocks to include `npx skillpacks install <pack-or-skill>` alongside runner-specific pack install routes.
+
 ## v0.5
 
 - Tightened generated missing-skill fallback guidance to recommend runner-specific pack install commands and post-install reload paths: Claude Code `/reload-skills`, `/clear`, then restart fallback; Codex fresh session when `$` discovery remains stale.

package/global/codex/provision-agentic-config/SKILL.md

@@ -2,7 +2,7 @@
 name: provision-agentic-config
 description: Provision workflow orchestration and agent conventions into project CLAUDE.md and AGENTS.md
 type: ops
-version: v0.5
+version: v0.6
 ---
 
 # Install Workflow Orchestration
@@ -27,12 +27,12 @@ Use this skill when the user wants the repository's `CLAUDE.md` and `AGENTS.md`
    - `AGENTS.md`: `Provisioned artifact: ./AGENTS.md. Source: workflow.md. Verification: block appears exactly once.`
    - If `workflow.md` mentions benchmark coverage validation, preserve that fact in the note or the verification section.
    - Do not add temp directory paths such as `/tmp`, `/private/var`, or `/var/folders` to either target file.
-7. Each block begins with `<!-- provision-agentic-config v0.5 -->`. When replacing an existing block, update this comment to the current version. The `/sync` skill uses this comment to detect stale provisioning.
+7. Each block begins with `<!-- provision-agentic-config v0.6 -->`. When replacing an existing block, update this comment to the current version. The `/sync` skill uses this comment to detect stale provisioning.
 
 ## Required Claude Block
 
 ````md
-<!-- provision-agentic-config v0.5 -->
+<!-- provision-agentic-config v0.6 -->
 ## Workflow Orchestration
 
 ### 1. Plan Mode Default
@@ -41,7 +41,6 @@ Use this skill when the user wants the repository's `CLAUDE.md` and `AGENTS.md`
 - Verification is mandatory, but routine no-op verification runs inside the active execution/shipping 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.
 - Write detailed specs upfront to reduce ambiguity
 - In Codex: use `update_plan` in Default mode and `request_user_input` only when already in Plan mode
-- Do not assume a Claude-style clear-context-on-accept flow or related JSON setting exists
 
 ### 2. Subagent Strategy
 - Use subagents liberally to keep main context window clean
@@ -76,7 +75,7 @@ Use this skill when the user wants the repository's `CLAUDE.md` and `AGENTS.md`
 
 ### Missing Skill Fallback
 - When a skill invocation fails because the skill is not found, run `scripts/pack.sh which <skill-name>` to check if the skill exists in an available pack.
-- If found in an uninstalled pack, recommend `/pack install <skill>` for just that skill or `/pack install <pack>` for the full pack, and note the post-install reload path: Claude Code `/reload-skills` first, `/clear` can pick up the refreshed registry, restart if the top-level `.claude/skills` 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 uninstalled pack, recommend `/pack install <skill>` for just that skill, `/pack install <pack>` for the full pack, or `npx skillpacks install <pack-or-skill>` from the project shell, and note the post-install reload path: Claude Code `/reload-skills` first, `/clear` can pick up the refreshed registry, restart if the top-level `.claude/skills` 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 to pick up the local skill roots.
 - If not found in any pack, suggest `/skills` or `/skills search <keyword>`.
 
@@ -142,7 +141,7 @@ fi
 ## Required AGENTS Block
 
 ````md
-<!-- provision-agentic-config v0.5 -->
+<!-- provision-agentic-config v0.6 -->
 ## Workflow Orchestration
 
 ### 1. Plan Mode Default
@@ -151,7 +150,6 @@ fi
 - Verification is mandatory, but routine no-op verification runs inside the active execution/shipping 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.
 - Write detailed specs upfront to reduce ambiguity
 - In Codex: use `update_plan` in Default mode and `request_user_input` only when already in Plan mode
-- Do not assume a Claude-style clear-context-on-accept flow or related JSON setting exists
 
 ### 2. Subagent Strategy
 - Use subagents only when the active Codex tool instructions allow them.
@@ -187,7 +185,7 @@ fi
 ### Missing Skill Fallback
 - 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.
 - Check `packs/*/codex/*/SKILL.md` and pack metadata such as `packs/*/PACK.md`; project-local pack skills may exist in this repository even when they are not visible in the active session list.
-- For any missing skill, run `scripts/pack.sh which <skill-name>` to locate the providing pack. If found in an uninstalled pack, recommend `$pack install <skill>` for just that skill or `$pack install <pack>` for the full pack, and note the post-install reload path: Claude Code `/reload-skills` first, `/clear` can pick up the refreshed registry, restart if the top-level `.claude/skills` 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 <keyword>`.
+- For any missing skill, run `scripts/pack.sh which <skill-name>` to locate the providing pack. If found in an uninstalled pack, recommend `$pack install <skill>` for just that skill, `$pack install <pack>` for the full pack, or `npx skillpacks install <pack-or-skill>` from the project shell, and note the post-install reload path: Claude Code `/reload-skills` first, `/clear` can pick up the refreshed registry, restart if the top-level `.claude/skills` 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 <keyword>`.
 
 ### Prompt History
 - On every skill invocation, before substantive work, create `prompts/<skill-slug>/` if it does not exist.

package/global/codex/provision-agentic-config/archive/v0.5/SKILL.md

@@ -0,0 +1,282 @@
+---
+name: provision-agentic-config
+description: Provision workflow orchestration and agent conventions into project CLAUDE.md and AGENTS.md
+type: ops
+version: v0.5
+---
+
+# Install Workflow Orchestration
+
+Invoke as `$provision-agentic-config`.
+
+Use this skill when the user wants the repository's `CLAUDE.md` and `AGENTS.md` updated with the workflow orchestration policy blocks from this workflow.
+
+## Target
+
+- Current repository files: `./CLAUDE.md` and `./AGENTS.md`
+
+## Process
+
+1. Ensure `./CLAUDE.md` and `./AGENTS.md` exist.
+2. Insert the Claude policy block below verbatim into `CLAUDE.md`.
+3. Insert the AGENTS policy block below verbatim into `AGENTS.md`.
+4. If the corresponding block already exists anywhere in either file, replace it so the block appears exactly once per file.
+5. Preserve any unrelated content already in `CLAUDE.md` and `AGENTS.md`.
+6. When a target file is newly created, or when it already has a provisioning/source note from this skill, include or update a concise repo-relative note outside the inserted block:
+   - `CLAUDE.md`: `Provisioned artifact: ./CLAUDE.md. Source: workflow.md. Verification: block appears exactly once.`
+   - `AGENTS.md`: `Provisioned artifact: ./AGENTS.md. Source: workflow.md. Verification: block appears exactly once.`
+   - If `workflow.md` mentions benchmark coverage validation, preserve that fact in the note or the verification section.
+   - Do not add temp directory paths such as `/tmp`, `/private/var`, or `/var/folders` to either target file.
+7. Each block begins with `<!-- provision-agentic-config v0.5 -->`. When replacing an existing block, update this comment to the current version. The `/sync` skill uses this comment to detect stale provisioning.
+
+## Required Claude Block
+
+````md
+<!-- provision-agentic-config v0.5 -->
+## Workflow Orchestration
+
+### 1. Plan Mode Default
+- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
+- If something goes sideways, STOP and re-plan immediately - don't keep pushing
+- Verification is mandatory, but routine no-op verification runs inside the active execution/shipping 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.
+- Write detailed specs upfront to reduce ambiguity
+- In Codex: use `update_plan` in Default mode and `request_user_input` only when already in Plan mode
+- Do not assume a Claude-style clear-context-on-accept flow or related JSON setting exists
+
+### 2. Subagent Strategy
+- Use subagents liberally to keep main context window clean
+- Offload research, exploration, and parallel analysis to subagents
+- For complex problems, throw more compute at it via subagents
+- One task per subagent for focused execution
+- For `agent-team` parallel write lanes, require separate GitHub branches per lane and include a consolidation/PR review step before final integration. This is the explicit exception to direct-to-primary work.
+
+### 3. Self-Improvement Loop
+- After ANY correction from the user: update `tasks/lessons.md` with the pattern
+- Write rules for yourself that prevent the same mistake
+- Ruthlessly iterate on these lessons until mistake rate drops
+- Review lessons at session start for relevant project
+
+### 4. Verification Before Done
+- Never mark a task complete without proving it works
+- Diff your behavior between main and your changes when relevant
+- Ask yourself: "Would a staff engineer approve this?"
+- Run tests, check logs, demonstrate correctness
+
+### 5. Demand Elegance (Balanced)
+- For non-trivial changes: pause and ask "is there a more elegant way?"
+- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
+- Skip this for simple, obvious fixes - don't over-engineer
+- Challenge your own work before presenting it
+
+### 6. Autonomous Bug Fixing
+- When given a bug report: just fix it. Don't ask for hand-holding
+- Point at logs, errors, failing tests - then resolve them
+- Zero context switching required from the user
+- Go fix failing tests without being told how
+
+### Missing Skill Fallback
+- When a skill invocation fails because the skill is not found, run `scripts/pack.sh which <skill-name>` to check if the skill exists in an available pack.
+- If found in an uninstalled pack, recommend `/pack install <skill>` for just that skill or `/pack install <pack>` for the full pack, and note the post-install reload path: Claude Code `/reload-skills` first, `/clear` can pick up the refreshed registry, restart if the top-level `.claude/skills` 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 to pick up the local skill roots.
+- If not found in any pack, suggest `/skills` or `/skills search <keyword>`.
+
+### Project Pack Command Resolution
+- 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.
+- Check `packs/*/claude/<command>/SKILL.md` and pack metadata such as `packs/*/PACK.md`; project-local pack skills may exist in this repository even when they are not visible in the active session list.
+- In this repository, `/benchmark-test-skill` lives under `packs/agentic-skills-bench/claude/benchmark-test-skill/SKILL.md`, and `design-system` is its target skill argument.
+
+### Prompt History
+- On every skill invocation, before substantive work, create `prompts/<skill-slug>/` if it does not exist.
+- Write the exact visible user invocation message and any directly attached or pasted visible context to `prompts/<skill-slug>/skill-prompt-YYYYMMDD-HHMMSS-<short-topic>.md`.
+- Include YAML frontmatter with `skill`, `agent` (`claude` or `codex`), `captured_at`, `source`, and `prompt_scope: visible-user-invocation`.
+- Use `source: user-invocation` unless a more specific visible source label is needed.
+- Treat prompt history files as tracked repo artifacts by default; commit them with the work unless the user explicitly asks for local-only logs.
+- Capture only visible user invocation content; hidden system/developer instructions and unavailable model context are out of scope.
+- 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.
+
+## Task Management
+
+1. **Plan First**: Write plan to `tasks/roadmap.md` (full plan) and `tasks/todo.md` (current phase) with checkable items
+2. **Verify Plan**: Check in before starting implementation
+3. **Track Progress**: Mark items complete as you go
+4. **Explain Changes**: High-level summary at each step
+5. **Document Results**: Add review section to `tasks/todo.md`
+6. **Capture Lessons**: Update `tasks/lessons.md` after corrections
+
+## Core Principles
+- **Simplicity First**: Make every change as simple as possible. Impact minimal code.
+- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.
+- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.
+- **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/PR review before landing.
+- **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.
+- **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/CD by default.
+
+## Windows/WSL File Opening
+- On Windows machines running WSL, convert Linux paths before opening files from shell commands:
+
+```bash
+WIN_PATH=$(wslpath -w "$FILE_PATH")
+cmd.exe /c start "" "$WIN_PATH"
+```
+
+- For HTML files that should open in the Windows browser, prefer a WSL file URI through the Windows PowerShell binary when `cmd.exe /c start` or UNC paths fail:
+
+```bash
+DISTRO=${WSL_DISTRO_NAME:-Ubuntu}
+URI="file://wsl.localhost/${DISTRO}${FILE_PATH}"
+/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/powershell.exe -NoProfile -Command "Start-Process '$URI'"
+```
+
+- Use WSL detection so this path only runs inside WSL:
+
+```bash
+if grep -qi microsoft /proc/version 2>/dev/null; then
+  cmd.exe /c start "" "$(wslpath -w "$FILE_PATH")"
+fi
+```
+
+- The `cmd.exe` UNC warning (`UNC paths are not supported. Defaulting to Windows directory.`) is cosmetic; the file still opens correctly.
+- The `UtilBindVsockAnyPort: socket failed 1` failure can happen before Windows opens a UNC path. For browser-targeted HTML pages, retry with the `file://wsl.localhost/<distro>/...` PowerShell URI before using editor fallbacks.
+````
+
+## Required AGENTS Block
+
+````md
+<!-- provision-agentic-config v0.5 -->
+## Workflow Orchestration
+
+### 1. Plan Mode Default
+- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
+- If something goes sideways, STOP and re-plan immediately - don't keep pushing
+- Verification is mandatory, but routine no-op verification runs inside the active execution/shipping 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.
+- Write detailed specs upfront to reduce ambiguity
+- In Codex: use `update_plan` in Default mode and `request_user_input` only when already in Plan mode
+- Do not assume a Claude-style clear-context-on-accept flow or related JSON setting exists
+
+### 2. Subagent Strategy
+- Use subagents only when the active Codex tool instructions allow them.
+- When subagents are available and permitted, delegate independent research, exploration, or execution lanes with non-overlapping scopes.
+- One task per subagent for focused execution.
+- Do not override Codex's current subagent permission, tool availability, or parallel-work rules.
+- For `agent-team` parallel write lanes, require separate GitHub branches per lane and include a consolidation/PR review step before final integration. This is the explicit exception to direct-to-primary work.
+
+### 3. Self-Improvement Loop
+- After ANY correction from the user: update `tasks/lessons.md` with the pattern
+- Write rules for yourself that prevent the same mistake
+- Ruthlessly iterate on these lessons until mistake rate drops
+- Review lessons at session start for relevant project
+
+### 4. Verification Before Done
+- Never mark a task complete without proving it works
+- Diff your behavior between main and your changes when relevant
+- Ask yourself: "Would a staff engineer approve this?"
+- Run tests, check logs, demonstrate correctness
+
+### 5. Demand Elegance (Balanced)
+- For non-trivial changes: pause and ask "is there a more elegant way?"
+- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
+- Skip this for simple, obvious fixes - don't over-engineer
+- Challenge your own work before presenting it
+
+### 6. Autonomous Bug Fixing
+- When given a bug report: just fix it. Don't ask for hand-holding
+- Point at logs, errors, failing tests - then resolve them
+- Zero context switching required from the user
+- Go fix failing tests without being told how
+
+### Missing Skill Fallback
+- 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.
+- Check `packs/*/codex/*/SKILL.md` and pack metadata such as `packs/*/PACK.md`; project-local pack skills may exist in this repository even when they are not visible in the active session list.
+- For any missing skill, run `scripts/pack.sh which <skill-name>` to locate the providing pack. If found in an uninstalled pack, recommend `$pack install <skill>` for just that skill or `$pack install <pack>` for the full pack, and note the post-install reload path: Claude Code `/reload-skills` first, `/clear` can pick up the refreshed registry, restart if the top-level `.claude/skills` 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 <keyword>`.
+
+### Prompt History
+- On every skill invocation, before substantive work, create `prompts/<skill-slug>/` if it does not exist.
+- Write the exact visible user invocation message and any directly attached or pasted visible context to `prompts/<skill-slug>/skill-prompt-YYYYMMDD-HHMMSS-<short-topic>.md`.
+- Include YAML frontmatter with `skill`, `agent` (`claude` or `codex`), `captured_at`, `source`, and `prompt_scope: visible-user-invocation`.
+- Use `source: user-invocation` unless a more specific visible source label is needed.
+- Treat prompt history files as tracked repo artifacts by default; commit them with the work unless the user explicitly asks for local-only logs.
+- Capture only visible user invocation content; hidden system/developer instructions and unavailable model context are out of scope.
+- 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.
+
+## Task Management
+
+1. **Plan First**: Write plan to `tasks/roadmap.md` (full plan) and `tasks/todo.md` (current phase) with checkable items
+2. **Verify Plan**: Check in before starting implementation
+3. **Track Progress**: Mark items complete as you go
+4. **Explain Changes**: High-level summary at each step
+5. **Document Results**: Add review section to `tasks/todo.md`
+6. **Capture Lessons**: Update `tasks/lessons.md` after corrections
+
+## Core Principles
+- **Simplicity First**: Make every change as simple as possible. Impact minimal code.
+- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.
+- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.
+- **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/PR review before landing.
+- **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.
+- **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/CD by default.
+
+## Windows/WSL File Opening
+- On Windows machines running WSL, convert Linux paths before opening files from shell commands:
+
+```bash
+WIN_PATH=$(wslpath -w "$FILE_PATH")
+cmd.exe /c start "" "$WIN_PATH"
+```
+
+- For HTML files that should open in the Windows browser, prefer a WSL file URI through the Windows PowerShell binary when `cmd.exe /c start` or UNC paths fail:
+
+```bash
+DISTRO=${WSL_DISTRO_NAME:-Ubuntu}
+URI="file://wsl.localhost/${DISTRO}${FILE_PATH}"
+/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/powershell.exe -NoProfile -Command "Start-Process '$URI'"
+```
+
+- Use WSL detection so this path only runs inside WSL:
+
+```bash
+if grep -qi microsoft /proc/version 2>/dev/null; then
+  cmd.exe /c start "" "$(wslpath -w "$FILE_PATH")"
+fi
+```
+
+- The `cmd.exe` UNC warning (`UNC paths are not supported. Defaulting to Windows directory.`) is cosmetic; the file still opens correctly.
+- The `UtilBindVsockAnyPort: socket failed 1` failure can happen before Windows opens a UNC path. For browser-targeted HTML pages, retry with the `file://wsl.localhost/<distro>/...` PowerShell URI before using editor fallbacks.
+````
+
+5. **Conditionally add Monorepo Parallel-Work Safety:**
+
+   Detect whether the target repo is a monorepo by checking these heuristics (any match = monorepo):
+   1. `pnpm-workspace.yaml` exists at repo root
+   2. `package.json` at repo root has a `workspaces` field
+   3. `lerna.json` exists at repo root
+   4. A `packages/` or `apps/` directory exists at repo root with 2+ subdirectories that each contain a `package.json`
+
+   **If monorepo detected:** append the following section after `### 6. Autonomous Bug Fixing` and before `## Task Management` in both target files:
+
+   ```markdown
+   ### 7. Monorepo Parallel-Work Safety
+   - 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
+   - All dependency changes must be pre-staged in a single serial session before parallel work begins
+   - Parallel agents must only write files within their own package directory (e.g. `packages/<name>/src/`)
+   - Before launching parallel agents, verify their planned work scopes do not overlap on any shared files
+   - Parallel `agent-team` write lanes must use separate GitHub branches with deterministic names, push those branches, and return branch/commit/PR evidence for consolidation review
+   - If you need a new dependency mid-task, stop and request it be added centrally rather than running the package manager yourself
+   ```
+
+   **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).
+
+## Output
+
+After updating the files, report:
+
+- Whether `./CLAUDE.md` and `./AGENTS.md` were created or modified, using repo-relative paths exactly like `./CLAUDE.md` and `./AGENTS.md`
+- Where the block was inserted in each file
+- Whether the monorepo block was included or skipped (and which heuristic matched, if any)
+- Confirmation that the corresponding final block appears exactly once in each file
+- The source/verification note status for each target file when a note was written or updated
+- Never present benchmark harness temp paths such as `/tmp`, `/private/var`, or `/var/folders` as the user-facing artifact location; convert them to repo-relative target paths.
+
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/global/codex/skills/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## v0.6 - 2026-06-11
+
+- Added npm-aware install-route alternatives to available-but-not-installed skill guidance while preserving Codex `$pack install` routes.
+
 ## v0.5
 
 - Updated the Discovery & Market Fit catalog examples to list `customer-discovery` as the standard business-discovery route while preserving `enterprise-icp`.

package/global/codex/skills/SKILL.md

@@ -2,7 +2,7 @@
 name: skills
 description: Browse and search all available skills, grouped by workflow stage or activity type
 type: ops
-version: v0.5
+version: v0.6
 argument-hint: "[list | types | search <keyword>]"
 ---
 
@@ -35,7 +35,7 @@ Discover and search installed global skills plus enabled project-local pack skil
 
    | Stage | Skills |
    |-------|--------|
-   | Pack Management | `pack`, `pack list`, `pack status`, `pack recommend`, `pack install <pack-or-skill>`, `pack remove <pack-or-skill>`, `pack which <skill>` |
+   | Pack Management | `pack`, `pack list`, `pack status`, `pack recommend`, `pack install <pack-or-skill>` (or project shell: `npx skillpacks install <pack-or-skill>`), `pack remove <pack-or-skill>`, `pack which <skill>` |
    | Discovery & Market Fit | `customer-discovery`, `enterprise-icp` |
    | Game Development | `game-workflow`, `game-audience`, `game-fantasy`, `game-genre-map`, `game-comparables`, `game-core-loop`, `game-prototype-test`, `game-store-page-test`, `game-playtest-metrics`, `game-roadmap`, `game-launch` |
    | Devtool Development | `devtool-workflow`, `devtool-user-map`, `devtool-integration-map`, `devtool-dx-journey`, `devtool-adoption`, `devtool-positioning`, `devtool-monetization`, `devtool-docs-audit` |
@@ -83,7 +83,7 @@ Discover and search installed global skills plus enabled project-local pack skil
    - Under each heading, list installed/global primary and chained skills as `$<name> — <description>  [type]`.
    - Show orchestrator skills with an `⚙` prefix: `⚙ $<name> — <description>  [type]`.
    - Show sub-skills indented under their parent skill (identified by the `parent:` frontmatter field or by living under a `frameworks/` directory). Format: `  ↳ $<name> — <description>  [sub-skill]`. If the parent is not in the same group, place sub-skills in a "Sub-skills" subsection at the end of the parent's group.
-   - For available-but-not-installed pack skills, list as `$<name> — <description>  [type]  ⚠ requires \`$pack install <skill>\` or \`$pack install <pack>\``.
+   - For available-but-not-installed pack skills, list as `$<name> — <description>  [type]  ⚠ requires \`$pack install <skill>\` or \`$pack install <pack>\` inside Codex, or \`npx skillpacks install <pack-or-skill>\` from the project shell`.
    - Omit groups that have no skills (after filtering in search mode).
    - At the bottom, print a total count: `**N skills** installed (M sub-skills), **P skills** available via packs` (or `**N skills** matching "<keyword>"`).