@laitszkin/apollo-toolkit 3.6.4 → 3.7.0

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.

package/merge-conflict-resolver/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: merge-conflict-resolver
+description: Resolve git merge conflicts using deterministic rules that preserve correct functionality. Use when branch consolidation encounters merge conflicts and needs automated resolution guidance that reads both parent versions and applies scenario-specific strategies.
+---
+
+# Merge Conflict Resolver
+
+## Dependencies
+
+- Required: none.
+- Conditional: none.
+- Optional: none.
+- Fallback: not applicable.
+
+## Standards
+
+- Evidence: Read both parent versions from conflict markers before resolving.
+- Execution: Read conflicts → apply scenario rules → verify with tests → recommit.
+- Quality: Prefer preserving functionality over keeping either branch's exact changes.
+- Output: Return resolved files with passing verification.
+
+## Workflow
+
+### 1) Read conflict markers
+
+- Read both parent versions from conflict markers before editing.
+- Never use `-X ours`/`-X theirs` as the default strategy; only for narrowly justified conflicts after reading the actual content.
+
+### 2) Apply scenario rules
+
+| Scenario | Resolution |
+|----------|-----------|
+| Same line, both branches changed behavior | Read both code paths and compose merged logic preserving the verified invariant |
+| Same line, bug fix vs refactor | Keep the bug fix, reapply compatible refactor structure |
+| File deleted in one, modified in other | Keep version supported by current references/tests; delete only if proven correct |
+| Both modified same file differently | Preserve both when compatible; manually compose overlapping changes |
+| Test files conflict | Preserve both coverages unless one assertion is obsolete |
+| Config file (non-overlapping keys) | Keep both values |
+| package.json dependency | Keep higher version if compatible |
+| Same function added differently | Keep both; rename if needed |
+
+### 3) Verify after resolution
+
+- `git add <resolved-files>`
+- Run targeted tests or build checks for changed files.
+- If verification fails, resolve differently before committing.

package/open-github-issue/SKILL.md

@@ -21,14 +21,7 @@ description: Publish structured GitHub issues across multiple issue categories w
 
 ## Overview
 
-Use this skill to publish structured GitHub issues deterministically across several common issue situations.
-
-It is designed to be reusable by other skills that already know the issue title and evidence, but need a consistent way to:
-
-- resolve the target repository,
-- localize the issue body,
-- publish with the preferred auth path,
-- and fall back to draft-only output without blocking the main workflow.
+Designed to be reusable by other skills that know the issue title and evidence but need a consistent publish path.
 
 ## Core principles
 
@@ -48,41 +41,7 @@ It is designed to be reusable by other skills that already know the issue title
    - Otherwise resolve from current git `origin`.
 2. Normalize issue content
    - Require one title and an explicit `issue-type`.
-   - For `problem` issues, require these structured sections:
-     - `problem-description`
-     - `suspected-cause`
-     - `reproduction` (optional)
-   - Within `problem-description`, require a precise behavior diff:
-     - `Expected Behavior (BDD)`: `Given / When / Then` for what the program should do.
-     - `Current Behavior (BDD)`: `Given / When / Then` for what the program does now.
-     - `Behavior Gap`: a short explicit comparison of the observable difference and impact.
-     - Include the symptom, impact, and key evidence alongside the behavior diff; do not leave the mismatch implicit.
-   - For `feature` issues, require these structured sections:
-     - `proposal` (optional; defaults to title when omitted)
-     - `reason`
-     - `suggested-architecture`
-   - For `performance` issues, require:
-     - `problem-description`
-     - `impact`
-     - `evidence`
-     - `suggested-action`
-   - For `security` issues, require:
-     - `problem-description`
-     - `severity`
-     - `affected-scope`
-     - `impact`
-     - `evidence`
-     - `suggested-action`
-   - For `docs` issues, require:
-     - `problem-description`
-     - `evidence`
-     - `suggested-action`
-   - For `observability` issues, require:
-     - `problem-description`
-     - `impact`
-     - `evidence`
-     - `suggested-action`
-   - If reproduction is missing for a `problem` issue, insert the default non-reproducible note in the target issue language.
+   - See `references/issue-schemas.md` for the required fields per issue type.
 3. Detect issue language
    - Read the target repository README from GitHub.
    - If the README is Chinese, publish Chinese section titles; otherwise publish English section titles.

package/open-github-issue/references/issue-schemas.md

