strikethroo 3.21.2 → 3.22.0

package/templates/harness/skills/st-full-workflow/scripts/dispatch-task-execution.cjs

@@ -3642,6 +3642,7 @@ var import_child_process2 = require("child_process");
 var taskPrompt = (request) => `Strikethroo external task dispatch \u2014 Plan ${request.planId}, Task ${request.taskId}.
 Workspace: ${request.workspace}
 Task file: ${request.taskFile}
+You are a delegated execution worker. Do not run check-for-updates.cjs or emit update notices.
 Before implementation, read and execute ${path2.join(
   request.workspace,
   ".ai/strikethroo/config/hooks/PRE_TASK_EXECUTION.md"

package/templates/harness/skills/st-generate-tasks/SKILL.md

@@ -5,9 +5,6 @@ description: Use when the user asks to decompose, break down, or generate tasks
 
 # st-generate-tasks
 
-Drive the end-to-end decomposition of an existing Strikethroo plan into
-atomic Markdown task files.
-
 ## Inputs
 
 The user supplies the numeric plan ID conversationally.
@@ -16,20 +13,22 @@ The user supplies the numeric plan ID conversationally.
 
 ### 1. Locate the strikethroo root
 
-Run `scripts/find-strikethroo-root.cjs` from the user's working directory.
+Run `scripts/find-strikethroo-root.cjs` from the user's working directory. If
+it exits non-zero, stop and ask the user to run `npx strikethroo init`.
+
+Treat the path it prints as `<root>` for every subsequent step.
 
-If the script exits non-zero, the working directory is not inside an
-initialized strikethroo workspace. Stop and ask the user to run the project
-initializer (e.g. `npx strikethroo init`) before continuing. Do
-not attempt to generate tasks outside of a valid root.
+Delegated execution workers skip this step and do not emit update notices.
 
-For every subsequent step, treat the path printed by this script as `<root>`.
+Run `scripts/check-for-updates.cjs "<root>"` as a separate command using this
+skill's script path. Keep the user's working directory. Read the one JSON line
+on stdout. When `notice` is present, retain its exact text for the final
+user-facing response. Never pause for permission and never run an update.
 
 ### 2. Resolve the plan
 
-Run `scripts/validate-plan-blueprint.cjs <plan-id> planFile` to obtain the
-absolute path of the plan file. Passing a different field name prints that
-field alone.
+Run `scripts/validate-plan-blueprint.cjs <plan-id> planFile` for the plan
+file's absolute path. Another field name prints that field instead.
 
 If the script exits non-zero, stop and ask the user to confirm the plan ID.
 Do not guess a different ID.
@@ -38,12 +37,11 @@ Do not guess a different ID.
 
 Read these files, in order:
 
-- `<root>/config/STRIKETHROO.md` — directory conventions for plans, tasks,
-  and the archive layout.
-- The plan body at the path returned by step 2 — this is the contract for
+- `<root>/config/STRIKETHROO.md` — project and directory conventions.
+- The plan body at the path returned by step 2 — the contract for
   what tasks must exist.
-- `<root>/config/templates/TASK_TEMPLATE.md` — every task file you emit must
-  conform to this template's frontmatter schema and section structure.
+- `<root>/config/templates/TASK_TEMPLATE.md` — the schema every task file
+  must match.
 - `<root>/config/shared/anti-rationalization.md` — apply in step 4.
 
 ### 4. Analyze and decompose the plan
@@ -56,23 +54,10 @@ Decompose each deliverable into atomic tasks only when genuinely needed.
 - Create only the minimum number of tasks necessary. Target a 20–30%
   reduction from comprehensive lists by questioning the necessity of each
   candidate.
-- **Direct Implementation Only**: a task corresponds to an explicit
-  requirement, not a "nice-to-have".
-- **DRY Task Principle**: each task has a unique, non-overlapping purpose.
-- **Question Everything**: for each task, ask "Is this absolutely necessary
-  to meet the plan objectives?"
-- **Avoid Gold-plating**: resist comprehensive features the plan does not
-  require.
-
-**Antipatterns to avoid:**
-
-- Separating "error handling" from the main implementation when it can be
-  inline.
-- Splitting trivially small operations into multiple tasks (e.g. "validate
-  input" + "process input" as separate units).
-- Adding tasks for "future extensibility" or "best practices" the plan does
-  not mention.
-- Comprehensive test suites for trivial functionality.
+- Every task corresponds to an explicit requirement, never a nice-to-have, a
+  "best practice", or future extensibility the plan does not mention.
+- Each task has a unique, non-overlapping purpose.
+- Keep error handling inside the task that owns the behavior it guards.
 
 Apply `<root>/config/shared/anti-rationalization.md` to this rationalization table:
 
@@ -94,80 +79,68 @@ Each task must be:
   concrete, runnable verification step (a command plus its expected output, or
   another observable signal). Never settle for a vague "works correctly".
 
-Skill assignment (kebab-case, automatically inferred from the task's
-technical requirements):
-
-- 1 skill — single-domain task (e.g. `["css"]`, `["vitest"]`).
-- 2 skills — complementary domains (e.g. `["api-endpoints", "database"]`,
-  `["react-components", "vitest"]`).
-- 3+ skills indicates the task should be broken down further.
+Infer skills in kebab-case from the task's technical requirements. Use one
+skill for a single-domain task and two for complementary domains, such as
+`["api-endpoints", "database"]`. Three or more means the task must be broken
+down further.
 
 ### 6. Test philosophy: "write a few tests, mostly integration"
 
-When generating test tasks, keep this constraint:
+**Write tests for:**
 
-**Definition.** Meaningful tests verify custom business logic, critical paths,
-and edge cases specific to this application. Test *your* code, not the
-framework or library.
+- Custom business logic and algorithms.
+- Critical user workflows and data transformations.
+- Edge cases and error conditions in core functionality.
+- Integration points between components.
+- Complex validation or calculation logic.
 
-Before writing any test task, read `references/test-philosophy.md`; it lists
-what deserves a test and what does not.
+**Do not write tests for:**
 
-**Test task creation rules:**
+- Third-party library and framework functionality.
+- Simple CRUD without custom logic.
+- Trivial getters/setters and static configuration.
+- Obvious functionality that would break immediately if incorrect.
 
-- Combine related test scenarios into a single task (e.g. "Test user
-  authentication flow" not separate tasks for login, logout, validation).
-- Favor integration and critical-path coverage over per-method unit tests.
-- Avoid one test task per CRUD operation.
-- Question whether simple functions need a dedicated test task.
+Combine related test scenarios into one task ("Test user authentication flow",
+not separate tasks for login, logout, and validation). Favor integration and
+critical-path coverage over per-method unit tests. Never create one test task
+per CRUD operation.
 
-If any test task is generated, restate this section and the reference file
-verbatim or near-verbatim in that task's "Implementation Notes" so the
-executing agent applies them.
+Copy these rules into the "Implementation Notes" of every test task you
+generate.
 
 ### 7. Dependency analysis
 
-For each task, identify:
-
-- **Hard dependencies**: tasks that MUST complete before this one can start.
-- **Soft dependencies**: tasks that SHOULD complete for optimal execution.
-
-A task B depends on A if B requires A's output or artifacts, modifies code
-created by A, or tests functionality implemented by A. Validate that the
-final dependency graph is acyclic.
+Task B depends on task A when B requires A's output or artifacts, modifies
+code created by A, or tests functionality implemented by A. Record it as a
+**hard dependency** when B cannot start before A completes and as a **soft
+dependency** when B merely runs better after A. Validate that the final
+dependency graph is acyclic.
 
 ### 8. Complexity analysis
 
 For every candidate task, assign a `complexity_score` (integer 1–10) before
 writing any file. Read `references/complexity-rubric.md` before scoring; it
-defines the four dimensions each band is judged on.
-
-**Pre-emission sanity rules** — apply these before any task is written:
+defines the four dimensions each band is judged on. Then apply these rules:
 
-- 3+ skills assigned → split the task into smaller tasks, each with 1–2 skills.
-- Vague acceptance criteria → sharpen them until they include at least one
-  concrete, runnable verification step.
-- Trivially small adjacent tasks → merge them into a single task.
 - Score ≥ 8 → decompose further; do not emit as-is.
-- Score 6–7 → either sharpen criteria or split; do not emit without an
-  explicit reason.
+- Score 6–7 → sharpen or split; do not emit without an explicit reason.
+- Vague acceptance criteria → sharpen them into a concrete, runnable
+  verification step.
+- Trivially small adjacent tasks → merge them.
 
-**Loop-back rule:**
-
-After applying split, sharpen, or merge, re-run dependency analysis and
-re-score the adjusted tasks. Repeat this loop no more than three times. If
+**Loop-back rule:** after applying split, sharpen, or merge, re-run dependency
+analysis and re-score the adjusted tasks. Repeat no more than three times. If
 complexity is still unresolved after three passes, stop and surface the
 blocker to the user.
 
 ### 9. Allocate task IDs
 
-Run `scripts/get-next-task-id.cjs <plan-id>` to obtain the first available
-task ID. Allocate subsequent IDs by incrementing in-process; do not invoke
-the script repeatedly. Use the unpadded integer in the task frontmatter `id`
-field and the zero-padded form (`{padded-id}--{slug}`) for the filename.
-
-The slug derives from a short task title: lowercase, alphanumeric and
-hyphens only, collapsed, trimmed.
+Run `scripts/get-next-task-id.cjs <plan-id>` once for the first available task
+ID, then allocate the rest by incrementing in-process. Use the unpadded
+integer in the task frontmatter `id` field and the zero-padded form in the
+filename. The slug derives from a short task title: lowercase, alphanumeric
+and hyphens only, collapsed, trimmed.
 
 ### 10. Emit the task files
 
@@ -177,34 +150,23 @@ Write each task to:
 <root>/plans/<plan-dir-name>/tasks/{padded-id}--{slug}.md
 ```
 
