@glexcorp/gskp 0.1.1 → 0.1.2

package/packs/gitops/codex/sync/archive/v0.4/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: sync
+description: Pull latest changes from remote and report status
+type: shipping
+version: v0.4
+---
+
+# Sync
+
+Invoke as `$sync`.
+
+Pull the latest changes from the remote repository and report status.
+
+## Process
+
+1. Check current state:
+   - Run `git status` to check for uncommitted changes.
+   - If there are uncommitted changes, stash them first, pull, then pop the stash. Warn the user about the stash.
+2. Pull from remote:
+   - Run `git pull --rebase origin <current-branch>`.
+   - If rebase conflicts occur, abort the rebase, try `git pull --no-rebase` instead, and report any merge conflicts for the user to resolve.
+3. Check for outstanding work:
+   - Check if `tasks/roadmap.md` exists for the full plan, and `tasks/todo.md` for the current phase.
+   - If `tasks/todo.md` exists, read it and look for unchecked items (`- [ ]`).
+   - If there are incomplete items, summarise: which phase is current, what the next step is, and how many steps/phases remain.
+   - If `tasks/manual-todo.md` exists, count unchecked manual tasks and include in the summary.
+   - If `tasks/record-todo.md` or `tasks/recurring-todo.md` exists, count unchecked advisory items and include those counts separately. Do not treat them as active plan steps.
+   - If all items are checked, report that the plan is complete.
+   - If neither file exists, note that there is no active plan.
+4. Check provisioned agent config:
+   - If `CLAUDE.md` or `AGENTS.md` contains `<!-- provision-agentic-config vX.Y -->`, extract the version.
+   - Read the canonical `provision-agentic-config` skill from the first existing path in this order:
+     1. `~/.codex/skills/provision-agentic-config/SKILL.md`
+     2. `~/.claude/skills/provision-agentic-config/SKILL.md`
+     3. `base/codex/provision-agentic-config/SKILL.md` in the current repo, when present
+     4. `base/claude/provision-agentic-config/SKILL.md` in the current repo, when present
+   - Extract the `version:` field from the canonical skill's YAML frontmatter.
+   - Extract the canonical provisioned blocks from the same skill:
+     - `CLAUDE.md`: the fenced block under `Required Claude Block` or the section that says "The Claude block to insert into `./CLAUDE.md`".
+     - `AGENTS.md`: the fenced block under `Required AGENTS Block` or the section that says "The AGENTS block to insert into `./AGENTS.md`".
+   - Compare each existing project file against its corresponding canonical block after normalizing line endings and trimming only leading/trailing whitespace around the block. Do not ignore changed bullets, headings, command examples, or policy text.
+   - If the installed skill version is newer than the provisioned version in either file, warn: `⚠ CLAUDE.md provisioned with vX.Y but provision-agentic-config is at vX.Y — consider re-running $provision-agentic-config`
+   - If the version comment is missing from `CLAUDE.md` or `AGENTS.md`, note: `ℹ No provision version found in CLAUDE.md/AGENTS.md — run $provision-agentic-config to add version tracking`
+   - If a project file has the current version comment but the provisioned block content differs from the canonical block, warn: `⚠ CLAUDE.md provisioned block differs from the canonical provision-agentic-config vX.Y block — re-run $provision-agentic-config`
+   - If a canonical block cannot be extracted, fall back to the version-only check and note: `ℹ Could not extract canonical provision-agentic-config block; checked version comment only`
+   - If none of the canonical skill files exists, skip this check silently.
+   - Always report the local canonical source path used and its `version:` field when this check runs.
+5. Check skill-install drift (track-latest):
+   - Project-local pack/skill installs under `.claude/skills` and `.codex/skills` are managed copies stamped with `.agentic-skills-managed`, which now records `source_version` and `source_sha`. When canonical sources in the `agentic-skills` checkout move ahead, the installed copies fall behind.
+   - Resolve the `agentic-skills` checkout from any install marker's `source=` path (the parent above `.../packs/..` or `.../base/..` is the repo root). If no managed install exists or the checkout cannot be resolved, skip this check silently.
+   - Run `scripts/pack.sh doctor` from the project root using that checkout (read-only; it never mutates installs).
+   - Fold any `stale` skills into the Report status block with the fix command `scripts/pack.sh refresh`. Report `unknown` skills as "run `scripts/pack.sh refresh` to enable drift tracking" and leave `pinned` skills noted as frozen.
+   - Must not mutate. Plain `$sync` only warns; it never runs `refresh`, re-copies, or otherwise changes installs. Direct the user to `scripts/pack.sh refresh` (or enable auto-refresh) for the actual update.
+6. Resolve GitHub freshness preference:
+   - Use the user-local machine-wide preference file at `~/.agentic-skills/preferences.json`.
+   - Read `sync.github_freshness_check`, whose only allowed values are `"ask"`, `"always"`, and `"never"`.
+   - If the file or key is missing, ask the user once which default to remember:
+     - Always check GitHub during sync
+     - Never check GitHub during sync
+     - Ask each time
+   - Create `~/.agentic-skills/preferences.json` if needed and save the selected value as:
+     ```json
+     {
+       "sync": {
+         "github_freshness_check": "ask"
+       }
+     }
+     ```
+   - If the value is `"always"`, check GitHub remote freshness automatically.
+   - If the value is `"never"`, skip GitHub freshness checks and report that local canonical `provision-agentic-config` was used without a GitHub check.
+   - If the value is `"ask"`, ask before checking GitHub for this sync.
+   - Treat malformed JSON or an unsupported value as missing preference and ask again before writing one of the allowed values.
+7. Optional GitHub freshness check:
+   - Only run this check when the resolved preference or explicit user approval says to check GitHub.
+   - Compare the local `agentic-skills` checkout against `origin/HEAD` using non-mutating commands such as `git remote get-url origin`, `git rev-parse HEAD`, `git rev-parse origin/HEAD`, and, when remote freshness is explicitly enabled, `git fetch --dry-run` or an equivalent non-mutating freshness probe.
+   - Report the local checkout commit, remote URL, local `origin/HEAD` commit if available, and whether the local checkout appears behind the remote.
+   - Do not pull, fast-forward, rebase, install, or mutate the checkout from plain `$sync`.
+   - If a GitHub check shows the local checkout is stale, recommend `$init-agentic-skills update` for an explicit update.
+8. Report status:
+   - Branch name
+   - Commits pulled (if any) — show short log of new commits
+   - Whether stashed changes were re-applied
+   - Any conflicts that need manual resolution
+   - Current `git status`
+   - **Agent config drift** — provisioning version, local canonical source path/version, and canonical block match/drift status for `CLAUDE.md` and `AGENTS.md`, if checked
+   - **Skill-install drift** — any `stale` project skill installs (with `vOld → vNew`), `unknown` installs needing a refresh to enable tracking, and the `scripts/pack.sh refresh` fix command; report "all installs current" when none are stale, or skip the line when no managed installs exist
+   - **GitHub freshness** — preference value, whether GitHub was checked, and the local checkout/remote status; when skipped, say local canonical was used
+   - **Outstanding work** — summary from step 3 (next step, current phase, remaining work, pending manual tasks) or "No active plan"
+   - **Advisory tasks** — pending record/recurring counts, if those files exist
+9. Post-sync actions:
+   a) Check if `sync.md` exists at the project root.
+   b) **If `sync.md` exists** — parse and execute it:
+      - Read `sync.md` and identify sections by H2 headings.
+      - **Dependencies** (aliases: "Deps", "Dependency Management"): Execute shell commands in fenced code blocks. Report output briefly.
+      - **Conflict Resolution** (aliases: "Conflicts"): If the pull introduced merge conflicts (from step 2), apply the guidance in this section. If no conflicts, skip silently.
+      - **Custom** (aliases: "Project-Specific", "Scripts", "Setup"): Execute shell commands in fenced code blocks in order. Report output briefly.
+      - **Notifications** (aliases: "Awareness", "Alerts", "Watch"): For each bullet, check if the mentioned file/directory was modified in pulled commits (`git diff --name-only` against pre-pull HEAD). If any match, print a prominent alert.
+      - Unrecognised headings: skip with a note.
+      - Report a summary of all post-sync actions taken.
+   c) **If `sync.md` does not exist** — suggest creating one:
+      - Analyse the project to detect: package manager (look for lockfiles), common scripts (package.json, Makefile, Justfile), config templates (.env.example, docker-compose.yml).
+      - Present a suggested `sync.md` following the format below.
+      - Ask: "Would you like me to create this `sync.md`?"
+      - **Only create the file if the user approves.**
+
+## sync.md format
+
+The `sync.md` file lives at the project root. H2 sections are categories. Shell commands go in fenced code blocks; prose guidance goes in bullet points.
+
+```markdown
+# Post-Sync Actions
+
+## Dependencies
+
+```sh
+npm install
+```
+
+## Conflict Resolution
+
+- Always accept theirs for `package-lock.json`
+
+## Custom
+
+```sh
+npm run codegen
+```
+
+## Notifications
+
+- `.env.example` — check for new environment variables
+- `CLAUDE.md` — review if project conventions were updated
+```
+
+## Constraints
+
+- Do not force-push or rewrite history.
+- Do not auto-resolve merge conflicts — report them and let the user decide. However, if `sync.md` has a Conflict Resolution section, follow its guidance for the specific files/patterns it covers.
+- If stash pop fails due to conflicts, leave the stash intact and report it.
+- Post-sync commands from `sync.md` run in the project root directory.
+- If any post-sync command fails, report the error and continue with remaining actions.
+- Never auto-create `sync.md` without explicit user approval.
+- Do not execute commented-out sections (`<!-- ... -->`).
+- Plain `$sync` must not update the `agentic-skills` checkout, pull from GitHub for the local canonical source, or reinstall skills. Only `$init-agentic-skills update` / `$init-agentic-skills latest` may perform that explicit update flow after confirmation.
+
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/gitops/codex/sync/archive/v0.5/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: sync
+description: Pull latest changes from remote and report status
+type: shipping
+version: v0.5
+---
+
+# Sync
+
+Invoke as `$sync`.
+
+Pull the latest changes from the remote repository and report status.
+
+## Process
+
+1. Check current state:
+   - Run `git status` to check for uncommitted changes.
+   - If there are uncommitted changes, stash them first, pull, then pop the stash. Warn the user about the stash.
+2. Pull from remote:
+   - Run `git pull --rebase origin <current-branch>`.
+   - If rebase conflicts occur, abort the rebase, try `git pull --no-rebase` instead, and report any merge conflicts for the user to resolve.
+3. Check for outstanding work:
+   - Check if `tasks/roadmap.md` exists for the full plan, and `tasks/todo.md` for the current phase.
+   - If `tasks/todo.md` exists, read it and look for unchecked items (`- [ ]`).
+   - If there are incomplete items, summarise: which phase is current, what the next step is, and how many steps/phases remain.
+   - If `tasks/manual-todo.md` exists, count unchecked manual tasks and include in the summary.
+   - If `tasks/record-todo.md` or `tasks/recurring-todo.md` exists, count unchecked advisory items and include those counts separately. Do not treat them as active plan steps.
+   - If all items are checked, report that the plan is complete.
+   - If neither file exists, note that there is no active plan.
+4. Check provisioned agent config:
+   - If `CLAUDE.md` or `AGENTS.md` contains `<!-- provision-agentic-config vX.Y -->`, extract the version.
+   - Read the canonical `provision-agentic-config` skill from the first existing path in this order:
+     1. `~/.codex/skills/provision-agentic-config/SKILL.md`
+     2. `~/.claude/skills/provision-agentic-config/SKILL.md`
+     3. `base/codex/provision-agentic-config/SKILL.md` in the current repo, when present
+     4. `base/claude/provision-agentic-config/SKILL.md` in the current repo, when present
+   - Extract the `version:` field from the canonical skill's YAML frontmatter.
+   - Extract the canonical provisioned blocks from the same skill:
+     - `CLAUDE.md`: the fenced block under `Required Claude Block` or the section that says "The Claude block to insert into `./CLAUDE.md`".
+     - `AGENTS.md`: the fenced block under `Required AGENTS Block` or the section that says "The AGENTS block to insert into `./AGENTS.md`".
+   - Compare each existing project file against its corresponding canonical block after normalizing line endings and trimming only leading/trailing whitespace around the block. Do not ignore changed bullets, headings, command examples, or policy text.
+   - If the installed skill version is newer than the provisioned version in either file, warn: `⚠ CLAUDE.md provisioned with vX.Y but provision-agentic-config is at vX.Y — consider re-running $provision-agentic-config`
+   - If the version comment is missing from `CLAUDE.md` or `AGENTS.md`, note: `ℹ No provision version found in CLAUDE.md/AGENTS.md — run $provision-agentic-config to add version tracking`
+   - If a project file has the current version comment but the provisioned block content differs from the canonical block, warn: `⚠ CLAUDE.md provisioned block differs from the canonical provision-agentic-config vX.Y block — re-run $provision-agentic-config`
+   - If a canonical block cannot be extracted, fall back to the version-only check and note: `ℹ Could not extract canonical provision-agentic-config block; checked version comment only`
+   - If none of the canonical skill files exists, skip this check silently.
+   - Always report the local canonical source path used and its `version:` field when this check runs.
+5. Check skill-install drift (track-latest):
+   - Project-local pack/skill installs under `.claude/skills` and `.codex/skills` are managed copies stamped with `.agentic-skills-managed`, which now records `source_version` and `source_sha`. When canonical sources in the `agentic-skills` checkout move ahead, the installed copies fall behind.
+   - Resolve the `agentic-skills` checkout from any install marker's `source=` path (the parent above `.../packs/..` or `.../base/..` is the repo root). If no managed install exists or the checkout cannot be resolved, skip this check silently.
+   - Run `scripts/pack.sh doctor` from the project root using that checkout (read-only; it never mutates installs).
+   - Fold any `stale` skills into the Report status block and surface the exact refresh command the doctor itself reported (the context-aware dual hint). Prefer `npx skillpacks refresh` when the resolved managing source is the published npx `skillpacks` package (the marker `source=` path has no `.git`); use `scripts/pack.sh refresh` run from the resolved source-checkout root otherwise. Report `unknown` skills as "run the doctor-reported refresh command to enable drift tracking" with the same npx-vs-checkout choice, and leave `pinned` skills noted as frozen. Do not print a bare `scripts/pack.sh refresh`, which will not resolve from a non-checkout project directory.
+   - Must not mutate. Plain `$sync` only warns; it never runs `refresh`, re-copies, or otherwise changes installs. Direct the user to the doctor-reported refresh command — `npx skillpacks refresh` for installs managed by the published npx package, or `scripts/pack.sh refresh` run from the source checkout (or enable auto-refresh) — for the actual update.
+6. Resolve GitHub freshness preference:
+   - Use the user-local machine-wide preference file at `~/.agentic-skills/preferences.json`.
+   - Read `sync.github_freshness_check`, whose only allowed values are `"ask"`, `"always"`, and `"never"`.
+   - If the file or key is missing, ask the user once which default to remember:
+     - Always check GitHub during sync
+     - Never check GitHub during sync
+     - Ask each time
+   - Create `~/.agentic-skills/preferences.json` if needed and save the selected value as:
+     ```json
+     {
+       "sync": {
+         "github_freshness_check": "ask"
+       }
+     }
+     ```
+   - If the value is `"always"`, check GitHub remote freshness automatically.
+   - If the value is `"never"`, skip GitHub freshness checks and report that local canonical `provision-agentic-config` was used without a GitHub check.
+   - If the value is `"ask"`, ask before checking GitHub for this sync.
+   - Treat malformed JSON or an unsupported value as missing preference and ask again before writing one of the allowed values.
+7. Optional GitHub freshness check:
+   - Only run this check when the resolved preference or explicit user approval says to check GitHub.
+   - Compare the local `agentic-skills` checkout against `origin/HEAD` using non-mutating commands such as `git remote get-url origin`, `git rev-parse HEAD`, `git rev-parse origin/HEAD`, and, when remote freshness is explicitly enabled, `git fetch --dry-run` or an equivalent non-mutating freshness probe.
+   - Report the local checkout commit, remote URL, local `origin/HEAD` commit if available, and whether the local checkout appears behind the remote.
+   - Do not pull, fast-forward, rebase, install, or mutate the checkout from plain `$sync`.
+   - If a GitHub check shows the local checkout is stale, recommend `$init-agentic-skills update` for an explicit update.
+8. Report status:
+   - Branch name
+   - Commits pulled (if any) — show short log of new commits
+   - Whether stashed changes were re-applied
+   - Any conflicts that need manual resolution
+   - Current `git status`
+   - **Agent config drift** — provisioning version, local canonical source path/version, and canonical block match/drift status for `CLAUDE.md` and `AGENTS.md`, if checked
+   - **Skill-install drift** — any `stale` project skill installs (with `vOld → vNew`), `unknown` installs needing a refresh to enable tracking, and the doctor-reported refresh command (`npx skillpacks refresh`, or `scripts/pack.sh refresh` from a source checkout); report "all installs current" when none are stale, or skip the line when no managed installs exist
+   - **GitHub freshness** — preference value, whether GitHub was checked, and the local checkout/remote status; when skipped, say local canonical was used
+   - **Outstanding work** — summary from step 3 (next step, current phase, remaining work, pending manual tasks) or "No active plan"
+   - **Advisory tasks** — pending record/recurring counts, if those files exist
+9. Post-sync actions:
+   a) Check if `sync.md` exists at the project root.
+   b) **If `sync.md` exists** — parse and execute it:
+      - Read `sync.md` and identify sections by H2 headings.
+      - **Dependencies** (aliases: "Deps", "Dependency Management"): Execute shell commands in fenced code blocks. Report output briefly.
+      - **Conflict Resolution** (aliases: "Conflicts"): If the pull introduced merge conflicts (from step 2), apply the guidance in this section. If no conflicts, skip silently.
+      - **Custom** (aliases: "Project-Specific", "Scripts", "Setup"): Execute shell commands in fenced code blocks in order. Report output briefly.
+      - **Notifications** (aliases: "Awareness", "Alerts", "Watch"): For each bullet, check if the mentioned file/directory was modified in pulled commits (`git diff --name-only` against pre-pull HEAD). If any match, print a prominent alert.
+      - Unrecognised headings: skip with a note.
+      - Report a summary of all post-sync actions taken.
+   c) **If `sync.md` does not exist** — suggest creating one:
+      - Analyse the project to detect: package manager (look for lockfiles), common scripts (package.json, Makefile, Justfile), config templates (.env.example, docker-compose.yml).
+      - Present a suggested `sync.md` following the format below.
+      - Ask: "Would you like me to create this `sync.md`?"
+      - **Only create the file if the user approves.**
+
+## sync.md format
+
+The `sync.md` file lives at the project root. H2 sections are categories. Shell commands go in fenced code blocks; prose guidance goes in bullet points.
+
+```markdown
+# Post-Sync Actions
+
+## Dependencies
+
+```sh
+npm install
+```
+
+## Conflict Resolution
+
+- Always accept theirs for `package-lock.json`
+
+## Custom
+
+```sh
+npm run codegen
+```
+
+## Notifications
+
+- `.env.example` — check for new environment variables
+- `CLAUDE.md` — review if project conventions were updated
+```
+
+## Constraints
+
+- Do not force-push or rewrite history.
+- Do not auto-resolve merge conflicts — report them and let the user decide. However, if `sync.md` has a Conflict Resolution section, follow its guidance for the specific files/patterns it covers.
+- If stash pop fails due to conflicts, leave the stash intact and report it.
+- Post-sync commands from `sync.md` run in the project root directory.
+- If any post-sync command fails, report the error and continue with remaining actions.
+- Never auto-create `sync.md` without explicit user approval.
+- Do not execute commented-out sections (`<!-- ... -->`).
+- Plain `$sync` must not update the `agentic-skills` checkout, pull from GitHub for the local canonical source, or reinstall skills. Only `$init-agentic-skills update` / `$init-agentic-skills latest` may perform that explicit update flow after confirmation.
+
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/monorepo/PACK.md