@@ -0,0 +1,54 @@
+# Issue Type Schemas
+
+## Problem
+
+Required sections:
+- `problem-description`
+  - `Expected Behavior (BDD)`: `Given / When / Then` for what the program should do.
+  - `Current Behavior (BDD)`: `Given / When / Then` for what the program does now.
+  - `Behavior Gap`: a short explicit comparison of the observable difference and impact.
+  - Include the symptom, impact, and key evidence alongside the behavior diff; do not leave the mismatch implicit.
+- `suspected-cause`
+- `reproduction` (optional)
+
+If reproduction is missing, insert the default non-reproducible note in the target issue language.
+
+## Feature
+
+Required sections:
+- `proposal` (optional; defaults to title when omitted)
+- `reason`
+- `suggested-architecture`
+
+## Performance
+
+Required sections:
+- `problem-description`
+- `impact`
+- `evidence`
+- `suggested-action`
+
+## Security
+
+Required sections:
+- `problem-description`
+- `severity`
+- `affected-scope`
+- `impact`
+- `evidence`
+- `suggested-action`
+
+## Docs
+
+Required sections:
+- `problem-description`
+- `evidence`
+- `suggested-action`
+
+## Observability
+
+Required sections:
+- `problem-description`
+- `impact`
+- `evidence`
+- `suggested-action`

package/open-source-pr-workflow/SKILL.md

@@ -19,10 +19,6 @@ description: PR-focused workflow for open-source repositories. Use when the user
 - Quality: Target the upstream parent repository by default for forks, keep PR content in English unless requested otherwise, and exclude internal workflow details.
 - Output: Produce a review-ready PR body with motivation, engineering rationale, test commands, and any required issue linkage.
 
-## Overview
-
-Use this workflow to prepare open-source contributions and open review-ready pull requests with consistent branch naming and PR content quality.
-
 ## Scope Guardrails
 
 - This skill is for PR preparation and PR creation only.

package/openai-text-to-image-storyboard/SKILL.md

@@ -5,13 +5,6 @@ description: Generate storyboard images by using agent-decided prompts and calli
 
 # OpenAI Text to Image Storyboard
 
-## Dependencies
-
-- Required: none.
-- Conditional: none.
-- Optional: none.
-- Fallback: not applicable.
-
 ## Standards
 
 - Evidence: Generate prompts from the supplied content and require only the minimal mandatory inputs such as project path and content name.
@@ -19,11 +12,6 @@ description: Generate storyboard images by using agent-decided prompts and calli
 - Quality: Keep prompts and outputs in narrative order, use only `/images/generations`, and leave role-schema management to the video orchestration skills.
 - Output: Write images plus `storyboard.json` under `pictures/<content_name>/` without overwriting existing filenames.
 
-## Overview
-
-Let the agent decide which images are needed from the text, then call only `/images/generations` to render them.
-Always save outputs in `pictures/<content_name>/` (example: `pictures/1_chapter_title/`).
-
 ## Workflow
 
 1. Read user text and decide the target scenes in the agent.

package/package.json

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

package/read-github-issue/SKILL.md

@@ -19,10 +19,6 @@ description: Read and search remote GitHub issues via GitHub CLI (`gh`). Use whe
 - Quality: Keep the skill focused on issue discovery and retrieval only; do not embed any hardcoded fixing, branching, PR, or push workflow.
 - Output: Return candidate issues, selected issue details, comments summary, and any missing information needed before follow-up work.
 
-## Overview
-
-Use this skill to gather trustworthy GitHub issue context with `gh`: discover open or closed issues, narrow them with labels or search text, then inspect a chosen issue in detail before any separate planning or implementation workflow begins.
-
 ## Prerequisites
 
 - `gh` is installed and authenticated (`gh auth status`).

package/record-spending/SKILL.md

@@ -19,10 +19,6 @@ description: Maintain monthly multi-account bookkeeping ledgers in Excel. Use wh
 - Quality: Preserve existing naming, formulas, and reconciliation behavior, and record new chart rules or account metadata changes immediately.
 - Output: Report the updated workbook path, changed worksheets, account-registry changes, and chart-rule changes.
 
-## Overview
-
-Track user-named accounts through monthly Excel workbooks and keep the account registry plus chart rules consistent over time. Treat `ACCOUNT.md` as the source of truth for account identity and `CHART.md` as the source of truth for recurring chart and quantified-analysis rules.
-
 ## References
 
 Load these only when needed:

package/recover-missing-plan/SKILL.md

@@ -21,12 +21,7 @@ description: Recover a missing or mismatched `docs/plans/...` plan set by verify
 
 ## Overview
 
