@laitszkin/apollo-toolkit 3.14.4 → 3.14.6

package/CHANGELOG.md

@@ -2,6 +2,18 @@
 
 All notable changes to this repository are documented in this file.
 
+## [v3.14.6] - 2026-05-16
+
+### Changed
+
+- Rename `generate-spec` to `spec` for consistency with other short skill aliases.
+
+## [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

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
@@ -19,10 +19,10 @@ A curated skill catalog for Codex, OpenClaw, Trae, Agents, and Claude Code with
 - exam-pdf-workflow
 - feature-propose
 - financial-research
-- generate-spec
-- implement-specs
-- implement-specs-with-subagents
-- implement-specs-with-worktree
+- spec
+- 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
@@ -199,11 +199,11 @@ 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.
+- `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-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/README.md

@@ -1,10 +1,10 @@
 # develop-new-features
 
-A spec-first feature development skill for new behavior and greenfield work. It delegates shared planning-doc generation to `generate-spec`, uses `test-case-strategy` for risk-driven test selection, then implements the approved feature with focused validation.
+A spec-first feature development skill for new behavior and greenfield work. It delegates shared planning-doc generation to `spec`, uses `test-case-strategy` for risk-driven test selection, then implements the approved feature with focused validation.
 
 ## Key capabilities
 
-- Requires `generate-spec` before any implementation starts.
+- Requires `spec` before any implementation starts.
 - Treats `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, and `design.md` as approval-gated artifacts, not optional notes.
 - Covers unit, regression, property-based, integration, E2E, adversarial, mock/fake, rollback, and unit drift-check testing based on actual risk through `test-case-strategy`.
 - Reuses existing architecture and avoids speculative expansion.
@@ -25,7 +25,7 @@ A spec-first feature development skill for new behavior and greenfield work. It
 ## Workflow summary
 
 1. Review only the official docs and code paths needed for the feature.
-2. Run `generate-spec` to create and maintain `docs/plans/{YYYY-MM-DD}/{change_name}/`, or `docs/plans/{YYYY-MM-DD}/{batch_name}/{change_name}/` plus `coordination.md` for parallel batches.
+2. Run `spec` to create and maintain `docs/plans/{YYYY-MM-DD}/{change_name}/`, or `docs/plans/{YYYY-MM-DD}/{batch_name}/{change_name}/` plus `coordination.md` for parallel batches.
 3. Wait for explicit approval on the spec set.
 4. Implement the approved behavior with minimal changes.
 5. Run risk-driven tests and backfill `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, and `design.md`.
@@ -40,5 +40,5 @@ A spec-first feature development skill for new behavior and greenfield work. It
 
 ## References
 
-- Shared planning workflow: `generate-spec`
+- Shared planning workflow: `spec`
 - Test selection and unit drift-check guide: `test-case-strategy`

package/develop-new-features/SKILL.md

@@ -16,14 +16,14 @@ description: 用於從零開始打造新專案。當你需要從零開始打造
 
 ### 1. 理解用戶需求
 
-分析用戶需求，並使用 `generate-spec` 技能建立spec。
+分析用戶需求，並使用 `spec` 技能建立spec。
 
 ### 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/develop-new-features/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Develop New Features"
-  short_description: "Spec-first feature development that depends on generate-spec"
-  default_prompt: "Use $develop-new-features to design new behavior through a spec-first workflow: review the required external docs, run $generate-spec to create and maintain docs/plans/<date>/<change_name>/... for single-spec work or docs/plans/<date>/<batch_name>/<change_name>/... plus coordination.md for parallel batches, wait for explicit approval, document material external dependency contracts in contract.md, document the architecture/design delta in design.md, record shared preparation and legacy-replacement direction in coordination.md when multiple specs will be implemented in parallel, use $test-case-strategy to choose risk-driven tests and unit drift checks before implementation, then complete the approved implementation end-to-end with full backfill of spec.md, tasks.md, checklist.md, contract.md, design.md, and when applicable coordination.md before yielding, unless the user changes scope or an external blocker prevents safe completion."
+  short_description: "Spec-first feature development that depends on spec"
+  default_prompt: "Use $develop-new-features to design new behavior through a spec-first workflow: review the required external docs, run $spec to create and maintain docs/plans/<date>/<change_name>/... for single-spec work or docs/plans/<date>/<batch_name>/<change_name>/... plus coordination.md for parallel batches, wait for explicit approval, document material external dependency contracts in contract.md, document the architecture/design delta in design.md, record shared preparation and legacy-replacement direction in coordination.md when multiple specs will be implemented in parallel, use $test-case-strategy to choose risk-driven tests and unit drift checks before implementation, then complete the approved implementation end-to-end with full backfill of spec.md, tasks.md, checklist.md, contract.md, design.md, and when applicable coordination.md before yielding, unless the user changes scope or an external blocker prevents safe completion."

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

@@ -1,5 +1,5 @@
 ---
-name: align-project-documents
+name: docs-project
 description: >-
     提供標準化的文檔格式，用於協助維護項目文檔。
     使用場景：更新、修改、重寫項目文檔。

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/README.md

@@ -5,7 +5,7 @@ A brownfield feature-extension skill: map dependencies first, decide whether sha
 ## Core capabilities
 
 - Explores dependencies and data flow before deciding how to change the system.
-- Uses `generate-spec` whenever the change is high-complexity, touches a critical module, or crosses module boundaries.
+- Uses `spec` whenever the change is high-complexity, touches a critical module, or crosses module boundaries.
 - Requires explicit approval before coding when specs are generated.
 - Still requires meaningful tests even when specs are skipped, selected through `test-case-strategy`.
 - Keeps brownfield changes focused and traceable.
@@ -25,7 +25,7 @@ A brownfield feature-extension skill: map dependencies first, decide whether sha
 ## Workflow summary
 
 1. Explore the existing codebase and affected logic chain first.
-2. Trigger `generate-spec` only when the change is high complexity, hits a critical module, or crosses module boundaries.
+2. Trigger `spec` only when the change is high complexity, hits a critical module, or crosses module boundaries.
 3. Wait for explicit approval if planning docs were generated.
 4. Implement the smallest safe brownfield change.
 5. Run risk-driven tests and backfill `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, and `design.md` when specs exist.
