@laitszkin/apollo-toolkit 3.14.3 → 3.14.5

package/CHANGELOG.md

@@ -2,6 +2,18 @@
 
 All notable changes to this repository are documented in this file.
 
+## [v3.14.5] - 2026-05-16
+
+### Changed
+
+- Rename 7 skills with shorter aliases: `align-project-documents` → `docs-project`, `commit-and-push` → `commit`, `implement-specs` → `implement`, `implement-specs-with-subagents` → `implement-with-subagents`, `implement-specs-with-worktree` → `implement-with-worktree`, `review-spec-related-changes` → `qa`, `solve-issues-found-during-review` → `fix`.
+
+## [v3.14.4] - 2026-05-16
+
+### Changed
+
+- Standardize spec template task numbering (P1.x/P2.x, T1.x/T2.x) and simplify SKILL.md description format across skill docs.
+
 ## [v3.14.3] - 2026-05-15
 
 ### Changed

package/README.md

@@ -4,13 +4,13 @@ A curated skill catalog for Codex, OpenClaw, Trae, Agents, and Claude Code with
 
 ## Included skills
 
-- align-project-documents
+- docs-project
 - analyse-app-logs
 - answering-questions-with-research
 - archive-specs
 - cjk-pdf
 - codex-memory-manager
-- commit-and-push
+- commit
 - deep-research-topics
 - develop-new-features
 - docs-to-voice
@@ -20,9 +20,9 @@ A curated skill catalog for Codex, OpenClaw, Trae, Agents, and Claude Code with
 - feature-propose
 - financial-research
 - generate-spec
-- implement-specs
-- implement-specs-with-subagents
-- implement-specs-with-worktree
+- implement
+- implement-with-subagents
+- implement-with-worktree
 - improve-observability
 - init-project-html
 - jupiter-development
@@ -41,11 +41,11 @@ A curated skill catalog for Codex, OpenClaw, Trae, Agents, and Claude Code with
 - read-github-issue
 - record-spending
 - resolve-review-comments
-- review-spec-related-changes
+- qa
 - shadow-api-model-research
 - ship-github-issue-fix
 - solana-development
-- solve-issues-found-during-review
+- fix
 - systematic-debug
 - test-case-strategy
 - text-to-short-video
@@ -200,10 +200,10 @@ The install commands below were checked with the Skills CLI unless otherwise not
 Compatibility note:
 
 - `generate-spec` is a local skill used by `develop-new-features` and `enhance-existing-features`, and it can produce either a single spec set under `docs/plans/{YYYY-MM-DD}/{change_name}/` or a coordinated parallel batch under `docs/plans/{YYYY-MM-DD}/{batch_name}/{change_name}/` with shared `coordination.md`.
-- `implement-specs-with-subagents` coordinates one `implement-specs-with-worktree` subagent per spec directory for approved multi-spec batches.
+- `implement-with-subagents` coordinates one `implement-with-worktree` subagent per spec directory for approved multi-spec batches.
 
 - `read-github-issue` uses GitHub CLI (`gh`) directly for remote issue discovery and inspection, so it does not add any extra skill dependency.
-- `review-spec-related-changes` is a local skill that reviews spec compliance of changes against governing planning documents, assessing business goals before secondary code-practice concerns.
+- `qa` is a local skill that reviews spec compliance of changes against governing planning documents, assessing business goals before secondary code-practice concerns.
 - `update-project-html` is a local skill that depends on `init-project-html` for semantic rules and on the `apltk architecture` CLI to refresh the base atlas after code changes; for spec overlay diagrams use `spec-to-project-html` instead.
 
 

package/archive-specs/README.md

@@ -1,12 +1,12 @@
 # archive-specs
 