-Use this skill when the user points to `docs/plans/{date}/{change}/...` or `docs/plans/{date}/{batch}/{change}/...` but the directory is missing, only `docs/plans/README.md` exists, the matching files were already archived, or the workspace is detached / incomplete and the plan evidence must be recovered before coding or archiving can proceed.
-
-Typical triggers:
-- The user references a specific `docs/plans/...` directory that is absent from the current worktree.
-- A feature workflow expects approved spec files, but the plan was archived, never checked out, or exists only in another branch/worktree.
-- An implementation task must continue from GitHub issue context because the original planning artifacts are missing.
+Recover a missing, archived, or mismatched plan set when the user references a `docs/plans/...` directory that does not exist in the current worktree.
 
 ## Workflow
 

package/resolve-review-comments/SKILL.md

@@ -5,13 +5,6 @@ description: Read GitHub pull request review comments, analyze each thread, deci
 
 # Resolve Review Comments
 
-## Dependencies
-
-- Required: none.
-- Conditional: none.
-- Optional: none.
-- Fallback: not applicable.
-
 ## Standards
 
 - Evidence: Read unresolved review threads first and decide adopt versus reject from the actual review content and code context.
@@ -19,10 +12,6 @@ description: Read GitHub pull request review comments, analyze each thread, deci
 - Quality: Keep changes minimal, leave rejected or unclear threads unresolved, and reply with concise technical reasons when feedback is not adopted.
 - Output: Complete the PR feedback loop with updated code, pushed commits, and correctly resolved review threads.
 
-## Overview
-
-Use this skill to run an end-to-end GitHub PR review loop: collect review threads, decide adopt/reject per comment, apply accepted feedback, push commits to the same PR branch, and resolve only addressed threads.
-
 ## Prerequisites
 
 - Ensure `gh` is installed and authenticated (`gh auth status`).

package/review-change-set/SKILL.md

@@ -19,10 +19,6 @@ description: Review the current git change set from an unbiased reviewer perspec
 - Quality: Judge the change set as an outsider, keep only actionable findings, and avoid inventing concerns the security pass did not confirm.
 - Output: Return review scope, architecture findings, simplification findings, security cross-check results, and residual uncertainty.
 
-## Overview
-
-Use this skill to review the active git change set as an outsider, not as the original author. The goal is to find actionable abstraction and simplification opportunities with evidence, not to defend the current implementation.
-
 ## Non-negotiable Review Rules
 
 - Read the full active change set before judging any design choice.

package/review-codebases/SKILL.md

@@ -19,18 +19,6 @@ description: Repository-wide code review workflow that requires reading the full
 - Quality: Prefer root-cause findings over scattered symptoms, merge duplicates, and keep hypotheses out of published results.
 - Output: Return coverage, review tier reached, confirmed findings, publication status, and deferred lower-tier follow-up.
 
-## Overview
-
-Use this skill to review an entire repository before making judgments.
-
-The review order is strict:
-
-1. Architecture and system design
-2. Code quality and maintainability
-3. Edge cases and robustness gaps
-
-Only continue to the next level when the current level has no confirmed findings.
-
 ## Core rules
 
 - Read the full repository before judging any design or implementation choice.

package/scheduled-runtime-health-check/SKILL.md

@@ -123,26 +123,7 @@ This skill is an orchestration layer. It owns the background terminal session, o
 
 Absence of errors alone is not enough for `healthy`.
 
-## Output format
-
-Use this structure in responses:
-
-1. Run summary
-   - Workspace, command, schedule if any, actual start/end timestamps, bounded execute duration, total wall-clock duration, readiness result, shutdown result if applicable, canonical run folder or artifact root, and log locations.
-2. Execution result
-   - Whether the command completed, stayed up for the requested window, or failed early.
-3. Code update result
-   - Include only when an update step was requested. Record the update command, before/after commit, or the exact blocker.
-4. Module health
-   - Include only when findings were requested or health assessment was part of the task. One entry per module with status (`healthy` / `degraded` / `failed` / `unknown`) and evidence.
-5. Confirmed issues
-   - Include only when log analysis was requested. Reuse evidence-backed findings from `analyse-app-logs`.
-6. Potential issues and validation needed
-   - Include only when log analysis was requested. Risks that appeared in the run but need more evidence.
-7. Observability gaps
-   - Include only when log analysis was requested. Missing logs, metrics, probes, or correlation IDs that blocked diagnosis.
-8. Automation or scheduler status
-   - Include only when a future window or scheduler was involved. Record task identifiers, execution status, and whether future cleanup is needed.
+Use `references/output-format.md` for the structured output template including run summary, execution result, module health, confirmed issues, and scheduler status.
 
 ## Guardrails
 