@@ -40,5 +40,5 @@ A brownfield feature-extension skill: map dependencies first, decide whether sha
 
 ## References
 
-- Shared planning workflow: `generate-spec`
+- Shared planning workflow: `spec`
 - Test selection and unit drift-check guide: `test-case-strategy`

package/enhance-existing-features/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: enhance-existing-features
 description: >-
-  在既有系統上增強或調整產品行為。先讀懂受影響模組，再決定直接實作或走 generate-spec；所有非平凡變更必須經過 test-case-strategy。
+  在既有系統上增強或調整產品行為。先讀懂受影響模組，再決定直接實作或走 spec；所有非平凡變更必須經過 test-case-strategy。
 ---
 
 ## 技能目標
@@ -11,16 +11,16 @@ description: >-
 ## 驗收條件
 
 - 變更範圍明確：已讀懂受影響模組、入口點、整合邊界與變更爆炸半徑。
-- 已正確判斷直接實作或必須先走 `generate-spec`，並在不需要 spec 時給出明確理由。
+- 已正確判斷直接實作或必須先走 `spec`，並在不需要 spec 時給出明確理由。
 - 每個非平凡變更都經過 `test-case-strategy`，留下清楚的 oracle、驗證方式與通過證據。
 - 若使用 spec：批准、實作、回填與計劃文件狀態同步全部完成。
 - 若未使用 spec：最終摘要足以說明風險、測試結果與剩餘限制。
-- `test-case-strategy` 不可用時必須停止；需要 spec 但 `generate-spec` 不可用時必須停止。
+- `test-case-strategy` 不可用時必須停止；需要 spec 但 `spec` 不可用時必須停止。
 
 ## 工作流程
 
 1. 完整閱讀受影響模組、資料流、整合點與現有測試，明確界定變更的爆炸半徑。
