@laitszkin/apollo-toolkit 3.6.5 → 3.8.0

package/version-release/SKILL.md

@@ -7,7 +7,7 @@ description: "Guide the agent to prepare and publish a versioned release (versio
 
 ## Dependencies
 
-- Required: `submission-readiness-check` before version metadata edits, tagging, or release publication.
+- Required: `commit-and-push`, `submission-readiness-check` before version metadata edits, tagging, or release publication.
 - Conditional: `archive-specs` when completed plan sets should be converted or repository docs need alignment; `review-change-set` is required for code-affecting releases before metadata edits and the final commit; `discover-edge-cases` and `harden-app-security` are important review gates that remain conditional, but become required whenever the reviewed scope or risk profile warrants them.
 - Optional: none.
 - Fallback: If a required release dependency is unavailable, stop and report the missing dependency.
@@ -19,16 +19,6 @@ description: "Guide the agent to prepare and publish a versioned release (versio
 - Quality: Never guess versions, align user-facing docs with actual code, do not bypass readiness blockers from `submission-readiness-check`, do not reconstruct release notes from `git diff` when curated changelog content already exists, and do not report release success until the commit, tag, and GitHub release all exist for the same version.
 - Output: Produce a versioned release commit and tag, publish a matching GitHub release, and keep changelog plus relevant repository documentation synchronized.
 
-## Overview
-
-Run a standardized release workflow for versioned delivery:
-
-- resolve release scope
-- align project code and standardized categorized project documentation
-- bump version files
-- cut the release from `CHANGELOG.md` `Unreleased` and update relevant docs
-- commit, tag, push, and publish the GitHub release
-
 ## References
 
 Load only when needed:
@@ -41,76 +31,91 @@ Load only when needed:
 
 ## Workflow
 
