@laitszkin/apollo-toolkit 3.6.0 → 3.6.2

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

@@ -5,9 +5,10 @@ description: >-
   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 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.
+  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
@@ -21,9 +22,9 @@ description: >-
 
 ## Standards
 
-- Evidence: Read the batch-level `coordination.md` when present, enumerate the exact spec directories to implement, and verify each delegated spec has the required planning files before starting subagents.
-- Execution: 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.
-- Quality: Preserve spec ownership boundaries, avoid duplicate delegation for the same spec, track branch/worktree/commit/test outcomes for every subagent, and pause new launches when a shared blocker, collision, or rate-limit pressure appears.
+- 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.
+- 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.
 
 ## Goal
@@ -36,6 +37,7 @@ Coordinate a multi-spec implementation batch safely by delegating each approved
 
 - Locate the requested batch under `docs/plans/{YYYY-MM-DD}/{batch_name}/`.
 - Read `coordination.md` first when it exists.
+- Read `preparation.md` when it exists.
 - Enumerate only the spec directories that are in scope for this request.
 - For each spec directory, verify the presence of:
   - `spec.md`
@@ -45,6 +47,19 @@ Coordinate a multi-spec implementation batch safely by delegating each approved
   - `design.md`
 - Do not delegate archived, sibling, or approximate specs unless the user explicitly includes them.
 - If `coordination.md` says the batch is not ready for parallel implementation, stop and report the blocking coordination item instead of spawning subagents.
+- If `preparation.md` exists, or if the in-scope spec documents explicitly state that prerequisite work must be completed before parallel implementation, treat that preparation as blocking before subagent launch.
+
+### 1.5) Complete documented prerequisite preparation
+
+- Use this step only when `preparation.md` exists or the specs clearly annotate required pre-work.
+- The coordinating agent owns the prerequisite work; do not delegate it to implementation subagents.
+- Read the preparation tasks, expected outputs, and verification hooks before editing.
+- Complete only the shared prerequisite scope that all specs must assume before parallel work starts.
+- Run the verification commands or checks listed for the preparation.
+- Commit the preparation to the working branch that future implementation worktrees or subagents will use as their base.
+- Record the preparation commit in the ledger.
+- 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
 
@@ -58,6 +73,7 @@ Coordinate a multi-spec implementation batch safely by delegating each approved
   - commit
   - tests
   - blockers
+- If preparation was completed, include the preparation commit that all subagents must treat as their base.
 - Determine the model policy before launch:
   - If the user specifies a model, use that model for the implementation subagents when the environment supports model selection.
   - If the user does not specify a model, let subagents use the same model or default model policy as the coordinating agent.
@@ -79,6 +95,7 @@ For each subagent, provide only task-local instructions:
 - Exact spec directory path.
 - Parent `coordination.md` path when present.
 - Requirement to use `implement-specs-with-worktree`.
+- Requirement to base work on the committed prerequisite-preparation branch state when preparation was performed.
 - Requirement to read the full spec bundle before editing.
 - Requirement to implement inside its own isolated worktree.
 - Requirement to run relevant tests.
@@ -107,11 +124,13 @@ Do not pass the coordinating agent's full reasoning, unrelated sibling specs, or
 ## 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.
 - 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.
+- 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.
 
