@laitszkin/apollo-toolkit 3.3.4 → 3.4.0

package/AGENTS.md

@@ -58,6 +58,7 @@ This repository enables users to install and run a curated set of reusable agent
 - Users can add focused observability to opaque workflows through targeted logs, metrics, traces, and tests.
 - Users can iteratively improve repository code quality through behavior-neutral naming, simplification, module-boundary, logging, and test-coverage passes.
 - Users can iteratively improve repository performance through evidence-backed module scans, safe hot-path optimization, benchmark guardrails, batching, caching, allocation, concurrency, and repeated full-codebase stage gates.
+- Users can select risk-driven test levels and define unit drift checks through a shared testing strategy skill.
 - Users can build against Jupiter's official Solana swap, token, price, lending, trigger, recurring, and portfolio APIs with an evidence-based development guide.
 - Users can render and embed math formulas with KaTeX using official documentation-backed guidance and reusable rendering scripts.
 - Users can debug software systematically by reproducing causes, validating fixes, and testing outcomes.

package/CHANGELOG.md

@@ -7,6 +7,19 @@ All notable changes to this repository are documented in this file.
 ### Added
 - (None yet)
 
+## [v3.4.0] - 2026-04-28
+
+### Added
+- Add `test-case-strategy`, a shared skill for selecting risk-driven test levels, defining meaningful test oracles, and adding focused unit drift checks for atomic implementation tasks.
+
+### Changed
+- Make `generate-spec`, `develop-new-features`, and `enhance-existing-features` depend on `test-case-strategy` for test case selection, while tightening `tasks.md` into an atomic implementation queue with verification hooks.
+
+## [v3.3.5] - 2026-04-28
+
+### Changed
+- Tighten `implement-specs-with-worktree` so parallel batch implementations must inspect active sibling worktrees before editing shared runtime, config, or contract boundaries that may already be in flight elsewhere.
+
 ## [v3.3.4] - 2026-04-27
 
 ### Changed

package/README.md

@@ -48,6 +48,7 @@ A curated skill catalog for Codex, OpenClaw, Trae, Agents, and Claude Code with
 - solana-development
 - submission-readiness-check
 - systematic-debug
+- test-case-strategy
 - text-to-short-video
 - version-release
 - video-production

package/develop-new-features/README.md

@@ -1,12 +1,12 @@
 # develop-new-features
 
-A spec-first feature development skill for new behavior and greenfield work. It delegates shared planning-doc generation to `generate-spec`, then implements the approved feature with risk-driven testing.
+A spec-first feature development skill for new behavior and greenfield work. It delegates shared planning-doc generation to `generate-spec`, uses `test-case-strategy` for risk-driven test selection, then implements the approved feature with focused validation.
 
 ## Key capabilities
 
 - Requires `generate-spec` before any implementation starts.
 - Treats `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, and `design.md` as approval-gated artifacts, not optional notes.
-- Covers unit, regression, property-based, integration, E2E, and adversarial testing based on actual risk.
+- Covers unit, regression, property-based, integration, E2E, adversarial, mock/fake, rollback, and unit drift-check testing based on actual risk through `test-case-strategy`.
 - Reuses existing architecture and avoids speculative expansion.
 - Backfills `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, and `design.md` after implementation and testing complete.
 - Once approval is granted and implementation starts, finishes all in-scope planned tasks and applicable checklist items before yielding unless the user defers work or an external blocker prevents safe completion.
@@ -18,13 +18,8 @@ A spec-first feature development skill for new behavior and greenfield work. It
 ├── SKILL.md
 ├── README.md
 ├── LICENSE
