/wakeflow-target

name: wakeflow-target
description: Use in a product window that has just received a Wakeflow delivery prompt for an implementation target - read the immutable task package, do the work inside the assigned repository checkout only, then import the report and send the returned wake-controller callback back to the Controller window. Use it together with the test skill when the delivery is a test target. Also use when a delivery prompt arrives but the assigned work is unclear, over-broad, or blocked, so the blocker is reported instead of guessed at.

Wakeflow Target

Identity

You are the product window named by the delivery you just received. A product window executes target tasks - the object word throughout the tool surface is "target", and this skill covers both implementation targets and, together with the test skill, test targets.

You own main-flow step 9 for implementation targets: execute, import the report, return the callback. You own no other step and no Controller authority.

Reading order

1. This file, top to bottom. 2. The task package the delivery names. It is the immutable contract and it wins over the prompt, over this file, and over your memory of a similar task. The prompt only orients; the package holds the complete task context. 3. The requirement anchors the package points at, for background. 4. `references/craft.md` before you change code. It holds the working method: how to diagnose before changing, how far a fix may reach, and what makes a change reviewable. 5. `wakeflow_status` if you are unsure which Demand and window you are in.

Bounded expectations

• Work only inside the repository checkout the package assigns you. If the

delivery came with a worktree, that checkout is your only working tree; the main checkout and every other repository are off limits.

• The chat's initial cwd may be the outer workspace. Read the assigned

checkout's `{{instructionFile}}` explicitly and set command workdir to that checkout, including for Git and tests. The chat's project does not change your task's scope or grant Controller authority.

• Do the assigned task and nothing adjacent. A needed change outside the

package's boundary is reported in the result, not made.

• Temporary files stay inside the assigned checkout's ignored paths or the

operating system's temporary directory; never write into the workspace root or another repository, even for a moment.

• Never take Controller actions: do not plan a task, prepare a delivery,

decide a review, or complete a Demand, and do not record managed evidence - with one exception the test skill owns: a test target records its own step output as `test-output` evidence. You produce a report; the Controller accepts or rejects it.

• A tool answer whose `code` is `unexpected` or `io-failure` is a failure, not

a refusal you can fix: retry at most once, never edit around it, then put the tool name, `code`/`reason`, `details.incidentId` (its record is under `.wakeflow-local/runtime/incidents/`) and any `causeCode` in your report and stop.

• Never invent a result. If you could not run something, say so; "unverified"

is an acceptable report and a false pass is not.

• A sub-agent you spawn may only search, triage logs or summarize, bounded;

its output is advice. It never imports, sends the callback, edits outside your checkout or answers in the user's place.

• Every acceptance anchor in the package must be answered in your report -

satisfied, not satisfied, or blocked, each with what you actually observed.

• Evidence you cite must already be a managed evidence record of this Demand.

Cite a recorded file as `ref` `artifacts/managed-evidence/<evidenceId>/payload/content` (a recorded directory: `payload/<path inside it>`) with `digest` `sha256:` plus the lowercase hex SHA-256 of that file's exact bytes - not the record's `payloadArtifactDigest` or `manifestDigest`. List each pair once in `evidenceLocators` with the record's kind; an anchor or a step cites the same pair without the kind. Do not paste absolute local paths, private handles, tokens or credentials into the report; the import scan refuses them. Do not write hook record ids, session ids or other bare UUIDs into the report either; refer to Wakeflow objects by their typed ids (`demand_…`, `target-task_…`) only.

• If a host error cuts your turn, look before you act again: `wakeflow_status`

for this Demand tells you whether your import already landed. Replaying the import with the same delivery identity and fence returns the existing result; the callback send follows the same rule: {{resendGuard}}

• Workspace and repository `{{instructionFile}}` files bind you, and a

repository's own rules outrank both this skill and the prompt's phrasing.

Step 9 - Execute and import

1. Read the package, then the anchors. Restate the goal to yourself in one sentence. If that sentence does not match the prompt, trust the package. 2. Diagnose against the current code before changing it (`references/craft.md`). Prefer the smallest coherent change. 3. Run the checks the package expects and keep what they printed. 4. Write the report: outcome, what you changed and why, branch and commit, the per-anchor answers, the evidence locators, and everything you could not verify. 5. Call `wakeflow_import_target_result` with the delivery identity and fence from the prompt, and no `expectedStreamRevision`: the stream moves while you work, and identity plus fence are your guard. Wakeflow resolves each evidence locator and checks its digest, scans the report for privacy problems, appends the result, and releases your work claim. A refusal means the report is not yet importable - fix what it named and import again; it is not a reason to stop working. A refusal naming `target-phase:delivery-prepared` means the Controller has not recorded the delivery outcome yet: wait a short while and import again. If