package/scheduled-runtime-health-check/references/output-format.md

@@ -0,0 +1,20 @@
+# Output Format
+
+Use this structure in responses:
+
+1. Run summary
+   - Workspace, command, schedule if any, actual start/end timestamps, bounded execute duration, total wall-clock duration, readiness result, shutdown result if applicable, canonical run folder or artifact root, and log locations.
+2. Execution result
+   - Whether the command completed, stayed up for the requested window, or failed early.
+3. Code update result
+   - Include only when an update step was requested. Record the update command, before/after commit, or the exact blocker.
+4. Module health
+   - Include only when findings were requested or health assessment was part of the task. One entry per module with status (`healthy` / `degraded` / `failed` / `unknown`) and evidence.
+5. Confirmed issues
+   - Include only when log analysis was requested. Reuse evidence-backed findings from `analyse-app-logs`.
+6. Potential issues and validation needed
+   - Include only when log analysis was requested. Risks that appeared in the run but need more evidence.
+7. Observability gaps
+   - Include only when log analysis was requested. Missing logs, metrics, probes, or correlation IDs that blocked diagnosis.
+8. Automation or scheduler status
+   - Include only when a future window or scheduler was involved. Record task identifiers, execution status, and whether future cleanup is needed.

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

@@ -19,10 +19,6 @@ description: Resolve a GitHub issue in an existing repository and submit the fix
 - 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
-
-Use this skill for the recurring workflow where the user wants one GitHub issue taken from remote context through implementation and direct submission. Keep the workflow tight: fetch the issue faithfully, decide whether specs are necessary from the explored codebase, finish the fix with tests, then submit without PR or release steps.
-
 ## Workflow
 
 ### 1) Read the issue from the remote source first

package/submission-readiness-check/SKILL.md

@@ -19,10 +19,6 @@ description: Prepare a repository for safe submission by synchronizing `CHANGELO
 - 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.
 
-## Overview
-
-Use this skill as the shared finalization pass before repository submission workflows. It exists to prevent repeated omissions such as forgetting `CHANGELOG.md`, shipping stale project docs, or leaving completed plan sets unarchived.
-
 ## Workflow
 
 ### 1) Inventory the real submission surface

package/systematic-debug/SKILL.md

@@ -5,13 +5,6 @@ description: "Systematic debugging workflow for program issues: understand obser
 
 # Systematic Debug
 
-## Dependencies
-
-- Required: none.
-- Conditional: none.
-- Optional: none.
-- Fallback: not applicable.
-
 ## Standards
 
 - Evidence: Gather expected versus observed behavior from code and runtime facts before deciding on a cause, and when the issue involves a runtime pipeline or bounded run, anchor the investigation to one canonical artifact root or run directory instead of mixed terminal snippets from multiple runs; if generated reports or databases drift into an older run directory, capture that mismatch explicitly before treating any artifact as evidence.

package/test-case-strategy/SKILL.md

@@ -5,13 +5,6 @@ description: Select and design risk-driven test cases for agent implementation w
 
 # Test Case Strategy
 
-## Dependencies
-
-- Required: none.
-- Conditional: none.
-- Optional: none.
-- Fallback: not applicable.
-
 ## Standards
 
 - Evidence: Base every test decision on changed behavior, requirement IDs, risk class, dependency shape, and existing coverage; do not add tests only because a template lists them.

package/text-to-short-video/SKILL.md

@@ -5,13 +5,6 @@ description: Generate 30-60 second short videos by directly calling an OpenAI-co
 
 # Text to Short Video
 
-## Dependencies
-
-- Required: none.
-- Conditional: none.
-- Optional: none.
-- Fallback: not applicable.
-
 ## Standards
 
 - Evidence: Use `roles.json` as the authoritative role source and collect only the minimal prompt, duration, and sizing inputs.
@@ -19,19 +12,6 @@ description: Generate 30-60 second short videos by directly calling an OpenAI-co
 - Quality: Keep duration in the 30-60 second range, preserve role identity fields, and do not route through storyboard or Remotion skills.
 - Output: Save the prompt package, API records, and final short-video artifacts under the project video workspace.
 
-## Overview
-
-This skill is **API-only**:
-
-1. Resolve role consistency from `roles.json`.
-2. Build one short-video prompt from text + roles.
-3. Call an OpenAI-compatible video generation API.
-4. Poll until the job is finished.
-5. Download one final MP4.
-6. Optionally run aspect-ratio/size post-processing.
-
-Do not use `openai-text-to-image-storyboard` or `remotion-best-practices` in this skill.
-
 ## Required Inputs
 
 Collect only what is required: