strikethroo 3.21.2 → 3.22.0

package/templates/harness/skills/st-execute-blueprint/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-execute-task/SKILL.md

@@ -5,46 +5,35 @@ description: Use when the user asks to run, execute, or implement one specific t
 
 # st-execute-task
 
-Drive the execution of a single task within an existing Strikethroo plan.
-
 ## Critical Rules
 
-1. **Never skip dependency validation** — task execution requires all dependencies to be completed.
-2. **Validate task status** — never execute tasks that are already completed, in-progress, or needs-clarification.
-3. **Maintain status integrity** — update task status throughout the execution lifecycle.
-4. **Document execution** — record all outcomes and issues encountered.
-5. **Provide structured output** — always emit the structured result block for orchestrator parsing.
+1. **Maintain status integrity** — update task status throughout the execution lifecycle.
+2. **Document execution** — record all outcomes and issues encountered.
 
 ## Inputs
 
 The user supplies the numeric plan ID and task ID conversationally.
 
-## Failure Modes
-
-- **Execution or hook failure.** If `PRE_TASK_EXECUTION.md`,
-  `PRE_TASK_ASSIGNMENT.md`, or `POST_ERROR_DETECTION.md` fails, or the
-  implementing agent encounters an unrecoverable error, set the task status
-  to `failed`, document the error in Noteworthy Events, and emit the
-  structured result with `Exit Code: 1`.
-
 ## Operating Procedure
 
 ### 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`.
 
-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 execute a task outside of a valid root.
+Treat the path it prints as `<root>` for every subsequent step.
 
-For every subsequent step, treat the path printed by this script as `<root>`.
+Delegated execution workers skip this step and do not emit update notices.
+
+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.
@@ -54,40 +43,25 @@ printed path as `<plan-dir>`.
 
 ### 3. Validate the task file
 
-Locate the specific task file inside `<plan-dir>/tasks/`. Match using both
-padded and unpadded forms of the task ID:
-
-- First, look for `<plan-dir>/tasks/<task-id>--*.md`
-- If not found, look for `<plan-dir>/tasks/0<task-id>--*.md`
-
-If no file matches, stop and report that the task ID was not found in the
-plan. List the available task files in `<plan-dir>/tasks/` to help the user
-identify the correct ID.
-
-Treat the resolved file path as `<task-file>`.
+Look for `<plan-dir>/tasks/<task-id>--*.md`, then for the zero-padded
+`<plan-dir>/tasks/0<task-id>--*.md`. If neither matches, list the files in
+`<plan-dir>/tasks/` and stop. Treat the match as `<task-file>`.
 
 ### 4. Check task status
 
-Read the YAML frontmatter of `<task-file>` and extract the `status` field.
+Read `status` from the `<task-file>` frontmatter.
 
-- Block execution if the status is `completed`, `in-progress`, or
-  `needs-clarification`.
-- Allow execution if the status is `pending` or `failed`.
-- If the status is missing or unrecognized, proceed with caution and note
-  the ambiguity.
-
-If execution is blocked, stop and explain why, including guidance on how
-to resolve the blocker (e.g., use execute-blueprint to re-execute a completed
-task, or resolve clarification questions first).
+- `completed`, `in-progress`, or `needs-clarification`: stop, and name the way
+  out (re-execute a completed task through execute-blueprint, answer the open
+  clarification questions first).
+- `pending` or `failed`: execute.
+- Missing or unrecognized: proceed with caution and note the ambiguity.
 
 ### 5. Validate dependencies
 
-Run `scripts/check-task-dependencies.cjs <plan-id> <task-id>`. The script
-validates that every dependency declared in the task frontmatter has status
-`completed`.
-
-If the script exits 1, stop and report that the task is blocked by unresolved
-dependencies. Do not proceed until dependencies are satisfied.
+Run `scripts/check-task-dependencies.cjs <plan-id> <task-id>`. If it exits 1,
+stop and report that unresolved dependencies block the task. Do not proceed
+until they are satisfied.
 
 ### 6. Agent selection
 
@@ -124,33 +98,22 @@ Interpret the one-line JSON result and act on its `kind` exactly once:
 | `native-default` | Dispatch natively with no execution-setting prose. |
 | `native-override` | Dispatch natively, explicitly requiring the exact returned `model`. Require the returned `reasoningEffort` only when that property is present. |
 | `external-override` | Run the `execute` command with the returned `handoff`, then read its result against this same table. |
-| `fallback` | Nothing launched. Record the returned `reason` and `detail` visibly, then dispatch natively with no execution-setting prose. Either command can return it. |
+| `fallback` | Nothing launched. Record the returned `reason` and `detail` visibly, then dispatch natively with no execution-setting prose. |
 | `launched-success` | The external process exited zero. Do not dispatch natively; review status and evidence as you would for a native agent. |
 | `launched-failure` | A failed task. Set its status to `failed` and run `<root>/config/hooks/POST_ERROR_DETECTION.md`. Never retry it natively. |
-| `infrastructure-failure` | A failed task. Set its status to `failed` and run `<root>/config/hooks/POST_ERROR_DETECTION.md`. Never retry it natively. |
+| `infrastructure-failure` | Handle exactly as the preceding row. |
 
-Handoff and exit rules:
+Handoff rules:
 
 - Pass the exact opaque `handoff` string the resolver returned for that task. Never reconstruct one.
 - Never reuse a handoff for another task, and never rerun resolution after launches begin.
-- `execute` validates the handoff and does not reread routing configuration.
-- The command emits exactly one JSON line. Exit code `2` is an infrastructure failure; exit code `1` is a launched task failure.
 
 Steps 9–11 are this skill's failed-status and error-hook path.
 
 For a native dispatch, deploy an agent using your internal Task tool. The agent
-MUST perform these steps in order:
-
-1. **Pre-flight validation**: Read and execute
-   `<root>/config/hooks/PRE_TASK_EXECUTION.md` before starting any
-   implementation work.
-2. **Execute the task**: Read the complete `<task-file>` and implement
-   according to its requirements, including:
-   - Objective and acceptance criteria
-   - Technical requirements and implementation notes
-   - Input dependencies and expected output artifacts
-3. **Monitor progress**: Capture outputs, artifacts, and any issues
-   encountered during implementation.
+must read and execute `<root>/config/hooks/PRE_TASK_EXECUTION.md` before any
+implementation work, then read the complete `<task-file>` and implement it.
+Do not run `scripts/check-for-updates.cjs`; delegated workers do not consume update notices.
 
 ### 9. Update status to completed or failed
 
@@ -175,8 +138,6 @@ append a "Noteworthy Events" section to the end of `<task-file>`:
 - [YYYY-MM-DD] [Event description with sufficient context for the orchestrator]
 ```
 
-If no noteworthy events occurred, do not add the section.
-
 ### 11. Error handling
 
 If any error occurred during execution, read
@@ -184,14 +145,10 @@ If any error occurred during execution, read
 Document the error in Noteworthy Events and ensure the task status is set to
 `failed` if it is not already.
 
-### 12. Emit structured output
+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.
 
-End the session with exactly this block as the final output:
+## Failure Modes
 
-```
----
-Task Execution Result:
-- Plan ID: [numeric-id]
-- Task ID: [numeric-id]
-- Exit Code: [0 for success, 1 for failure]
-```
+- **Execution errors.** If a task fails, read `<root>/config/hooks/POST_ERROR_DETECTION.md`, document the error in Noteworthy Events, and ensure the task status is set to `failed`.