-├── agents/
-│   └── openai.yaml
-└── references/
-    ├── testing-unit.md
-    ├── testing-property-based.md
-    ├── testing-integration.md
-    └── testing-e2e.md
+└── agents/
+    └── openai.yaml
 ```
 
 ## Workflow summary
@@ -38,17 +33,12 @@ A spec-first feature development skill for new behavior and greenfield work. It
 
 ## Testing expectations
 
-- Unit: changed logic, boundaries, failure paths.
-- Regression: pin down bug-prone or high-risk behavior.
-- Property-based: required for business logic unless concrete `N/A` is recorded.
-- Integration: cover the user-critical logic chain.
-- E2E: cover the most important success and denial/failure paths when justified.
-- Adversarial: include abuse, malformed input, privilege, replay, concurrency, and edge-combination cases when relevant.
+- Use `test-case-strategy` to choose the smallest useful test level for each risk.
+- Define meaningful oracles before implementation.
+- Add focused unit drift checks for non-trivial atomic tasks when possible.
+- Record concrete `N/A` reasons when a test level is not suitable.
 
 ## References
 
 - Shared planning workflow: `generate-spec`
-- Unit testing guide: `references/testing-unit.md`
-- Property-based testing guide: `references/testing-property-based.md`
-- Integration testing guide: `references/testing-integration.md`
-- E2E testing guide: `references/testing-e2e.md`
+- Test selection and unit drift-check guide: `test-case-strategy`

package/develop-new-features/SKILL.md

@@ -2,8 +2,9 @@
 name: develop-new-features
 description: >-
   Spec-first feature development workflow for new behavior and greenfield
-  features. Depends on `generate-spec` for shared planning artifacts before
-  coding, then implements the approved feature with risk-driven test coverage.
+  features. Depends on `generate-spec` for shared planning artifacts and
+  `test-case-strategy` for risk-driven test selection before coding, then
+  implements the approved feature with focused validation.
   Use when users ask to design or implement new features, change product
   behavior, request a planning-first process, or ask for a greenfield feature.
   Once the approved spec set exists and implementation begins, complete all
@@ -20,16 +21,16 @@ description: >-
 
 ## Dependencies
 
-- Required: `generate-spec` for `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, `design.md`, clarification handling, approval gating, and completion-status backfill.
+- Required: `generate-spec` for `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, `design.md`, clarification handling, approval gating, and completion-status backfill; `test-case-strategy` for risk-driven test selection, meaningful oracle design, and unit drift checks.
 - Conditional: none.
 - Optional: none.
-- Fallback: If `generate-spec` is unavailable, stop and report the missing dependency.
+- Fallback: If `generate-spec` or `test-case-strategy` is unavailable, stop and report the missing dependency.
 
 ## Standards
 
 - Evidence: Review authoritative docs and the existing codebase before planning or implementation.
 - Execution: Use specs only for feature work that is genuinely multi-step, cross-surface, or higher risk; skip specs for obviously small/localized work and route that work to direct implementation or the appropriate maintenance skill instead.
-- Quality: Add risk-based tests with property-based, regression, integration, E2E, adversarial, and rollback coverage when relevant.
+- Quality: Use `test-case-strategy` to add risk-based tests with property-based, regression, integration, E2E, adversarial, and rollback coverage when relevant.
 - Output: Keep the approved planning artifacts and the final implementation aligned with actual completion results.
 
 ## Goal
@@ -93,21 +94,13 @@ Use a shared spec-generation workflow for non-trivial new feature work, then imp
 
 ### 5) Testing coverage (required)
 
-For every non-trivial change, evaluate all categories and add test cases or record justified `N/A`:
-- Start from a risk inventory, not from the happy path: assess misuse/abuse, authorization, invalid transitions, idempotency, replay/duplication, concurrency/races, data-integrity, and partial-failure/rollback risks.
-- Unit tests: changed logic, boundaries, failure paths, and exact error/side-effect expectations.
-- Regression tests: bug-prone or high-risk behavior that should never silently regress again.
-- Property-based tests: required for business-logic changes unless truly unsuitable; use them for invariants, generated business input spaces, state-machine/metamorphic checks when useful, and output expectation checks.
-- Integration tests: user-critical logic chain across modules/layers.
-- E2E tests: key user-visible path impacted by this change; prefer one minimal critical success path plus one highest-value denial/failure path when the risk warrants it.
-- Adversarial/penetration-style cases: abuse paths, malformed inputs, forged identities/privileges, invalid transitions, replay/duplication, stale/out-of-order events, toxic payload sizes, and risky edge combinations.
-
-Rules:
-- If E2E is too costly or unstable, add stronger integration coverage for the same risk and record the reason in the checklist.
-- If property-based testing is not suitable, record `N/A` with a concrete reason.
-- For logic chains with external services, mock or fake those services unless the real contract itself is under test; simulate diverse external states and verify the business chain remains correct.
-- Where the feature can partially commit work, test rollback, compensation, or no-partial-write behavior explicitly.
-- Each test must assert a meaningful oracle: exact business output, persisted state, emitted side effects, or intentional lack of side effects. Avoid assertion-light smoke tests and snapshot-only coverage.
+Use `$test-case-strategy` for every non-trivial change.
+
+- Start from risk inventory and requirement IDs, not from the happy path.
+- Define test oracles before implementation and map them to `spec.md`, `tasks.md`, and `checklist.md`.
+- For each atomic task that changes non-trivial local logic, define a focused unit drift check or record the smallest replacement verification with a concrete `N/A` reason.
+- Add unit, regression, property-based, integration, E2E, adversarial, mock/fake, rollback, or no-partial-write coverage only when the risk profile warrants it.
+- Each planned test must have a meaningful oracle: exact business output, persisted state, emitted side effects, or intentional lack of side effects.
 - Run relevant tests when possible and fix failures.
 
 ### 6) Completion updates
@@ -138,7 +131,4 @@ Rules:
 ## References
 
 - `$generate-spec`: shared planning and approval workflow.
-- `references/testing-unit.md`: unit testing principles.
-- `references/testing-property-based.md`: property-based testing principles.
-- `references/testing-integration.md`: integration testing principles.
-- `references/testing-e2e.md`: E2E decision and design principles.
+- `$test-case-strategy`: shared test selection, oracle design, and unit drift-check workflow.

package/develop-new-features/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Develop New Features"
   short_description: "Spec-first feature development that depends on generate-spec"
-  default_prompt: "Use $develop-new-features to design new behavior through a spec-first workflow: review the required external docs, run $generate-spec to create and maintain docs/plans/<date>/<change_name>/... for single-spec work or docs/plans/<date>/<batch_name>/<change_name>/... plus coordination.md for parallel batches, wait for explicit approval, document material external dependency contracts in contract.md, document the architecture/design delta in design.md, record shared preparation and legacy-replacement direction in coordination.md when multiple specs will be implemented in parallel, then complete the approved implementation end-to-end with risk-driven tests and full backfill of spec.md, tasks.md, checklist.md, contract.md, design.md, and when applicable coordination.md before yielding, unless the user changes scope or an external blocker prevents safe completion."
+  default_prompt: "Use $develop-new-features to design new behavior through a spec-first workflow: review the required external docs, run $generate-spec to create and maintain docs/plans/<date>/<change_name>/... for single-spec work or docs/plans/<date>/<batch_name>/<change_name>/... plus coordination.md for parallel batches, wait for explicit approval, document material external dependency contracts in contract.md, document the architecture/design delta in design.md, record shared preparation and legacy-replacement direction in coordination.md when multiple specs will be implemented in parallel, use $test-case-strategy to choose risk-driven tests and unit drift checks before implementation, then complete the approved implementation end-to-end with full backfill of spec.md, tasks.md, checklist.md, contract.md, design.md, and when applicable coordination.md before yielding, unless the user changes scope or an external blocker prevents safe completion."

package/enhance-existing-features/README.md

@@ -1,13 +1,13 @@
 # enhance-existing-features
 
-A brownfield feature-extension skill: map dependencies first, decide whether shared specs are required, then implement the approved change with risk-driven hardening tests.
+A brownfield feature-extension skill: map dependencies first, decide whether shared specs are required, then use `test-case-strategy` to implement the change with risk-driven hardening tests and unit drift checks.
 
 ## Core capabilities
 
 - Explores dependencies and data flow before deciding how to change the system.
 - Uses `generate-spec` whenever the change is high-complexity, touches a critical module, or crosses module boundaries.
 - Requires explicit approval before coding when specs are generated.
-- Still requires meaningful tests even when specs are skipped.
+- Still requires meaningful tests even when specs are skipped, selected through `test-case-strategy`.
 - Keeps brownfield changes focused and traceable.
 - When specs exist and are approved, finishes all in-scope planned tasks and applicable checklist items before yielding unless the user defers work or an external blocker prevents safe completion.
 
@@ -18,13 +18,8 @@ A brownfield feature-extension skill: map dependencies first, decide whether sha
 ├── SKILL.md
 ├── README.md
 ├── LICENSE
-├── agents/
-│   └── openai.yaml
-└── references/
-    ├── unit-tests.md
-    ├── property-based-tests.md
-    ├── integration-tests.md
-    └── e2e-tests.md
+└── agents/
+    └── openai.yaml
 ```
 
 ## Workflow summary