-2. 判斷是否需要 spec：涉及新的或改變使用者可見行為、跨模組協調、高風險敏感流程、重大歧義時走 `generate-spec`。不需 spec 時明確說出理由。
+2. 判斷是否需要 spec：涉及新的或改變使用者可見行為、跨模組協調、高風險敏感流程、重大歧義時走 `spec`。不需 spec 時明確說出理由。
 3. 若需要 spec，必須等批准後才能改產品程式碼。
 4. 查閱變更依賴的官方文件或 API spec，以最小差異實作需求，不順手做額外重構或範圍擴張。
 5. 使用 `test-case-strategy` 選擇測試組合，跑測試並修正失敗。
@@ -28,13 +28,13 @@ description: >-
 
 ## 使用範例
 
-- 「新增一套影響 API、資料庫與 UI 的權限模型」→ 先走 `generate-spec`，批准後再實作，並補上跨層測試。交付物包含已批准的 spec、通過的測試證據、回填完成的計劃文件。
+- 「新增一套影響 API、資料庫與 UI 的權限模型」→ 先走 `spec`，批准後再實作，並補上跨層測試。交付物包含已批准的 spec、通過的測試證據、回填完成的計劃文件。
 - 「修正分頁 off-by-one，讓行為回到 README 描述」→ 不開 spec，直接修復並加回歸測試。交付物為修復後的代碼與測試通過證據。
 
 
 ## 參考資料索引
 
-- `generate-spec`：需要書面批准時的 spec 流程。
+- `spec`：需要書面批准時的 spec 流程。
 
 - `test-case-strategy`：非平凡變更的測試選型與 oracle 設計。
-- `commit-and-push`：使用者要求提交或推送時的最終交付流程。
+- `commit`：使用者要求提交或推送時的最終交付流程。

