e0ipso st-execute-task
Critical Rules
- Maintain status integrity — update task status throughout the execution lifecycle.
- Document execution — record all outcomes and issues encountered.
Inputs
The user supplies the numeric plan ID and task ID conversationally.
Operating Procedure
1. Locate the strikethroo root
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.
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 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.
Run scripts/validate-plan-blueprint.cjs <plan-id> planDir and treat the
printed path as <plan-dir>.
3. Validate the 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 status from the <task-file> frontmatter.
completed,in-progress, orneeds-clarification: stop, and name the way out (re-execute a completed task through execute-blueprint, answer the open clarification questions first).pendingorfailed: execute.- Missing or unrecognized: proceed with caution and note the ambiguity.
5. Validate dependencies
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
Read <root>/config/hooks/PRE_TASK_ASSIGNMENT.md and follow its instructions
for selecting the appropriate agent or skill set for this task.
7. Update status to in-progress
Rewrite the YAML frontmatter of <task-file>, setting status: "in-progress".
Preserve all other frontmatter fields exactly.
8. Execute the task
Resolve the route before deploying any agent; resolution launches no task work:
scripts/dispatch-task-execution.cjs resolve <task-file> <current-harness> <workspace> <plan-id> <task-id>
External execution uses:
scripts/dispatch-task-execution.cjs execute <handoff> <task-file> <current-harness> <workspace> <plan-id> <task-id>
<current-harness> is the exact supported harness identifier running this
skill; <workspace> is the project working directory.
Interpret the one-line JSON result and act on its kind exactly once:
kind |
Required action |
|---|---|
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. |
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 |
Handle exactly as the preceding row. |
Handoff rules:
- Pass the exact opaque
handoffstring the resolver returned for that task. Never reconstruct one. - Never reuse a handoff for another task, and never rerun resolution after launches begin.
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 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
After the agent finishes, rewrite the YAML frontmatter of <task-file> based
on the outcome:
- Set
status: "completed"if the task was implemented successfully and all acceptance criteria are met. - Set
status: "failed"if the task could not be completed, acceptance criteria were not met, or an unrecoverable error occurred.
Preserve all other frontmatter fields exactly.
10. Document noteworthy events
If anything significant occurred during execution — decisions made, issues
encountered, deviations from the plan, or follow-up actions required —
append a "Noteworthy Events" section to the end of <task-file>:
## Noteworthy Events
- [YYYY-MM-DD] [Event description with sufficient context for the orchestrator]
11. Error handling
If any error occurred during execution, read
<root>/config/hooks/POST_ERROR_DETECTION.md and execute its instructions.
Document the error in Noteworthy Events and ensure the task status is set to
failed if it is not already.
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
- 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 tofailed.