@@ -38,19 +33,12 @@ A brownfield feature-extension skill: map dependencies first, decide whether sha
 
 ## Test requirements
 
-- Unit: changed logic, boundaries, failure paths.
-- Regression: bug-prone or high-risk behavior that must not silently return.
-- Property-based: mandatory for business logic unless concrete `N/A` is recorded.
-- Integration: user-critical logic chain across layers/modules.
-- E2E: affected key user-visible path when the risk justifies it.
-- Adversarial: abuse paths, malformed inputs, privilege issues, replay, concurrency, and edge combinations when relevant.
-
-If E2E is not feasible, replace it with stronger integration coverage and record the reason.
+- Use `test-case-strategy` to choose the smallest useful test level for each risk.
+- Define meaningful oracles before finalizing tests.
+- Add focused unit drift checks for non-trivial atomic tasks when possible.
+- Record concrete `N/A` reasons when a test level is not suitable.
 
 ## References
 
 - Shared planning workflow: `generate-spec`
-- Unit testing guide: `references/unit-tests.md`
-- Property-based testing guide: `references/property-based-tests.md`
-- Integration testing guide: `references/integration-tests.md`
-- E2E testing guide: `references/e2e-tests.md`
+- Test selection and unit drift-check guide: `test-case-strategy`

package/enhance-existing-features/SKILL.md

@@ -6,26 +6,26 @@ description: >-
   before coding. When specs are needed, use `generate-spec` for planning,
   clarification, approval, and backfill, and complete approved in-scope tasks
   before yielding unless scope changes or an external blocker prevents safe
-  completion. With or without specs, add and run relevant unit,
-  property-based, regression, integration, E2E, and adversarial tests as
-  applicable, use mocks for external services in logic chains, and verify
-  meaningful business outcomes instead of smoke-only success.
+  completion. With or without specs, use `test-case-strategy` to select and
+  run relevant unit, property-based, regression, integration, E2E, adversarial,
+  mock/fake, and drift-check coverage, and verify meaningful business outcomes
+  instead of smoke-only success.
 ---
 
 # Enhance Existing Features
 
 ## Dependencies
 
