@laitszkin/apollo-toolkit 3.6.1 → 3.6.3

package/CHANGELOG.md

@@ -7,6 +7,16 @@ All notable changes to this repository are documented in this file.
 ### Added
 - (None yet)
 
+## [v3.6.3] - 2026-04-28
+
+### Changed
+- Extend `implement-specs-with-subagents` with multi-phase execution: analyse spec dependencies from `coordination.md`, build phased delegation plans via topological sort, execute phases sequentially with parallel subagents per phase, and merge completed spec branches back via `merge-changes-from-local-branches` between phases.
+
+## [v3.6.2] - 2026-04-28
+
+### Changed
+- Normalize `AGENTS.md` references to `AGENTS.md/CLAUDE.md` across the skill catalog for CLAUDE.md awareness.
+
 ## [v3.6.1] - 2026-04-28
 
 ### Added

package/archive-specs/SKILL.md

@@ -7,7 +7,7 @@ description: Convert completed project plan sets into maintainable project docum
 
 ## Dependencies
 
-- Required: `align-project-documents` to align repository docs with current code before archiving, and `maintain-project-constraints` to synchronize `AGENTS.md` after the doc update.
+- Required: `align-project-documents` to align repository docs with current code before archiving, and `maintain-project-constraints` to synchronize `AGENTS.md/CLAUDE.md` after the doc update.
 - Conditional: none.
 - Optional: none.
 - Fallback: not applicable.
@@ -15,9 +15,9 @@ description: Convert completed project plan sets into maintainable project docum
 ## Standards
 
 - Evidence: Treat code, config, deployment files, and current spec files as evidence sources; never guess when a detail is missing.
-- Execution: Inventory all relevant specs first, reconcile them with the current repository, use `align-project-documents` to update durable project docs, use `maintain-project-constraints` to refresh `AGENTS.md` when repository guidance changed, then archive only the truly consumed planning artifacts.
+- Execution: Inventory all relevant specs first, reconcile them with the current repository, use `align-project-documents` to update durable project docs, use `maintain-project-constraints` to refresh `AGENTS.md/CLAUDE.md` when repository guidance changed, then archive only the truly consumed planning artifacts.
 - Quality: Prefer source-of-truth behavior over stale plan text, align existing docs to the same standard structure, and call out unknowns explicitly instead of inventing missing setup details.
-- Output: Produce synchronized durable docs (`README.md`, categorized project docs, and `AGENTS.md` when needed), then archive or remove superseded spec files after the conversion is complete.
+- Output: Produce synchronized durable docs (`README.md`, categorized project docs, and `AGENTS.md/CLAUDE.md` when needed), then archive or remove superseded spec files after the conversion is complete.
 
 ## Goal
 
@@ -87,7 +87,7 @@ Ensure the split project docs cover all of the following:
 - `docs/README.md` should act as the reference list for the categorized docs.
 - Each category doc should stay focused on one topic instead of acting like another monolithic handbook.
 - Remove template placeholders and stale planning language before finishing.
-- After the docs are aligned, run `maintain-project-constraints` whenever the documentation changes imply `AGENTS.md` needs to reflect updated workflows, commands, or repository capabilities.
+- After the docs are aligned, run `maintain-project-constraints` whenever the documentation changes imply `AGENTS.md/CLAUDE.md` needs to reflect updated workflows, commands, or repository capabilities.
 
 ### 7) Archive superseded spec files after successful conversion
 

package/commit-and-push/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Commit and Push"
   short_description: "Submit local changes with commit and push only"
-  default_prompt: "Use $commit-and-push to inspect the current git state and classify the diff. Treat every conditional gate whose scenario is met as blocking before any commit: if the change set includes code changes, run $review-change-set; if the reviewed risk profile says edge-case or security review is needed, run $discover-edge-cases and $harden-app-security as blocking gates too; if completed specs should be converted or docs need normalization, ensure $archive-specs runs through $submission-readiness-check; if changelog synchronization is needed, complete it before continuing. Then run any additional required code-quality skills, hand the repository to $submission-readiness-check so it can synchronize completed plan archives, project docs, AGENTS.md, and CHANGELOG.md before any commit, confirm root CHANGELOG.md Unreleased reflects the actual pending change set, preserve user staging intent, create a concise Conventional Commit, and push to the intended branch without any versioning or release steps."
+  default_prompt: "Use $commit-and-push to inspect the current git state and classify the diff. Treat every conditional gate whose scenario is met as blocking before any commit: if the change set includes code changes, run $review-change-set; if the reviewed risk profile says edge-case or security review is needed, run $discover-edge-cases and $harden-app-security as blocking gates too; if completed specs should be converted or docs need normalization, ensure $archive-specs runs through $submission-readiness-check; if changelog synchronization is needed, complete it before continuing. Then run any additional required code-quality skills, hand the repository to $submission-readiness-check so it can synchronize completed plan archives, project docs, AGENTS.md/CLAUDE.md, and CHANGELOG.md before any commit, confirm root CHANGELOG.md Unreleased reflects the actual pending change set, preserve user staging intent, create a concise Conventional Commit, and push to the intended branch without any versioning or release steps."

package/feature-propose/README.md

@@ -7,8 +7,8 @@ It guides the agent to:
 2. Classify user-facing functions into MVP / Important / Enhancement / Performance.
 3. Propose numbered feature recommendations with clear implementation direction.
 4. Publish accepted proposals through `open-github-issue` with reason and suggested architecture.
-5. Record accepted feature proposals in `AGENTS.md`.
-6. Remove implemented proposals from `AGENTS.md` after delivery.
+5. Record accepted feature proposals in `AGENTS.md/CLAUDE.md`.
+6. Remove implemented proposals from `AGENTS.md/CLAUDE.md` after delivery.
 
 ## Repository layout
 

package/feature-propose/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: feature-propose
-description: Professional product-management workflow for proposing features from an existing codebase. Use when the user asks to understand an application, classify features from a user perspective into MVP/Important/Enhancement/Performance tiers, ask 3-5 clarifying questions when needed, propose numbered feature recommendations, publish accepted proposals through `open-github-issue`, record accepted items in AGENTS.md, and remove implemented items from AGENTS.md.
+description: Professional product-management workflow for proposing features from an existing codebase. Use when the user asks to understand an application, classify features from a user perspective into MVP/Important/Enhancement/Performance tiers, ask 3-5 clarifying questions when needed, propose numbered feature recommendations, publish accepted proposals through `open-github-issue`, record accepted items in AGENTS.md/CLAUDE.md, and remove implemented items from AGENTS.md/CLAUDE.md.
 ---
 
 # Feature Propose
@@ -10,7 +10,7 @@ description: Professional product-management workflow for proposing features fro
 - Required: none.
 - Conditional: `open-github-issue` for accepted features that should be published as GitHub issues.
 - Optional: none.
