@laitszkin/apollo-toolkit 3.6.5 → 3.7.0

package/CHANGELOG.md

@@ -2,6 +2,16 @@
 
 All notable changes to this repository are documented in this file.
 
+## [v3.7.0] - 2026-04-29
+
+### Added
+- Extract shared CJK PDF layout, merge-conflict-resolver, and common git-submission workflows into standalone reusable skills (`cjk-pdf`, `merge-conflict-resolver`)
+- Establish skill-dependency pattern: `implement-specs-with-worktree` depends on `implement-specs`; `version-release` depends on `commit-and-push`
+
+### Changed
+- Strip ~375 lines of verbosity across 32 skill files: remove empty Dependencies sections, merge redundant Overview paragraphs, deduplicate repeated principles in `generate-spec`, and consolidate `archive-specs` workflow steps
+- Extract inline output templates and issue schemas into skill-local reference files for `scheduled-runtime-health-check` and `open-github-issue`
+
 ## [Unreleased]
 
 ### Added

package/align-project-documents/SKILL.md

@@ -5,13 +5,6 @@ description: Read and understand a software project, then generate or align proj
 
 # Align Project Documents
 
-## Dependencies
-
-- Required: none.
-- Conditional: none.
-- Optional: none.
-- Fallback: not applicable.
-
 ## Standards
 
 - Evidence: Treat source code, configuration, scripts, and tests as the source of truth.

package/analyse-app-logs/SKILL.md

@@ -19,10 +19,6 @@ description: Comprehensive application log investigation workflow that reads log
 - Quality: Separate confirmed issues from hypotheses and include time-window, log, code, impact, and confidence evidence for each report.
 - Output: Return incident summary, confirmed issues, hypotheses, monitoring improvements, and publication status.
 
-## Overview
-
-Use this skill to analyze application logs systematically with the codebase and runtime context, then report confirmed issues with clear evidence, confidence, and next actions.
-
 ## Core principles
 
 - Prioritize evidence over assumptions; avoid speculative conclusions.

package/answering-questions-with-research/SKILL.md

@@ -5,13 +5,6 @@ description: This skill should be used when the user asks a question that needs
 
 # Answering Questions With Research
 
-## Dependencies
-
-- Required: none.
-- Conditional: none.
-- Optional: none.
-- Fallback: not applicable.
-
 ## Standards
 
 - Evidence: Verify repository facts from local files first and confirm time-sensitive claims with current external sources.

package/archive-specs/SKILL.md

@@ -9,8 +9,6 @@ description: Convert completed project plan sets into maintainable project docum
 
 - Required: `align-project-documents` to align repository docs with current code before archiving, and `maintain-project-constraints` to synchronize `AGENTS.md/CLAUDE.md` after the doc update.
 - Conditional: none.
-- Optional: none.
-- Fallback: not applicable.
 
 ## Standards
 
@@ -58,19 +56,10 @@ Convert completed planning artifacts into stable, standardized project documenta
   - `docs/architecture.md`
   - `docs/features.md`
   - `docs/developer-guide.md`
+- Ensure the categorized docs cover: installation and deployment, configuration, external services with required credentials and API key acquisition tutorials when applicable, architecture and module boundaries, feature introductions, and developer onboarding context.
 - If the repository already uses different doc paths, preserve the established locations only when the resulting documents still match the same categorized sections and remain easy to maintain.
 
-### 4) Fill the required documentation sections
-
-Ensure the split project docs cover all of the following:
-- how to install and deploy the project
-- how to configure the project
-- external services, required credentials, and API key acquisition tutorials when applicable
-- project architecture and key module boundaries
-- project feature introductions and user-facing flows
-- project context developers should understand before making changes
-
-### 5) Write the configuration and external-service guidance carefully
+### 4) Write the configuration and external-service guidance carefully
 
 - List each env var, config file, or secret only when supported by repository evidence.
 - For every external service, document:
@@ -81,7 +70,7 @@ Ensure the split project docs cover all of the following:
   - any safe-development notes such as sandbox/test-mode usage
 - If the repository does not show how to obtain a credential, say so explicitly and point to the service's official setup page rather than guessing steps.
 