@@ -34,14 +34,14 @@ scripts/pack.sh refresh
 
 ## Augmentation Injection Pattern
 
-This pack does not duplicate the global execution and shipping skills. It injects monorepo-aware pre/post steps around the existing contracts:
+This pack does not duplicate the base execution and shipping skills. It injects monorepo-aware pre/post steps around the existing contracts:
 
 - Pre-execution: run `mono-detect`, read the phase execution profile, generate lane specs when appropriate, and run `mono-guard` pre-flight.
 - Execution: keep root-only and cross-cutting steps serial in the main agent; dispatch only approved package-scoped lanes with disjoint `owns` paths and separate non-primary GitHub branches.
 - Post-integration: run consolidation/PR review, then `mono-guard` against the actual diff before package-scoped shipping.
 - Pre-ship: use `.agents/monorepo.json` and lane specs to run package and transitive-dependent validation before delegating to `/ship` or `$ship`.
 
-This differs from `*-kanban` packs, which intentionally provide workflow variants. The monorepo pack is an overlay that makes the normal skill pipeline workspace-aware while preserving the global skill contracts as the source of truth.
+This differs from `*-kanban` packs, which intentionally provide workflow variants. The monorepo pack is an overlay that makes the normal skill pipeline workspace-aware while preserving the base skill contracts as the source of truth.
 
 ## Package-Scope Tags
 