-- Fallback: If issue publication is skipped or unavailable, keep accepted proposals synchronized in `AGENTS.md` and report the publication state explicitly.
+- Fallback: If issue publication is skipped or unavailable, keep accepted proposals synchronized in `AGENTS.md/CLAUDE.md` and report the publication state explicitly.
 
 ## Standards
 
@@ -21,7 +21,7 @@ description: Professional product-management workflow for proposing features fro
 
 ## Overview
 
-Act as a professional PM: build a complete understanding of the current product from code, classify capabilities by user value, propose prioritized features, publish accepted proposals through `open-github-issue`, persist accepted proposals in `AGENTS.md`, and keep the list clean by removing implemented items.
+Act as a professional PM: build a complete understanding of the current product from code, classify capabilities by user value, propose prioritized features, publish accepted proposals through `open-github-issue`, persist accepted proposals in `AGENTS.md/CLAUDE.md`, and keep the list clean by removing implemented items.
 
 ## References
 
@@ -36,7 +36,7 @@ Load these references as needed during classification:
 
 ### 1) Explore the codebase before proposing anything
 
-- Read repo-level guidance first (`AGENTS.md`, `README`, major docs).
+- Read repo-level guidance first (`AGENTS.md/CLAUDE.md`, `README`, major docs).
 - Map architecture, entrypoints, user-facing flows, data models, and external integrations.
 - Identify implemented features, obvious gaps, and technical constraints from code and tests.
 - Summarize findings before moving to prioritization.
@@ -72,17 +72,17 @@ Load these references as needed during classification:
   - Acceptance criteria
 - Keep proposals focused and minimal; avoid over-engineering.
 
-### 5) Persist accepted features to AGENTS.md, publish them, and clean up after implementation
+### 5) Persist accepted features to AGENTS.md/CLAUDE.md, publish them, and clean up after implementation
 
 - Ask the user to accept/reject/edit features by number.
-- Once accepted, update repo-root `AGENTS.md` with a dedicated section:
+- Once accepted, update repo-root `AGENTS.md/CLAUDE.md` with a dedicated section:
   - `## Accepted Feature Proposals`
 - Append accepted features as a numbered list with:
   - Date (`YYYY-MM-DD`)
   - Type (`MVP`, `Important`, `Enhancement`, `Performance`)
   - Short feature statement
-- Preserve existing `AGENTS.md` content and style; do not rewrite unrelated sections.
-- If `AGENTS.md` does not exist, ask before creating it.
+- Preserve existing `AGENTS.md/CLAUDE.md` content and style; do not rewrite unrelated sections.
+- If `AGENTS.md/CLAUDE.md` does not exist, ask before creating it.
 - For each accepted feature, invoke `open-github-issue` exactly once with feature-proposal content.
 - Default to publishing accepted features unless the user explicitly says not to create GitHub issues.
 - Pass these fields to `open-github-issue`:
@@ -94,7 +94,7 @@ Load these references as needed during classification:
   - `repo`: target repository in `owner/repo` format when known
 - If invoking the publisher CLI directly, pass accepted proposal details through `apltk open-github-issue --payload-file <json>` or `@file` inputs rather than inline shell arguments so Markdown and code identifiers remain literal.
 - Reuse the returned `mode`, `issue_url`, and `publish_error` in the response.
-- After the related feature is implemented, remove that feature entry from `## Accepted Feature Proposals` in `AGENTS.md`.
+- After the related feature is implemented, remove that feature entry from `## Accepted Feature Proposals` in `AGENTS.md/CLAUDE.md`.
 - Remove only implemented items; keep unimplemented accepted items untouched.
 
 ## Output template

package/implement-specs-with-subagents/SKILL.md

@@ -3,33 +3,38 @@ name: implement-specs-with-subagents
 description: >-
   Coordinate parallel implementation of multiple approved spec sets by assigning
   each `docs/plans/.../<change_name>/` spec directory to a separate subagent that
-  uses `implement-specs-with-worktree`. Use when a user asks to implement a
-  multi-spec batch with subagents, parallel agents, delegated agents, or isolated
-  workers while completing any explicitly documented shared prerequisite work
-  before delegation, keeping at most four implementation subagents active at
-  once, staggering starts to avoid rate-limit bursts, preserving independent
-  subagent contexts, and using the user's requested model when specified.
+  uses `implement-specs-with-worktree`. Supports multi-phase execution for
+  interdependent specs: analyse dependencies, implement base specs first, merge
+  back via `merge-changes-from-local-branches`, then implement dependent specs,
+  and finally submit with commit, push, and patch version bump. Use when a user
+  asks to implement a multi-spec batch with subagents, parallel agents, delegated
+  agents, or isolated workers while completing any explicitly documented shared
+  prerequisite work before delegation, keeping at most four implementation
+  subagents active at once, staggering starts to avoid rate-limit bursts,
+  preserving independent subagent contexts, and using the user's requested model
+  when specified.
 ---
 
-# Implement Specs with Subagents
+# Implement Specs with Subagents (Multi-Phase)
 
 ## Dependencies
 
 - Required: `implement-specs-with-worktree` for each delegated spec implementation.
+- Required: `merge-changes-from-local-branches` for merging worktree branches back between phases.
 - Conditional: `generate-spec` if the batch needs clarification before implementation; `review-change-set` if the user asks for an integration review after subagents finish.
 - Optional: none.
 - Fallback: If the environment cannot start independent subagents, report that limitation and fall back only if the user explicitly approves serial `implement-specs-with-worktree` execution.
 
 ## Standards
 
-- Evidence: Read the batch-level `coordination.md` and `preparation.md` when present, enumerate the exact spec directories to implement, verify each delegated spec has the required planning files, and identify any explicit prerequisite notes before starting subagents.
-- Execution: Complete and commit explicitly documented prerequisite preparation on the working branch before delegation, then assign exactly one implementation subagent per spec directory, keep no more than four implementation subagents active at the same time, start subagents one at a time rather than in a burst, give each subagent an independent task-local context, and instruct every subagent to use `implement-specs-with-worktree` for its assigned spec.
+- Evidence: Read the batch-level `coordination.md` and `preparation.md` when present, enumerate the exact spec directories to implement, verify each delegated spec has the required planning files, and identify any explicit prerequisite or dependency notes before starting subagents.
+- Execution: Complete and commit explicitly documented prerequisite preparation on the working branch before delegation. Analyse spec dependencies from `coordination.md` and spec docs to build a multi-phase plan. For each phase, assign exactly one implementation subagent per spec directory, keep no more than four implementation subagents active at the same time, start subagents one at a time rather than in a burst, give each subagent an independent task-local context, and instruct every subagent to use `implement-specs-with-worktree` for its assigned spec. After each phase completes, use `merge-changes-from-local-branches` to merge all phase branches back before launching the next phase.
 - Quality: Preserve spec ownership boundaries, avoid duplicate delegation for the same spec, ensure subagents branch from a baseline that includes prerequisite commits, track branch/worktree/commit/test outcomes for every subagent, and pause new launches when a shared blocker, collision, or rate-limit pressure appears.