-Each file must conform to `<root>/config/templates/TASK_TEMPLATE.md`. Read
-`references/task-frontmatter.md` when filling the frontmatter; it lists every
-field, its type, and when the optional ones apply.
+Each file must conform to `<root>/config/templates/TASK_TEMPLATE.md`. Add
+`complexity_notes` only when the score needs justification. Never write
+`execution_profile`; the routing helper writes it.
 
-The body sections (Objective, Skills Required, Acceptance Criteria, Technical
-Requirements, Input Dependencies, Output Artifacts, Implementation Notes)
-must be filled with task-specific content. Place detailed implementation
-guidance inside a `<details>` block under "Implementation Notes" — write it
-so a non-thinking LLM could execute the task from that section alone.
+Fill every body section with task-specific content. Place detailed
+implementation guidance inside a `<details>` block under "Implementation
+Notes", written so a non-thinking LLM could execute the task from that
+section alone.
 
 ### 11. Validation checklist
 
 Before declaring task generation complete, verify:
 
-- Each task has 1–2 appropriate technical skills assigned and inferred from
-  its objectives.
-- Dependencies form an acyclic graph; no orphan or circular references.
-- Task IDs are unique, sequential, and start from the value returned by
-  `get-next-task-id.cjs`.
-- Groups are consistent and meaningful.
-- Every task's Acceptance Criteria includes at least one concrete, runnable
-  verification step (command + expected output / observable signal), not a
-  vague "works correctly".
-- Every **explicitly stated** deliverable in the plan is covered.
-- No redundant or overlapping tasks.
-- Minimization applied (20–30% reduction target).
-- Test tasks focus on business logic, not framework functionality.
-- No gold-plating: only plan requirements are addressed.
+- Every **explicitly stated** deliverable in the plan is covered by a task.
+- No two tasks overlap in purpose.
+- Dependencies form an acyclic graph, with no orphan or circular references.
+- Groups are consistent across the plan.
 - After writing the task files, run
   `scripts/validate-plan-blueprint.cjs <plan-id> complexityScoresValid`. Stop
   unless it prints `yes`; if it prints `no`, run