package/packs/monorepo/claude/mono-detect/SKILL.md

@@ -12,11 +12,11 @@ parent: mono-plan
 
 Use this skill to detect a pnpm workspace monorepo and generate the `.agents/monorepo.json` artifact consumed by the monorepo pack.
 
-`mono-detect` is the foundation skill for `mono-exec`, `mono-ship`, and `mono-guard`. Those skills use its output to inject monorepo-aware pre/post steps into the standard `/exec` and `/ship` contracts without duplicating the global workflow.
+`mono-detect` is the foundation skill for `mono-exec`, `mono-ship`, and `mono-guard`. Those skills use its output to inject monorepo-aware pre/post steps into the standard `/exec` and `/ship` contracts without duplicating the base workflow.
 
 ## Augmentation Injection Pattern
 
-`mono-detect` is the pack's detection foundation for the augmentation injection pattern. It does not replace `/exec`, `/ship`, or global monorepo planning skills; it supplies `.agents/monorepo.json` so `mono-exec`, `mono-ship`, and `mono-guard` can inject monorepo-aware pre-flight and post-integration checks around those existing workflows.
+`mono-detect` is the pack's detection foundation for the augmentation injection pattern. It does not replace `/exec`, `/ship`, or base monorepo planning skills; it supplies `.agents/monorepo.json` so `mono-exec`, `mono-ship`, and `mono-guard` can inject monorepo-aware pre-flight and post-integration checks around those existing workflows.
 
 ## Process
 