-### 6) Keep README short and the doc set navigable
+### 5) Keep README short and the doc set navigable
 
 - `README.md` should stay short: project intro, quick install/deploy, major features, and key doc links.
 - `docs/README.md` should act as the reference list for the categorized docs.
@@ -89,7 +78,7 @@ Ensure the split project docs cover all of the following:
 - Remove template placeholders and stale planning language before finishing.
 - After the docs are aligned, run `maintain-project-constraints` whenever the documentation changes imply `AGENTS.md/CLAUDE.md` needs to reflect updated workflows, commands, or repository capabilities.
 
-### 7) Archive superseded spec files after successful conversion
+### 6) Archive superseded spec files after successful conversion
 
 - After the standardized project docs are complete and verified, archive the old source spec files that were converted.
 - Prefer moving the consumed `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, `design.md`, and when applicable their shared `coordination.md`, or the containing batch/spec plan directory, into a clearly marked archive path instead of leaving them mixed with active docs.

package/cjk-pdf/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: cjk-pdf
+description: Handle CJK PDF font selection, rendering requirements, and visual QA for Chinese-compatible PDF output. Use when any skill needs to render PDFs with Chinese or mixed CJK text, verify font paths, apply content safety rules, and perform screenshot-based visual QA.
+---
+
+# CJK PDF
+
+## Dependencies
+
+- Required: `pdf` for all PDF rendering and visual QA.
+- Conditional: none.
+- Optional: none.
+- Fallback: If `pdf` is unavailable, stop and report the missing dependency.
+
+## Standards
+
+- Evidence: Verify font paths exist on the current macOS host before rendering.
+- Execution: Select fonts → enforce content safety → delegate to `pdf` → screenshot QA → cleanup.
+- Quality: Verify CJK glyphs render correctly (no tofu boxes), headings and body text are balanced, tables stay readable.
+- Output: Return the final verified PDF path after passing visual QA.
+
+## Workflow
+
+### 1) Select CJK fonts (macOS)
+
+Prefer fonts in this order (verify path exists before use):
+1. `/System/Library/Fonts/Hiragino Sans GB.ttc`
+2. `/System/Library/Fonts/Supplemental/Songti.ttc`
+3. `/Library/Fonts/Arial Unicode.ttf`
+4. `/System/Library/Fonts/STHeiti Medium.ttc`
+5. `/System/Library/Fonts/STHeiti Light.ttc`
+
+- Do not hardcode missing or poorly-rendering fonts.
+- Do not assume `PingFang` is available on every macOS host.
+- If the `pdf` skill already has a verified CJK-safe default, reuse it instead of overriding.
+
+### 2) Content safety
+
+- Use Chinese-compatible characters, punctuation, and fonts.
+- Avoid emoji, decorative symbols, and unusual glyphs that often break rendering.
+
+### 3) Delegate rendering to `pdf`
+
+- Pass content and font requirements to the `pdf` skill.
+- For tables with long Chinese phrases: require wrapped paragraph cells, width-constrained columns, and row heights that expand with content.
+
+### 4) Visual QA
+
+Open the rendered PDF and inspect:
+- First page — layout, title, headings
+- One page with a table or structured data
+- One page with dense paragraph text
+
+Verify:
+- CJK glyphs render correctly (no tofu boxes or missing characters)
+- Reasonable line wrapping
+- Table borders and columns staying readable
+- Page margins and spacing look clean
+- Heading hierarchy visually balanced
+- Long table cells do not overlap adjacent text
+- Row heights expand to fit wrapped content
+
+If layout or glyph rendering is wrong, fix font, spacing, or content and re-render.
+
+### 5) Cleanup
+
+- QA screenshots are temporary — delete after visual check unless the user asks to keep them.
+- Keep only the final PDF as the persistent deliverable.

package/codex/learn-skill-from-conversations/SKILL.md

@@ -19,10 +19,6 @@ description: Learn and evolve the local skill library from recent Codex conversa
 - Quality: Take no action when there are no recent sessions, avoid unrelated broad refactors, keep shared skills cross-project reusable, route project-specific tooling patterns into the relevant project's `~/.codex/skills/`, and validate every changed skill.
 - Output: Report the analyzed sessions, extracted lessons, created or updated skills, shared-vs-project-specific placement decisions, and the reasoning behind each decision.
 
-## Overview
-
-Extract recent conversations, identify reusable lessons, and convert those lessons into concrete skill updates.
-
 ## Required Resources
 
 - `scripts/extract_recent_conversations.py` for deterministic session extraction, exposed as `apltk extract-skill-conversations`.

package/commit-and-push/SKILL.md

@@ -19,10 +19,6 @@ description: "Guide the agent to submit local changes with commit and push only
 - Quality: Re-run relevant validation for runtime changes, preserve unrelated local work safely when branch switching or post-push local sync is required, do not bypass blocking readiness findings such as missing/stale `Unreleased` bullets or unsynchronized project docs, and never collapse intentionally separated commit scopes just because related unstaged changes are present.
 - Output: Produce a concise Conventional Commit, push it to the intended branch, and report any temporary stash/restore, commit-scope separation, or local branch sync that was required.
 
-## Overview
-
-Run a standardized commit-and-push workflow without release/version steps.
-
 ## References
 
 Load only when needed:

package/deep-research-topics/SKILL.md

@@ -19,10 +19,6 @@ description: "Research specific topics deeply and turn them into evidence-based
 - Quality: Distinguish verified facts from analysis or inference and call out limitations, conflicts, or stale data explicitly.
 - Output: Deliver a polished research file with clear sections, citations, dates, and source links.
 
-## Overview
-
-Use this skill when a user needs topic research that goes beyond a quick answer and should end as a polished file deliverable.
-
 ## Required Workflow
 
 1. Understand the request

package/discover-edge-cases/SKILL.md

@@ -19,10 +19,6 @@ description: Discover reproducible edge-case risks in changed code or a selected
 - Quality: Separate confirmed findings from hypotheses and cover boundary, failure, stateful, and observability edge cases that matter to the scope.
 - Output: Return prioritized findings, edge-case evidence, risk assessment, hardening guidance, and residual risk only.
 
-## Overview
-
-Use this skill to discover edge-case failures and coverage gaps with evidence-first analysis. The goal is to surface reproducible findings, not to remediate them.
-
 ## Non-negotiable Boundaries
 
 - This skill is discovery-only: do not edit code, do not add or modify tests, and do not open PRs.

package/docs-to-voice/SKILL.md

@@ -5,13 +5,6 @@ description: Convert text and document content into audio files and sentence-lev
 
 # Docs to Voice
 
-## Dependencies
-
-- Required: none.
-- Conditional: none.
-- Optional: none.
-- Fallback: not applicable.
-
 ## Standards
 
 - Evidence: Confirm `project_dir`, input source, mode, and environment-backed settings before generation.
@@ -19,22 +12,6 @@ description: Convert text and document content into audio files and sentence-lev
 - Quality: Respect mode-specific options, sentence splitting rules, and post-process requirements such as `ffmpeg` for speed changes.
 - Output: Return the absolute output audio path together with the generated `.timeline.json` and `.srt` companions.
 
-## Overview
-
-Use `apltk docs-to-voice` to convert raw text or text files into audio and always save under:
-
-`project_dir/audio/{project_name}/`
-
-Alongside each audio file, the script also writes:
-
-- `{audio_name_without_extension}.timeline.json`
-- `{audio_name_without_extension}.srt`
-
-Modes:
-
-- `say`: local macOS `say`
-- `api`: Alibaba Cloud Model Studio TTS API (for example `qwen3-tts`)
-
 ## Workflow
 
 1. Collect inputs.

package/enhance-existing-features/SKILL.md

@@ -28,10 +28,6 @@ description: >-
 - 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
-
-Safely extend brownfield systems by exploring the existing codebase first, using the user's requested change plus discovered impact to decide whether specs are needed, then following a consistent implementation and testing workflow with minimal, well-validated changes.
-
 ## Workflow
 
 ### 1) Explore codebase first

package/financial-research/SKILL.md

@@ -7,7 +7,7 @@ description: Research the most important tradeable instruments to watch for the
 
 ## Dependencies
 
-- Required: `pdf` for the final deliverable.
+- Required: `pdf` for the final deliverable, `cjk-pdf` for CJK font and PDF QA needs.
 - Conditional: none.
 - Optional: none.
 - Fallback: If `pdf` is unavailable, stop and report the missing dependency instead of inventing another export workflow.
@@ -123,18 +123,7 @@ Do not guess missing facts that materially change the report scope.
 - Start from `assets/weekly_market_report_template.md`.
 - Localize headings to the requested output language.
 - Default to Chinese if the user did not specify a language.
-- Use Chinese-compatible characters, punctuation, and fonts.
-- On macOS, do not assume a font family is available just because it worked elsewhere.
-- On macOS, prefer a locally verified CJK font in this order when the PDF workflow allows explicit font selection:
-  - `/System/Library/Fonts/Hiragino Sans GB.ttc`
-  - `/System/Library/Fonts/Supplemental/Songti.ttc`
-  - `/Library/Fonts/Arial Unicode.ttf`
-  - `/System/Library/Fonts/STHeiti Medium.ttc`
-  - `/System/Library/Fonts/STHeiti Light.ttc`
-- Do not hardcode fonts that are missing or known to render poorly on the current macOS host.
-- Do not assume `PingFang` exists on every macOS environment.
-- If the `pdf` skill already has a verified CJK-safe default on the current machine, reuse that default instead of overriding it.
-- Avoid emoji, decorative symbols, and unusual glyphs that often break in PDF rendering.
+Use $cjk-pdf for CJK font selection, content safety, visual QA, and temporary file cleanup.
 - Only include exact price levels, yields, or percentages when they were verified from current sources.
 
 ### 6) Render the final PDF

package/generate-spec/SKILL.md

@@ -15,7 +15,7 @@ description: Generate and maintain shared feature planning artifacts (`spec.md`,
 ## 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 from this skill's current templates 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, add `preparation.md` only when the specs cannot be made parallel-safe without prior shared work, keep that preparation minimal and free of core business logic or target outcomes, complete plans with traceable requirements and risks, handle clarification updates, then wait for explicit approval before implementation.
+- Execution: Generate the planning files from this skill's current templates first. Follow the scoping, independence, and parallel-safety rules in Working Rules. Surface shared-file or shared-contract collision risks during planning and resolve coordination rules before implementation starts. Use `preparation.md` only when needed; keep that preparation minimal and free of core business logic or target outcomes (see Working Rules). Complete plans 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`, `design.md`, and any shared batch docs synchronized, use `test-case-strategy` to map each planned test to a concrete risk or requirement, preserve the actual headings and field structure from this skill's templates, 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 shared `coordination.md` for multi-spec parallel work. Add shared `preparation.md` at the batch root only when prerequisite work must land before member specs can run in parallel, and keep individual specs concise, executable, non-overlapping with that preparation, and easy to update.
 