-- Required: `generate-spec` for shared planning docs when spec-trigger conditions are met.
-- Conditional: `recover-missing-plan` when the user points to a required `docs/plans/...` spec set that is missing, archived, or mismatched in the current workspace.
+- Required: `test-case-strategy` for risk-driven test selection, meaningful oracle design, and unit drift checks.
+- Conditional: `generate-spec` for shared planning docs when spec-trigger conditions are met; `recover-missing-plan` when the user points to a required `docs/plans/...` spec set that is missing, archived, or mismatched in the current workspace.
 - Optional: none.
-- Fallback: If specs are required and `generate-spec` is unavailable, stop and report the missing dependency.
+- Fallback: If `test-case-strategy` is unavailable, stop and report the missing dependency. If specs are required and `generate-spec` is unavailable, stop and report the missing dependency.
 
 ## Standards
 
 - Evidence: Explore the existing codebase first and verify the latest authoritative docs for the involved stack or integrations.
 - Execution: Decide whether specs are required from the actual change surface, run `generate-spec` when needed, then continue through implementation, testing, and backfill until the active scope is fully reconciled; when the user asks for a specific final behavior or architectural end state, do not substitute a preparatory or partial milestone unless the user explicitly re-scopes the request.
-- Quality: Add risk-based tests with property-based, regression, integration, E2E, adversarial, and rollback coverage when relevant.
+- Quality: Use `test-case-strategy` to add risk-based tests with property-based, regression, integration, E2E, adversarial, and rollback coverage when relevant.
 - Output: Keep implementation and any planning artifacts traceable, updated, and aligned with actual completion results.
 
 ## Overview
@@ -106,21 +106,13 @@ If not triggered:
 
 ### 5) Testing coverage (required with or without specs)
 
-For every non-trivial change, evaluate all categories and add test cases or record justified `N/A`:
-- Start from a risk inventory, not from the happy path: assess misuse/abuse, authorization, invalid transitions, idempotency, replay/duplication, concurrency/races, data-integrity, and partial-failure/rollback risks.
-- Unit tests: changed logic, boundaries, failure paths, and exact error/side-effect expectations.
-- Regression tests: bug-prone or high-risk behavior that should never silently regress again.
-- Property-based tests: required for business-logic changes unless truly unsuitable; use them for invariants, generated business input spaces, state-machine/metamorphic checks when useful, and output expectation checks.
-- Integration tests: user-critical logic chain across modules/layers.
-- E2E tests: key user-visible path impacted by this change; prefer one minimal critical success path plus one highest-value denial/failure path when the risk warrants it.
-- Adversarial/penetration-style cases: abuse paths, malformed inputs, forged identities/privileges, invalid transitions, replay/duplication, stale/out-of-order events, toxic payload sizes, and risky edge combinations.
-
-Rules:
-- If E2E is too costly or unstable, add stronger integration coverage for the same risk and record the reason.
-- If property-based testing is not suitable, record `N/A` with a concrete reason.
-- For logic chains with external services, mock or fake those services unless the real contract itself is under test; simulate diverse external states and verify the business chain remains correct.
-- Where the feature can partially commit work, test rollback, compensation, or no-partial-write behavior explicitly.
-- Each test must assert a meaningful oracle: exact business output, persisted state, emitted side effects, or intentional lack of side effects. Avoid assertion-light smoke tests and snapshot-only coverage.
+Use `$test-case-strategy` for every non-trivial change, even when specs are skipped.
+
+- Start from risk inventory and changed behavior, not from the happy path.
+- Define test oracles before implementation when the change is planned, and before finalizing tests when the change is discovered during brownfield exploration.
+- For each atomic task that changes non-trivial local logic, define a focused unit drift check or record the smallest replacement verification with a concrete `N/A` reason.
+- Add unit, regression, property-based, integration, E2E, adversarial, mock/fake, rollback, or no-partial-write coverage only when the risk profile warrants it.
+- Each planned test must have a meaningful oracle: exact business output, persisted state, emitted side effects, or intentional lack of side effects.
 - Run relevant tests when possible and fix failures.
 
 ### 6) Completion updates
@@ -152,7 +144,4 @@ Rules:
 ## References
 
 - `$generate-spec`: shared planning and approval workflow.
-- `references/unit-tests.md`: unit testing guidance.
-- `references/property-based-tests.md`: property-based testing guidance.
-- `references/integration-tests.md`: integration testing guidance.
-- `references/e2e-tests.md`: E2E decision and design guidance.
+- `$test-case-strategy`: shared test selection, oracle design, and unit drift-check workflow.

package/enhance-existing-features/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "enhance-existing-features"
   short_description: "Extend brownfield features with conditional generate-spec planning and risk-driven tests"