-A documentation skill that converts completed spec files and batch-level coordination files into the standardized project documentation structure and archives the consumed planning files. It delegates documentation generation to `align-project-documents` and constraint file refresh to `maintain-project-constraints`.
+A documentation skill that converts completed spec files and batch-level coordination files into the standardized project documentation structure and archives the consumed planning files. It delegates documentation generation to `docs-project` and constraint file refresh to `maintain-project-constraints`.
 
 ## Core capabilities
 
 - Scans `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, `design.md`, and batch-level `coordination.md` collections as documentation input.
 - Reconciles spec claims against code, config, scripts, and deployment files.
-- Delegates to `align-project-documents` to generate standardized docs under `docs/features/` (BDD user-facing features), `docs/architecture/` (macro-level design principles), and `docs/principles/` (code conventions and constraints).
+- Delegates to `docs-project` to generate standardized docs under `docs/features/` (BDD user-facing features), `docs/architecture/` (macro-level design principles), and `docs/principles/` (code conventions and constraints).
 - Delegates to `maintain-project-constraints` to refresh `AGENTS.md`/`CLAUDE.md` with business goals, common commands, and the project documentation index.
 - Archives superseded spec source files after a successful conversion, and deletes them only when the repository clearly does not need historical retention.
 - Preserves active batch coordination files until no remaining spec set still depends on their shared preparation or replacement direction.
@@ -41,5 +41,5 @@ A documentation skill that converts completed spec files and batch-level coordin
 ## Notes
 
 - Prefer code, config, and deployment files over stale spec text when they disagree.
-- If the repository already has docs, delegate to `align-project-documents` to rewrite them into the standardized structure.
+- If the repository already has docs, delegate to `docs-project` to rewrite them into the standardized structure.
 - Keep `README.md` short; the documentation index lives in `AGENTS.md`/`CLAUDE.md`.

package/archive-specs/SKILL.md

@@ -21,7 +21,7 @@ description: 將已完成的spec歸檔到 `docs/archive/` 下。當你需要將s
 
 ### 2. 歸檔spec並更新項目文檔
 
-使用 `align-project-documents`, `maintain-project-constraints` 技能，按照這兩個技能之中的指引，更新項目文檔。並將完成的spec全部移動到 `docs/archive/`。
+使用 `docs-project`, `maintain-project-constraints` 技能，按照這兩個技能之中的指引，更新項目文檔。並將完成的spec全部移動到 `docs/archive/`。
 
 ## 參考資料索引
 

package/archive-specs/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "archive-specs"
   short_description: "Convert completed specs into standardized project docs and archive the consumed plans"
-  default_prompt: "Use $archive-specs to inventory the project's spec.md/tasks.md/checklist.md/contract.md/design.md files plus any batch-level coordination.md, reconcile them with the current repository, use coordination.md to understand shared preparation and legacy-replacement direction across parallel plan sets, delegate documentation generation to align-project-documents which produces standardized docs under docs/features/ (BDD user-facing features), docs/architecture/ (macro-level design principles), and docs/principles/ (code conventions and constraints), then delegate AGENTS.md/CLAUDE.md refresh to maintain-project-constraints which writes business goals, common commands, and the project documentation index. Archive the consumed source plans after successful conversion, deleting them only when the repository clearly does not need historical retention and keeping coordination.md active while any spec set still depends on it."
+  default_prompt: "Use $archive-specs to inventory the project's spec.md/tasks.md/checklist.md/contract.md/design.md files plus any batch-level coordination.md, reconcile them with the current repository, use coordination.md to understand shared preparation and legacy-replacement direction across parallel plan sets, delegate documentation generation to docs-project which produces standardized docs under docs/features/ (BDD user-facing features), docs/architecture/ (macro-level design principles), and docs/principles/ (code conventions and constraints), then delegate AGENTS.md/CLAUDE.md refresh to maintain-project-constraints which writes business goals, common commands, and the project documentation index. Archive the consumed source plans after successful conversion, deleting them only when the repository clearly does not need historical retention and keeping coordination.md active while any spec set still depends on it."

package/{commit-and-push → commit}/README.md

@@ -1,16 +1,16 @@
-# commit-and-push
+# commit
 
-A Codex skill for commit-and-push workflows without release/version operations.
+A Codex skill for commit workflows without release/version operations.
 
 ## What this skill does
 
-`commit-and-push` helps agents safely submit local changes by:
+`commit` helps agents safely submit local changes by:
 
 1. Inspecting git status and staged state.
 2. Running `review-change-set` as a blocking gate whenever the change set includes code changes.
 3. Running `archive-specs` during submission to convert completed spec sets and archive them, or when existing project docs need normalization.
 4. Keeping root `CHANGELOG.md` `Unreleased` aligned with the actual pending change set, including removing stale conflicting bullets when needed.
-5. Running `align-project-documents` and `maintain-project-constraints` before commit.
+5. Running `docs-project` and `maintain-project-constraints` before commit.
 6. Running additional dependency skills for code-affecting diffs when their coverage is needed.
 7. Committing with a concise Conventional Commit message.
 8. Pushing to the current branch.

package/{commit-and-push → commit}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: commit-and-push
+name: commit
 description: 提供提交指引以及作為提交前的必要品控閘門。當你需要將變更提交到git repo或者是推送到remote，使用這個技能。
 ---
 
@@ -23,7 +23,7 @@ description: 提供提交指引以及作為提交前的必要品控閘門。當
 
 ### 3. 同步項目文檔
 
-使用 `align-project-documents`, `maintain-project-constraints` 這兩個技能，並遵照當中的指引，同步更新項目文檔，確保項目文檔時刻與repo保持一致。
+使用 `docs-project`, `maintain-project-constraints` 這兩個技能，並遵照當中的指引，同步更新項目文檔，確保項目文檔時刻與repo保持一致。
 
 ### 4. 提交及推送變更
 

package/commit/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Commit and Push"
+  short_description: "Submit local changes with commit and push only"
+  default_prompt: "Use $commit to inspect the current git state and classify the diff. Treat every conditional gate whose scenario is met as blocking before any commit: if the change set includes code changes, run $review-change-set; if completed specs should be converted or docs need normalization, ensure $archive-specs runs through $submission-readiness-check; if changelog synchronization is needed, complete it before continuing. Then run any additional required code-quality skills, hand the repository to $submission-readiness-check so it can synchronize completed plan archives, project docs, AGENTS.md/CLAUDE.md, and CHANGELOG.md before any commit, confirm root CHANGELOG.md Unreleased reflects the actual pending change set, preserve user staging intent, create a concise Conventional Commit, and push to the intended branch without any versioning or release steps."

package/develop-new-features/SKILL.md

@@ -20,10 +20,10 @@ description: 用於從零開始打造新專案。當你需要從零開始打造
 
 ### 2. 實作spec
 
-在明確獲取用戶的同意之後，使用 `implement-specs` 技能實作spec。
-如果spec是batch spec（存在多份spec），且外部環境允許使用subagents，建議使用 `implement-specs-with-subagents` 技能並行調度 subagents 實作spec。
+在明確獲取用戶的同意之後，使用 `implement` 技能實作spec。
+如果spec是batch spec（存在多份spec），且外部環境允許使用subagents，建議使用 `implement-with-subagents` 技能並行調度 subagents 實作spec。
 
 ## 使用範例
 
 - "現有repo完全不存在任何的CSV解析、讀取、會出功能。用戶要求替 dashboard 新增 CSV 匯出功能。-> "建立spec並等待用戶批准，再實作匯出流程，並用 property tests 驗證欄位順序、編碼與內容不變量"
-- "原repo不存在任何cli功能。用戶要求同時新增 CLI、後端與基礎設施的新能力" -> "拆成多份 spec，用 `coordination.md` 管理跨模組依賴，並使用 `implement-specs-with-subagents` 技能調度subagents實作spec。"
+- "原repo不存在任何cli功能。用戶要求同時新增 CLI、後端與基礎設施的新能力" -> "拆成多份 spec，用 `coordination.md` 管理跨模組依賴，並使用 `implement-with-subagents` 技能調度subagents實作spec。"

package/{align-project-documents → docs-project}/SKILL.md

@@ -1,6 +1,8 @@
 ---
-name: align-project-documents
-description: 整理及維護項目文檔。當你需要管理項目說明文檔時，使用此技能。
+name: docs-project
+description: >-
+    提供標準化的文檔格式，用於協助維護項目文檔。
+    使用場景：更新、修改、重寫項目文檔。
 ---
 
 ## 目標
@@ -25,13 +27,7 @@ description: 整理及維護項目文檔。當你需要管理項目說明文檔
 
 ### 3. 制定文檔更新策略
 
-根據上一步找到的所有遺漏或項目文檔與實際代碼脫節之處，制定文檔更新策略。將所有項目文檔更新為符合模板格式的標準化文檔，並移除除必要文檔（如 `CHANGELOG.md`, `CONTRIBUTION.md` ）外的舊有說明文檔。
-
-## 範例
-
-- "根據當前repo重建整套專案文檔。" -> "完整讀碼後重建三類標準文檔，清理舊文檔並同步刷新 `AGENTS.md` / `CLAUDE.md`。"
-- "這個倉庫的 docs 很散，請重新對齊成統一結構。" -> "把可保留內容遷入 `docs/features/`、`docs/architecture/`、`docs/principles/`，移除重複或失效文件。"
-- "我要的不是 README 小修，而是整個文檔體系重整。" -> "以全倉庫證據為基礎重建標準化文檔樹，而不是只修改單一說明文件。"
+根據上一步找到的所有遺漏或項目文檔與實際代碼脫節之處，制定文檔更新策略。使用模板之中所規範的格式，重寫項目文檔，並移除除必要文檔（如 `CHANGELOG.md`, `CONTRIBUTION.md` ）外的舊有說明文檔。
 
 ## 參考資料
 - `references/templates/standardized-docs-template.md` - 三類文檔的目標結構、分類規則與清理檢查表。

package/docs-project/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Align Project Documents"
+  short_description: "Generate standardized project docs under docs/features/, docs/architecture/, and docs/principles/ from code evidence"
+  default_prompt: "Use $docs-project to read the entire codebase first, ground every claim in code/config/test evidence, then generate standardized project documentation in three categories: features (BDD-described, user perspective), architecture (macro-level design principles by module), and principles (code style, naming conventions, development constraints). Remove old non-conforming docs and refresh AGENTS.md/CLAUDE.md via maintain-project-constraints."

package/enhance-existing-features/SKILL.md

@@ -37,4 +37,4 @@ description: >-
 - `generate-spec`：需要書面批准時的 spec 流程。
 
 - `test-case-strategy`：非平凡變更的測試選型與 oracle 設計。
-- `commit-and-push`：使用者要求提交或推送時的最終交付流程。
+- `commit`：使用者要求提交或推送時的最終交付流程。

package/{solve-issues-found-during-review → fix}/README.md

@@ -5,10 +5,10 @@ Fix issues discovered during a review pass, proceeding from the highest-severity
 ## Usage
 
 ```