@@ -46,13 +46,11 @@ Own the shared planning-doc lifecycle for feature work so other skills can reuse
 - Keep each spec set scoped to at most three modules.
 - If the requested work would span more than three modules, do not draft one oversized coupled plan.
 - Instead, split the work into multiple spec sets, each independently valid and each covering no more than three modules.
-- Define those spec sets so they do not conflict with each other and do not require another spec set to land first in order to be approved or implemented safely.
-- For batch generation, treat cross-spec implementation dependency as a planning bug: if Spec B cannot be completed safely until Spec A lands, they should be one spec set or be re-sliced so each spec has its own self-contained outcome.
+- See Working Rules for the independence rule.
 - Use `preparation.md`, not individual spec files, when the only safe way to parallelize a batch is to land shared prerequisite work before any spec starts.
-- Keep `preparation.md` as small as possible: it may define enabling scaffolds, shared test fixtures, naming/contract stubs, mechanical migrations, or non-business compatibility surfaces, but it must not implement core business logic, the target user behavior, or any member spec's actual outcome.
-- If the required pre-work would change business behavior, implement target logic, or satisfy a meaningful requirement by itself, re-slice it into one or more normal spec sets instead of placing it in `preparation.md`.
+- Keep `preparation.md` small: it may define enabling scaffolds, shared test fixtures, naming/contract stubs, mechanical migrations, or non-business compatibility surfaces. See Working Rules for the preparation.md rule.
 - Allow shared preparation only when it is completed before parallel implementation begins; do not hide required pre-work inside one member spec while other specs depend on it.