-  default_prompt: "Use $enhance-existing-features to extend a brownfield feature: map the affected code and dependencies first, decide whether the change is high complexity / critical module / cross-module, run $generate-spec when specs are required, wait for explicit approval before coding, document material external dependency contracts in contract.md, document the architecture/design delta in design.md, and when one change is split into parallel spec sets maintain a shared coordination.md for common preparation, ownership boundaries, and legacy-replacement direction; always add risk-driven tests plus clear N/A reasons when a category truly does not apply; if the user asked for a specific final behavior or architecture state, do not stop at an enabling intermediate milestone unless the user explicitly narrows scope; if a spec set exists, finish the approved tasks and applicable checklist items and backfill spec.md, tasks.md, checklist.md, contract.md, design.md, and when applicable coordination.md before yielding unless the user changes scope or an external blocker prevents safe completion."
+  default_prompt: "Use $enhance-existing-features to extend a brownfield feature: map the affected code and dependencies first, decide whether the change is high complexity / critical module / cross-module, run $generate-spec when specs are required, wait for explicit approval before coding, document material external dependency contracts in contract.md, document the architecture/design delta in design.md, and when one change is split into parallel spec sets maintain a shared coordination.md for common preparation, ownership boundaries, and legacy-replacement direction; use $test-case-strategy to choose risk-driven tests, unit drift checks, and clear N/A reasons even when specs are skipped; if the user asked for a specific final behavior or architecture state, do not stop at an enabling intermediate milestone unless the user explicitly narrows scope; if a spec set exists, finish the approved tasks and applicable checklist items and backfill spec.md, tasks.md, checklist.md, contract.md, design.md, and when applicable coordination.md before yielding unless the user changes scope or an external blocker prevents safe completion."

package/generate-spec/README.md

@@ -1,6 +1,6 @@
 # generate-spec
 
-A shared planning skill for feature work. It centralizes creation and maintenance of `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, `design.md`, and when needed `coordination.md` so other skills can reuse one consistent approval-gated spec workflow.
+A shared planning skill for feature work. It centralizes creation and maintenance of `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, `design.md`, and when needed `coordination.md` so other skills can reuse one consistent approval-gated spec workflow with risk-driven test planning from `test-case-strategy`.
 
 ## Core capabilities
 
@@ -10,6 +10,7 @@ A shared planning skill for feature work. It centralizes creation and maintenanc
 - Requires clarification handling and explicit user approval before implementation starts.
 - Backfills task and checklist status after implementation and testing.
 - Keeps requirement, task, and test coverage mapping traceable.
+- Uses `test-case-strategy` to choose test levels, define meaningful oracles, and add focused unit drift checks to atomic implementation tasks.
 - Standardizes external dependency contracts in `contract.md` and architecture/design deltas in `design.md`.
 
 ## Repository layout
@@ -77,8 +78,8 @@ docs/plans/<today>/membership-cutover/
 ## Authoring rules
 
 - `spec.md`: use BDD keywords `GIVEN / WHEN / THEN / AND / Requirements`.
-- `tasks.md`: use `## **Task N: ...**`, `- N. [ ]`, and `- N.x [ ]`.
-- `checklist.md`: use `- [ ]` only, adapt items to real scope, and record actual results.
+- `tasks.md`: use `## **Task N: ...**` and atomic implementation queue items with allowed scope, output, completion condition, verification hook, and unit drift check.
+- `checklist.md`: use `- [ ]` only, adapt items to real scope, record actual results, and map behavior risks to test IDs plus oracles selected through `test-case-strategy`.
 - `contract.md`: when external dependencies materially shape the change, record their official-source-backed invocation surface, constraints, and caller obligations in the standard dependency-record format.
 - `design.md`: record the architecture/design delta in the standard format, including affected modules, flow, invariants, tradeoffs, and validation plan.
 - `coordination.md`: for multi-spec batches only, record shared preparation, ownership boundaries, replacement direction, file ownership guardrails, known collision candidates, pre-agreed edit rules for shared surfaces, shared API/schema freeze or additive-only rules, compatibility-shim retention rules, merge order, and cross-spec integration checkpoints, but never use it to make one spec depend on another spec's implementation before it can be completed.

package/generate-spec/SKILL.md

@@ -1,22 +1,22 @@
 ---
 name: generate-spec
-description: Generate and maintain shared feature planning artifacts (`spec.md`, `tasks.md`, `checklist.md`, `contract.md`, `design.md`, and when needed `coordination.md`) from standard templates with clarification tracking, approval gating, and post-implementation backfill. Use when a workflow needs specs before coding, or when another skill needs to create/update planning docs under `docs/plans/{YYYY-MM-DD}/...`.
+description: Generate and maintain shared feature planning artifacts (`spec.md`, `tasks.md`, `checklist.md`, `contract.md`, `design.md`, and when needed `coordination.md`) from standard templates with clarification tracking, approval gating, unit drift-check planning, and post-implementation backfill. Use when a workflow needs specs before coding, or when another skill needs to create/update planning docs under `docs/plans/{YYYY-MM-DD}/...`.
 ---
 
 # Generate Spec
 
 ## Dependencies
 
-- Required: none.
+- Required: `test-case-strategy` for risk-driven test case selection, meaningful oracle design, and unit drift-check planning.
 - Conditional: none.
 - Optional: none.