-1. Inspect current changes
-   - Run `git status -sb`, `git diff --stat`, and `git diff --cached --stat`.
-   - Check staged files with `git diff --cached --name-only`.
-   - Inventory repository planning artifacts and project docs, not only staged files, to detect repo specs and non-standard documentation layouts.
-2. Confirm release intent
-   - Use this skill only when the user explicitly requests version/tag/release work.
-   - Treat explicit semver-delivery wording such as `patch update`, `minor update`, `major update`, `patch release`, `bump the version`, or requests to trigger release-published automation as release intent even when the user does not separately say `make a release`.
-   - If no release intent is present, use `commit-and-push` instead.
-3. Classify changes and run dependencies when required
-   - `code-affecting`: runtime code, tests, build scripts, CI logic, or behavior-changing config.
-   - `docs-only`: documentation/content updates only.
-   - `repo-specs-present`: the repository contains live project planning artifacts such as `spec.md`, `tasks.md`, `checklist.md`, or plan directories; exclude reference examples, templates, and archived samples.
-   - `repo-specs-ready-for-conversion`: the relevant `spec.md`, `tasks.md`, and `checklist.md` reflect the actual delivered outcome, and any unchecked task/decision checkbox that is clearly not selected, replaced, deferred, or `N/A` (for example, E2E intentionally not created) does not by itself mean the spec set is unfinished.
-   - `project-doc-structure-mismatch`: existing `README.md` and project docs do not match the categorized structure required by `archive-specs`.
-   - For code-affecting changes, run `review-change-set` for the same release scope before continuing; treat unresolved review findings as blocking.
-   - Run `discover-edge-cases` and `harden-app-security` for the same release scope when the reviewed risk profile or repository context says their coverage is needed; treat them as blocking review gates, not optional polish, whenever that condition is met.
-   - Any conditional gate whose trigger is confirmed by this classification becomes mandatory before version bumping, tagging, or release publication, including review, spec archival, docs synchronization, and changelog readiness.
-   - Consolidate all confirmed findings before continuing.
-   - Resolve all confirmed findings before changing version files, tags, or release metadata.
-4. Run shared submission readiness
-   - Execute `$submission-readiness-check` before version file edits, tags, or release publication.
-   - Let it decide whether completed plan sets should be converted, whether project docs need alignment through `archive-specs`, and whether `CHANGELOG.md` `Unreleased` is ready to be cut into a versioned release entry.
-   - Do not continue while `submission-readiness-check` reports unresolved blockers.
-   - When readiness indicates completed-spec conversion or project-doc drift, run `archive-specs` before version edits instead of reproducing documentation alignment inside the release workflow.
-5. Decide version and tag format
-   - Read existing version files (for example `project.toml`, `package.json`, or repo-specific version files).
-   - Infer existing tag format (`vX.Y.Z` or `X.Y.Z`) from repository tags.
-   - Inspect existing local and remote tags plus any existing GitHub Release for the target version before creating new release metadata, so duplicate or conflicting releases are caught early.
-   - Determine release channel explicitly before publishing: if the user did not say `prerelease`, `draft`, `latest`, or an equivalent repository-specific release state, default to asking or to the repository's already-documented convention instead of inferring from the tag text.
-   - If the user explicitly asks to keep the same prerelease version or to `repoint`, `retarget`, or `move` an existing prerelease after follow-up fixes, treat that as a retarget flow: keep the version unchanged, confirm the existing prerelease tag/release name, and plan to move that tag/release to the new commit instead of bumping semver.
-   - If the requested version tag and matching published GitHub release already exist and point at the intended commit, report that the release is already complete instead of creating duplicate metadata.
-   - If the user provides the target version, use it directly.
-   - If it is missing, ask the user for the target version or semver bump type.
-   - Provide recommendations only when explicitly requested.
-   - Do not continue until you can state the current version, the intended next version, and the exact tag name that will be created.
-   - For retarget flows, explicitly state that the intended next version stays unchanged and that the existing tag name will be moved to the new commit.
-6. Update version files
-   - Update every detected version file consistently.
-   - Preserve file formatting; change only version values.
-7. Update release docs
-   - Treat root `CHANGELOG.md` `Unreleased` as the canonical pending release content.
-   - If `Unreleased` is empty, stop and report that there are no curated release notes to publish yet.
-   - Create the new version entry by moving the current `Unreleased` sections under the selected version heading and release date.
-   - Reset `Unreleased` to an empty placeholder after the version entry is created.
-   - Remove duplicate section headers or bullets only when the move would otherwise create repeated content.
-   - Update `README.md` only when behavior or usage changed.
-   - Update `AGENTS.md/CLAUDE.md` only when agent workflow/rules changed.
-8. Commit and tag
-   - Create a release-oriented commit message (for example `chore(release): publish 2.12.1`) when applicable.
-   - For new-version flows, create the version tag locally after commit.
-   - For prerelease retarget flows, move the existing tag locally only after the new fix commit exists, and verify the target commit hash before rewriting the tag.
-   - Re-read the version files after editing and before tagging to confirm they all match the intended release version.
-   - Use actual git mutations for staging, commit creation, and tag creation; do not substitute UI git directives for these steps.
-9. Push
-   - Push commit(s) and the release tag to the current branch before publishing the GitHub release when the hosting platform requires the tag to exist remotely.
-   - For prerelease retarget flows, push the rewritten tag explicitly (for example `--force-with-lease` for the single tag only), then verify the remote tag hash matches local `HEAD` before touching the GitHub release.
-   - Do not overlap `git commit`, `git tag`, `git push`, or release-publish steps; wait for each mutation to finish before starting the next one.
-   - After pushing, verify the remote branch tip matches local `HEAD`, and verify the release tag exists remotely via `git ls-remote --tags <remote> <tag>`.
-   - If any git step finishes ambiguously or the remote hashes do not match local state, rerun the missing step sequentially and re-check before publishing the GitHub release.
-10. Publish the GitHub release
-   - Create a non-draft GitHub release that matches the pushed version tag.
-   - Set the GitHub release's prerelease flag only when the user explicitly asked for a prerelease or an already-verified repository convention for this exact release channel requires it.
-   - For prerelease retarget flows, update the existing GitHub prerelease so it points at the rewritten tag/commit and refresh its notes when the new fix changes the shipped behavior.
-   - If the release tool rejects a raw commit SHA while updating `target_commitish`, retry with the authoritative branch name or another GitHub-accepted target identifier, then verify the published release now resolves to the rewritten tag.
-   - Use the release notes from the new `CHANGELOG.md` entry unless the repository has a stronger established release-note source.
-   - If the repository has publish automation triggered by `release.published`, ensure the GitHub release is actually published rather than left as a draft.
-   - Prefer `gh release create <tag>` or the repository's existing release tool when available.
-   - Do not use PR-opening tools, PR directives, or placeholder URLs as a substitute for actual release publication.
-   - Confirm the GitHub release URL and any triggered publish workflow status in the final report.
-   - Never stop after the release commit or tag alone; creating the matching GitHub release is part of done criteria unless the user explicitly says to skip release publication.
+### 1. Inspect Current Changes
+
+Use $commit-and-push for the standard git state inspection workflow.
+
+### 2. Confirm Release Intent
+
+- Use this skill only when the user explicitly requests version/tag/release work.
+- Treat explicit semver-delivery wording such as `patch update`, `minor update`, `major update`, `patch release`, `bump the version`, or requests to trigger release-published automation as release intent even when the user does not separately say `make a release`.
+- If no release intent is present, use `commit-and-push` instead.
+
+### 3. Classify Changes and Run Dependencies
+
+Use $commit-and-push for the standard change classification and code-affecting dependency skills workflow.
+
+Release-specific requirements:
+- For code-affecting changes, run `review-change-set` for the same release scope before continuing; treat unresolved review findings as blocking.
+- Run `discover-edge-cases` and `harden-app-security` for the same release scope when the reviewed risk profile or repository context says their coverage is needed; treat them as blocking review gates, not optional polish, whenever that condition is met.
+- Any conditional gate whose trigger is confirmed by this classification becomes mandatory before version bumping, tagging, or release publication, including review, spec archival, docs synchronization, and changelog readiness.
+- Consolidate all confirmed findings before continuing.
+- Resolve all confirmed findings before changing version files, tags, or release metadata.
+
+### 4. Run Shared Submission Readiness
+
+Use $commit-and-push for the standard submission readiness workflow.
+
+### 5. Decide Version and Tag Format
+
+- Read existing version files (for example `project.toml`, `package.json`, or repo-specific version files).
+- Infer existing tag format (`vX.Y.Z` or `X.Y.Z`) from repository tags.
+- Inspect existing local and remote tags plus any existing GitHub Release for the target version before creating new release metadata, so duplicate or conflicting releases are caught early.
+- Determine release channel explicitly before publishing: if the user did not say `prerelease`, `draft`, `latest`, or an equivalent repository-specific release state, default to asking or to the repository's already-documented convention instead of inferring from the tag text.
+- If the user explicitly asks to keep the same prerelease version or to `repoint`, `retarget`, or `move` an existing prerelease after follow-up fixes, treat that as a retarget flow: keep the version unchanged, confirm the existing prerelease tag/release name, and plan to move that tag/release to the new commit instead of bumping semver.
+- If the requested version tag and matching published GitHub release already exist and point at the intended commit, report that the release is already complete instead of creating duplicate metadata.
+- If the user provides the target version, use it directly.
+- If it is missing, ask the user for the target version or semver bump type.
+- Provide recommendations only when explicitly requested.
+- Do not continue until you can state the current version, the intended next version, and the exact tag name that will be created.
+- For retarget flows, explicitly state that the intended next version stays unchanged and that the existing tag name will be moved to the new commit.
+
+### 6. Update Version Files
+
+- Update every detected version file consistently.
+- Preserve file formatting; change only version values.
+
+### 7. Update Release Docs
+
+- Treat root `CHANGELOG.md` `Unreleased` as the canonical pending release content.
+- If `Unreleased` is empty, stop and report that there are no curated release notes to publish yet.
+- Create the new version entry by moving the current `Unreleased` sections under the selected version heading and release date.
+- Reset `Unreleased` to an empty placeholder after the version entry is created.
+- Remove duplicate section headers or bullets only when the move would otherwise create repeated content.
+- Update `README.md` only when behavior or usage changed.
+- Update `AGENTS.md/CLAUDE.md` only when agent workflow/rules changed.
+
+### 8. Commit and Tag
+
+Use $commit-and-push for the standard commit mechanics workflow.
+
+Release-specific commit and tag operations:
+- Create a release-oriented commit message (for example `chore(release): publish 2.12.1`) when applicable.
+- For new-version flows, create the version tag locally after commit.
+- For prerelease retarget flows, move the existing tag locally only after the new fix commit exists, and verify the target commit hash before rewriting the tag.
+- Re-read the version files after editing and before tagging to confirm they all match the intended release version.
+
+### 9. Push
+
+Use $commit-and-push for the standard push mechanics workflow.
+
+Release-specific push operations:
+- Push commit(s) and the release tag to the current branch before publishing the GitHub release when the hosting platform requires the tag to exist remotely.
+- For prerelease retarget flows, push the rewritten tag explicitly (for example `--force-with-lease` for the single tag only), then verify the remote tag hash matches local `HEAD` before touching the GitHub release.
+- After pushing, verify the release tag exists remotely via `git ls-remote --tags <remote> <tag>`.
+
+### 10. Publish the GitHub Release
+
+- Create a non-draft GitHub release that matches the pushed version tag.
+- Set the GitHub release's prerelease flag only when the user explicitly asked for a prerelease or an already-verified repository convention for this exact release channel requires it.
+- For prerelease retarget flows, update the existing GitHub prerelease so it points at the rewritten tag/commit and refresh its notes when the new fix changes the shipped behavior.
+- If the release tool rejects a raw commit SHA while updating `target_commitish`, retry with the authoritative branch name or another GitHub-accepted target identifier, then verify the published release now resolves to the rewritten tag.
+- Use the release notes from the new `CHANGELOG.md` entry unless the repository has a stronger established release-note source.
+- If the repository has publish automation triggered by `release.published`, ensure the GitHub release is actually published rather than left as a draft.
+- Prefer `gh release create <tag>` or the repository's existing release tool when available.
+- Do not use PR-opening tools, PR directives, or placeholder URLs as a substitute for actual release publication.
+- Confirm the GitHub release URL and any triggered publish workflow status in the final report.
+- Never stop after the release commit or tag alone; creating the matching GitHub release is part of done criteria unless the user explicitly says to skip release publication.
 
 ## Notes
 