@@ -62,7 +62,7 @@ Use this skill to detect a pnpm workspace monorepo and generate the `.agents/mon
 - Do not run package manager install/add commands.
 - Do not infer non-pnpm workspace managers in V1.
 - Do not modify `.agents/monorepo.json` manually; use `mono-detect.sh`.
-- Treat `mono-detect` as an augmentation foundation for `mono-exec`, `mono-ship`, and `mono-guard`, not as a replacement for `/exec`, `/ship`, or global monorepo planning skills.
+- Treat `mono-detect` as an augmentation foundation for `mono-exec`, `mono-ship`, and `mono-guard`, not as a replacement for `/exec`, `/ship`, or base monorepo planning skills.
 
 ## Default Shipping Contract
 

package/packs/monorepo/claude/mono-exec/SKILL.md

@@ -19,7 +19,7 @@ Use this skill to execute planned work in a pnpm workspace monorepo with package
 2. **Dispatch:** run cross-cutting steps serially first in the main agent, then dispatch package-scoped worktree waves on separate GitHub branches only after lane specs are approved and guard validation passes.
 3. **Post-dispatch:** perform consolidation/PR review, run `mono-guard --post-integration`, update lane-spec lifecycle, then continue to `mono-ship` when shipping is requested.
 
-The global `/exec` skill remains the source of truth for task selection, task docs, validation, history updates, commit/push, deploy handling, and next-step routing.
+The base `/exec` skill remains the source of truth for task selection, task docs, validation, history updates, commit/push, deploy handling, and next-step routing.
 
 ## Flags
 

package/packs/monorepo/claude/mono-guard/SKILL.md

@@ -10,7 +10,7 @@ argument-hint: "[--post-integration] [optional: lane-specs.json]"
 
 Use this skill to validate monorepo pack lane artifacts before parallel dispatch and to audit integrated lane changes after dispatch.
 
-This pack-local `mono-guard` consumes `.agents/lane-specs.json` and `.agents/monorepo.json`. It preserves behavioral compatibility with the global `/mono-guard` contract while using the monorepo pack's JSON artifacts and scripts as the project-local enforcement surface.
+This pack-local `mono-guard` consumes `.agents/lane-specs.json` and `.agents/monorepo.json`. It preserves behavioral compatibility with the base `/mono-guard` contract while using the monorepo pack's JSON artifacts and scripts as the project-local enforcement surface.
 
 ## Augmentation Injection Pattern
 
@@ -116,7 +116,7 @@ If `.agents/monorepo.json` is missing or stale, run `mono-detect` first. If `.ag
 - Do not run package manager install/add commands.
 - Do not modify `.agents/lane-specs.json` or `.agents/monorepo.json` except by invoking the designated generation/detection skills when appropriate.
 - Do not revert or repair post-integration changes; report violations only.