-- Treat any unresolved shared-file collision, overlapping ownership, or incompatible contract change across spec sets as a planning bug to resolve before approval, not an implementation-time surprise.
+- See Working Rules for the parallel-safety rule.
 - If two candidate spec sets would still need to edit the same non-additive surface, either merge them into one spec set, record a concrete ownership split plus additive-only rule that makes parallel work safe, or move the shared pre-work into `preparation.md` when the pre-work can be completed once before all specs.
 - Use:
   - `WORKSPACE_ROOT=<target_project_root>`
@@ -121,7 +119,7 @@ Own the shared planning-doc lifecycle for feature work so other skills can reuse
 - Create `coordination.md` only when one user request is intentionally split into multiple spec sets that may be implemented in parallel.
 - Place it at `docs/plans/{YYYY-MM-DD}/{batch_name}/coordination.md`.
 - Use it as the batch-level source of truth for shared preparation, ownership boundaries, merge order, and cross-spec constraints.
-- Record explicitly that each spec set must remain independently completable and must not rely on another spec set's code changes, unfinished tasks, or merge order to achieve its own approved outcome.
+- See Working Rules for the independence rule.
 - Record shared fields, shared contracts, or shared data-shape assumptions that multiple spec sets must align on.
 - Record whether the batch is ready for parallel implementation now; if not, point to `preparation.md` for executable prerequisite work or list coordination decisions that must still be settled.
 - When one spec set replaces or removes legacy behavior, state that direction explicitly so all worktrees implement toward the same target rather than preserving the old behavior accidentally.
