@laitszkin/apollo-toolkit 3.6.3 → 3.6.5

package/CHANGELOG.md

@@ -7,6 +7,17 @@ All notable changes to this repository are documented in this file.
 ### Added
 - (None yet)
 
+## [v3.6.5] - 2026-04-29
+
+### Fixed
+- Synchronize `package-lock.json` version with release
+- Fix template assertion test to match the simplified tasks.md format
+
+## [v3.6.4] - 2026-04-29
+
+### Changed
+- Simplify `generate-spec` tasks.md template with compact per-item format (inline file/change/outcome + Verify field), and strengthen SKILL.md §4 to require exact file path, modification, and verification step for every task item
+
 ## [v3.6.3] - 2026-04-28
 
 ### Changed

package/generate-spec/SKILL.md

@@ -86,16 +86,19 @@ Own the shared planning-doc lifecycle for feature work so other skills can reuse
 
 ### 4) Fill `tasks.md`
 
-- Use `## **Task N: [Task Title]**` for each main task.
-- Describe each task's purpose and the related requirement IDs.
+- Use `## **Task N: [Task Title]**` for each main task with `Purpose`, `Requirements`, `Scope`, and `Out of scope` guardrails.
 - Use `- N. [ ]` for atomic task items; use `- N.x [ ]` only when a task must be split into additional atomic subtasks.
 - Treat `tasks.md` as an implementation queue, not a high-level summary.
-- Make each checkbox atomic: one verb, one responsibility, one concrete output, and one verification hook.
-- For every task, include allowed scope, out-of-scope guardrails, requirement/design/contract inputs, expected output, completion condition, and verification hook.
+- **Every checkbox must specify three things: (a) the exact file path or function, (b) the specific modification to make, and (c) a concrete verification step.** These three are mandatory — no item may omit any of them.
+- Per-item format (compact template):
+  - `[file/function]` — `[specific modification; expected outcome]`
+  - `- Verify:` — focused command, test reference, or manual inspection
+- Do not add extra sub-fields beyond what the template provides; put all change detail in the inline description.
+- Make each checkbox atomic: one verb, one file/function, one change outcome, and one verification hook.
 - If one task needs more than three files, more than one behavior slice, or an implementation decision not already captured in `design.md` or `contract.md`, split it before approval.
 - Use `$test-case-strategy` to define test IDs and unit drift checks for non-trivial local logic before implementation starts.
 - Include explicit tasks for testing, mocks/fakes, regression coverage, and adversarial or edge-case hardening when relevant.
-- Do not write vague tasks such as `Implement integration`, `Add tests`, or `Update docs`; replace them with task-local outputs, test IDs, and verification commands.
+- Vague items such as `Implement integration`, `Add tests`, or `Update docs` are forbidden; replace them with specific file paths, concrete changes, and executable verification commands.
 
 ### 5) Fill `contract.md`
 

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

@@ -7,59 +7,36 @@
 
 Purpose: [one sentence describing the narrow outcome]
 Requirements: [R1.x]
-Allowed scope: [files/modules/functions this task may touch]
+Scope: [files/modules/functions this task may touch]
 Out of scope: [files/modules/behaviors this task must not change]
 
-- 1. [ ] [Main task item]
-  - Input: [requirement/design/contract evidence]
-  - Touches: [specific file/function/module]
-  - Output: [specific code/doc/test artifact]
-  - Done when: [observable completion condition]
-  - Verify with: [focused command/check/manual inspection]
-  - Unit drift check: [UT-xx target unit; expected result/assertion, or N/A with reason]
-  - Do not: [explicit implementation-drift guardrail]
+- 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]**
+  - Verify: [focused command/check/manual inspection; drift check ref if applicable]
 
 ## **Task 2: [Task Title]**
 
 Purpose: [one sentence describing the narrow outcome]
 Requirements: [R2.x]
-Allowed scope: [files/modules/functions this task may touch]
+Scope: [files/modules/functions this task may touch]
 Out of scope: [files/modules/behaviors this task must not change]
 
-- 2. [ ] [Main task item]
-  - Input: [requirement/design/contract evidence]
-  - Touches: [specific file/function/module]
-  - Output: [specific code/doc/test artifact]
-  - Done when: [observable completion condition]
-  - Verify with: [focused command/check/manual inspection]
-  - Unit drift check: [UT-xx target unit; expected result/assertion, or N/A with reason]
-  - Do not: [explicit implementation-drift guardrail]
-
-## **Task 3: [Task Title]**
-
-Purpose: [one sentence describing the narrow outcome]
-Requirements: [R3.x]
-Allowed 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]**
+  - Verify: [focused command/check/manual inspection; drift check ref if applicable]
 
-- 3. [ ] [Main task item]
-  - Input: [requirement/design/contract evidence]
-  - Touches: [specific file/function/module]
-  - Output: [specific code/doc/test artifact]
-  - Done when: [observable completion condition]
-  - Verify with: [focused command/check/manual inspection]
-  - Unit drift check: [UT-xx target unit; expected result/assertion, or N/A with reason]
-  - Do not: [explicit implementation-drift guardrail]
+- 2. [ ] **[file/function]** — **[specific modification to make; expected outcome]**
+  - Verify: [focused command/check/manual inspection; drift check ref if applicable]
 
 ## Notes
-- Task order should reflect actual implementation sequence.
-- Every main task must map back to `spec.md` requirement IDs.
-- Treat `tasks.md` as an implementation queue, not a high-level work summary.
-- Each checkbox must be atomic: one verb, one responsibility, one concrete output, and one verification hook.
-- Split any task that needs more than three files, more than one behavior slice, or a design decision not already captured in `design.md` or `contract.md`.
-- Use `$test-case-strategy` to define test IDs and unit drift checks before implementation.
-- Include explicit tasks for required test coverage (unit, regression, property-based, integration/E2E as applicable), mock scenario setup, and adversarial/edge-case hardening.
-- Do not write vague tasks such as `Implement integration`, `Add tests`, or `Update docs`; replace them with task-local outputs, test IDs, and verification commands.
-- For batch specs, tasks must never include "wait for Spec X to land first" as a prerequisite; if such a dependency appears, re-slice the plan or move the coordination rule into `coordination.md`.
-- After execution, the agent must update each checkbox (`[x]` for done, `[ ]` for not done).
-- Remove all placeholder guidance text in square brackets after filling.
+- 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/package.json

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