-$solve-issues-found-during-review
+$fix
 ```
 
-Provide a review report (from `review-change-set`, `review-spec-related-changes`, `review-codebases`, `discover-edge-cases`, `discover-security-issues`, or any structured review) and this skill will:
+Provide a review report (from `review-change-set`, `qa`, `review-codebases`, `discover-edge-cases`, `discover-security-issues`, or any structured review) and this skill will:
 
 1. Read and prioritize all findings by severity
 2. Fix each finding from Critical down to Low

package/{solve-issues-found-during-review → fix}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: solve-issues-found-during-review
+name: fix
 description: 當你需要修復 code review report 之中發現的問題時，調用這個技能。
 ---
 

package/fix/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Solve Issues Found During Review"
+  short_description: "Fix review findings from high to low severity"
+  default_prompt: "Use $fix to process a review report or finding list, fix each confirmed issue in severity order (Critical → High → Medium → Low), validate every fix before proceeding, and re-validate the full scope when all issues are resolved."

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

@@ -3,26 +3,16 @@
 - Date: [YYYY-MM-DD]
 - Batch: [batch_name]
 
-## Preparation Goal
-
-[Describe the smallest shared prerequisite state that must exist before member specs can be implemented in parallel. This must not implement core business logic or deliver the batch target outcome.]
-
-- Why this exists: [why the batch cannot be parallelized without this prerequisite work]
-- Core business boundary: [No core business logic or target outcome is implemented here]
-- Depends on (specs): [[spec-name-1], [spec-name-2]]
-- Parallel work starts after: [commit / verification / approval of this preparation]
-- Out of scope: [member-spec implementation work that must remain in spec files]
-
 ## **Task P1: [Preparation Task Title]**
 
 Purpose: [why this prerequisite is required before parallel work]
 Scope: [files/modules this task may touch]
 Out of scope: [core business logic, target outcome, member-spec behavior]
 
-- P1. [ ] **[file/function]** — **[specific modification; expected output]**
+- P1.1 [ ] **[file/function]** — **[specific modification; expected output]**
   - Verify: [command/check/manual inspection]
 
-- P2. [ ] **[file/function]** — **[specific modification; expected output]**
+- P1.2 [ ] **[file/function]** — **[specific modification; expected output]**
   - Verify: [command/check/manual inspection]
 
 ## **Task P2: [Preparation Task Title]**
@@ -31,10 +21,10 @@ Purpose: [why this prerequisite is required before parallel work]
 Scope: [files/modules this task may touch]
 Out of scope: [core business logic, target outcome, member-spec behavior]
 
-- P1. [ ] **[file/function]** — **[specific modification; expected output]**
+- P2.1 [ ] **[file/function]** — **[specific modification; expected output]**
   - Verify: [command/check/manual inspection]
 
-- P2. [ ] **[file/function]** — **[specific modification; expected output]**
+- P2.2 [ ] **[file/function]** — **[specific modification; expected output]**
   - Verify: [command/check/manual inspection]
 
 ## Validation
@@ -42,11 +32,3 @@ Out of scope: [core business logic, target outcome, member-spec behavior]
 - Verification required: [commands/checks before subagents start]
 - Expected results: [what proves the prepared baseline is usable]
 - Regression risks covered: [risk IDs or behavior slices]
-
-## Handoff
-
-- Preparation commit required before parallel work: [Yes / No]
-- Member specs assume: [prepared baseline assumptions]
-- Member specs must not change: [prepared surfaces now frozen or additive-only]
-- Member specs own all business behavior: [Yes]
-- If preparation changes later: [stop and re-coordinate rule]

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

@@ -10,10 +10,10 @@ Requirements: [R1.x]
 Scope: [files/modules/functions this task may touch]
 Out of scope: [files/modules/behaviors this task must not change]
 
-- 1. [ ] **[file/function]** — **[specific modification to make; expected outcome]**
+- T1.1 [ ] **[file/function]** — **[specific modification to make; expected outcome]**
   - Verify: [focused command/check/manual inspection; drift check ref if applicable]
 
-- 2. [ ] **[file/function]** — **[specific modification to make; expected outcome]**
+- T1.2 [ ] **[file/function]** — **[specific modification to make; expected outcome]**
   - Verify: [focused command/check/manual inspection; drift check ref if applicable]
 
 ## **Task 2: [Task Title]**
@@ -23,22 +23,8 @@ Requirements: [R2.x]
 Scope: [files/modules/functions this task may touch]
 Out of scope: [files/modules/behaviors this task must not change]
 
-- 1. [ ] **[file/function]** — **[specific modification to make; expected outcome]**
+- T2.1 [ ] **[file/function]** — **[specific modification to make; expected outcome]**
   - Verify: [focused command/check/manual inspection; drift check ref if applicable]
 
-- 2. [ ] **[file/function]** — **[specific modification to make; expected outcome]**
+- T2.2 [ ] **[file/function]** — **[specific modification to make; expected outcome]**
   - Verify: [focused command/check/manual inspection; drift check ref if applicable]
-
-## Notes
-- **Layering:** **`design.md`** / **`contract.md`** are **guiding context** only (architecture + external truth). **`tasks.md` is the sole numbered, file-level execution queue**—do not expect design/contract to re-list its checkboxes.
-- When drafting, derive task order and scope from **`spec.md`** + **`design.md`** + **`contract.md`**; optionally cite **`INT-###` / `EXT-###`** on rows those anchors constrain.
-- Task order reflects implementation sequence.
-- Every task must map back to `spec.md` requirement IDs.
-- Treat `tasks.md` as an implementation queue, not a summary.
-- Each item must include the exact file path (or function/module), the specific change, and a concrete verification step — vague items are forbidden.
-- Each checkbox is atomic: one verb, one file/function, one change outcome, one verification hook.
-- Use `N.x [ ]` for sub-items only when a parent item needs further breakdown.
-- Split tasks that exceed 3 files or span multiple behavior slices.
-- Use `$test-case-strategy` for drift checks before implementation.
-- After execution, update `[x]` for done, `[ ]` for pending.
-- Remove all `[...]` placeholder text after filling.