-- Output: Return a concise implementation ledger covering each spec, its subagent result, worktree branch, commit or blocker, verification run, and any integration follow-up needed.
+- Output: Return a concise implementation ledger covering each spec, its subagent result, worktree branch, commit or blocker, verification run, and the merge outcome.
 
 ## Goal
 
-Coordinate a multi-spec implementation batch safely by delegating each approved spec set to an isolated subagent-backed worktree implementation.
+Coordinate a multi-spec implementation batch safely by delegating each approved spec set to an isolated subagent-backed worktree implementation, handling interdependent specs through phased execution.
 
 ## Workflow
 
@@ -61,15 +66,37 @@ Coordinate a multi-spec implementation batch safely by delegating each approved
 - Do not start implementation subagents until the preparation commit exists and the working branch is clean.
 - If preparation cannot be completed or verified, stop and report the blocker instead of launching subagents.
 
-### 2) Build a delegation plan
+### 2) Analyse spec dependencies
 
-- Create one queue item per spec directory.
+- Read each in-scope spec's `spec.md` and `design.md` to identify explicit references to other in-scope specs.
+- Read `coordination.md` for any documented dependency ordering between specs (e.g. "spec A must be implemented before spec B").
+- For each spec dependency found, determine which specs are **base specs** (depended upon by others) and which are **dependent specs** (depend on base specs).
+- If a spec both depends on others and is depended upon, it belongs to its own middle phase.
+- If no dependencies exist between any specs, all specs can run in a single parallel phase.
+- Build a dependency graph and record it in the ledger:
+  - spec path
+  - phase number (starting from 1)
+  - depends-on (list of spec paths)
+  - depended-by (list of spec paths)
+- If the dependency graph contains a cycle, stop and report the cycle instead of proceeding.
+
+### 3) Build a multi-phase delegation plan
+
+- Group specs into ordered phases based on the dependency graph (topological sort order):
+  - **Phase 1**: Base specs with no in-batch dependencies (depended upon by others).
+  - **Phase N**: Specs whose dependencies are all satisfied by earlier phases.
+  - **Final Phase**: Specs with no dependents (leaf specs).
+- Each phase must have all its dependencies satisfied by earlier phases before it can start.
+- Within each phase, specs are independent and can run in parallel.
+- Create one queue item per spec directory per phase.
 - Assign one subagent to one spec only; never ask one subagent to implement multiple spec directories.
 - Keep a visible ledger with:
   - spec path
+  - phase number
+  - depends-on
   - intended branch/worktree name if known
   - assigned subagent
-  - status
+  - status (pending / in-progress / merged / blocked)
   - commit
   - tests
   - blockers
@@ -79,7 +106,11 @@ Coordinate a multi-spec implementation batch safely by delegating each approved
   - If the user does not specify a model, let subagents use the same model or default model policy as the coordinating agent.
   - If the environment does not expose model selection, state that the requested model cannot be enforced and continue only when the platform's default subagent model is acceptable.
 
-### 3) Launch subagents gradually
+### 4) Execute phases sequentially
+
+For each phase in order (Phase 1, Phase 2, ... Final Phase):
+
+#### 4.1) Launch subagents for this phase
 
 - Maintain a maximum of four active implementation subagents at any time.
 - Start subagents independently and one at a time.
@@ -87,7 +118,7 @@ Coordinate a multi-spec implementation batch safely by delegating each approved
 - If a start fails due to throttling, rate limits, capacity, or platform pressure, wait before retrying and do not start additional subagents during the cooldown.
 - Prefer steady scheduling over maximum burst parallelism; four is the ceiling, not a target that must always be filled.
 
-### 4) Give each subagent independent context
+#### 4.2) Give each subagent independent context
 
 For each subagent, provide only task-local instructions:
 
@@ -105,31 +136,40 @@ For each subagent, provide only task-local instructions:
 
 Do not pass the coordinating agent's full reasoning, unrelated sibling specs, or other subagents' private work unless a concrete coordination conflict requires it.
 
-### 5) Monitor and coordinate
+#### 4.3) Monitor and coordinate
 
 - While subagents run, track completions and blockers in the ledger.
 - When one subagent finishes, record its branch, worktree path, commit, verification results, and changed ownership boundaries.
-- Start the next queued spec only when the active count drops below four and no shared blocker is unresolved.
+- Start the next queued spec for this phase only when the active count drops below four and no shared blocker is unresolved.
 - If two subagents report overlapping edits to a shared file or contract, pause new launches, inspect the conflict against `coordination.md`, and resolve the ownership question before continuing.
-- If a subagent fails for a spec-local issue, keep other independent subagents running, but do not launch additional work that depends on the failed scope.
+- If a subagent fails for a spec-local issue, keep other independent subagents in the same phase running, but do not launch additional work that depends on the failed scope.
 - If failures indicate a batch-wide planning defect, stop scheduling new subagents and report the defect.
+- If all specs in the current phase are completed (or blocked), proceed to the merge step.
 
-### 6) Finish the batch report
+#### 4.4) Merge phase branches back
 
-- Do not merge branches, archive specs, push, or release unless the user explicitly requests that follow-up.
-- Summarize every spec outcome from the ledger.
-- Distinguish completed local commits from blocked or partial specs.
-- Report any integration review, merge order, or post-merge validation required by `coordination.md`.
+- After all subagents in the current phase complete, use `merge-changes-from-local-branches` to merge each completed spec's worktree branch back into the current working branch.
+- For each successful spec in the phase:
+  - Identify the branch name from the ledger.
+  - Merge the branch using `merge-changes-from-local-branches`.
+  - Resolve any merge conflicts that arise, prioritising correctness from the spec contracts.
+  - Verify the working branch is clean and tests still pass after merging.
+- Record the merge outcome in the ledger (success / conflicts / blockers).
+- If a merge fails and cannot be resolved, stop and report the merge blocker before proceeding to the next phase.
+- Once merged, the current working branch now includes all changes from this phase, making them available as a baseline for dependent specs in later phases.
 
 ## Working Rules
 
 - One spec directory maps to one implementation subagent.
 - Explicitly documented prerequisite preparation is completed, verified, and committed by the coordinating agent before any implementation subagent starts.
-- Maximum active implementation subagents: four.
+- Spec dependencies are analysed before delegation to determine phase ordering.
+- Phases execute sequentially; within a phase, specs are independent and run in parallel.
+- Maximum active implementation subagents per phase: four.
 - Subagents must be started gradually, not all at once.
 - Every subagent must have independent context scoped to its assigned spec.
 - Every implementation subagent must use `implement-specs-with-worktree`.
-- The coordinating agent owns scheduling, ledger tracking, and conflict escalation; implementation subagents own their assigned worktree commits.
+- After each phase, `merge-changes-from-local-branches` merges all completed spec branches back into the working branch.
+- The coordinating agent owns scheduling, ledger tracking, dependency analysis, inter-phase merging, and conflict escalation; implementation subagents own their assigned worktree commits.
 - The coordinating agent owns shared prerequisite commits; implementation subagents must not redo or overlap that preparation unless the preparation commit is missing or invalid.
 - User-specified subagent model choices should be honored when supported; otherwise inherit the coordinating agent's model/default model policy.
 - Do not use this skill for a single spec unless the user explicitly wants subagent delegation.
@@ -137,6 +177,8 @@ Do not pass the coordinating agent's full reasoning, unrelated sibling specs, or
 ## References
 
 - `implement-specs-with-worktree`: required per-spec worktree implementation workflow.
+- `merge-changes-from-local-branches`: required for merging worktree branches back between phases.
 - `generate-spec`: clarification and planning repair workflow when a batch is not ready for parallel implementation.
 - `preparation.md`: optional batch-level prerequisite plan that must be completed before parallel subagent work starts.
-- `review-change-set`: optional post-implementation review workflow before merge or submission.
+- `coordination.md`: batch-level coordination plan that may contain dependency ordering information.
+- `review-change-set`: optional post-implementation review workflow before final submission.

package/implement-specs-with-subagents/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Implement Specs with Subagents"
   short_description: "Coordinate parallel spec worktree implementations"
-  default_prompt: "Use $implement-specs-with-subagents to read coordination.md and any preparation.md first, complete and commit explicitly documented prerequisite preparation on the working branch before delegation, then assign each approved docs/plans spec directory to one independent subagent that uses $implement-specs-with-worktree, launch at most four implementation subagents at once with staggered starts, honor any requested model when supported, track each branch, commit, test result, and blocker, and report the batch ledger without merging or pushing unless explicitly requested."
+  default_prompt: "Use $implement-specs-with-subagents to read coordination.md and any preparation.md first, complete and commit explicitly documented prerequisite preparation on the working branch before delegation, analyse spec dependencies to build a multi-phase plan, for each phase assign each approved docs/plans spec directory to one independent subagent that uses $implement-specs-with-worktree, launch at most four implementation subagents at once with staggered starts, after each phase use $merge-changes-from-local-branches to merge completed spec branches back into the working branch before launching the next phase, honor any requested model when supported, and track each branch, commit, test result, and blocker."

package/iterative-code-performance/README.md

@@ -15,7 +15,7 @@ Improve an existing repository through a strict three-step loop of full-codebase
 - Introduces caching or memoization only when ownership, invalidation, size bounds, and failure behavior are clear.
 - Treats large coupled hot paths as staged unlock problems, not as automatic stop signals.
 - Re-scans the full repository after every iteration and repeats while any known in-scope actionable performance issue or unvisited in-scope module remains.
-- Synchronizes project docs and `AGENTS.md` through `align-project-documents` and `maintain-project-constraints` after implementation.
+- Synchronizes project docs and `AGENTS.md/CLAUDE.md` through `align-project-documents` and `maintain-project-constraints` after implementation.
 
 ## Repository structure
 

package/iterative-code-performance/SKILL.md

@@ -39,7 +39,7 @@ For this skill, `macro architecture` means the system's top-level runtime shape
 
 ### 1) Scan the repository
 
-- Read root guidance first: `AGENTS.md`, `README*`, package manifests, task runners, CI/test config, benchmark tooling, profiler setup, and major project docs.
+- Read root guidance first: `AGENTS.md/CLAUDE.md`, `README*`, package manifests, task runners, CI/test config, benchmark tooling, profiler setup, and major project docs.
 - Map runtime entrypoints, domain modules, external integrations, persistence/query boundaries, queue or job workers, request paths, hot loops, and current performance guardrails.
 - Exclude generated, vendored, lock, build-output, fixture, snapshot, or minified files unless evidence shows they are human-maintained source.
 - Build or refresh a concrete repository-wide backlog of known actionable performance issues.
@@ -82,7 +82,7 @@ Load references for this step only as needed:
 Only enter this step when the latest full-codebase scan confirms there is no remaining known actionable in-scope performance issue and every in-scope module has received a deep-read iteration, except items explicitly classified as blocked, unsafe, speculative, low-value, excluded, approval-dependent, or requiring production-only measurement that is unavailable.
 
 - Run `align-project-documents` when README, architecture notes, setup docs, benchmark docs, performance budgets, operational docs, or test guidance may have drifted.
-- Run `maintain-project-constraints` to verify `AGENTS.md` still matches the repository's real architecture, business flow, commands, and conventions.
+- Run `maintain-project-constraints` to verify `AGENTS.md/CLAUDE.md` still matches the repository's real architecture, business flow, commands, and conventions.
 - Update only the documentation and constraints that changed in reality because of the optimization.
 
 ## Hard Guardrails
@@ -112,5 +112,5 @@ Return:
 6. Business behavior preservation evidence.
 7. Benchmarks, regression tests, or other guardrails added or updated, including property/integration/E2E/load-test `N/A` reasons where relevant.
 8. Validation commands and results.
-9. Documentation and `AGENTS.md` synchronization status.
+9. Documentation and `AGENTS.md/CLAUDE.md` synchronization status.
 10. Remaining blocked, production-measurement-only, or approval-dependent items, if any.

package/iterative-code-performance/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Iterative Code Performance"
   short_description: "Optimize latency, throughput, CPU, IO, caching, and hot paths in repeated safe passes"
-  default_prompt: "Use $iterative-code-performance as a strict three-step loop. Step 1: scan the full repository for performance evidence, refresh the actionable bottleneck backlog, and maintain a module inventory plus performance coverage ledger. Step 2: choose this round's module or bounded module cluster, scan it through every available performance job lens, and only then decide which jobs actually land now; prioritize measured or clearly complexity-backed hot paths, jobs are selectable directions rather than workflow steps, and assess optimization confidence from your own ability to understand and complete the change, task complexity, guardrail strength, rollback or repair paths, and whether tests or benchmarks can drive accidental breakage back to green. If a high-risk hot path is weakly guarded add benchmarks, characterization tests, or other guardrails instead of stopping; if strong tests and benchmarks guard the behavior, use them to justify bolder safe optimizations rather than avoiding the work. If a file is too coupled or too central for direct optimization, switch to staged unlock work and keep progressing. After validation, run a full-codebase stage-gate; if any known in-scope actionable bottleneck remains or any in-scope module has not received a performance-oriented deep-read iteration, go back to Step 1 immediately. Step 3: only when the latest full-codebase performance scan is clear and every in-scope module is deeply read through the available-job lenses, run $align-project-documents and $maintain-project-constraints to synchronize docs and AGENTS.md. Preserve intended business behavior and the system's macro architecture, keep correctness guardrails green, and do not write a completion report while actionable bottlenecks or unvisited modules still exist."
+  default_prompt: "Use $iterative-code-performance as a strict three-step loop. Step 1: scan the full repository for performance evidence, refresh the actionable bottleneck backlog, and maintain a module inventory plus performance coverage ledger. Step 2: choose this round's module or bounded module cluster, scan it through every available performance job lens, and only then decide which jobs actually land now; prioritize measured or clearly complexity-backed hot paths, jobs are selectable directions rather than workflow steps, and assess optimization confidence from your own ability to understand and complete the change, task complexity, guardrail strength, rollback or repair paths, and whether tests or benchmarks can drive accidental breakage back to green. If a high-risk hot path is weakly guarded add benchmarks, characterization tests, or other guardrails instead of stopping; if strong tests and benchmarks guard the behavior, use them to justify bolder safe optimizations rather than avoiding the work. If a file is too coupled or too central for direct optimization, switch to staged unlock work and keep progressing. After validation, run a full-codebase stage-gate; if any known in-scope actionable bottleneck remains or any in-scope module has not received a performance-oriented deep-read iteration, go back to Step 1 immediately. Step 3: only when the latest full-codebase performance scan is clear and every in-scope module is deeply read through the available-job lenses, run $align-project-documents and $maintain-project-constraints to synchronize docs and AGENTS.md/CLAUDE.md. Preserve intended business behavior and the system's macro architecture, keep correctness guardrails green, and do not write a completion report while actionable bottlenecks or unvisited modules still exist."

package/iterative-code-performance/references/iteration-gates.md

@@ -56,7 +56,7 @@ Inspect the full known performance backlog for:
 - hot loops that still allocate avoidable objects,
 - concurrency changes that need backpressure or max-in-flight proof,
 - logs, metrics, traces, or benchmarks that now describe stale names or paths,
-- documentation or `AGENTS.md` drift.
+- documentation or `AGENTS.md/CLAUDE.md` drift.
 
 Then choose the next execution directions with these priorities:
 

package/iterative-code-performance/references/repository-scan.md

@@ -6,7 +6,7 @@ Build a factual performance map before changing code, then choose the highest-va
 
 ## Required scan
 
-- Read `AGENTS.md`, `README*`, project docs, manifests, task runners, CI configs, benchmark setup, profiler setup, and test setup.
+- Read `AGENTS.md/CLAUDE.md`, `README*`, project docs, manifests, task runners, CI configs, benchmark setup, profiler setup, and test setup.
 - List entrypoints: CLI commands, servers, workers, jobs, frontend routes, scripts, libraries, public packages, and scheduled tasks.
 - Identify core domain modules, persistence/query boundaries, external integrations, serialization/parsing paths, logging utilities, queues, caches, and test helpers.
 - Create a module inventory and coverage ledger using `references/module-coverage.md`.

package/iterative-code-quality/README.md

@@ -26,7 +26,7 @@ Improve an existing repository through a strict three-step loop of full-codebase
 - Repeats the pass cycle while any known in-scope actionable quality issue remains, and forbids a completion report until the latest scan is clear or remaining items are explicitly deferred with a valid reason.
 - Forbids completion while any in-scope module remains unvisited, even if already-read modules look clean.
 - Targets as many inherited repository quality problems as can be solved safely, and expects the guarded test surface to remain green after the refactor.
-- Synchronizes project docs and `AGENTS.md` through `align-project-documents` and `maintain-project-constraints` after implementation.
+- Synchronizes project docs and `AGENTS.md/CLAUDE.md` through `align-project-documents` and `maintain-project-constraints` after implementation.
 
 ## Repository structure
 

package/iterative-code-quality/SKILL.md

@@ -38,7 +38,7 @@ For this skill, `macro architecture` means the system's top-level runtime shape
 
 ### 1) Scan the repository
 
-- Read root guidance first: `AGENTS.md`, `README*`, package manifests, task runners, CI/test config, and major project docs.
+- Read root guidance first: `AGENTS.md/CLAUDE.md`, `README*`, package manifests, task runners, CI/test config, and major project docs.
 - Map runtime entrypoints, domain modules, external integrations, logging utilities, and current test surfaces.
 - Exclude generated, vendored, lock, build-output, fixture, or snapshot files unless evidence shows they are human-maintained source.
 - Build or refresh a concrete repository-wide backlog of known actionable quality issues.
@@ -80,7 +80,7 @@ Load references for this step only as needed:
 Only enter this step when the latest full-codebase scan confirms there is no remaining known actionable in-scope quality issue and every in-scope module has received a deep-read iteration, except items explicitly classified as blocked, unsafe, speculative, low-value, excluded, or approval-dependent.
 
 - Run `align-project-documents` when README, architecture notes, setup docs, debugging docs, or test guidance may have drifted.
-- Run `maintain-project-constraints` to verify `AGENTS.md` still matches the repository's real architecture, business flow, commands, and conventions.
+- Run `maintain-project-constraints` to verify `AGENTS.md/CLAUDE.md` still matches the repository's real architecture, business flow, commands, and conventions.
 - Update only the documentation and constraints that changed in reality because of the refactor.
 
 ## Hard Guardrails
@@ -108,5 +108,5 @@ Return:
 5. Business behavior preservation evidence.
 6. Tests or other guardrails added or updated, including property/integration/E2E `N/A` reasons where relevant.
 7. Validation commands and results.
-8. Documentation and `AGENTS.md` synchronization status.
+8. Documentation and `AGENTS.md/CLAUDE.md` synchronization status.
 9. Remaining blocked or approval-dependent items, if any.

package/iterative-code-quality/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Iterative Code Quality"
   short_description: "Refactor names, functions, modules, logs, and tests in repeated behavior-safe passes"
