skillpacks 0.1.1 → 0.1.2

package/packs/skill-dev/codex/create-agentic-skill/archive/v0.1/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: create-agentic-skill
+description: Create or update a repo-managed skill inside this agentic-skills checkout under global/codex and optionally global/claude, then validate, commit, and push it
+type: execution
+version: v0.1
+argument-hint: "<skill-name> [description] [--codex-only|--claude-only|--mirror]"
+---
+
+# Create Agentic Skill
+
+Invoke as `$create-agentic-skill`.
+
+Use this skill when the user wants to add or update a skill in the `agentic-skills` repository itself. This is the repo-managed counterpart to `$create-local-skill`, which writes experimental user-local skills under `~/.codex/skills` or `~/.claude/skills`.
+
+## Process
+
+1. **Confirm repository context.**
+   - Verify the current repo is `agentic-skills` by checking for `init.sh`, `global/codex/`, and `global/claude/`.
+   - 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/codex/<skill-name>/SKILL.md` and `global/claude/<skill-name>/SKILL.md` when the skill should exist for both agents.
+   - Honor `--codex-only`, `--claude-only`, or `--mirror`.
+   - If a local-only workflow is requested, route to `$create-local-skill` instead.
+
+3. **Check for conflicts.**
+   - Refuse to overwrite an existing unrelated skill without explicit user approval.
+   - If updating an existing skill, read the current `SKILL.md` and preserve its purpose unless the user asked for a rewrite.
+   - Check for stale old names when the task is a rename, and move directories rather than duplicating the skill.
+
+4. **Draft the skill.**
+   - Follow repo frontmatter conventions:
+     - `name`
+     - `description`
+     - `type`
+     - `version`
+     - optional `argument-hint`
+   - For Codex skills, include `Invoke as \`$<skill-name>\`.` after the title.
+   - For Claude skills, omit the Codex invocation line unless existing local convention requires it.
+   - Include clear `## Workflow`, `## Output`, and `## Constraints` sections.
+   - Prefer durable procedure over one-off project notes.
+
+5. **Apply correction lessons when relevant.**
+   - If the skill is being created because of a user correction, update `tasks/lessons.md` with the mistake pattern and prevention rule.
+   - Keep the lesson specific enough to prevent recurrence.
+
+6. **Handle benchmark coverage.**
+   - For every new shared skill or material behavior update, update `tests/harness/bench-coverage.ts` in the same shipping boundary.
+   - Add or register a deterministic custom setup under `tests/layer4/setups/` when local fixtures can exercise the skill without credentials, external services, paid actions, production deploys, or unsafe account state.
+   - When adding or materially updating a custom setup, include a deterministic quality rubric when practical. Score local fixture facts, concrete file/command references, expected next-route handoffs, specificity, and forbidden fabrications as appropriate for the skill.
+   - If output quality cannot be scored reliably from local fixtures, record an explicit blocked/deferred quality note in the setup or coverage review instead of adding a weak subjective rubric.
+   - If deterministic local coverage is not safe yet, record an explicit `blocked` row with `blocked_reason` and `next_command`.
+   - Use `$targeted-skill-builder <skill-name> benchmark coverage` when the coverage work needs a focused follow-up before the skill can ship.
+   - Run `pnpm --dir tests bench:coverage` after updating the matrix.
+
+7. **Validate.**
+   - Read back the new or updated `SKILL.md` files.
+   - Run `rg` checks for old skill names, missing `version:`, missing `Invoke as` in Codex skills, and accidental writes under `~/.codex/skills` or `~/.claude/skills`.
+   - Run `pnpm --dir tests bench:coverage` and any focused setup tests changed for the new benchmark row.
+   - If any tracked `SKILL.md` or `PACK.md` was created, deleted, renamed, or changed in behavior or metadata, refresh the Skills Showcase data before shipping:
+     - `node apps/skills-showcase/scripts/generate-skills-showcase-data.mjs`
+     - `node apps/skills-showcase/scripts/generate-skills-showcase-github-data.mjs`
+     - `apps/skills-showcase/scripts/validate-skills-showcase-data.sh`
+   - Review curated showcase copy, catalog grouping, workflow animation text, and proof receipts when the skill change could affect the public website. Update the relevant site files or explicitly record why no curated website copy changed.
+   - Confirm unrelated dirty files remain unstaged.
+
+8. **Commit and push.**
+   - Stage only intended repo-managed skill files, generated showcase assets, and directly related docs or lesson updates.
+   - Commit on the repository primary branch (`main` when present, otherwise `master`) with a concise conventional commit message.
+   - Push the branch.
+   - Do not stage unrelated user changes.
+
+## Output
+
+- **Skill**: name and target paths created or updated
+- **Mode**: Codex, Claude, or mirrored
+- **Validation**: checks run and result
+- **Git**: commit hash and pushed branch
+- **Next Work**: exact follow-up, or `none` only when there is no useful follow-up
+
+## Constraints
+
+- Do not write to `~/.codex/skills` or `~/.claude/skills`; that is `$create-local-skill`.
+- Do not update README or generated references when they already have unrelated unstaged edits unless the user explicitly asks to include them.
+- Do not create pack-local skills unless the user asks for a pack path.
+- Do not leave repo-managed skill changes uncommitted or unpushed unless the user explicitly says not to ship.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/skill-dev/codex/create-agentic-skill/archive/v0.2/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: create-agentic-skill
+description: Create or update a repo-managed skill inside this agentic-skills checkout under base/codex and optionally base/claude, then validate, commit, and push it
+type: execution
+version: v0.2
+argument-hint: "<skill-name> [description] [--codex-only|--claude-only|--mirror]"
+---
+
+# Create Agentic Skill
+
+Invoke as `$create-agentic-skill`.
+
+Use this skill when the user wants to add or update a skill in the `agentic-skills` repository itself. This is the repo-managed counterpart to `$create-local-skill`, which writes experimental user-local skills under `~/.codex/skills` or `~/.claude/skills`.
+
+## Process
+
+1. **Confirm repository context.**
+   - Verify the current repo is `agentic-skills` by checking for `init.sh`, `base/codex/`, and `base/claude/`.
+   - 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 `base/codex/<skill-name>/SKILL.md` and `base/claude/<skill-name>/SKILL.md` when the skill should exist for both agents.
+   - Honor `--codex-only`, `--claude-only`, or `--mirror`.
+   - If a local-only workflow is requested, route to `$create-local-skill` instead.
+
+3. **Check for conflicts.**
+   - Refuse to overwrite an existing unrelated skill without explicit user approval.
+   - If updating an existing skill, read the current `SKILL.md` and preserve its purpose unless the user asked for a rewrite.
+   - Check for stale old names when the task is a rename, and move directories rather than duplicating the skill.
+
+4. **Draft the skill.**
+   - Follow repo frontmatter conventions:
+     - `name`
+     - `description`
+     - `type`
+     - `version`
+     - optional `argument-hint`
+   - For Codex skills, include `Invoke as \`$<skill-name>\`.` after the title.
+   - For Claude skills, omit the Codex invocation line unless existing local convention requires it.
+   - Include clear `## Workflow`, `## Output`, and `## Constraints` sections.
+   - Prefer durable procedure over one-off project notes.
+
+5. **Apply correction lessons when relevant.**
+   - If the skill is being created because of a user correction, update `tasks/lessons.md` with the mistake pattern and prevention rule.
+   - Keep the lesson specific enough to prevent recurrence.
+
+6. **Handle benchmark coverage.**
+   - For every new shared skill or material behavior update, update `tests/harness/bench-coverage.ts` in the same shipping boundary.
+   - Add or register a deterministic custom setup under `tests/layer4/setups/` when local fixtures can exercise the skill without credentials, external services, paid actions, production deploys, or unsafe account state.
+   - When adding or materially updating a custom setup, include a deterministic quality rubric when practical. Score local fixture facts, concrete file/command references, expected next-route handoffs, specificity, and forbidden fabrications as appropriate for the skill.
+   - If output quality cannot be scored reliably from local fixtures, record an explicit blocked/deferred quality note in the setup or coverage review instead of adding a weak subjective rubric.
+   - If deterministic local coverage is not safe yet, record an explicit `blocked` row with `blocked_reason` and `next_command`.
+   - Use `$targeted-skill-builder <skill-name> benchmark coverage` when the coverage work needs a focused follow-up before the skill can ship.
+   - Run `pnpm --dir tests bench:coverage` after updating the matrix.
+
+7. **Validate.**
+   - Read back the new or updated `SKILL.md` files.
+   - Run `rg` checks for old skill names, missing `version:`, missing `Invoke as` in Codex skills, and accidental writes under `~/.codex/skills` or `~/.claude/skills`.
+   - Run `pnpm --dir tests bench:coverage` and any focused setup tests changed for the new benchmark row.
+   - If any tracked `SKILL.md` or `PACK.md` was created, deleted, renamed, or changed in behavior or metadata, refresh the Skills Showcase data before shipping:
+     - `node apps/skills-showcase/scripts/generate-skills-showcase-data.mjs`
+     - `node apps/skills-showcase/scripts/generate-skills-showcase-github-data.mjs`
+     - `apps/skills-showcase/scripts/validate-skills-showcase-data.sh`
+   - Review curated showcase copy, catalog grouping, workflow animation text, and proof receipts when the skill change could affect the public website. Update the relevant site files or explicitly record why no curated website copy changed.
+   - Confirm unrelated dirty files remain unstaged.
+
+8. **Commit and push.**
+   - Stage only intended repo-managed skill files, generated showcase assets, and directly related docs or lesson updates.
+   - Commit on the repository primary branch (`main` when present, otherwise `master`) with a concise conventional commit message.
+   - Push the branch.
+   - Do not stage unrelated user changes.
+
+## Output
+
+- **Skill**: name and target paths created or updated
+- **Mode**: Codex, Claude, or mirrored
+- **Validation**: checks run and result
+- **Git**: commit hash and pushed branch
+- **Next Work**: exact follow-up, or `none` only when there is no useful follow-up
+
+## Constraints
+
+- Do not write to `~/.codex/skills` or `~/.claude/skills`; that is `$create-local-skill`.
+- Do not update README or generated references when they already have unrelated unstaged edits unless the user explicitly asks to include them.
+- Do not create pack-local skills unless the user asks for a pack path.
+- Do not leave repo-managed skill changes uncommitted or unpushed unless the user explicitly says not to ship.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/skill-dev/codex/create-local-skill/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## v0.2 - 2026-06-13
+
+- Upstream-safety note references `npx skillpacks uninstall-global` instead of the removed `init.sh --uninstall`.
+
 ## v0.1 - 2026-05-30
 
 - Tightened post-creation skill visibility guidance to distinguish Claude Code `/reload-skills`, `/clear`, and restart fallback behavior from Codex fresh CLI session fallback.

package/packs/skill-dev/codex/create-local-skill/SKILL.md

@@ -2,7 +2,7 @@
 name: create-local-skill
 description: Scaffold a new user-local skill in ~/.codex/skills (and optionally ~/.claude/skills), then offer to promote it to a personal fork of agentic-skills
 type: execution
-version: v0.1
+version: v0.2
 ---
 
 # Create Local Skill
@@ -11,7 +11,7 @@ Invoke as `$create-local-skill`.
 
 Scaffold a new **user-local** skill directly into `~/.codex/skills/<name>/` (and optionally `~/.claude/skills/<name>/`) as a real directory. The upstream agentic-skills repo is not touched. At the end, offer to **promote** the skill by copying it into the user's personal fork.
 
-`init.sh --uninstall` only removes repo-managed skill installs whose source is inside the agentic-skills repo, so user-authored real directories are safe from upstream sync.
+`npx skillpacks uninstall-global` only removes skillpacks-owned skill installs whose source is inside the agentic-skills repo, so user-authored real directories are safe from upstream sync.
 
 ## Process
 
@@ -22,7 +22,7 @@ Scaffold a new **user-local** skill directly into `~/.codex/skills/<name>/` (and
    - Whether to also create a Claude version in `~/.claude/skills/<name>/`
 
 2. Validate `$HOME/.codex/skills/<name>`:
-   - If it is a symlink into `agentic-skills/global/` or `agentic-skills/packs/`, refuse — it would shadow a repo-managed skill.
+   - If it is a symlink into `agentic-skills/base/` or `agentic-skills/packs/`, refuse — it would shadow a repo-managed skill.
    - If it is a real dir or user-owned symlink, confirm before overwriting.
 
 3. Write `~/.codex/skills/<name>/SKILL.md`:
@@ -61,8 +61,8 @@ Scaffold a new **user-local** skill directly into `~/.codex/skills/<name>/` (and
    If yes:
    - Ask for the path to their fork. If they don't have one, explain: fork on GitHub and clone, or `git remote set-url origin <their-repo>` to repoint an existing clone.
    - Verify with `git -C <path> rev-parse --show-toplevel`.
-   - Copy the skill into `<fork>/global/codex/<name>/` (and `<fork>/global/claude/<name>/` if applicable), or into a `<fork>/personal/...` subtree if the user prefers to segregate personal skills.
-   - If the skill is promoted into a fork's `global/` or `packs/` tree, also update that fork's `tests/harness/bench-coverage.ts` and add either a deterministic custom setup under `tests/layer4/setups/` or an explicit blocked row with `blocked_reason` and `next_command`.
+   - Copy the skill into `<fork>/base/codex/<name>/` (and `<fork>/base/claude/<name>/` if applicable), or into a `<fork>/personal/...` subtree if the user prefers to segregate personal skills.
+   - If the skill is promoted into a fork's `base/` or `packs/` tree, also update that fork's `tests/harness/bench-coverage.ts` and add either a deterministic custom setup under `tests/layer4/setups/` or an explicit blocked row with `blocked_reason` and `next_command`.
    - For promoted custom setups, include a deterministic quality rubric when practical, or record why quality scoring is blocked/deferred instead of adding a subjective rubric.
    - Recommend `pnpm --dir tests bench:coverage` before the promoted skill is committed.
    - Run `git status` in the fork and suggest a commit message. Do not commit or push — leave that to the user.
@@ -71,7 +71,7 @@ Scaffold a new **user-local** skill directly into `~/.codex/skills/<name>/` (and
 
 ## Notes
 
-- Never write into this repo's `global/` or `packs/` directories. Target paths are always under `$HOME/.codex/skills`, `$HOME/.claude/skills`, or an explicitly-supplied personal fork path.
+- Never write into this repo's `base/` or `packs/` directories. Target paths are always under `$HOME/.codex/skills`, `$HOME/.claude/skills`, or an explicitly-supplied personal fork path.
 - Do not create extra docs beyond `SKILL.md` unless asked.
 
 ## Default Shipping Contract

package/packs/skill-dev/codex/create-local-skill/archive/v0.1/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: create-local-skill
+description: Scaffold a new user-local skill in ~/.codex/skills (and optionally ~/.claude/skills), then offer to promote it to a personal fork of agentic-skills
+type: execution
+version: v0.1
+---
+
+# Create Local Skill
+
+Invoke as `$create-local-skill`.
+
+Scaffold a new **user-local** skill directly into `~/.codex/skills/<name>/` (and optionally `~/.claude/skills/<name>/`) as a real directory. The upstream agentic-skills repo is not touched. At the end, offer to **promote** the skill by copying it into the user's personal fork.
+
+`init.sh --uninstall` only removes repo-managed skill installs whose source is inside the agentic-skills repo, so user-authored real directories are safe from upstream sync.
+
+## Process
+
+1. Parse `<skill-name>` and optional description from arguments. If missing, ask for:
+   - Skill name (kebab-case)
+   - One-line description
+   - Type (default `execution`)
+   - Whether to also create a Claude version in `~/.claude/skills/<name>/`
+
+2. Validate `$HOME/.codex/skills/<name>`:
+   - If it is a symlink into `agentic-skills/base/` or `agentic-skills/packs/`, refuse — it would shadow a repo-managed skill.
+   - If it is a real dir or user-owned symlink, confirm before overwriting.
+
+3. Write `~/.codex/skills/<name>/SKILL.md`:
+
+   ```markdown
+   ---
+   name: <name>
+   description: <description>
+   type: <type>
+   version: v0.0
+   ---
+
+   # <Title>
+
+   Invoke as `$<name>`.
+
+   <1-2 sentence purpose statement.>
+
+   ## Workflow
+
+   1. <step>
+   2. <step>
+   3. <step>
+
+   ## Output
+
+   <what the skill produces>
+   ```
+
+4. Optionally mirror to `~/.claude/skills/<name>/SKILL.md` (Claude frontmatter convention — no `Invoke as` line; add `argument-hint` if relevant).
+
+5. Report created paths and remind the user of the runner-specific reload path. Claude Code should run `/reload-skills` first; `/clear` starts a new empty-context conversation and 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.
+
+6. Ask: "Would you like to promote this skill to your personal fork of agentic-skills?"
+
+   If yes:
+   - Ask for the path to their fork. If they don't have one, explain: fork on GitHub and clone, or `git remote set-url origin <their-repo>` to repoint an existing clone.
+   - Verify with `git -C <path> rev-parse --show-toplevel`.
+   - Copy the skill into `<fork>/base/codex/<name>/` (and `<fork>/base/claude/<name>/` if applicable), or into a `<fork>/personal/...` subtree if the user prefers to segregate personal skills.
+   - If the skill is promoted into a fork's `base/` or `packs/` tree, also update that fork's `tests/harness/bench-coverage.ts` and add either a deterministic custom setup under `tests/layer4/setups/` or an explicit blocked row with `blocked_reason` and `next_command`.
+   - For promoted custom setups, include a deterministic quality rubric when practical, or record why quality scoring is blocked/deferred instead of adding a subjective rubric.
+   - Recommend `pnpm --dir tests bench:coverage` before the promoted skill is committed.
+   - Run `git status` in the fork and suggest a commit message. Do not commit or push — leave that to the user.
+
+7. Safety note: pushing to the upstream agentic-skills repo requires write access. Plain clones without access are rejected at the remote; forks push to the user's own repo. Cannot route a user's experimental skill into the shared upstream.
+
+## Notes
+
+- Never write into this repo's `base/` or `packs/` directories. Target paths are always under `$HOME/.codex/skills`, `$HOME/.claude/skills`, or an explicitly-supplied personal fork path.
+- Do not create extra docs beyond `SKILL.md` unless asked.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.
+

package/packs/skill-dev/codex/skill-interview/ALIGNMENT-PAGE.md

@@ -9,6 +9,8 @@ When this skill produces durable deliverables (research, specs, plans, reports,
 
 The tier is set per skill via `visual_tier` in SKILL.md frontmatter (or detected by the upgrade script). The bundled ALIGNMENT-PAGE.md receives tier-appropriate rendering guidance from the generator.
 
+**Context intake.** This skill declares `context_intake: deep` (Deep interview). Gather repo/project context before asking, present an assumptions manifest when the contract requires it, ask focused questions, and confirm coverage before building review artifacts.
+
 **Alignment lifecycle.** Alignment pages have three lifecycle states. `review` is the draft/pre-approval page: it contains the complete deliverable preview, evidence, required inline gate questions, section feedback controls, local section-feedback YAML only after a section feedback choice is selected, and one bottom `Compile Responses` control. `confirmed` is the post-approval page after the agent has consumed final compiled response YAML, made any approved user-requested edits, and written or updated the approved canonical artifacts. A confirmed page is finished and current for the completed alignment cycle, but it remains amendable when later research changes or extends the conclusions. `amended` is a future revision of a confirmed page: archive the previous confirmed page first, mark what changed, preserve the prior approval record, and highlight the new evidence, decisions, or scope that changed the earlier conclusion.
 
 **Central alignment index.** When a research-producing skill writes or updates an HTML alignment page, also maintain the repository's central alignment index. Look for `alignment/index.html` at the repository root; if the target repo documents a different central alignment-index path, use that path and report it. If the index does not exist, create it as a self-contained HTML page that works from `file://`, links to every active `alignment/*.html` page except itself, and includes the newly written page. Every index entry must include the page's alignment date in a muted meta span after the link, formatted `YYYY-MM-DD`, for example `<a href="page.html">Title</a> <span class="meta">2026-06-09</span>`. The alignment date is the review or confirmed date written inside the page itself; new pages use today's date. If the index exists, update it instead of blindly appending: preserve valid existing entries, metadata, and entry dates; remove duplicate entries for the same page path; keep links repo-relative; and include the new or updated page. When updating an existing index, add a date only to entries that are missing one, deriving it from the page's internal alignment date, or from file history when the page has no internal date. If a `new` marker is used, combine it with the date as `<span class="meta">new · YYYY-MM-DD</span>`, and remove stale `new` markers from entries that are no longer the latest addition.
@@ -57,7 +59,9 @@ The tier is set per skill via `visual_tier` in SKILL.md frontmatter (or detected
 
 **Report-only research gates.** For report-only or pre-approval research skills, the first `review` alignment page must explicitly contain proposed research scope, source plan, assumptions/confidence, recommended output path, proposed file changes, and approval gates before synthesized research begins and before any working packet, canonical research, spec, or task file is created or updated.
 
-**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, and research-scope approval gates. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-skill-interview-research.md`; product-path mode uses `research/{slug}/_working/preliminary-skill-interview-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the full preliminary packet, evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, research-scope approval gates, and a `Stage 2 Preview / Expected Review Format` section that shows the future Stage 2 review shape before research starts. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-skill-interview-research.md`; product-path mode uses `research/{slug}/_working/preliminary-skill-interview-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the complete working-packet substance as structured HTML review UI: purpose-built sections, tables, matrices, gates, cards, and tier-appropriate charts or diagrams that preserve every packet section, finding, caveat, and decision detail without summary loss. Raw Markdown packet text may appear only as a supplemental source view after the rendered review UI; do not make a `Full Preliminary Packet` or `Full Working Packet` raw Markdown dump, giant `<pre><code>` block, link-only view, or source-only view the primary review surface. Include the evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+
+**Stage 2 review-page template.** Stage 1 scope-review pages must include a `Stage 2 Preview / Expected Review Format` section that previews the exact section sequence, table shapes, evidence treatment, visual density, and approval gates the user will see after research; make it specific enough for the user to flag preferred content formats, grouping, labels, visuals, and evidence density before the agent does heavy research. After scope approval and research, the Stage 2 review page must include these sections as structured HTML, not as raw Markdown dumps: `Research Scope Approved` status block with approved scope, source plan, output paths, and unresolved caveats; `Executive Findings` or a skill-specific top-findings section with confidence labels; `Evidence Matrix` mapping claim, evidence/source/path, inference, confidence, assumptions, and decision impact; `Working Packet Review` with the complete working-packet substance rendered as purpose-built HTML sections, lists, tables, matrices, cards, and tier-appropriate charts or diagrams; `Alternatives / Rejected or Lower-Confidence Findings`; `Source Coverage & Gaps`; `Assumptions / Confidence Register`; `Proposed Canonical Artifacts & File Changes`; a required `User Format Preferences` gate asking whether the layout, tables, grouping, visuals, labels, and evidence density match expectations; and a required `Final Artifact Approval` gate for Stage 3 readiness. Raw Markdown packet text, search logs, or source notes may appear only as supplemental source views after the rendered review UI and never replace the Stage 2 review sections.
 
 **Required inline questions.** In `review` pages, each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: "Other / None of the above" backed by a multi-line text box for free-form input, and "Need clarification" backed by an optional notes box where the user can explain what is unclear. When any radio option other than "Other" or "Need clarification" is selected, show an optional "Additional notes" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom "Decisions & Clarifications" section. Confirmed pages must not keep these as required input controls; render the answered decisions as read-only records.
 

package/packs/skill-dev/codex/skill-interview/SKILL.md

@@ -4,7 +4,7 @@ description: Interview the user to define the characteristics of a skill they wa
 type: planning
 version: v0.2
 argument-hint: "[skill-name-or-topic]"
-interview_depth: full
+context_intake: deep
 ---
 
 # Skill Interview
@@ -22,7 +22,7 @@ Use this skill when the user wants to create or substantially redesign a skill b
    - If the user wants an experimental personal skill under `~/.codex/skills`, plan for `$create-local-skill`; otherwise default to repo-managed `$create-agentic-skill`.
 
 2. **Gather local evidence before probing.**
-   - Search for overlapping skills in the active skill list and repository paths such as `global/codex/`, `global/claude/`, and `packs/*/{codex,claude}/`.
+   - Search for overlapping skills in the active skill list and repository paths such as `base/codex/`, `base/claude/`, and `packs/*/{codex,claude}/`.
    - Read the closest existing skill contracts and any relevant `tasks/lessons.md` entries before asking detailed questions.
    - If an existing skill already covers the request, explain the overlap and ask whether the user wants an update, alias, narrower variant, or new skill.
 
@@ -91,10 +91,10 @@ Use this skill when the user wants to create or substantially redesign a skill b
 
 After writing the brief and interview log, recommend exactly one next command:
 
-- `$create-agentic-skill <skill-name>` for repo-managed global skills.
+- `$create-agentic-skill <skill-name>` for repo-managed base skills.
 - `$create-local-skill <skill-name>` for personal local-only skills.
 - `$targeted-skill-builder <existing-skill> <gap>` when the interview found that an existing skill should be updated instead of creating a new skill.
-- `$pack` or a pack-local creation route when the skill belongs inside a project-local pack rather than global skills.
+- `$pack` or a pack-local creation route when the skill belongs inside a project-local pack rather than base skills.
 
 Output exactly two lines beyond the normal report:
 

package/packs/skill-dev/codex/targeted-skill-builder/ALIGNMENT-PAGE.md

@@ -57,7 +57,9 @@ The tier is set per skill via `visual_tier` in SKILL.md frontmatter (or detected
 
 **Report-only research gates.** For report-only or pre-approval research skills, the first `review` alignment page must explicitly contain proposed research scope, source plan, assumptions/confidence, recommended output path, proposed file changes, and approval gates before synthesized research begins and before any working packet, canonical research, spec, or task file is created or updated.
 
-**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, and research-scope approval gates. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-targeted-skill-builder-research.md`; product-path mode uses `research/{slug}/_working/preliminary-targeted-skill-builder-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the full preliminary packet, evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, research-scope approval gates, and a `Stage 2 Preview / Expected Review Format` section that shows the future Stage 2 review shape before research starts. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-targeted-skill-builder-research.md`; product-path mode uses `research/{slug}/_working/preliminary-targeted-skill-builder-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the complete working-packet substance as structured HTML review UI: purpose-built sections, tables, matrices, gates, cards, and tier-appropriate charts or diagrams that preserve every packet section, finding, caveat, and decision detail without summary loss. Raw Markdown packet text may appear only as a supplemental source view after the rendered review UI; do not make a `Full Preliminary Packet` or `Full Working Packet` raw Markdown dump, giant `<pre><code>` block, link-only view, or source-only view the primary review surface. Include the evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+
+**Stage 2 review-page template.** Stage 1 scope-review pages must include a `Stage 2 Preview / Expected Review Format` section that previews the exact section sequence, table shapes, evidence treatment, visual density, and approval gates the user will see after research; make it specific enough for the user to flag preferred content formats, grouping, labels, visuals, and evidence density before the agent does heavy research. After scope approval and research, the Stage 2 review page must include these sections as structured HTML, not as raw Markdown dumps: `Research Scope Approved` status block with approved scope, source plan, output paths, and unresolved caveats; `Executive Findings` or a skill-specific top-findings section with confidence labels; `Evidence Matrix` mapping claim, evidence/source/path, inference, confidence, assumptions, and decision impact; `Working Packet Review` with the complete working-packet substance rendered as purpose-built HTML sections, lists, tables, matrices, cards, and tier-appropriate charts or diagrams; `Alternatives / Rejected or Lower-Confidence Findings`; `Source Coverage & Gaps`; `Assumptions / Confidence Register`; `Proposed Canonical Artifacts & File Changes`; a required `User Format Preferences` gate asking whether the layout, tables, grouping, visuals, labels, and evidence density match expectations; and a required `Final Artifact Approval` gate for Stage 3 readiness. Raw Markdown packet text, search logs, or source notes may appear only as supplemental source views after the rendered review UI and never replace the Stage 2 review sections.
 
 **Required inline questions.** In `review` pages, each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: "Other / None of the above" backed by a multi-line text box for free-form input, and "Need clarification" backed by an optional notes box where the user can explain what is unclear. When any radio option other than "Other" or "Need clarification" is selected, show an optional "Additional notes" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom "Decisions & Clarifications" section. Confirmed pages must not keep these as required input controls; render the answered decisions as read-only records.
 

package/packs/skill-dev/codex/targeted-skill-builder/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## v0.4 - 2026-06-13
+
+- Validation and reload steps use `npx skillpacks refresh` instead of the removed `./init.sh`.
+
 ## v0.3 - 2026-06-09
 
 - Updated Skills Showcase refresh commands to use app-owned generator and validator paths after the workspace split.

package/packs/skill-dev/codex/targeted-skill-builder/SKILL.md

@@ -2,7 +2,7 @@
 name: targeted-skill-builder
 description: Build or update one specific skill from a concrete workflow gap, correction, or repeated bad recommendation
 type: execution
-version: v0.3
+version: v0.4
 argument-hint: "[workflow gap, correction, skill name, or capability request]"
 ---
 
@@ -35,7 +35,7 @@ This is intentionally narrower than `$analyze-sessions`. Do not scan all Claude/
    - If examples are needed, ask for them or run a tightly scoped history query limited by path, skill name, date range, or exact phrase.
    - Do not scan all session history unless explicitly requested.
 5. Search existing skills for overlap before creating anything:
-   - Search `global/claude`, `global/codex`, `packs`, and project-local `.claude/skills` or `.codex/skills` when present.
+   - Search `base/claude`, `base/codex`, `packs`, and project-local `.claude/skills` or `.codex/skills` when present.
    - Compare name, description, workflow, and next-step routing behavior.
    - If an existing skill substantially covers the job, recommend updating that skill instead of adding a duplicate.
 6. Decide the smallest durable fix:
@@ -44,14 +44,14 @@ This is intentionally narrower than `$analyze-sessions`. Do not scan all Claude/
    - Reusable prompt/template: choose this when the behavior is too situational or not stable enough for a skill.
    - No repository change: choose this when the request is already covered and only needs a usage note.
 7. Resolve the destination:
-   - Default new shared Claude/Codex skills to this repository: `/Users/georgele/projects/tools/agentic-skills/global/claude/<name>/SKILL.md` and `/Users/georgele/projects/tools/agentic-skills/global/codex/<name>/SKILL.md`.
+   - Default new shared Claude/Codex skills to this repository: `/Users/georgele/projects/tools/agentic-skills/base/claude/<name>/SKILL.md` and `/Users/georgele/projects/tools/agentic-skills/base/codex/<name>/SKILL.md`.
    - If the current session is not in the agentic-skills repository and the user wants to audit or amend an existing shared skill, do not edit a local copy. Provide a concise prompt for the user to run from `/Users/georgele/projects/tools/agentic-skills` with the target skill path and requested adjustment.
    - Use user-local `~/.claude/skills` or `~/.codex/skills` only when the user explicitly asks for a personal/local skill.
 8. If creating or updating a repository skill:
    - Follow existing frontmatter conventions: `name`, specific `description`, `type`, `version`, and `argument-hint` when useful.
    - Keep `SKILL.md` concise and operational.
    - Include clear trigger conditions, workflow steps, outputs, constraints, and next-step routing for mutation-capable skills.
-   - For Codex global skills, add `agents/openai.yaml` with display name, short description, default prompt, and implicit-invocation policy.
+   - For Codex base skills, add `agents/openai.yaml` with display name, short description, default prompt, and implicit-invocation policy.
    - Update `tests/harness/bench-coverage.ts` for every new repository skill or material skill behavior update.
    - Add/register a deterministic custom setup under `tests/layer4/setups/` when practical, or record an explicit blocked row with `blocked_reason` and `next_command` when coverage depends on unsafe or external conditions.
    - For custom setup work, include a deterministic output-quality rubric when practical. Prefer fixture fact coverage, concrete file/command references, expected next-route handoffs, specificity checks, reference traits, and forbidden-fabrication checks over broad prose judgments.
@@ -61,7 +61,7 @@ This is intentionally narrower than `$analyze-sessions`. Do not scan all Claude/
    - Store it only when the user asks for a file or the current repo has an obvious prompt/template location.
    - Otherwise output the reusable prompt directly.
 10. Run validation after repository skill changes:
-    - `./init.sh`
+    - `npx skillpacks refresh` (recreate project-local base/pack skill installs from the changed sources)
     - `./scripts/skill-deps.sh --broken`
     - `./scripts/skill-versions.sh --missing`
     - `./scripts/skill-next-step-routing.sh --missing`
@@ -86,7 +86,7 @@ Produce a concise report with:
 - Existing-skill overlap findings.
 - Files created or changed, if any, including generated showcase assets when skill metadata or behavior changed.
 - Validation results.
-- Reload note: after `./init.sh`, tell the user the runner-specific reload path. Claude Code should run `/reload-skills` first; `/clear` starts a new empty-context conversation and 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.
+- Reload note: after `npx skillpacks refresh`, tell the user the runner-specific reload path. Claude Code should run `/reload-skills` first; `/clear` starts a new empty-context conversation and 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.
 
 When an external project session needs an existing shared skill amended, output a prompt like:
 

package/packs/skill-dev/codex/targeted-skill-builder/archive/v0.3/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: targeted-skill-builder
+description: Build or update one specific skill from a concrete workflow gap, correction, or repeated bad recommendation
+type: execution
+version: v0.3
+argument-hint: "[workflow gap, correction, skill name, or capability request]"
+---
+
+# Targeted Skill Builder
+
+Invoke as `$targeted-skill-builder`.
+
+Use this skill when the user wants a narrow, durable workflow improvement from the current prompt or conversation: a concrete problem, user correction, repeated bad recommendation, or capability gap that may deserve a new skill, an existing-skill update, or a reusable prompt/template.
+
+This is intentionally narrower than `$analyze-sessions`. Do not scan all Claude/Codex history by default. Treat broad session analysis as optional evidence only when the user explicitly asks for it. Use `$session-triage` first when one immediate issue, correction, repo incident, or suspected skill failure still needs verification before a skill change is designed.
+
+## Process
+
+1. Read `tasks/lessons.md` first when it exists. Extract only correction patterns relevant to the user's current request.
+2. Identify the narrow workflow gap:
+   - Problem or correction.
+   - Triggering context from the current prompt/conversation.
+   - Bad recommendation or missing capability to prevent.
+   - Desired future behavior.
+3. Ask for the intended output unless the user already made it explicit:
+   - New skill.
+   - Update existing skill.
+   - Reusable prompt/template only.
+   - Unsure, recommend.
+4. Gather only targeted evidence:
+   - Use the current prompt and conversation context first.
+   - Read a named skill file when provided.
+   - Inspect user-provided files or paths when provided.
+   - Route to `$session-triage` when the user wants investigation of one immediate issue or the available evidence is not enough to verify the correction.
+   - If examples are needed, ask for them or run a tightly scoped history query limited by path, skill name, date range, or exact phrase.
+   - Do not scan all session history unless explicitly requested.
+5. Search existing skills for overlap before creating anything:
+   - Search `base/claude`, `base/codex`, `packs`, and project-local `.claude/skills` or `.codex/skills` when present.
+   - Compare name, description, workflow, and next-step routing behavior.
+   - If an existing skill substantially covers the job, recommend updating that skill instead of adding a duplicate.
+6. Decide the smallest durable fix:
+   - New skill: choose this only when no existing skill owns the workflow and the behavior is repeatable.
+   - Existing skill update: choose this when the fix is a missing branch, constraint, evidence gate, or routing correction inside an existing workflow.
+   - Reusable prompt/template: choose this when the behavior is too situational or not stable enough for a skill.
+   - No repository change: choose this when the request is already covered and only needs a usage note.
+7. Resolve the destination:
+   - Default new shared Claude/Codex skills to this repository: `/Users/georgele/projects/tools/agentic-skills/base/claude/<name>/SKILL.md` and `/Users/georgele/projects/tools/agentic-skills/base/codex/<name>/SKILL.md`.
+   - If the current session is not in the agentic-skills repository and the user wants to audit or amend an existing shared skill, do not edit a local copy. Provide a concise prompt for the user to run from `/Users/georgele/projects/tools/agentic-skills` with the target skill path and requested adjustment.
+   - Use user-local `~/.claude/skills` or `~/.codex/skills` only when the user explicitly asks for a personal/local skill.
+8. If creating or updating a repository skill:
+   - Follow existing frontmatter conventions: `name`, specific `description`, `type`, `version`, and `argument-hint` when useful.
+   - Keep `SKILL.md` concise and operational.
+   - Include clear trigger conditions, workflow steps, outputs, constraints, and next-step routing for mutation-capable skills.
+   - For Codex base skills, add `agents/openai.yaml` with display name, short description, default prompt, and implicit-invocation policy.
+   - Update `tests/harness/bench-coverage.ts` for every new repository skill or material skill behavior update.
+   - Add/register a deterministic custom setup under `tests/layer4/setups/` when practical, or record an explicit blocked row with `blocked_reason` and `next_command` when coverage depends on unsafe or external conditions.
+   - For custom setup work, include a deterministic output-quality rubric when practical. Prefer fixture fact coverage, concrete file/command references, expected next-route handoffs, specificity checks, reference traits, and forbidden-fabrication checks over broad prose judgments.
+   - If deterministic quality scoring is not reliable for the skill, record the blocked/deferred quality rationale in the setup review notes or coverage follow-up instead of shipping only silent hard assertions.
+   - Update skill discovery docs and routing docs only when the new or changed skill must be discoverable or routed by other skills.
+9. If writing a reusable prompt/template only:
+   - Store it only when the user asks for a file or the current repo has an obvious prompt/template location.
+   - Otherwise output the reusable prompt directly.
+10. Run validation after repository skill changes:
+    - `./init.sh`
+    - `./scripts/skill-deps.sh --broken`
+    - `./scripts/skill-versions.sh --missing`
+    - `./scripts/skill-next-step-routing.sh --missing`
+    - `pnpm --dir tests bench:coverage`
+    - Focused layer1 benchmark setup tests when `tests/harness/bench-coverage.ts`, `tests/harness/bench-setups.ts`, or `tests/layer4/setups/` changed.
+    - If any tracked `SKILL.md` or `PACK.md` behavior or metadata changed, refresh the Skills Showcase data:
+      - `node apps/skills-showcase/scripts/generate-skills-showcase-data.mjs`
+      - `node apps/skills-showcase/scripts/generate-skills-showcase-github-data.mjs`
+      - `apps/skills-showcase/scripts/validate-skills-showcase-data.sh`
+    - Review curated showcase copy, catalog grouping, workflow animation text, and proof receipts when the skill change could affect the public website; update those files or record why no curated website copy changed.
+    - Targeted `rg` checks for the behavior being changed.
+    - `git diff --check`
+11. Update `tasks/todo.md` review notes with validation results.
+12. Commit and push per the repository contract when tracked files changed.
+
+## Output
+
+Produce a concise report with:
+
+- Decision: new skill, existing-skill update, reusable prompt/template, or no repository change.
+- Evidence used and evidence intentionally skipped.
+- Existing-skill overlap findings.
+- Files created or changed, if any, including generated showcase assets when skill metadata or behavior changed.
+- Validation results.
+- Reload note: after `./init.sh`, tell the user the runner-specific reload path. Claude Code should run `/reload-skills` first; `/clear` starts a new empty-context conversation and 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.
+
+When an external project session needs an existing shared skill amended, output a prompt like:
+
+```text
+From /Users/georgele/projects/tools/agentic-skills, run targeted-skill-builder for:
+- Target skill: <path or skill name>
+- Problem: <concrete correction or workflow gap>
+- Desired change: <specific behavior>
+- Evidence: <small scoped files/examples>
+- Preferred output: update existing skill
+```
+
+## Constraints
+
+- Prefer the smallest durable workflow fix.
+- Do not create a broad meta-skill when a precise skill, existing-skill update, or reusable prompt solves the problem.
+- Do not route every idea to `$spec-interview`; use `$feature-interview` when the planning destination is uncertain.
+- Treat broad `$analyze-sessions` work as optional evidence for recurrence and trend analysis, not the default workflow.
+- Use `$session-triage` for one immediate issue, correction, repo incident, or suspected skill failure that needs verification before building or updating a skill.
+- Do not read unrelated history, projects, or private files for examples without user direction.
+- Do not create or modify GitHub Actions workflows.
+
+## Alignment Page
+
+When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment/targeted-skill-builder-{topic}.html`.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.