@@ -144,10 +142,8 @@ Own the shared planning-doc lifecycle for feature work so other skills can reuse
 - Include only the smallest shared prerequisite work that every affected spec can assume after it lands.
 - Exclude core business logic, target business outcomes, user-visible behavior changes, and member-spec implementation guidance; those belong in normal spec files.
 - Include relevant validation work for the preparation itself.
-- Do not include member-spec implementation tasks in `preparation.md`.
 - Remove overlapping instructions from member specs; specs must reference the prepared baseline as an assumption instead of repeating the setup tasks.
-- If the required work is large enough to become its own product behavior slice, or if it carries core business logic, re-slice the batch instead of hiding that slice in `preparation.md`.
-- If the batch can be made parallel-safe through ownership rules, additive-only constraints, or re-slicing, do not create `preparation.md`.
+- See Working Rules for the parallel-safety rule.
 
 ### 7) Fill `checklist.md`
 

package/implement-specs/SKILL.md

@@ -34,86 +34,38 @@ Implement approved spec planning sets directly in the current checkout when the
 
 ### 1) Identify and read the specs set
 
-- Locate the specs directory. The path format is `docs/plans/{YYYY-MM-DD}/{change_name}/` for single-spec work, or `docs/plans/{YYYY-MM-DD}/{batch_name}/{change_name}/` for coordinated multi-spec work.
-- If the user provides a specific path, use that directly.
-- If only a `change_name` or date is given, search for matching directories under `docs/plans/`.
-- If the requested path is absent from the current checkout, stop and identify the authoritative source before implementing:
-  - inspect the repository history and relevant local branches for that exact `docs/plans/...` path
-  - use `recover-missing-plan` when the plan must be restored or reconstructed before work can continue
-  - prefer the exact matching plan directory from the authoritative branch or main working tree over archived, approximate, or sibling plan directories
-  - if the plan lives under a batch directory, recover only the requested spec directory plus the shared `coordination.md` that governs it
-  - do not copy neighboring sibling spec directories into scope unless the user explicitly expands scope
-- When the plan sits under a batch directory, also read the sibling `coordination.md` before implementation.
-- 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.
-- Understand the scope, requirements, and planned tasks before proceeding.
+See `../references/implement-specs-common.md` for the standard spec discovery and reading workflow.
 
 ### 2) Check current branch state
 
 - Run `git status -sb` and identify the current branch.
 - Preserve unrelated user changes. If the checkout contains unrelated dirty files, avoid editing them and report any blockers before proceeding.
 - Confirm that the current branch is the intended destination for the implementation. Do not create, rename, or switch branches unless the user explicitly changes scope.
-- If the exact requested plan was recovered into the current checkout, re-read the recovered files before coding so implementation and backfill use the same plan snapshot.
+- If the exact requested plan was recovered (e.g. via `recover-missing-plan`) into the current checkout, re-read the recovered files before coding so implementation and backfill use the same plan snapshot.
 
 ### 3) Implement the planned tasks
 