package/{implement-specs → implement}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: implement-specs
+name: implement
 description: 當你需要在當前分支之中實作spec時，使用這個技能。
 ---
 

package/implement/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Implement Specs"
+  short_description: "Implement approved specs in the current checkout"
+  default_prompt: "Use $implement to resolve the user-named docs/plans path or the evidence-backed latest plan (never guess), read parent coordination.md when present, read spec.md then design.md then contract.md then checklist.md before executing every tasks.md line; when multiple member directories apply, finish one directory completely before the next per coordination.md; never create branches or git worktrees unless the user rescopes, backfill the planning docs, and finalize with $commit."

package/{implement-specs-with-subagents → implement-with-subagents}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: implement-specs-with-subagents
+name: implement-with-subagents
 description: 當有多份規格文檔需要被實作時，且環境允許使用subagents，建議使用本技能調度subagents完成任務
 ---
 
@@ -31,7 +31,7 @@ description: 當有多份規格文檔需要被實作時，且環境允許使用s
 
 ### 2. 完成前置準備工作（如有）
 
-如果實作的batch spec 有 `preparation.md`，你需要在開始實作之前需要先完成 `preparation.md` 之中所規定的任務內容，並在驗收條件滿足之後回填 `preparation.md`。使用 `commit-and-push` 技能並遵守當中的流程將前置準備工作提交，不需要推送到remote。
+如果實作的batch spec 有 `preparation.md`，你需要在開始實作之前需要先完成 `preparation.md` 之中所規定的任務內容，並在驗收條件滿足之後回填 `preparation.md`。使用 `commit` 技能並遵守當中的流程將前置準備工作提交，不需要推送到remote。
 
 ### 3. 規劃subagents調度順序
 

