@laitszkin/apollo-toolkit 3.14.5 → 3.14.6

package/CHANGELOG.md

@@ -2,6 +2,12 @@
 
 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

package/README.md

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

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,7 +16,7 @@ description: 用於從零開始打造新專案。當你需要從零開始打造
 
 ### 1. 理解用戶需求
 
-分析用戶需求，並使用 `generate-spec` 技能建立spec。
+分析用戶需求，並使用 `spec` 技能建立spec。
 
 ### 2. 實作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/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`：使用者要求提交或推送時的最終交付流程。

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/package.json

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

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