-- Fallback: not applicable.
+- Fallback: If `test-case-strategy` is unavailable, stop and report the missing dependency instead of inventing test coverage heuristics locally.
 
 ## Standards
 
 - Evidence: Review the relevant code, configs, and authoritative docs before filling requirements or test plans; when external dependencies, libraries, frameworks, APIs, or platforms are involved, checking their official documentation is mandatory during spec creation.
 - Execution: Generate the planning files first, keep each spec set tightly scoped, split broader work into multiple independent spec sets when needed, ensure every batch spec is independently completable and truly parallel-implementable without depending on another spec set to land first, surface shared-file or shared-contract collision risks during planning, resolve those coordination rules before implementation starts, complete them with traceable requirements and risks, handle clarification updates, then wait for explicit approval before implementation.
-- Quality: Keep `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, and `design.md` synchronized, map each planned test to a concrete risk or requirement, and tailor the templates so only applicable items remain active.
+- Quality: Keep `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, and `design.md` synchronized, use `test-case-strategy` to map each planned test to a concrete risk or requirement, and tailor the templates so only applicable items remain active.
 - Output: Store planning artifacts under `docs/plans/{YYYY-MM-DD}/{change_name}/` for single-spec work, or `docs/plans/{YYYY-MM-DD}/{batch_name}/{change_name}/` plus `coordination.md` for multi-spec parallel work whose member specs remain independently approvable, independently implementable, and ready for concurrent worktree execution with pre-agreed collision rules, and keep them concise, executable, and easy to update.
 
 ## Goal
@@ -78,8 +78,14 @@ Own the shared planning-doc lifecycle for feature work so other skills can reuse
 
 - Use `## **Task N: [Task Title]**` for each main task.
 - Describe each task's purpose and the related requirement IDs.
-- Use `- N. [ ]` for tasks and `- N.x [ ]` for subtasks.
+- Use `- N. [ ]` for atomic task items; use `- N.x [ ]` only when a task must be split into additional atomic subtasks.
+- Treat `tasks.md` as an implementation queue, not a high-level summary.
+- Make each checkbox atomic: one verb, one responsibility, one concrete output, and one verification hook.
+- For every task, include allowed scope, out-of-scope guardrails, requirement/design/contract inputs, expected output, completion condition, and verification hook.
+- If one task needs more than three files, more than one behavior slice, or an implementation decision not already captured in `design.md` or `contract.md`, split it before approval.
+- Use `$test-case-strategy` to define test IDs and unit drift checks for non-trivial local logic before implementation starts.
 - Include explicit tasks for testing, mocks/fakes, regression coverage, and adversarial or edge-case hardening when relevant.
+- Do not write vague tasks such as `Implement integration`, `Add tests`, or `Update docs`; replace them with task-local outputs, test IDs, and verification commands.
 
 ### 5) Fill `contract.md`
 
@@ -121,6 +127,7 @@ Own the shared planning-doc lifecycle for feature work so other skills can reuse
 - Treat the template as a starting point and adapt it to the actual scope.
 - Remove or rewrite template examples that are not part of the real plan instead of leaving them as fake work to be checked later.
 - Map observable behaviors to requirement IDs and real test case IDs.
+- Use `$test-case-strategy` to choose the smallest test level that proves each risk and to define meaningful oracles before implementation.
 - Record risk class, oracle/assertion focus, dependency strategy, and test results.
 - Property-based coverage is required for business-logic changes unless a concrete `N/A` reason is recorded.
 - For decision sections, create as many records as needed for distinct flows or risk slices; do not collapse unrelated decisions into one record.
@@ -152,6 +159,7 @@ Own the shared planning-doc lifecycle for feature work so other skills can reuse
 
 - By default, write planning docs in the user's language.
 - Keep requirement IDs, task IDs, and test IDs traceable across all three files.
+- Every non-trivial implementation task must have either a focused unit drift check, another concrete verification hook, or an explicit `N/A` reason.
 - Never allow one spec set to cover more than three modules.
 - When a request exceeds that scope, split it into independent, non-conflicting, non-dependent spec sets before approval.
 - For batch specs, independence is mandatory: each spec must describe a complete slice that can be implemented, tested, reviewed, and merged without waiting for another spec in the same batch.
@@ -169,6 +177,7 @@ Own the shared planning-doc lifecycle for feature work so other skills can reuse
 
 ## References
 
+- `$test-case-strategy`: shared test case selection, oracle design, and unit drift-check workflow.
 - `scripts/create-specs`: shared planning file generator, exposed as `apltk create-specs`.
 - `references/templates/spec.md`: BDD requirement template.
 - `references/templates/tasks.md`: task breakdown template.

package/generate-spec/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "generate-spec"
   short_description: "Generate shared feature spec, task, and checklist docs before coding"