@@ -119,4 +138,5 @@ Do not pass the coordinating agent's full reasoning, unrelated sibling specs, or
 
 - `implement-specs-with-worktree`: required per-spec worktree implementation workflow.
 - `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.

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 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, 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."

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

@@ -3,9 +3,9 @@ name: implement-specs-with-worktree
 description: >-
   Read a specs planning set (spec.md, tasks.md, checklist.md, contract.md, design.md)
   from `docs/plans/{YYYY-MM-DD}/{change_name}/` or `docs/plans/{YYYY-MM-DD}/{batch_name}/{change_name}/`
-  plus parent `coordination.md` when present, and implement the approved tasks
-  within an isolated git worktree, with every code, test, and spec edit made
-  inside that worktree rather than the parent checkout. Use when the user asks
+  plus parent `coordination.md` and `preparation.md` when present, and implement
+  the approved tasks within an isolated git worktree, with every code, test, and
+  spec edit made inside that worktree rather than the parent checkout. Use when the user asks
   to implement from an existing spec set, execute a spec plan, or work on a
   feature branch without affecting the parent working tree. If not already in a
   worktree, create a new worktree with a spec-named branch from the same parent
@@ -24,7 +24,7 @@ description: >-
 
 ## Standards
 
-- Evidence: Read and understand the complete specs set before starting implementation, identify the authoritative parent branch that the worktree should inherit from, verify whether the requested scope is already implemented on that parent branch or current main working tree, and when the requested plan path is missing from the current worktree verify where the authoritative copy actually lives before substituting any nearby spec.
+- Evidence: Read and understand the complete specs set before starting implementation, including parent `coordination.md` and `preparation.md` when present, identify the authoritative parent branch that the worktree should inherit from, verify whether the requested scope is already implemented on that parent branch or current main working tree, and when the requested plan path is missing from the current worktree verify where the authoritative copy actually lives before substituting any nearby spec.
 - Execution: Create or use an isolated worktree for implementation only when the requested spec still needs work, sync the exact approved plan set into that worktree when it is missing there, create the worktree branch from the same parent branch as the worktree base, use the spec-set name as the canonical branch/worktree name, inspect sibling worktrees for the same batch before editing shared files when parallel implementations may already be active, prefer direct `git` ref checks over brittle shell inference when deciding whether a branch or worktree already exists, and commit to a local branch when done. Do not edit product files from the parent checkout; every implementation, test, and spec backfill change must happen inside the active worktree directory after verifying `git rev-parse --show-toplevel` and `pwd` point at the same worktree root.
 - Quality: Complete all planned tasks, run relevant tests, backfill the spec documents with actual completion status, avoid dragging unrelated sibling specs into the worktree just because they share a batch directory, inspect overlapping runtime/config/shared touch points before diverging from another active sibling worktree in the same batch, revert unrelated formatter-only noise outside the spec-owned scope before committing, if branch/worktree creation reports ambiguous state re-check the actual git refs and worktree list before retrying, and when using targeted Rust `cargo test` selectors remember Cargo accepts only one positional test filter so each distinct selector needs its own confirmed command.
 - Output: Keep the worktree branch clean with only the intended implementation commits.
@@ -45,14 +45,15 @@ Implement approved spec planning sets in an isolated git worktree, ensuring the
   - prefer the exact matching plan directory from the repository's authoritative branch or main working tree over archived, approximate, or sibling plan directories
   - if the plan lives under a batch directory, sync only the requested spec directory plus the shared `coordination.md` that governs it
   - do not copy neighboring sibling spec directories into the worktree unless the user explicitly expanded scope
-- When the plan sits under a batch directory, also read the sibling `coordination.md` before implementation.
+- When the plan sits under a batch directory, also read the sibling `coordination.md` and `preparation.md` before implementation when those files exist.
 - Read all five spec files:
   - `spec.md` — requirements and BDD behaviors
   - `tasks.md` — task breakdown
   - `checklist.md` — behavior-to-test alignment and completion tracking
   - `contract.md` — API/interface contracts
   - `design.md` — design decisions and architecture notes
-- If `coordination.md` exists in the parent batch directory, read it as the shared source of truth for ownership boundaries, shared preparation, replacement direction, merge order, and cross-spec integration checkpoints.
+- If `coordination.md` exists in the parent batch directory, read it as the shared source of truth for ownership boundaries, replacement direction, merge order, and cross-spec integration checkpoints.
+- If `preparation.md` exists in the parent batch directory, treat it as the already-completed prerequisite baseline for this spec; do not redo its tasks inside the member spec unless the preparation commit is missing or the document says the prerequisite remains blocked.
 - Understand the scope, requirements, and planned tasks before proceeding.
 
 ### 2) Check current worktree state
@@ -106,6 +107,7 @@ Use branch naming from `references/branch-naming.md`.
 - Explore the existing codebase relevant to the planned tasks.
 - Verify latest authoritative docs for involved stacks/integrations.
 - When `coordination.md` exists, respect its shared-field preparation, legacy-replacement direction, and allowed touch-point boundaries before editing.
+- When `preparation.md` exists, implement against its prepared baseline assumptions and avoid duplicating preparation tasks in the member spec.
 - Implement each task in `tasks.md` systematically.
 - When `coordination.md` defines file ownership guardrails, additive-only shared-contract rules, or compatibility-shim retention requirements, treat them as blocking execution constraints rather than optional guidance.
 - For each implemented change, add appropriate tests:
@@ -128,6 +130,7 @@ After implementation and testing:
 - Mark completed tasks in `tasks.md`.
 - Update `checklist.md` with test execution results, N/A reasons, and any scope adjustments.
 - If the shared implementation direction changed, update the parent `coordination.md` as well before finishing.
+- If preparation assumptions changed or were found missing, update `preparation.md` or stop for re-coordination instead of silently moving prerequisite work into the member spec.
 - Do not mark unused template examples or non-applicable items as complete.
 
 ### 6) Commit changes
@@ -158,6 +161,7 @@ After implementation and testing:
 - Complete all planned tasks before committing; do not stop with partial work.
 - Treat the specs as the source of truth for scope — do not deviate without user approval.
 - When `coordination.md` exists, treat it as the source of truth for batch-level ownership and cutover direction.
+- When `preparation.md` exists, treat it as a prerequisite baseline owned outside the member spec; do not duplicate or alter its tasks unless explicitly requested.
 - Never remove a shared shim, rename a shared field, or rewrite a shared file outside the ownership map unless `coordination.md` explicitly allows that change or the user approves a coordination update first.
 - Revert formatter-only edits outside the owned spec scope before the final commit so the worktree stays reviewable and merge-safe.
 - Follow the testing standards from `enhance-existing-features` and `develop-new-features`.

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.0",
+  "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."