package/enhance-existing-features/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "enhance-existing-features"
-  short_description: "Extend brownfield features with conditional generate-spec planning and risk-driven tests"
-  default_prompt: "Use $enhance-existing-features to extend a brownfield feature: map the affected code and dependencies first, decide whether the change is high complexity / critical module / cross-module, run $generate-spec when specs are required, wait for explicit approval before coding, document material external dependency contracts in contract.md, document the architecture/design delta in design.md, and when one change is split into parallel spec sets maintain a shared coordination.md for common preparation, ownership boundaries, and legacy-replacement direction; use $test-case-strategy to choose risk-driven tests, unit drift checks, and clear N/A reasons even when specs are skipped; if the user asked for a specific final behavior or architecture state, do not stop at an enabling intermediate milestone unless the user explicitly narrows scope; if a spec set exists, finish the approved tasks and applicable checklist items and backfill spec.md, tasks.md, checklist.md, contract.md, design.md, and when applicable coordination.md before yielding unless the user changes scope or an external blocker prevents safe completion."
+  short_description: "Extend brownfield features with conditional spec planning and risk-driven tests"
+  default_prompt: "Use $enhance-existing-features to extend a brownfield feature: map the affected code and dependencies first, decide whether the change is high complexity / critical module / cross-module, run $spec when specs are required, wait for explicit approval before coding, document material external dependency contracts in contract.md, document the architecture/design delta in design.md, and when one change is split into parallel spec sets maintain a shared coordination.md for common preparation, ownership boundaries, and legacy-replacement direction; use $test-case-strategy to choose risk-driven tests, unit drift checks, and clear N/A reasons even when specs are skipped; if the user asked for a specific final behavior or architecture state, do not stop at an enabling intermediate milestone unless the user explicitly narrows scope; if a spec set exists, finish the approved tasks and applicable checklist items and backfill spec.md, tasks.md, checklist.md, contract.md, design.md, and when applicable coordination.md before yielding unless the user changes scope or an external blocker prevents safe completion."

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/{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.4",
+  "version": "3.14.6",
   "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/{generate-spec → spec}/README.md

@@ -1,4 +1,4 @@
-# generate-spec
+# spec
 
 A shared planning skill for feature work. It centralizes creation and maintenance of `spec.md`, `tasks.md`, `checklist.md`, `contract.md`, `design.md`, and when needed shared `coordination.md` or `preparation.md` so other skills can reuse one consistent approval-gated spec workflow with risk-driven test planning from `test-case-strategy`.
 

package/{generate-spec → spec}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: generate-spec
+name: spec
 description: 當你需要將用戶模糊的複雜需求拆解成有嚴格實作範圍的spec時，使用這個技能
 ---
 

package/{generate-spec → spec}/agents/openai.yaml

@@ -1,8 +1,8 @@
 interface:
-  display_name: "generate-spec"
+  display_name: "spec"
   short_description: "Generate shared feature spec, task, and checklist docs before coding"
   default_prompt: >-
-    Use $generate-spec to create or update single-spec plans under docs/plans/<date>/<change_name>/ or parallel batches under docs/plans/<date>/<batch_name>/<change_name>/ with shared coordination.md and, only when specs cannot be parallel-safe without prior shared work, minimal non-business preparation.md; treat references/templates/*.md as binding format; member specs assume preparation finished—do not duplicate preparation tasks; surface collisions early and resolve ownership via coordination.md; fill BDD in spec.md; integrate $test-case-strategy into tasks/checklists.
+    Use $spec to create or update single-spec plans under docs/plans/<date>/<change_name>/ or parallel batches under docs/plans/<date>/<batch_name>/<change_name>/ with shared coordination.md and, only when specs cannot be parallel-safe without prior shared work, minimal non-business preparation.md; treat references/templates/*.md as binding format; member specs assume preparation finished—do not duplicate preparation tasks; surface collisions early and resolve ownership via coordination.md; fill BDD in spec.md; integrate $test-case-strategy into tasks/checklists.
     **Critical layering:** design.md + contract.md are higher-level guiding context only (architecture + cite-backed external truth; coarse INT-### / EXT-### anchors). tasks.md MUST be the ONLY enumerated runnable queue with path-level edits and verification hooks—derive tasks FROM spec + design + contract WITHOUT mirroring checklist rows into design/contract; optionally cite INT/EXT on task lines for traceability—never duplicate task choreography inside design.md or contract.md.
     **Architecture overlay + diff:** When the spec touches atlas surface (feature/sub-module, edges, function/variable rows, dataflow, errors), declare proposed-after state ONLY via `apltk architecture --spec <spec_dir> …`. **Exact verbs/flags: ALWAYS `apltk architecture --help`.** Single-spec plans write `<spec_dir>/architecture_diff/atlas/` + rendered HTML under `<spec_dir>/architecture_diff/`. Batch plans resolve any member `--spec` path to the shared batch-root `architecture_diff/` beside `coordination.md`, so the whole batch keeps one architecture diff. NEVER hand-author `architecture_diff/**`.
     Completion standard for atlas work: every intended cross-feature edge, every feature-to-feature relationship, and every sub-module relationship in scope must be expressed precisely through the CLI output — not left implicit in prose. After mutations: `render --spec`, `validate --spec` (must be OK pre-approval). **`apltk architecture diff`** opens the paginated before/after viewer over all `docs/plans/**/architecture_diff/` vs base `resources/project-architecture/` — run it when atlas changed; verify modified/added/removed pairing and confirm the rendered graph contains the full intended relationship set.

package/{generate-spec → spec}/references/TEMPLATE_SPEC.md

@@ -1,6 +1,6 @@
-# Atlas component schema — reference cheat sheet (generate-spec copy)
+# Atlas component schema — reference cheat sheet (spec copy)
 
-> Reference material only. The binding rules for atlas pages (verbs, semantic contracts, evidence) live in `init-project-html/SKILL.md`. The binding rule for spec-time atlas changes (declare via CLI, never hand-author HTML) lives in this skill's own `generate-spec/SKILL.md`. This file lists the exact fields and enum values that `apltk architecture --spec <spec_dir>` accepts.
+> Reference material only. The binding rules for atlas pages (verbs, semantic contracts, evidence) live in `init-project-html/SKILL.md`. The binding rule for spec-time atlas changes (declare via CLI, never hand-author HTML) lives in this skill's own `spec/SKILL.md`. This file lists the exact fields and enum values that `apltk architecture --spec <spec_dir>` accepts.
 
 ## Where the overlay lands
 

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."