-  default_prompt: "Use $generate-spec to create or update single-spec plans under docs/plans/<date>/<change_name>/ or parallel batches under docs/plans/<date>/<batch_name>/<change_name>/ with a shared coordination.md, but ensure every spec in a batch remains independently approvable, independently implementable, and safe for true parallel execution without depending on another batch spec landing first; surface shared-file or shared-contract collision risks during planning, settle ownership and additive-only rules in coordination.md before implementation starts, fill BDD requirements and risk-driven test planning, document external dependency contracts in contract.md when they materially constrain the change, write the architecture/design delta in design.md, process clarification updates, and wait for explicit approval before implementation."
+  default_prompt: "Use $generate-spec to create or update single-spec plans under docs/plans/<date>/<change_name>/ or parallel batches under docs/plans/<date>/<batch_name>/<change_name>/ with a shared coordination.md, but ensure every spec in a batch remains independently approvable, independently implementable, and safe for true parallel execution without depending on another batch spec landing first; surface shared-file or shared-contract collision risks during planning, settle ownership and additive-only rules in coordination.md before implementation starts, fill BDD requirements, use $test-case-strategy for risk-driven test planning and unit drift checks, make tasks.md an atomic implementation queue with concrete outputs and verification hooks, document external dependency contracts in contract.md when they materially constrain the change, write the architecture/design delta in design.md, process clarification updates, and wait for explicit approval before implementation."

package/generate-spec/references/templates/checklist.md

@@ -12,6 +12,7 @@
 - Duplicate or remove decision-record blocks as needed; the final document should contain as many records as the real change requires.
 - Duplicate or remove completion-record blocks as needed; the final document should contain as many records as the real change requires.
 - Suggested test result values: `PASS / FAIL / BLOCKED / NOT RUN / N/A`.
+- Use `$test-case-strategy` to choose test levels, define meaningful oracles, and record unit drift checks for atomic tasks.
 - For business-logic changes, property-based coverage is required unless a concrete `N/A` reason is recorded.
 - Each checklist item should map to a distinct risk; avoid repeating shallow happy-path cases.
 
@@ -30,6 +31,7 @@
   - Property/matrix focus: [invariant / generated business input space / external state matrix / adversarial case]
   - External dependency strategy: [none / mocked service states / near-real dependency]
   - Oracle/assertion focus: [exact output / persisted state / side effects / no partial write / compensation / emitted event / permission denial]
+  - Unit drift check: [UT-xx target unit + oracle, or N/A with reason]
   - Test result: `PASS / FAIL / BLOCKED / NOT RUN / N/A`
   - Notes (optional): [risk, limitation, observation]
 
@@ -41,6 +43,7 @@
   - Property/matrix focus: [invariant / generated business input space / external state matrix / adversarial case]
   - External dependency strategy: [none / mocked service states / near-real dependency]
   - Oracle/assertion focus: [exact output / persisted state / side effects / no partial write / compensation / emitted event / permission denial]
+  - Unit drift check: [UT-xx target unit + oracle, or N/A with reason]
   - Test result: `PASS / FAIL / BLOCKED / NOT RUN / N/A`
   - Notes (optional): [risk, limitation, observation]
 
@@ -52,11 +55,13 @@
   - Property/matrix focus: [invariant / generated business input space / external state matrix / adversarial case]
   - External dependency strategy: [none / mocked service states / near-real dependency]
   - Oracle/assertion focus: [exact output / persisted state / side effects / no partial write / compensation / emitted event / permission denial]
+  - Unit drift check: [UT-xx target unit + oracle, or N/A with reason]
   - Test result: `PASS / FAIL / BLOCKED / NOT RUN / N/A`
   - Notes (optional): [risk, limitation, observation]
 
 ## Required Hardening Records
 - [ ] Regression tests are added/updated for bug-prone or high-risk behavior, or `N/A` is recorded with a concrete reason.
+- [ ] Focused unit drift checks are defined for non-trivial atomic implementation tasks, or `N/A` is recorded with the replacement verification and concrete reason.
 - [ ] Property-based coverage is added/updated for changed business logic, or `N/A` is recorded with a concrete reason.
 - [ ] External services in the business logic chain are mocked/faked for scenario testing, or `N/A` is recorded with a concrete reason.
 - [ ] Adversarial/penetration-style cases are added/updated for abuse paths and edge combinations, or `N/A` is recorded with a concrete reason.

package/generate-spec/references/templates/tasks.md

@@ -5,32 +5,61 @@
 
 ## **Task 1: [Task Title]**
 
-[Describe task purpose and requirement mapping (for example: maps to R1.x, core objective is [one sentence]).]
+Purpose: [one sentence describing the narrow outcome]
+Requirements: [R1.x]
+Allowed scope: [files/modules/functions this task may touch]
+Out of scope: [files/modules/behaviors this task must not change]
 
 - 1. [ ] [Main task item]
-  - 1.1 [ ] [Subtask item]
-  - 1.2 [ ] [Subtask item]
+  - Input: [requirement/design/contract evidence]
+  - Touches: [specific file/function/module]
+  - Output: [specific code/doc/test artifact]
+  - Done when: [observable completion condition]
+  - Verify with: [focused command/check/manual inspection]
+  - Unit drift check: [UT-xx target unit + oracle, or N/A with reason]
+  - Do not: [explicit implementation-drift guardrail]
 
 ## **Task 2: [Task Title]**
 