package/weekly-financial-event-report/SKILL.md

@@ -7,7 +7,7 @@ description: Read a user-specified PDF that marks the week's key financial event
 
 ## Dependencies
 
-- Required: `pdf` to render the final report.
+- Required: `pdf` to render the final report, `cjk-pdf` for CJK font and PDF QA needs.
 - Conditional: `document-vision-reader` when the source PDF's highlighted markers are visible in layout but not recoverable from machine-readable text alone.
 - Optional: none.
 - Fallback: If source-PDF extraction through `pdf` is unavailable or fails on macOS, use the bundled `apltk extract-pdf-text-pdfkit` helper before giving up; only stop when neither `pdf` nor the local PDFKit fallback can recover the marked events, or when final PDF rendering itself cannot be completed.
@@ -19,10 +19,6 @@ description: Read a user-specified PDF that marks the week's key financial event
 - Quality: Keep the report concise, Chinese-compatible, explicit about source-versus-breaking events, conflicts, uncertainty, PDF font safety, and long-text table legibility.
 - Output: Save only the final standardized PDF under the month folder using the financial-event-report naming scheme.
 
-## Overview
-
-Turn a marked weekly finance PDF into a short, evidence-based report that a user can read in a few minutes. The workflow starts from the user's source PDF, extracts the explicitly marked key events, validates each event with current reporting and primary sources, adds any material breaking financial developments, and delivers the final briefing as a Chinese-compatible PDF.
-
 ## Behavior Contract
 
 GIVEN the user provides a PDF that marks weekly key financial events  
