@laitszkin/apollo-toolkit 3.6.1 → 3.6.2

package/CHANGELOG.md

@@ -7,6 +7,11 @@ All notable changes to this repository are documented in this file.
 ### Added
 - (None yet)
 
+## [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/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.2",
   "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."