-- Keep behavior compatible with the global `/mono-guard` safety contract.
+- Keep behavior compatible with the base `/mono-guard` safety contract.
 
 ## Next-Step Routing
 

package/packs/monorepo/claude/mono-ship/SKILL.md

@@ -21,7 +21,7 @@ Use this skill to ship completed work in a pnpm workspace monorepo only after pa
 2. **Ship:** delegate to the standard `/ship` contract after validation passes.
 3. **Post-ship:** update `tasks/lane-specs.md` with shipping status, lifecycle notes, and the next routed command.
 
-The global `/ship` skill remains the source of truth for final validation policy, task docs, history updates, commit/push, deploy handling, and next-step routing.
+The base `/ship` skill remains the source of truth for final validation policy, task docs, history updates, commit/push, deploy handling, and next-step routing.
 
 ## Inputs
 

package/packs/monorepo/claude/scaffold/SKILL.md

@@ -81,7 +81,7 @@ For product/app workflows, `/scaffold` is normally downstream of research, proto
 
 ## Constraints
 - Always use an existing package/app as the reference template — do not invent conventions.
-- Do not install domain packs globally; use project-local pack skill roots.
+- Do not install domain packs as base skills; use project-local pack skill roots.
 - Always enter plan mode before creating files.
 - Do not call ExitPlanMode from normal mode. If Claude Code reports "You are not in plan mode" after approval, treat approval as complete and continue implementation.
 - Do not add unnecessary boilerplate — keep the scaffold minimal and consistent with existing packages.