package/implement-with-subagents/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Implement Specs with Subagents"
+  short_description: "Coordinate parallel spec worktree implementations"
+  default_prompt: "Use $implement-with-subagents to read coordination.md and any preparation.md first, complete and commit explicitly documented prerequisite preparation on the working branch before delegation, analyse spec dependencies to build a multi-phase plan, for each phase assign each approved docs/plans spec directory to one independent subagent that uses $implement-with-worktree, after each phase use $merge-changes-from-local-branches to merge completed spec branches back into the working branch before launching the next phase, honor any requested model when supported, and track each branch, commit, test result, and blocker."

package/{implement-specs-with-worktree → implement-with-worktree}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: implement-specs-with-worktree
+name: implement-with-worktree
 description: 當你需要在獨立分支和工作樹之中實作spec時，使用這個技能。
 ---
 
@@ -48,7 +48,7 @@ description: 當你需要在獨立分支和工作樹之中實作spec時，使用
 
 ### 6. 提交變更
 
-使用 `commit-and-push` 將變更提交到子分支上。不需要將變更推送到remote。
+使用 `commit` 將變更提交到子分支上。不需要將變更推送到remote。
 
 ## 範例
 

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Implement Specs with Worktree"
+  short_description: "Implement an approved spec set inside an isolated git worktree"
+  default_prompt: "Use $implement-with-worktree to follow the same docs/plans resolution and read-order rules as $implement (spec then design then contract then checklist then tasks; one directory fully done before the next per coordination.md when multiple apply), identify the parent branch, create or reuse an isolated worktree and matching branch, verify pwd matches git rev-parse --show-toplevel before any write, keep the parent checkout read-only for deliverables, complete every tasks.md line and checklist.md wrap-up in the worktree, backfill planning docs, and finalize with $commit on the worktree branch."

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

@@ -24,4 +24,4 @@ description: 當你需要將 spec 相關的本地實作分支合併回當前所
 
 ### 3. 提交變更
 
-使用 `commit-and-push` 這個技能，將變更提交到當前分支上，不需要 push 到 remote。
+使用 `commit` 這個技能，將變更提交到當前分支上，不需要 push 到 remote。

package/merge-changes-from-local-branches/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Merge Changes from Local Branches"
   short_description: "Merge named local branches back into the current branch with checked conflict resolution"
-  default_prompt: "Use $merge-changes-from-local-branches to inventory the current branch plus the named local branches that should be merged, inspect active batch-spec `coordination.md` files under `docs/plans/` and follow their documented merge order when present, match the merge scope by branch name instead of branch ancestry, merge only those in-scope branches back into the same current branch, resolve conflicts by reading and composing the correct behavior instead of relying on blanket merge strategies, run targeted verification after conflictful merges, delete successfully merged source branches and detached worktrees only after verification succeeds, then run $commit-and-push for submission-readiness and the final local commit on that branch without pushing unless the user explicitly requested remote update in the same thread. Do not invoke $archive-specs from this skill."
+  default_prompt: "Use $merge-changes-from-local-branches to inventory the current branch plus the named local branches that should be merged, inspect active batch-spec `coordination.md` files under `docs/plans/` and follow their documented merge order when present, match the merge scope by branch name instead of branch ancestry, merge only those in-scope branches back into the same current branch, resolve conflicts by reading and composing the correct behavior instead of relying on blanket merge strategies, run targeted verification after conflictful merges, delete successfully merged source branches and detached worktrees only after verification succeeds, then run $commit for submission-readiness and the final local commit on that branch without pushing unless the user explicitly requested remote update in the same thread. Do not invoke $archive-specs from this skill."

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

