@laitszkin/apollo-toolkit 2.14.17 → 2.14.19

package/CHANGELOG.md

@@ -7,6 +7,17 @@ All notable changes to this repository are documented in this file.
 ### Changed
 - None yet.
 
+## [v2.14.19] - 2026-04-14
+
+### Changed
+- Update `version-release` so same-version prerelease hotfixes retarget the existing prerelease tag and GitHub release instead of forcing an extra semver bump.
+
+## [v2.14.18] - 2026-04-13
+
+### Changed
+- Update `review-codebases` so issue-publishing runs must search for overlapping open or recent issues first and skip publishing duplicates when the root cause already has a tracker.
+- Tighten `implement-specs-with-worktree` so archived or already-landed spec requests must verify whether the work is already present before creating a fresh worktree, and report a no-op with evidence when appropriate.
+
 ## [v2.14.17] - 2026-04-12
 
 ### Changed

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

@@ -23,8 +23,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, 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, 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, follow the implementation standards from the dependent skills, and commit to a local branch when done.
+- 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, follow the implementation standards from the dependent skills, and commit to a local branch when done.
 - Quality: Complete all planned tasks, run relevant tests, backfill the spec documents with actual completion status, and avoid dragging unrelated sibling specs into the worktree just because they share a batch directory.
 - Output: Keep the worktree branch clean with only the intended implementation commits.
 
@@ -63,10 +63,14 @@ Implement approved spec planning sets in an isolated git worktree, ensuring the
   - if the current checkout already comes from a branch, reuse that branch as the base
   - if the current session is inside a detached worktree, identify the parent branch that owns that worktree before creating another branch from it
   - do not default to `main` unless `main` is actually the parent branch of the worktree you are extending
+- Before creating a new worktree, inspect the parent branch and current main working tree for evidence that the requested spec is already implemented:
+  - 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
 
 ### 3) Create a new worktree if needed
 
-If not already in a worktree, or if the user explicitly requests a fresh worktree:
+If not already in a worktree, or if the user explicitly requests a fresh worktree, and the spec is not already implemented:
 
 - Derive the canonical spec name from the requested `change_name` directory.
 - Use that spec name as the shared branch/worktree identifier:
@@ -132,6 +136,7 @@ After implementation and testing:
 ## Working Rules
 
 - Always work in an isolated worktree to keep the parent checkout clean.
+- 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.

package/package.json

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

package/review-codebases/SKILL.md

@@ -8,7 +8,7 @@ description: Repository-wide code review workflow that requires reading the full
 ## Dependencies
 
 - Required: none.
-- Conditional: `open-github-issue` when confirmed findings should be tracked as GitHub issues.
+- Conditional: `read-github-issue` when issue publication requires duplicate checks; `open-github-issue` when confirmed findings should be tracked as GitHub issues.
 - Optional: none.
 - Fallback: If publication is needed and `open-github-issue` is unavailable, return draft issue bodies instead of inventing another publisher.
 
@@ -58,7 +58,11 @@ Only continue to the next level when the current level has no confirmed findings
 5. Review edge cases last
    - Run this step only when there are no architecture or code-quality findings.
    - Check null or empty inputs, boundary values, partial failures, retries, concurrency, ordering assumptions, idempotency, and invalid state transitions.
-6. Publish each confirmed finding
+6. Check for duplicate issues before publication
+   - When findings will be published, use `read-github-issue` to search the target repository for open and recently closed issues that match the same module, failure mode, or architectural boundary.
+   - Treat an existing issue as a duplicate when the underlying root cause, affected boundary, and requested outcome materially overlap, even if the wording differs.
+   - If a duplicate exists, cite it in the final report and do not publish a new issue for that finding.
+7. Publish each confirmed non-duplicate finding
    - Invoke `open-github-issue` once per finding.
    - Use a tier-specific title prefix:
      - `[Architecture] <short finding>`
@@ -99,6 +103,7 @@ Use this structure in responses:
    - impact
    - confidence
 4. GitHub issue publication status
+   - duplicate-check status and any matching existing issue URLs
    - publication mode (`gh-cli` / `github-token` / `draft-only`)
    - created issue URL or draft output per finding
 5. Deferred follow-up

package/version-release/SKILL.md

@@ -15,7 +15,7 @@ description: "Guide the agent to prepare and publish a versioned release (versio
 ## Standards
 
 - Evidence: Inspect the active change set, current version files, existing tag format, existing remote tags/releases, and root `CHANGELOG.md` `Unreleased` content before touching version files, tags, or release metadata.
-- Execution: Use this workflow only for explicit release intent, run the required quality gates when applicable, and treat every conditional gate whose scenario is met as blocking before versioning or publication; hand the repository to `submission-readiness-check` before versioning work, invoke `archive-specs` directly whenever completed plan sets should be converted or project docs need alignment, and if the worktree is already clean inspect the current version, local/remote tag state, and existing GitHub release state before deciding whether the request is already satisfied; then cut the release directly from `CHANGELOG.md` `Unreleased`, update versions and docs, commit, tag, push, and publish the GitHub release with actual release tooling rather than PR-surrogate directives; run git mutations sequentially and verify both the branch tip and release tag exist remotely before publishing the GitHub release.
+- Execution: Use this workflow only for explicit release intent, run the required quality gates when applicable, and treat every conditional gate whose scenario is met as blocking before versioning or publication; hand the repository to `submission-readiness-check` before versioning work, invoke `archive-specs` directly whenever completed plan sets should be converted or project docs need alignment, and if the worktree is already clean inspect the current version, local/remote tag state, and existing GitHub release state before deciding whether the request is already satisfied; when the user explicitly wants the same prerelease version to point at newer fixes, retarget the existing prerelease tag and GitHub release instead of inventing an extra version bump; otherwise cut the release directly from `CHANGELOG.md` `Unreleased`, update versions and docs, commit, tag, push, and publish the GitHub release with actual release tooling rather than PR-surrogate directives; run git mutations sequentially and verify both the branch tip and release tag exist remotely before publishing the GitHub release.
 - 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.
 
@@ -69,11 +69,13 @@ Load only when needed:
    - 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.
+   - 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.
@@ -87,15 +89,18 @@ Load only when needed:
    - Update `AGENTS.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.
-   - Create the version tag locally after commit.
+   - 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
    - 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.
+   - 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.
    - 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.