-  default_prompt: "Use $iterative-code-quality as a strict three-step loop. Step 1: scan the full repository, refresh the actionable quality backlog, and maintain a module inventory plus coverage ledger. Step 2: choose this round's module or bounded module cluster, scan it through every available job lens, and only then decide which jobs actually land now; start from the easiest useful unvisited modules, jobs are selectable directions rather than workflow steps, and assess refactor confidence from your own ability to understand and complete the change, task complexity, guardrail strength, rollback or repair paths, and whether tests can drive accidental breakage back to green. If a high-risk area is weakly guarded add the missing tests or other guardrails instead of stopping; if strong tests guard the behavior, use them to justify bolder safe refactors rather than avoiding the work. If a file is too coupled or too central for direct cleanup, switch to staged unlock work and keep progressing. After validation, run a full-codebase stage-gate; if any known in-scope actionable issue remains or any in-scope module has not received a job-oriented deep-read iteration, go back to Step 1 immediately. Step 3: only when the latest full-codebase scan is clear and every in-scope module is deeply read through the available-job lenses, run $align-project-documents and $maintain-project-constraints to synchronize docs and AGENTS.md. Preserve intended business behavior and the system's macro architecture, keep the guarded test surface green, and do not write a completion report while actionable gaps or unvisited modules still exist."
+  default_prompt: "Use $iterative-code-quality as a strict three-step loop. Step 1: scan the full repository, refresh the actionable quality backlog, and maintain a module inventory plus coverage ledger. Step 2: choose this round's module or bounded module cluster, scan it through every available job lens, and only then decide which jobs actually land now; start from the easiest useful unvisited modules, jobs are selectable directions rather than workflow steps, and assess refactor confidence from your own ability to understand and complete the change, task complexity, guardrail strength, rollback or repair paths, and whether tests can drive accidental breakage back to green. If a high-risk area is weakly guarded add the missing tests or other guardrails instead of stopping; if strong tests guard the behavior, use them to justify bolder safe refactors rather than avoiding the work. If a file is too coupled or too central for direct cleanup, switch to staged unlock work and keep progressing. After validation, run a full-codebase stage-gate; if any known in-scope actionable issue remains or any in-scope module has not received a job-oriented deep-read iteration, go back to Step 1 immediately. Step 3: only when the latest full-codebase scan is clear and every in-scope module is deeply read through the available-job lenses, run $align-project-documents and $maintain-project-constraints to synchronize docs and AGENTS.md/CLAUDE.md. Preserve intended business behavior and the system's macro architecture, keep the guarded test surface green, and do not write a completion report while actionable gaps or unvisited modules still exist."

package/iterative-code-quality/references/iteration-gates.md

@@ -53,7 +53,7 @@ Inspect the full known quality backlog for:
 - module boundaries that are still mixed,
 - logs that now use stale names,
 - tests that cover only the happy path,
-- documentation or `AGENTS.md` drift.
+- documentation or `AGENTS.md/CLAUDE.md` drift.
 
 Then choose the next execution directions with these priorities:
 

package/iterative-code-quality/references/module-boundaries.md

@@ -80,4 +80,4 @@ After a split:
 - public entrypoints still call the same behavior,
 - tests cover moved logic and orchestration glue,
 - logs still carry the same correlation identifiers,
-- docs or `AGENTS.md` are updated only if the visible architecture or command surface changed.
+- docs or `AGENTS.md/CLAUDE.md` are updated only if the visible architecture or command surface changed.

package/iterative-code-quality/references/repository-scan.md

@@ -6,7 +6,7 @@ Build a factual map before changing code, then choose the highest-value quality
 
 ## Required scan
 
-- Read `AGENTS.md`, `README*`, project docs, manifests, task runners, CI configs, and test setup.
+- Read `AGENTS.md/CLAUDE.md`, `README*`, project docs, manifests, task runners, CI configs, and test setup.
 - List entrypoints: CLI commands, servers, workers, jobs, frontend routes, scripts, libraries, or public packages.
 - Identify core domain modules, external integrations, persistence boundaries, logging utilities, and test helpers.
 - Create a module inventory and coverage ledger using `references/module-coverage.md`.

package/maintain-project-constraints/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: maintain-project-constraints
-description: Automatically create and maintain AGENTS.md so it stays aligned with the current repository architecture, core business flow, common commands, macro project purpose, and coding conventions. Use when AGENTS.md is missing or may be outdated after code changes.
+description: Automatically create and maintain AGENTS.md/CLAUDE.md so it stays aligned with the current repository architecture, core business flow, common commands, macro project purpose, and coding conventions. Use when AGENTS.md/CLAUDE.md is missing or may be outdated after code changes.
 ---
 
 # Maintain Project Constraints
@@ -15,26 +15,26 @@ description: Automatically create and maintain AGENTS.md so it stays aligned wit
 ## Standards
 
 - Evidence: Infer repository architecture, business flow, and conventions from current code and docs rather than assumptions.
-- Execution: Create or align `AGENTS.md` only after building a concrete inventory of implemented capabilities.
+- Execution: Create or align `AGENTS.md/CLAUDE.md` only after building a concrete inventory of implemented capabilities.
 - Quality: Keep every statement traceable, remove stale guidance, and ensure `Core business flow` stays exhaustive and concrete.
-- Output: Maintain a concise root-level `AGENTS.md` with the required sections, repository-specific wording, and a factual `Common Commands` section when the repository exposes stable command entry points.
+- Output: Maintain a concise root-level `AGENTS.md/CLAUDE.md` with the required sections, repository-specific wording, and a factual `Common Commands` section when the repository exposes stable command entry points.
 
 ## Goal
 
-Keep `AGENTS.md` accurate, actionable, and synchronized with the latest state of the repository.
+Keep `AGENTS.md/CLAUDE.md` accurate, actionable, and synchronized with the latest state of the repository.
 
 ## Trigger Conditions
 
 Invoke this skill when either condition is true:
 
-1. `AGENTS.md` does not exist and the user needs this repository to expose agent-facing guidance.
-2. `AGENTS.md` exists but may have drifted after code changes, refactors, or workflow updates.
+1. `AGENTS.md/CLAUDE.md` does not exist and the user needs this repository to expose agent-facing guidance.
+2. `AGENTS.md/CLAUDE.md` exists but may have drifted after code changes, refactors, or workflow updates.
 
-After completing any code modification task, proactively run this skill to verify `AGENTS.md` is still aligned, and update it if needed.
+After completing any code modification task, proactively run this skill to verify `AGENTS.md/CLAUDE.md` is still aligned, and update it if needed.
 
 ## Required Outputs
 
-`AGENTS.md` must include these sections (use concise, repository-specific content):
+`AGENTS.md/CLAUDE.md` must include these sections (use concise, repository-specific content):
 
 - Project architecture
 - Core business flow
@@ -88,7 +88,7 @@ This project enables users to manage and run reusable automation workflows.
 
 ### 1) Build factual understanding first
 
-- Confirm whether `AGENTS.md` exists.
+- Confirm whether `AGENTS.md/CLAUDE.md` exists.
 - Read the repository before writing:
   - root docs (`README`, contribution docs, design docs)
   - key source directories and entry points
@@ -100,11 +100,11 @@ This project enables users to manage and run reusable automation workflows.
 - Build a concrete inventory of all currently implemented capabilities before drafting `Core business flow`.
 - Build a separate inventory of stable, repository-specific commands before drafting `Common Commands`.
 
-### 2) Create AGENTS.md when missing
+### 2) Create AGENTS.md/CLAUDE.md when missing
 
-When `AGENTS.md` is absent:
+When `AGENTS.md/CLAUDE.md` is absent:
 
-- Create a new root-level `AGENTS.md`.
+- Create a new root-level `AGENTS.md/CLAUDE.md`.
 - Document architecture, business flow, purpose, and coding conventions from observed facts.
 - Write `Core project purpose` as the repository's macro intent, such as the problem it aims to solve or the outcome it exists to achieve, rather than as a feature list.
 - Document the repository's common commands from observed command entry points and docs.