@@ -7,15 +7,15 @@ description: PR-focused workflow for open-source repositories. Use when the user
 
 ## Dependencies
 
-- Required: **`commit-and-push`** before publishing the contribution branch (any remaining changes **MUST** be committed/readiness-checked through that skill; **push** only when the user requested remote update—then continue to PR steps).
+- Required: **`commit`** before publishing the contribution branch (any remaining changes **MUST** be committed/readiness-checked through that skill; **push** only when the user requested remote update—then continue to PR steps).
 - Conditional: `code-simplifier` for code-affecting PRs before opening the PR.
 - Optional: none.
-- Fallback: If **`commit-and-push`** or a **required** code-affecting dependency is unavailable, stop and report the missing dependency instead of bypassing the quality gate.
+- Fallback: If **`commit`** or a **required** code-affecting dependency is unavailable, stop and report the missing dependency instead of bypassing the quality gate.
 
 ## Standards
 
 - Evidence: Assume implementation is already prepared, then verify PR scope, repository constraints, and validation commands from the actual change set.
-- Execution: Create a compliant branch, run **`commit-and-push`** when the working tree still needs a gated commit, run dependent skills for code changes, then draft and open the PR.
+- Execution: Create a compliant branch, run **`commit`** when the working tree still needs a gated commit, run dependent skills for code changes, then draft and open the PR.
 - 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.
 