-- 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.
-- 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:
-  - Unit tests for changed logic
-  - Regression tests for bug-prone behavior
-  - Property-based tests for business logic changes
-  - Integration tests for cross-module chains
-  - E2E tests for key user-visible paths
-  - Adversarial tests for abuse paths
-- Run relevant tests and fix failures.
-- Do not skip testing even for seemingly small changes.
+See `../references/implement-specs-common.md` for the standard implementation workflow.
 
 ### 4) Backfill completion status
 
-After implementation and testing:
-
-- Update `spec.md` with actual completion state for each requirement.
-- 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.
-- Do not mark unused template examples or non-applicable items as complete.
+See `../references/implement-specs-common.md` for the standard backfill workflow.
 
 ### 5) Commit changes
 
-- Stage the implementation files:
-  ```bash
-  git add <implementation-files> <test-files> <updated-specs>
-  ```
-- Write a concise Conventional Commit message describing the implemented scope.
-- Commit to the current branch:
-  ```bash
-  git commit -m "<conventional-commit-message>"
-  ```
+See `../references/implement-specs-common.md` for the standard commit workflow.
 
 ### 6) Report completion
 
-- Summarize what was implemented.
+See `../references/implement-specs-common.md` for the standard reporting format. Add the following context-specific details:
+
 - Note the current branch and commit hash.
 - Confirm which tests ran and which planned documents were backfilled.
 
 ## Working Rules
 
 - Always work in the current checkout; never create a branch or git worktree inside this skill unless the user explicitly changes the request.
-- 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.
-- 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.
-- Follow the testing standards from `enhance-existing-features` and `develop-new-features`.
-- Do not push to remote unless the user explicitly requests it.
+- The shared working rules in `../references/implement-specs-common.md` also apply (complete all tasks, treat specs as truth, respect coordination.md, follow testing standards, no remote push unless asked).
 
 ## References
 

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

@@ -17,10 +17,9 @@ description: >-
 
 ## Dependencies
 
-- Required: `enhance-existing-features` and `develop-new-features` for implementation standards.
+- Required: `implement-specs`, `enhance-existing-features`, and `develop-new-features` for implementation standards.
 - Conditional: `generate-spec` if spec files need clarification or updates.
-- Optional: none.
-- Fallback: If `enhance-existing-features` or `develop-new-features` is unavailable, stop and report the missing dependency.
+- Fallback: If `implement-specs`, `enhance-existing-features`, or `develop-new-features` is unavailable, stop and report the missing dependency.
 
 ## Standards
 
@@ -37,24 +36,11 @@ Implement approved spec planning sets in an isolated git worktree, ensuring the
 
 ### 1) Identify and read the specs set
 
-- Locate the specs directory. The path format is `docs/plans/{YYYY-MM-DD}/{change_name}/` for single-spec work, or `docs/plans/{YYYY-MM-DD}/{batch_name}/{change_name}/` for coordinated multi-spec work.
-- If the user provides a specific path, use that directly.
-- If only a `change_name` or date is given, search for matching directories under `docs/plans/`.
-- If the requested path is absent from the current worktree, stop and identify the authoritative source before implementing:
-  - inspect the main working tree and any relevant local branches/worktrees for that exact `docs/plans/...` path
-  - 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` 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, 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.
+Use $implement-specs for the standard spec discovery and reading workflow.
+
+Additionally:
+
+- When `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.
 
 ### 2) Check current worktree state
 
@@ -104,50 +90,29 @@ Use branch naming from `references/branch-naming.md`.
 
 ### 4) Implement the planned tasks
 
-- 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.
+Use $implement-specs for the standard implementation workflow.
+
+Additionally:
+
 - 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:
-  - Unit tests for changed logic
-  - Regression tests for bug-prone behavior
-  - Property-based tests for business logic changes
-  - Integration tests for cross-module chains
-  - E2E tests for key user-visible paths
-  - Adversarial tests for abuse paths
-- Run relevant tests and fix failures.
 - When using targeted Rust `cargo test` commands, pass at most one positional test filter per invocation; if multiple selectors are needed, run separate commands or a broader confirmed selector.