@@ -147,20 +143,7 @@ apltk extract-pdf-text-pdfkit /absolute/path/to/source.pdf
 - The final PDF must support Chinese text cleanly.
 - Pass the font and rendering requirements to the `pdf` skill instead of implementing a separate export path here.
 - On macOS, require the `pdf` skill to verify the font path before rendering.
-- When the PDF workflow allows explicit font selection, ask the `pdf` skill to prefer a locally verified CJK font in this order:
-  - `/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 assume `PingFang` is available on every macOS host.
-- If the active `pdf` workflow already has a verified Chinese-safe default on the current machine, reuse that verified default instead of overriding it.
-- Avoid emoji and uncommon glyphs that often break during rendering.
-- When the report includes tables, timelines, or matrix-style summaries with long phrases:
-  - require wrapped paragraph cells rather than single-line text rendering
-  - require width-constrained columns and row heights that expand with content
-  - require padding and font sizes that keep dense Chinese text readable
-  - prefer a deterministic renderer script when the default markdown-to-PDF path cannot guarantee those layout rules
+Use $cjk-pdf for CJK font selection, content safety, visual QA, and temporary file cleanup. For tables with long phrases, require wrapped paragraph cells and width-constrained columns that expand with content.
 
 ### 7) Delegate rendering and PDF QA to the `pdf` skill