package/packs/monorepo/codex/mono-detect/SKILL.md

@@ -14,11 +14,11 @@ Invoke as `$mono-detect`.
 
 Use this skill to detect a pnpm workspace monorepo and generate the `.agents/monorepo.json` artifact consumed by the monorepo pack.
 
-`mono-detect` is the foundation skill for `mono-exec`, `mono-ship`, and `mono-guard`. Those skills use its output to inject monorepo-aware pre/post steps into the standard `$exec` and `$ship` contracts without duplicating the global workflow.
+`mono-detect` is the foundation skill for `mono-exec`, `mono-ship`, and `mono-guard`. Those skills use its output to inject monorepo-aware pre/post steps into the standard `$exec` and `$ship` contracts without duplicating the base workflow.
 
 ## Augmentation Injection Pattern
 
-`mono-detect` is the pack's detection foundation for the augmentation injection pattern. It does not replace `$exec`, `$ship`, or global monorepo planning skills; it supplies `.agents/monorepo.json` so `mono-exec`, `mono-ship`, and `mono-guard` can inject monorepo-aware pre-flight and post-integration checks around those existing workflows.
+`mono-detect` is the pack's detection foundation for the augmentation injection pattern. It does not replace `$exec`, `$ship`, or base monorepo planning skills; it supplies `.agents/monorepo.json` so `mono-exec`, `mono-ship`, and `mono-guard` can inject monorepo-aware pre-flight and post-integration checks around those existing workflows.
 
 ## Process
 
@@ -64,7 +64,7 @@ Use this skill to detect a pnpm workspace monorepo and generate the `.agents/mon
 - Do not run package manager install/add commands.
 - Do not infer non-pnpm workspace managers in V1.
 - Do not modify `.agents/monorepo.json` manually; use `mono-detect.sh`.
-- Treat `mono-detect` as an augmentation foundation for `mono-exec`, `mono-ship`, and `mono-guard`, not as a replacement for `$exec`, `$ship`, or global monorepo planning skills.
+- Treat `mono-detect` as an augmentation foundation for `mono-exec`, `mono-ship`, and `mono-guard`, not as a replacement for `$exec`, `$ship`, or base monorepo planning skills.
 
 ## Default Shipping Contract
 

package/packs/monorepo/codex/mono-exec/SKILL.md

@@ -21,7 +21,7 @@ Use this skill to execute planned work in a pnpm workspace monorepo with package
 2. **Dispatch:** run cross-cutting steps serially first in the main agent, then dispatch package-scoped worktree waves on separate GitHub branches only after lane specs are approved and guard validation passes.
 3. **Post-dispatch:** perform consolidation/PR review, run `mono-guard --post-integration`, update lane-spec lifecycle, then continue to `mono-ship` when shipping is requested.
 
-The global `$exec` skill remains the source of truth for task selection, task docs, validation, history updates, commit/push, deploy handling, and next-step routing.
+The base `$exec` skill remains the source of truth for task selection, task docs, validation, history updates, commit/push, deploy handling, and next-step routing.
 
 ## Flags
 

package/packs/monorepo/codex/mono-guard/SKILL.md

@@ -12,7 +12,7 @@ Invoke as `$mono-guard`.
 
 Use this skill to validate monorepo pack lane artifacts before parallel dispatch and to audit integrated lane changes after dispatch.
 
-This pack-local `mono-guard` consumes `.agents/lane-specs.json` and `.agents/monorepo.json`. It preserves behavioral compatibility with the global `$mono-guard` contract while using the monorepo pack's JSON artifacts and scripts as the project-local enforcement surface.
+This pack-local `mono-guard` consumes `.agents/lane-specs.json` and `.agents/monorepo.json`. It preserves behavioral compatibility with the base `$mono-guard` contract while using the monorepo pack's JSON artifacts and scripts as the project-local enforcement surface.
 
 ## Augmentation Injection Pattern
 
@@ -118,7 +118,7 @@ If `.agents/monorepo.json` is missing or stale, run `mono-detect` first. If `.ag
 - Do not run package manager install/add commands.
 - Do not modify `.agents/lane-specs.json` or `.agents/monorepo.json` except by invoking the designated generation/detection skills when appropriate.
 - Do not revert or repair post-integration changes; report violations only.
-- Keep behavior compatible with the global `$mono-guard` safety contract.
+- Keep behavior compatible with the base `$mono-guard` safety contract.
 
 ## Next-Step Routing
 

package/packs/monorepo/codex/mono-ship/SKILL.md

@@ -21,7 +21,7 @@ Use this skill to ship completed work in a pnpm workspace monorepo only after pa
 2. **Ship:** delegate to the standard `$ship` contract after validation passes.
 3. **Post-ship:** update `tasks/lane-specs.md` with shipping status, lifecycle notes, and the next routed command.
 
-The global `$ship` skill remains the source of truth for final validation policy, task docs, history updates, commit/push, deploy handling, and next-step routing.
+The base `$ship` skill remains the source of truth for final validation policy, task docs, history updates, commit/push, deploy handling, and next-step routing.
 
 ## Inputs
 

package/packs/monorepo/codex/scaffold/SKILL.md

@@ -39,7 +39,7 @@ For product/app workflows, `$scaffold` is normally downstream of research, proto
 ## Constraints
 
 - Always use an existing package as the reference template.
-- Do not install domain packs globally; use project-local pack skill roots.
+- Do not install domain packs as base skills; use project-local pack skill roots.
 - Present the plan and get approval before creating files. Do not assume a Claude-style `EnterPlanMode` or clear-context accept flow exists.
 - Keep the scaffold minimal — no unnecessary boilerplate.
 - Do not treat scaffolding as product validation. It creates structure only; ICP, market, journey, UX, UI, and prototype decisions belong to their upstream skills.

package/packs/session-analytics/claude/prompt-history-backfill/SKILL.md

@@ -31,7 +31,7 @@ Use this skill when the user wants to audit or backfill `prompts/<skill-slug>/`
    - In report-only mode, prompt backfill candidates are reviewed but no files under `prompts/<skill-slug>/` are created.
 
 2. Resolve known skills in the target repo:
-   - Read active non-archive `SKILL.md` files under `global/`, `packs/`, `.claude/skills/`, and `.codex/skills/` when present.
+   - Read active non-archive `SKILL.md` files under `base/`, `packs/`, `.claude/skills/`, and `.codex/skills/` when present.
    - Include existing `prompts/<skill-slug>/` directories as known prompt-history targets.
    - Maintain a hardcoded legacy skill map for slugs that no longer exist as active skills:
      - `run` — renamed → `exec`

package/packs/session-analytics/claude/session-triage/SKILL.md

@@ -25,7 +25,7 @@ Use `/analyze-sessions` instead when the user wants broad cross-session trends,
 1. Define the investigation scope:
    - Treat the current conversation and current working directory as the default scope.
    - Prefer user-provided session IDs, files, repo paths, skill names, exact correction phrases, errors, logs, and test failures over broad history searches.
-   - Resolve named skills from `global/codex`, `global/claude`, `packs`, project-local `.agents`, `.codex`, `.claude`, and installed `~/.codex/skills` or `~/.claude/skills` as read-only fallback evidence.
+   - Resolve named skills from `base/codex`, `base/claude`, `packs`, project-local `.agents`, `.codex`, `.claude`, and installed `~/.codex/skills` or `~/.claude/skills` as read-only fallback evidence.
    - Do not create an `/analyze-session` alias or route; use this distinct command name to avoid singular/plural confusion.
 
 2. Gather narrow evidence first:

package/packs/session-analytics/codex/prompt-history-backfill/SKILL.md

@@ -31,7 +31,7 @@ Use this skill when the user wants to audit or backfill `prompts/<skill-slug>/`
    - In report-only mode, prompt backfill candidates are reviewed but no files under `prompts/<skill-slug>/` are created.
 
 2. Resolve known skills in the target repo:
-   - Read active non-archive `SKILL.md` files under `global/`, `packs/`, `.claude/skills/`, and `.codex/skills/` when present.
+   - Read active non-archive `SKILL.md` files under `base/`, `packs/`, `.claude/skills/`, and `.codex/skills/` when present.
    - Include existing `prompts/<skill-slug>/` directories as known prompt-history targets.
    - Maintain a hardcoded legacy skill map for slugs that no longer exist as active skills:
      - `run` — renamed → `exec`

package/packs/session-analytics/codex/session-triage/SKILL.md

@@ -27,7 +27,7 @@ Use `$analyze-sessions` instead when the user wants broad cross-session trends,
 1. Define the investigation scope:
    - Treat the current conversation and current working directory as the default scope.
    - Prefer user-provided session IDs, files, repo paths, skill names, exact correction phrases, errors, logs, and test failures over broad history searches.
-   - Resolve named skills from `global/codex`, `global/claude`, `packs`, project-local `.agents`, `.codex`, `.claude`, and installed `~/.codex/skills` or `~/.claude/skills` as read-only fallback evidence.
+   - Resolve named skills from `base/codex`, `base/claude`, `packs`, project-local `.agents`, `.codex`, `.claude`, and installed `~/.codex/skills` or `~/.claude/skills` as read-only fallback evidence.
    - Do not create an `$analyze-session` alias or route; use this distinct command name to avoid singular/plural confusion.
 
 2. Gather narrow evidence first:

package/packs/skill-dev/claude/create-agentic-skill/CHANGELOG.md

@@ -1,5 +1,13 @@
 # Changelog
 
+## v0.3 - 2026-06-13
+
+- Repo-verification check no longer looks for the removed `init.sh`; it now checks for `base/claude/`, `base/codex/`, and `packages/skillpacks/`.
+
+## v0.2 - 2026-06-13
+
+- Renamed authoring paths from `global/{claude,codex}` to `base/{claude,codex}` following the global→base directory migration.
+
 ## v0.1 - 2026-06-09
 
 - Updated Skills Showcase refresh commands to use app-owned generator and validator paths after the workspace split.

package/packs/skill-dev/claude/create-agentic-skill/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: create-agentic-skill
-description: Create or update a repo-managed skill inside this agentic-skills checkout under global/claude and optionally global/codex, then validate, commit, and push it
+description: Create or update a repo-managed skill inside this agentic-skills checkout under base/claude and optionally base/codex, then validate, commit, and push it
 type: execution
-version: v0.1
+version: v0.3
 argument-hint: <skill-name> [description] [--claude-only|--codex-only|--mirror]
 ---
 
@@ -13,14 +13,14 @@ Use this skill when the user wants to add or update a skill in the `agentic-skil
 ## Process
 
 1. **Confirm repository context.**
-   - Verify the current repo is `agentic-skills` by checking for `init.sh`, `global/claude/`, and `global/codex/`.
+   - Verify the current repo is `agentic-skills` by checking for `base/claude/`, `base/codex/`, and `packages/skillpacks/`.
    - If the current repo is not `agentic-skills`, stop and ask for the checkout path.
    - Inspect `git status --short` and identify unrelated dirty files before editing.
 
 2. **Resolve skill identity.**
    - Parse `<skill-name>` as kebab-case.
    - Parse the description when provided; otherwise ask for a one-line description.
-   - Default to creating both `global/claude/<skill-name>/SKILL.md` and `global/codex/<skill-name>/SKILL.md` when the skill should exist for both agents.
+   - Default to creating both `base/claude/<skill-name>/SKILL.md` and `base/codex/<skill-name>/SKILL.md` when the skill should exist for both agents.
    - Honor `--claude-only`, `--codex-only`, or `--mirror`.
    - If a local-only workflow is requested, route to `create-local-skill` instead.