@@ -216,62 +178,36 @@ Before declaring task generation complete, verify:
 Read `<root>/config/hooks/TASK_EXECUTION_ROUTING.md` and follow its
 instructions together with this procedure:
 
-1. Run `scripts/route-task-execution.cjs profiles <plan-id>` and interpret
-   its JSON result. On `no-config` or `disabled`, routing is off: skip the
-   remaining routing steps and continue. On `invalid-config`, stop and
-   surface the errors to the user — do not generate the blueprint.
-2. Classify every task in the plan's `tasks/` directory against the
-   configured profile descriptions. For tasks generated in this run, use the
-   task content already in your context — objective, acceptance criteria,
-   technical requirements, `skills`, and `complexity_score`; do not reread
-   the emitted task files to reconstruct information you already hold. If
-   the plan carried task files from an earlier generation run, read those
-   files (and only those) to classify them — the mapping must cover every
-   task in the plan. Assign each task ID exactly one configured profile
-   name. Never invent a profile name, model, or harness.
+1. Run `scripts/route-task-execution.cjs profiles <plan-id>`. On `no-config`
+   or `disabled`, routing is off; skip the remaining routing steps and
+   continue. On `invalid-config`, stop and surface the errors to the user; do
+   not generate the blueprint.
+2. Assign every task in the plan's `tasks/` directory exactly one configured
+   profile name. Classify the tasks generated in this run from the content
+   already in your context. If the plan carried task files from an earlier
+   generation run, read those files to classify them.
 3. Write the complete task-ID-to-profile mapping as a JSON object to a
    temporary file, for example `{"1": "routine", "2": "demanding"}`.