@@ -112,9 +112,9 @@ When `AGENTS.md` is absent:
 - Write `Common commands` as short bullets in the style of ``- `command` — when to use it.``.
 - Keep language specific to this repository; avoid generic boilerplate.
 
-### 3) Align AGENTS.md when drift is detected
+### 3) Align AGENTS.md/CLAUDE.md when drift is detected
 
-When `AGENTS.md` exists but is outdated:
+When `AGENTS.md/CLAUDE.md` exists but is outdated:
 
 - Re-read changed or high-impact modules.
 - Update only sections that no longer match reality.
@@ -124,7 +124,7 @@ When `AGENTS.md` exists but is outdated:
 
 ### 4) Quality checks before finishing
 
-- Ensure every statement in `AGENTS.md` is traceable to current repository files.
+- Ensure every statement in `AGENTS.md/CLAUDE.md` is traceable to current repository files.
 - Remove stale paths, renamed components, and obsolete workflows.
 - Remove stale commands, flags, or task names that no longer exist.
 - Verify every command in `Common Commands` is either documented in repository docs or directly supported by the current codebase.

package/maintain-project-constraints/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Maintain Project Constraints"
-  short_description: "Automatically create and maintain AGENTS.md so it stays aligned with the current repository architecture, core business flow, common commands, macro project purpose, and coding conventions. Use when AGENTS.md is missing or may be outdated after code changes."
-  default_prompt: "Use $maintain-project-constraints to automatically create and maintain AGENTS.md so it stays aligned with the current repository architecture, core business flow, common commands, macro project purpose, and coding conventions. Use when AGENTS.md is missing or may be outdated after code changes."
+  short_description: "Automatically create and maintain AGENTS.md/CLAUDE.md so it stays aligned with the current repository architecture, core business flow, common commands, macro project purpose, and coding conventions. Use when AGENTS.md/CLAUDE.md is missing or may be outdated after code changes."
+  default_prompt: "Use $maintain-project-constraints to automatically create and maintain AGENTS.md/CLAUDE.md so it stays aligned with the current repository architecture, core business flow, common commands, macro project purpose, and coding conventions. Use when AGENTS.md/CLAUDE.md is missing or may be outdated after code changes."

package/maintain-skill-catalog/README.md

@@ -6,7 +6,7 @@ Maintain a repository of installable skills by auditing skill definitions, depen
 
 - Scans top-level skills before adding or splitting new ones to avoid duplicate scope.
 - Audits standardized `## Dependencies` sections and separates vendored, local-only, external, and alias dependencies.
-- Syncs catalog docs such as `README.md` and `AGENTS.md` with actual skill capabilities.
+- Syncs catalog docs such as `README.md` and `AGENTS.md/CLAUDE.md` with actual skill capabilities.
 - Catches catalog-wide validation issues like missing `agents/openai.yaml` files or stale prompt references.
 - Encodes user corrections into durable catalog rules so the same classification mistakes do not repeat.
 

package/maintain-skill-catalog/SKILL.md

@@ -29,7 +29,7 @@ Keep a skill repository coherent when many top-level skills evolve together.
 
 - List the tracked top-level skill directories and read the relevant `SKILL.md` files before deciding that a new skill is needed.
 - Check whether the requested workflow already exists under another name or can be handled by a focused update.
-- Read current `README.md`, `AGENTS.md`, validator scripts, and any existing dependency notes that may need synchronization.
+- Read current `README.md`, `AGENTS.md/CLAUDE.md/CLAUDE.md`, validator scripts, and any existing dependency notes that may need synchronization.
 - When the task involves external dependencies, inspect local installed skills under `~/.codex/skills` first to confirm the exact skill names.
 
 ### 2) Audit dependency declarations and shared conventions
@@ -48,7 +48,7 @@ Keep a skill repository coherent when many top-level skills evolve together.
 
 - Keep edits minimal and repo-wide only where necessary.
 - Update `README.md` skill lists and external dependency sections when the catalog actually changes.
-- Update `AGENTS.md` when the repository gains or loses a user-visible capability or a standing convention changes.
+- Update `AGENTS.md/CLAUDE.md` when the repository gains or loses a user-visible capability or a standing convention changes.
 - When creating a new shared skill, align naming, frontmatter, `agents/openai.yaml`, and any lightweight README with neighboring skills.
 - When a failure comes from validator drift or a metadata constraint that was not caught early, tighten the validator or CI path in the same change instead of only fixing the offending skill text.
 - Do not treat unpublished local skills as external dependencies just because they are not yet installed elsewhere.

package/merge-changes-from-local-branches/SKILL.md

@@ -119,7 +119,7 @@ For each in-scope named branch:
 
 - After all in-scope merges succeed and the current-branch state has been verified, invoke `archive-specs`.
 - Let `archive-specs` convert and archive any completed `docs/plans/...` spec sets that now reflect the delivered outcome.
-- Let `archive-specs` synchronize durable project docs and `AGENTS.md` when the merged result changed operator workflows, repository guidance, or user-visible behavior.
+- Let `archive-specs` synchronize durable project docs and `AGENTS.md/CLAUDE.md` when the merged result changed operator workflows, repository guidance, or user-visible behavior.
 - Do not proceed to the final submission commit while required archival or documentation updates remain unfinished.
 - If no completed spec sets or project-doc drift are present, record that evidence explicitly before moving on.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@laitszkin/apollo-toolkit",
-  "version": "3.6.1",
+  "version": "3.6.3",
   "description": "Apollo Toolkit npm installer for managed skill copying across Codex, OpenClaw, and Trae.",
   "license": "MIT",
   "author": "LaiTszKin",

package/ship-github-issue-fix/SKILL.md

@@ -16,7 +16,7 @@ description: Resolve a GitHub issue in an existing repository and submit the fix
 
 - Evidence: Read the remote issue and the real implementation before deciding scope, process, or fixes.
 - Execution: Prefer the repo's existing issue-reading helpers, fall back to raw `gh issue` commands when helpers are missing, use spec planning only when the actual change surface justifies it, and push directly to the user-requested branch when submission is requested.
-- Quality: Treat localized bug fixes and narrow optimizations as direct implementation work unless the explored scope proves they need shared planning; finish tests, spec backfill, docs sync, and `AGENTS.md` sync before handing off submission.
+- Quality: Treat localized bug fixes and narrow optimizations as direct implementation work unless the explored scope proves they need shared planning; finish tests, spec backfill, docs sync, and `AGENTS.md/CLAUDE.md` sync before handing off submission.
 - Output: Report the issue context, chosen workflow, implemented fix, validation evidence, and commit/push result.
 
 ## Overview
@@ -54,7 +54,7 @@ Use this skill for the recurring workflow where the user wants one GitHub issue
 
 - If the user asked to commit or push, hand off to `$commit-and-push`.
 - Preserve the user's explicit branch target; when the user says `push to main`, treat direct push to `main` as the default goal.