-- Treat any targeted test command that executes zero tests as non-verification and rerun with a selector that proves the intended coverage actually ran.
-- Do not skip testing even for seemingly small changes.
 
 ### 5) Backfill completion status
 
-After implementation and testing:
+Use $implement-specs for the standard backfill workflow.
+
+Additionally:
 
-- Update `spec.md` with actual completion state for each requirement.
-- 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
 
-- Stage the implementation files:
-  ```bash
-  git add <implementation-files> <test-files> <updated-specs>
-  ```
-- Write a concise Conventional Commit message describing the implemented scope.
-- Commit to the worktree's local branch:
-  ```bash
-  git commit -m "<conventional-commit-message>"
-  ```
+Use $implement-specs for the standard commit workflow.
 
 ### 7) Report completion
 
-- Summarize what was implemented.
+See $implement-specs for the standard reporting format. Add the following context-specific details:
+
 - Note the spec-derived branch name and worktree location.
 - Confirm that the parent branch remains unaffected.
 
@@ -158,14 +123,9 @@ After implementation and testing:
 - Treat an already-landed spec as complete work, not as a reason to recreate a duplicate worktree.
 - Keep the new branch based on the same parent branch as the worktree base; do not silently rebase the workflow onto a different branch.
 - Use the spec-set name as the canonical identifier for the branch and worktree unless the user explicitly asks for a different naming scheme.
-- 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`.
-- Do not push to remote unless the user explicitly requests it.
+- The shared working rules from $implement-specs also apply (complete all tasks, treat specs as truth, respect coordination.md, follow testing standards, no remote push unless asked).
 
 ## References
 

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

@@ -17,7 +17,7 @@ description: >-
 ## Dependencies
 
 - Required: `archive-specs` to archive completed plan sets and synchronize durable project docs after merge verification, and `commit-and-push` for the final current-branch submission flow.
-- Conditional: none.
+- Conditional: `merge-conflict-resolver` to resolve merge conflicts deterministically when conflicts arise.
 - Optional: none.
 - Fallback: If git operations fail, stop and report the error.
 
@@ -82,13 +82,7 @@ For each in-scope named branch:
    git merge <branch-name> --no-ff -m "Merge branch '<branch-name>' into <current-branch>"
    ```
 
-3. If conflicts occur, resolve them automatically using these rules:
-   - Read the conflict markers and both parent versions before editing.
-   - **Same line, different content**: keep the version that matches the intended post-merge behavior, not simply the newer edit.
-   - **File deleted in one branch, modified in another**: keep the version supported by current code references and tests; do not silently drop reachable code.
-   - **Both branches modified the same file differently**: preserve both changes when they are compatible; if they overlap, manually compose a merged result that keeps the verified logic from both sides.
-   - **Test files conflicting**: preserve coverage for both behaviors unless one assertion is now obsolete by verified implementation changes.
-   - Use `-X ours` / `-X theirs` only for a narrowly justified conflict after reading the actual content; never use those flags as the default merge strategy.
+3. If conflicts occur, use $merge-conflict-resolver to resolve them deterministically.
 
    After resolving files:
    ```bash
@@ -170,14 +164,4 @@ For each in-scope named branch:
 - Delete merged source branches and their detached worktrees only after the merge commit and verification both succeed.
 - When active batch specs provide merge-order guidance for in-scope named branches, follow that order unless new evidence proves the plan is stale or inapplicable; if so, stop and report the mismatch instead of silently overriding the batch plan.
 
-## Conflict Resolution Examples
-
-| Scenario | Resolution Strategy |
-|----------|---------------------|
-| Same line, both branches changed behavior | Read both code paths and compose the merged logic that preserves the verified invariant |
-| Same line, one branch is a bug fix and the other is a refactor | Keep the bug fix and reapply the compatible refactor structure manually if needed |
-| File deleted in branch, modified in current branch | Keep the version supported by current references/tests and remove only if the deletion is proven correct |
-| Both added same function differently | Keep both; rename if needed |
-| Config file conflict | Keep both values if non-overlapping |
-| Test file conflict | Keep both test cases |
-| package.json dependency conflict | Keep higher version if compatible |
+Resolve conflicts using $merge-conflict-resolver.