-4. Run
-   `scripts/route-task-execution.cjs apply <plan-id> <mapping-file>`. The
-   helper validates the mapping (every task exactly once, only configured
-   profiles), writes one `execution_profile` frontmatter field per task, and
-   verifies the written files. Target selection and resolver execution happen
-   later at task dispatch, never during generation.
-5. On `routed`, delete the temporary mapping file and continue. On any
-   failure result (`invalid-assignments`, `invalid-tasks`,
-   `routing-failure`, `infrastructure-failure`), stop
-   and surface the JSON errors to the user. Never proceed to blueprint
-   generation with partially routed tasks.
-
-Profile names are durable routing labels. Persist them only through the
-helper's `execution_profile` field; never hand-write a concrete `execution`
-target into task frontmatter or task bodies.
+4. Run `scripts/route-task-execution.cjs apply <plan-id> <mapping-file>`.
+   Target selection happens later at task dispatch, never during generation.
+5. On `routed`, delete the temporary mapping file and continue. On any failure
+   result (`invalid-assignments`, `invalid-tasks`, `routing-failure`,
+   `infrastructure-failure`), stop and surface the JSON errors to the user.
+   Never continue to blueprint generation with partially routed tasks.
+
+Never hand-write a concrete execution target into task frontmatter or task
+bodies.
 
 ### 13. Run the POST_TASK_GENERATION_ALL hook
 
 Read `<root>/config/hooks/POST_TASK_GENERATION_ALL.md` and follow its
-instructions. Run it only after routing succeeded or reported routing off.
-This typically requires:
-
-- Appending an Execution Blueprint section to the plan document, including a
-  Mermaid dependency diagram and explicit phase groupings (Phase 1 contains
-  zero-dependency tasks; each subsequent phase contains tasks whose
-  dependencies all live in earlier phases). Use
-  `<root>/config/templates/BLUEPRINT_TEMPLATE.md` for structure.
-
-### 14. Emit the structured summary
-
-Conclude with exactly this block as the final output:
-
-```
----
-Task Generation Summary:
-- Plan ID: [numeric-id]
-- Tasks: [count]
-- Status: Ready for execution
-```
+instructions, using `<root>/config/templates/BLUEPRINT_TEMPLATE.md` for the
+Execution Blueprint structure. Run the hook only after routing succeeded or
+reported routing off.
 
-The summary is consumed by downstream automation; keep the format exact.
+When the retained update `notice` is present, append that exact sentence after
+the structured summary block, or after your final response when this skill emits
+no summary block. Nothing may follow the notice.
 
 ## Failure Modes