-- Before the final commit, ensure any required spec backfill, docs synchronization, and `AGENTS.md` alignment are completed.
+- Before the final commit, ensure any required spec backfill, docs synchronization, and `AGENTS.md/CLAUDE.md` alignment are completed.
 - Do not convert this flow into a PR workflow unless the user explicitly requests a PR.
 - Do not perform version bumps, tags, or GitHub Releases in this skill.
 

package/submission-readiness-check/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: submission-readiness-check
-description: Prepare a repository for safe submission by synchronizing `CHANGELOG.md`, project docs, `AGENTS.md`, and completed planning artifacts before commit, push, PR creation, or release. Use when a workflow is about to submit changes and must avoid missing finalization steps such as stale `Unreleased` notes, unarchived completed spec sets, or unsynchronized agent constraints.
+description: Prepare a repository for safe submission by synchronizing `CHANGELOG.md`, project docs, `AGENTS.md/CLAUDE.md`, and completed planning artifacts before commit, push, PR creation, or release. Use when a workflow is about to submit changes and must avoid missing finalization steps such as stale `Unreleased` notes, unarchived completed spec sets, or unsynchronized agent constraints.
 ---
 
 # Submission Readiness Check
@@ -15,7 +15,7 @@ description: Prepare a repository for safe submission by synchronizing `CHANGELO
 ## Standards
 
 - Evidence: Inspect the actual git diff, staged set, planning artifacts, `CHANGELOG.md`, and current project docs before declaring the repository ready to submit.
-- Execution: Decide whether the target flow is commit/push, PR, or release; normalize completed spec sets when appropriate; synchronize project docs plus `AGENTS.md`; then enforce changelog readiness before any commit, tag, push, PR creation, or release publishing step.
+- Execution: Decide whether the target flow is commit/push, PR, or release; normalize completed spec sets when appropriate; synchronize project docs plus `AGENTS.md/CLAUDE.md`; then enforce changelog readiness before any commit, tag, push, PR creation, or release publishing step.
 - Quality: Treat missing or stale changelog entries as blocking issues for submit workflows, preserve unrelated pending `Unreleased` bullets, do not archive active plan sets that still track unfinished scope, and do not hand back a ready verdict until every conditional gate whose scenario is met has actually been completed.
 - Output: Return a ready-to-submit verdict with the synchronized files and any blocking items that must be fixed before the owning submit workflow continues.
 
@@ -28,7 +28,7 @@ Use this skill as the shared finalization pass before repository submission work
 ### 1) Inventory the real submission surface
 
 - Read `git status -sb`, `git diff --stat`, and `git diff --cached --stat`.
-- Check whether the repository has root `CHANGELOG.md`, top-level `AGENTS.md`, and categorized project docs already in use.
+- Check whether the repository has root `CHANGELOG.md`, top-level `AGENTS.md/CLAUDE.md`, and categorized project docs already in use.
 - Inventory planning artifacts across the repository, not only staged files, so completed plan sets are not missed.
 - Classify the intended downstream flow:
   - `commit-push`
@@ -46,7 +46,7 @@ Use this skill as the shared finalization pass before repository submission work
 
 - Run `$align-project-documents` after spec conversion or doc inspection is complete.
 - Run `$maintain-project-constraints` immediately before the owning submission workflow mutates git history.
-- Apply the resulting doc and `AGENTS.md` updates when behavior, operator workflow, or standing project rules changed.
+- Apply the resulting doc and `AGENTS.md/CLAUDE.md` updates when behavior, operator workflow, or standing project rules changed.
 
 ### 4) Enforce changelog readiness
 
@@ -67,7 +67,7 @@ Use this skill as the shared finalization pass before repository submission work
 
 - Confirm which files were synchronized:
   - project docs
-  - `AGENTS.md`
+  - `AGENTS.md/CLAUDE.md`
   - `CHANGELOG.md`
   - archived plan sets
 - If anything remains unsynchronized, report it as a blocking item rather than letting the submit workflow continue optimistically.

package/version-release/SKILL.md

@@ -87,7 +87,7 @@ Load only when needed:
    - Reset `Unreleased` to an empty placeholder after the version entry is created.
    - Remove duplicate section headers or bullets only when the move would otherwise create repeated content.
    - Update `README.md` only when behavior or usage changed.
-   - Update `AGENTS.md` only when agent workflow/rules changed.
+   - Update `AGENTS.md/CLAUDE.md` only when agent workflow/rules changed.
 8. Commit and tag
    - Create a release-oriented commit message (for example `chore(release): publish 2.12.1`) when applicable.
    - For new-version flows, create the version tag locally after commit.

package/version-release/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Version Release"
   short_description: "Prepare a versioned release with bump, changelog, tag, GitHub release, and push"
-  default_prompt: "Use $version-release only for explicit release/version/tag requests, including direct semver wording like patch/minor/major update or requests to trigger release-published automation: inspect the current repository state, read the current version plus existing tag/release state, and inspect root CHANGELOG.md Unreleased content. Treat every conditional gate whose scenario is met as blocking before any version bump, tag, or release step: if the release includes code changes, run $review-change-set; if the reviewed risk profile says edge-case or security review is needed, run $discover-edge-cases and $harden-app-security as blocking gates too; if completed specs should be converted or docs need normalization, ensure $archive-specs runs through $submission-readiness-check; if changelog synchronization is needed, complete it before continuing. Then run any additional required code-quality skills, hand the repository to $submission-readiness-check so completed plan archives, project docs, AGENTS.md, and changelog readiness are settled before any version bump or tag, confirm CHANGELOG.md Unreleased is release-ready, update version files, cut the release directly from CHANGELOG.md Unreleased, create the release commit and matching tag, push commits and tags, and publish the matching GitHub release before reporting success."
+  default_prompt: "Use $version-release only for explicit release/version/tag requests, including direct semver wording like patch/minor/major update or requests to trigger release-published automation: inspect the current repository state, read the current version plus existing tag/release state, and inspect root CHANGELOG.md Unreleased content. Treat every conditional gate whose scenario is met as blocking before any version bump, tag, or release step: if the release includes code changes, run $review-change-set; if the reviewed risk profile says edge-case or security review is needed, run $discover-edge-cases and $harden-app-security as blocking gates too; if completed specs should be converted or docs need normalization, ensure $archive-specs runs through $submission-readiness-check; if changelog synchronization is needed, complete it before continuing. Then run any additional required code-quality skills, hand the repository to $submission-readiness-check so completed plan archives, project docs, AGENTS.md/CLAUDE.md, and changelog readiness are settled before any version bump or tag, confirm CHANGELOG.md Unreleased is release-ready, update version files, cut the release directly from CHANGELOG.md Unreleased, create the release commit and matching tag, push commits and tags, and publish the matching GitHub release before reporting success."