@@ -47,9 +47,9 @@ Example:
 git checkout -b codex/fix/add-rate-limit-retry
 ```
 
-### 3) Record changes with `commit-and-push`
+### 3) Record changes with `commit`
 
-- If `git status` shows uncommitted work on the PR branch, run **`commit-and-push`** through commit (and **push** when the user explicitly asked to publish the branch remotely) before PR creation—**MUST NOT** bypass readiness/review gates that skill applies.
+- If `git status` shows uncommitted work on the PR branch, run **`commit`** through commit (and **push** when the user explicitly asked to publish the branch remotely) before PR creation—**MUST NOT** bypass readiness/review gates that skill applies.
 - If the tree is already clean with commits present, skip only after confirming there is nothing left to stage.
 
 ### 4) Run dependent skills for code-affecting changes

package/openclaw-configuration/SKILL.md

@@ -9,7 +9,7 @@ description: Build, audit, and explain OpenClaw configuration from official docu
 
 - Required: none.
 - Conditional: `answering-questions-with-research` when a request depends on newer OpenClaw docs than the bundled references cover.
-- Conditional: `commit-and-push` when the user explicitly wants OpenClaw workspace changes committed and pushed after validation.
+- Conditional: `commit` when the user explicitly wants OpenClaw workspace changes committed and pushed after validation.
 - Optional: none.
 - Fallback: If the local CLI is unavailable, work from the bundled references and clearly mark any runtime behavior that was not verified on the machine.
 
@@ -104,7 +104,7 @@ When the request is about how the assistant should behave inside OpenClaw, inspe
 - `USER.md` for the user's profile and durable identity details
 - `memory/*.md` for durable corrections, failures, and learned preferences
 
-If the workspace is a git repo and the user explicitly asks to persist those changes remotely, validate first and then hand off to `commit-and-push`.
+If the workspace is a git repo and the user explicitly asks to persist those changes remotely, validate first and then hand off to `commit`.
 
 ### Verify tool permissions
 

package/package.json

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

package/{review-spec-related-changes → qa}/README.md

@@ -1,6 +1,6 @@
-# review-spec-related-changes
+# qa
 
-`review-spec-related-changes` reviews implementation changes against recent or user-specified planning documents.
+`qa` reviews implementation changes against recent or user-specified planning documents.
 
 ## What this skill does
 
@@ -34,7 +34,7 @@ Use this skill when the task asks you to:
 Prompt example:
 
 ```text
-Use $review-spec-related-changes to review the changes related to docs/plans/2026-04-28/order-routing.
+Use $qa to review the changes related to docs/plans/2026-04-28/order-routing.
 List any business goals that were not fully achieved, then run edge-case, security, and code-review checks on the related code.
 ```
 

package/{review-spec-related-changes → qa}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: review-spec-related-changes
+name: qa
 description: 當你需要審查規格文檔相關變更時，調用此技能
 ---
 

package/qa/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Review Spec Related Changes"
+  short_description: "Review spec-backed changes for business-goal completion and secondary code-practice risks"
+  default_prompt: "Use $qa to resolve the recent or user-specified spec documents, verify each business goal and acceptance criterion against the related implementation evidence, and treat unmet business goals as the most severe findings. When code is involved, prefer dispatching one read-only subagent per secondary skill in parallel — one for $review-change-set, one for $discover-edge-cases, one for $discover-security-issues — each running against the same diff scope and returning structured findings; the main agent waits for all secondary subagents, then aggregates them into the fixed report order without re-running any of those skills. Independent requirement clusters with disjoint owned paths may also be scored by parallel read-only business-goal subagents; tightly coupled requirements stay on the main agent. Subagents always run in read-only mode."

package/resolve-review-comments/SKILL.md

@@ -7,17 +7,17 @@ description: Read GitHub pull request review comments, analyze each thread, deci
 
 ## Dependencies
 
-- Required: **`commit-and-push`** for staging adopted fixes, creating the commit, and **pushing** when the user requested a PR branch update—**MUST NOT** substitute bare `git commit` / unverified push for that leg.
+- Required: **`commit`** for staging adopted fixes, creating the commit, and **pushing** when the user requested a PR branch update—**MUST NOT** substitute bare `git commit` / unverified push for that leg.
 - Conditional: none.
 - Optional: none.
-- Fallback: If **`commit-and-push`** is unavailable when submission is required, **MUST** stop and report.
+- Fallback: If **`commit`** is unavailable when submission is required, **MUST** stop and report.
 
 ## Standards
 
 - Evidence: Read unresolved review threads first and decide adopt versus reject from the actual review content and code context.
-- Execution: Implement only adopted feedback, validate it, **`commit-and-push`** on the same PR branch (commit + push when remote update is in scope), and resolve only the threads that were truly addressed.
+- Execution: Implement only adopted feedback, validate it, **`commit`** on the same PR branch (commit + push when remote update is in scope), and resolve only the threads that were truly addressed.
 - 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, **`commit-and-push`**-verified submission when applicable, and correctly resolved review threads.
+- Output: Complete the PR feedback loop with updated code, **`commit`**-verified submission when applicable, and correctly resolved review threads.
 
 ## Prerequisites
 
@@ -32,7 +32,7 @@ description: Read GitHub pull request review comments, analyze each thread, deci
 3. Decide adopt or reject thread-by-thread.
 4. Implement only adopted feedback.
 5. Run relevant tests and checks.
-6. **Submit** — Run **`commit-and-push`** on the same PR branch (commit always when there are staged fixes; **push** when updating the remote PR branch is in scope).
+6. **Submit** — Run **`commit`** on the same PR branch (commit always when there are staged fixes; **push** when updating the remote PR branch is in scope).
 7. Resolve only threads that were truly addressed.
 8. Reply on unresolved/rejected threads with reason.
 
@@ -73,11 +73,11 @@ Track adopted thread IDs in a JSON file:
 ## 5) Validate before submit
 
 - Run focused tests/lint/build that cover touched behavior.
-- If checks fail, fix before **`commit-and-push`**.
+- If checks fail, fix before **`commit`**.
 
 ## 6) Submit on the PR branch
 
-- Run **`commit-and-push`**: stage adopted fixes, commit with a clear message, **push** to the PR branch when remote update is in scope (same branch backing the open PR).
+- Run **`commit`**: stage adopted fixes, commit with a clear message, **push** to the PR branch when remote update is in scope (same branch backing the open PR).
 
 ## 7) Resolve addressed threads
 

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

@@ -7,7 +7,7 @@ description: Resolve a GitHub issue in an existing repository and submit the fix
 
 ## Dependencies
 
-- Required: `read-github-issue`, `enhance-existing-features`, and `commit-and-push`.
+- Required: `read-github-issue`, `enhance-existing-features`, and `commit`.
 - Conditional: `systematic-debug` when the issue is primarily a bug investigation or failing behavior report.
 - Optional: none.
 - Fallback: If any required dependency is unavailable, stop and report which dependency blocked the workflow.
@@ -48,7 +48,7 @@ description: Resolve a GitHub issue in an existing repository and submit the fix
 
 ### 4) Submit the fix without PR or release work
 
-- If the user asked to commit or push, hand off to `$commit-and-push`.
+- If the user asked to commit or push, hand off to `$commit`.
 - Preserve the user's explicit branch target; when the user says `push to main`, treat direct push to `main` as the default goal.
 - Before the final commit, ensure any required spec backfill, docs synchronization, and `AGENTS.md/CLAUDE.md` alignment are completed.
 - Do not convert this flow into a PR workflow unless the user explicitly requests a PR.

package/version-release/README.md

@@ -36,4 +36,4 @@ Apply the same rule to every other conditional gate: if its scenario is met duri
 
 Do not report release completion after only bumping versions or pushing a commit: the matching tag and GitHub release are part of done criteria unless the user explicitly says to skip publication.
 
-If the user only wants commit + push, use `commit-and-push`.
+If the user only wants commit + push, use `commit`.

package/version-release/SKILL.md

@@ -16,17 +16,17 @@ description: 當你需要協助用戶完成版本發佈時，使用這個技能
 
 ### 1. 檢查並確認 repo 狀態
 
-閱讀目前的 repo 狀態。查看是否依然存在未提交變更。如有，使用 `commit-and-push` 技能將目前為提交的變更暫存並提交。推送到 remote。
+閱讀目前的 repo 狀態。查看是否依然存在未提交變更。如有，使用 `commit` 技能將目前為提交的變更暫存並提交。推送到 remote。
 
 ### 2. 更新項目文檔狀態
 
-完整閱讀上一次發佈版本至今的所有變更，並檢查文檔之中的表述是否存在錯誤或遺漏。如有，使用 `align-project-documents`, `maintain-project-constraints` 這兩個技能將所有項目文檔同步到最新狀態。
+完整閱讀上一次發佈版本至今的所有變更，並檢查文檔之中的表述是否存在錯誤或遺漏。如有，使用 `docs-project`, `maintain-project-constraints` 這兩個技能將所有項目文檔同步到最新狀態。
 如果外部環境允許使用 subagents，建議通過並行調度 subagents 完成變更的逐行深度閱讀。
 
 ### 3. 發佈版本
 
 確認所有文檔都已經被更新之後，更新 repo 的版本文件（如 pyproject.toml, cargo.toml）。
-使用 `commit-and-push` 技能將所有變更提交並推送到 remote。
+使用 `commit` 技能將所有變更提交並推送到 remote。
 最後，將用戶要求的版本所對應的 version tag 推送到 remote 並建立 github release。
 
 ## 參考資料索引

package/align-project-documents/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Align Project Documents"
-  short_description: "Generate standardized project docs under docs/features/, docs/architecture/, and docs/principles/ from code evidence"
-  default_prompt: "Use $align-project-documents to read the entire codebase first, ground every claim in code/config/test evidence, then generate standardized project documentation in three categories: features (BDD-described, user perspective), architecture (macro-level design principles by module), and principles (code style, naming conventions, development constraints). Remove old non-conforming docs and refresh AGENTS.md/CLAUDE.md via maintain-project-constraints."

package/commit-and-push/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Commit and Push"
-  short_description: "Submit local changes with commit and push only"
-  default_prompt: "Use $commit-and-push to inspect the current git state and classify the diff. Treat every conditional gate whose scenario is met as blocking before any commit: if the change set includes code changes, run $review-change-set; if completed specs should be converted or docs need normalization, ensure $archive-specs runs through $submission-readiness-check; if changelog synchronization is needed, complete it before continuing. Then run any additional required code-quality skills, hand the repository to $submission-readiness-check so it can synchronize completed plan archives, project docs, AGENTS.md/CLAUDE.md, and CHANGELOG.md before any commit, confirm root CHANGELOG.md Unreleased reflects the actual pending change set, preserve user staging intent, create a concise Conventional Commit, and push to the intended branch without any versioning or release steps."

package/implement-specs/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Implement Specs"
-  short_description: "Implement approved specs in the current checkout"
-  default_prompt: "Use $implement-specs to resolve the user-named docs/plans path or the evidence-backed latest plan (never guess), read parent coordination.md when present, read spec.md then design.md then contract.md then checklist.md before executing every tasks.md line; when multiple member directories apply, finish one directory completely before the next per coordination.md; never create branches or git worktrees unless the user rescopes, backfill the planning docs, and finalize with $commit-and-push."

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

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Implement Specs with Subagents"
-  short_description: "Coordinate parallel spec worktree implementations"
-  default_prompt: "Use $implement-specs-with-subagents to read coordination.md and any preparation.md first, complete and commit explicitly documented prerequisite preparation on the working branch before delegation, analyse spec dependencies to build a multi-phase plan, for each phase assign each approved docs/plans spec directory to one independent subagent that uses $implement-specs-with-worktree, after each phase use $merge-changes-from-local-branches to merge completed spec branches back into the working branch before launching the next phase, honor any requested model when supported, and track each branch, commit, test result, and blocker."

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

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Implement Specs with Worktree"
-  short_description: "Implement an approved spec set inside an isolated git worktree"
-  default_prompt: "Use $implement-specs-with-worktree to follow the same docs/plans resolution and read-order rules as $implement-specs (spec then design then contract then checklist then tasks; one directory fully done before the next per coordination.md when multiple apply), identify the parent branch, create or reuse an isolated worktree and matching branch, verify pwd matches git rev-parse --show-toplevel before any write, keep the parent checkout read-only for deliverables, complete every tasks.md line and checklist.md wrap-up in the worktree, backfill planning docs, and finalize with $commit-and-push on the worktree branch."

package/review-spec-related-changes/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Review Spec Related Changes"
-  short_description: "Review spec-backed changes for business-goal completion and secondary code-practice risks"
-  default_prompt: "Use $review-spec-related-changes to resolve the recent or user-specified spec documents, verify each business goal and acceptance criterion against the related implementation evidence, and treat unmet business goals as the most severe findings. When code is involved, prefer dispatching one read-only subagent per secondary skill in parallel — one for $review-change-set, one for $discover-edge-cases, one for $discover-security-issues — each running against the same diff scope and returning structured findings; the main agent waits for all secondary subagents, then aggregates them into the fixed report order without re-running any of those skills. Independent requirement clusters with disjoint owned paths may also be scored by parallel read-only business-goal subagents; tightly coupled requirements stay on the main agent. Subagents always run in read-only mode."

package/solve-issues-found-during-review/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Solve Issues Found During Review"
-  short_description: "Fix review findings from high to low severity"
-  default_prompt: "Use $solve-issues-found-during-review to process a review report or finding list, fix each confirmed issue in severity order (Critical → High → Medium → Low), validate every fix before proceeding, and re-validate the full scope when all issues are resolved."