-[Describe task purpose and requirement mapping (for example: maps to R2.x, core objective is [one sentence]).]
+Purpose: [one sentence describing the narrow outcome]
+Requirements: [R2.x]
+Allowed scope: [files/modules/functions this task may touch]
+Out of scope: [files/modules/behaviors this task must not change]
 
 - 2. [ ] [Main task item]
-  - 2.1 [ ] [Subtask item]
-  - 2.2 [ ] [Subtask item]
+  - Input: [requirement/design/contract evidence]
+  - Touches: [specific file/function/module]
+  - Output: [specific code/doc/test artifact]
+  - Done when: [observable completion condition]
+  - Verify with: [focused command/check/manual inspection]
+  - Unit drift check: [UT-xx target unit + oracle, or N/A with reason]
+  - Do not: [explicit implementation-drift guardrail]
 
 ## **Task 3: [Task Title]**
 
-[Describe task purpose and requirement mapping (for example: maps to R3.x, core objective is [one sentence]).]
+Purpose: [one sentence describing the narrow outcome]
+Requirements: [R3.x]
+Allowed scope: [files/modules/functions this task may touch]
+Out of scope: [files/modules/behaviors this task must not change]
 
 - 3. [ ] [Main task item]
-  - 3.1 [ ] [Subtask item]
-  - 3.2 [ ] [Subtask item]
+  - Input: [requirement/design/contract evidence]
+  - Touches: [specific file/function/module]
+  - Output: [specific code/doc/test artifact]
+  - Done when: [observable completion condition]
+  - Verify with: [focused command/check/manual inspection]
+  - Unit drift check: [UT-xx target unit + oracle, or N/A with reason]
+  - Do not: [explicit implementation-drift guardrail]
 
 ## Notes
 - Task order should reflect actual implementation sequence.
 - Every main task must map back to `spec.md` requirement IDs.
+- Treat `tasks.md` as an implementation queue, not a high-level work summary.
+- Each checkbox must be atomic: one verb, one responsibility, one concrete output, and one verification hook.
+- Split any task that needs more than three files, more than one behavior slice, or a design decision not already captured in `design.md` or `contract.md`.
+- Use `$test-case-strategy` to define test IDs and unit drift checks before implementation.
 - Include explicit tasks for required test coverage (unit, regression, property-based, integration/E2E as applicable), mock scenario setup, and adversarial/edge-case hardening.
+- Do not write vague tasks such as `Implement integration`, `Add tests`, or `Update docs`; replace them with task-local outputs, test IDs, and verification commands.
 - For batch specs, tasks must never include "wait for Spec X to land first" as a prerequisite; if such a dependency appears, re-slice the plan or move the coordination rule into `coordination.md`.
 - After execution, the agent must update each checkbox (`[x]` for done, `[ ]` for not done).
 - Remove all placeholder guidance text in square brackets after filling.

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

@@ -25,8 +25,8 @@ 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.
-- 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, 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, 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.
+- 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.
 
 ## Goal
@@ -69,6 +69,10 @@ Implement approved spec planning sets in an isolated git worktree, ensuring the
   - search the codebase, tests, and recent git history for the exact feature boundary or cutover named by the spec
   - if the requested plan is archived, treat that as a signal to verify whether the implementation already landed before starting any new branch
   - when the requested behavior is already present and verified, report a `no-op` result with concrete evidence instead of recreating the same work in a fresh worktree
+- When the spec belongs to a parallel batch and other local worktrees for sibling specs already exist, inspect those sibling worktrees before editing any shared boundary module (for example shared runtime, config, or contract files):
+  - use `git worktree list --porcelain` plus the batch ownership map in `coordination.md` to identify likely sibling worktrees
+  - if a sibling worktree already touches the same shared file, read that diff first and either stay within your owned additive boundary or update the coordination evidence before proceeding
+  - do not assume coordination is collision-free just because the plan scopes differ at the directory level
 
 ### 3) Create a new worktree if needed
 

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

@@ -1,4 +1,4 @@
 interface:
   display_name: "Implement Specs with Worktree"
   short_description: "Implement an approved spec set inside an isolated git worktree"
-  default_prompt: "Use $implement-specs-with-worktree to read the full plan set under docs/plans, including parent coordination.md when the spec belongs to a parallel batch, identify the parent branch that the worktree should inherit from, create or reuse an isolated git worktree whose branch and directory names are derived from the spec name, implement all approved tasks within the shared ownership and replacement-direction constraints, backfill completion status into the planning docs, and commit the result to the local worktree branch without affecting the parent branch."
+  default_prompt: "Use $implement-specs-with-worktree to read the full plan set under docs/plans, including parent coordination.md when the spec belongs to a parallel batch, identify the parent branch that the worktree should inherit from, inspect sibling worktrees when shared runtime/config boundaries may overlap, create or reuse an isolated git worktree whose branch and directory names are derived from the spec name, implement all approved tasks within the shared ownership and replacement-direction constraints, backfill completion status into the planning docs, and commit the result to the local worktree branch without affecting the parent branch."

package/package.json

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