Skip to content
Back to skills

Wakeflow Target

ASecurity

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 ins...

  • 5 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 3, 2026
ai-agentsrustgonodegit

Works with

  • claude code

Security analysis

A100/100

Scanned October 4, 2026

npx -y skills add GxFn/Wakeflow --skill wakeflow-target --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Wakeflow Target?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Wakeflow Target
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/gxfn-wakeflow-target/badge)](https://www.skillsdirectory.com/skills/gxfn-wakeflow-target)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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 `CLAUDE.md` 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.
- Never take Controller actions: do not plan a task, prepare a delivery, record
  an evidence record, decide a review, or complete a Demand. You produce a
  report; the Controller accepts or rejects it.
- Never invent a result. If you could not run something, say so; "unverified"
  is an acceptable report and a false pass is not.
- 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: the helper checks the receiving window's landing record before it sends and refuses with `already-landed`, printing that landing, when the prompt is already there; record or report that landing instead of forcing a second send (`--force` is only for a prompt you have established never reached the window).
- Workspace and repository `CLAUDE.md` 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. 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. An
   evidence refusal's `path` points at the first citation it could not
   resolve, its `reason` says why (for example `evidence-digest-mismatch`), and
   `details.unresolvedCitations` counts them all. A
   `completed` outcome is accepted only when every acceptance anchor is tied to
   managed evidence the Controller recorded for this Demand; when none exists
   yet, import the report as `needs-review` - recording evidence is the
   Controller's step, not yours; Wakeflow refuses a `completed` import whose
   acceptance anchors are not all bound.
   A `needs-review` import is then a normal ending: the Controller records the
   evidence, verifies every anchor itself and accepts your report directly.
6. The import returns a wake-controller callback permit. Send its prompt to the
   Controller window the permit's host action names, by the host's own means:
   pipe the permit's prompt into the tmux helper, run from the workspace root: `node .wakeflow-local/runtime/hosts/claude-code/operations/assets/tmux.mjs deliver --window <windowId> --handle-digest <the permit's handleDigest>`. It checks the pane against the locator and the handle digest, refuses before sending with `target-not-at-prompt` when the pane shows a dialog or menu instead of its input box (nothing was sent: ask the user to answer it in that window, then send again - a target delivery recorded as `failed-before-send` is re-armed by the Controller, a callback is simply delivered again with the same permit; never send keys to that window yourself), pastes the prompt, presses Return once and captures the pane once, then waits a few seconds for the target session's prompt-submit hook record and prints the `attempt`, `readback` and `landing` to record verbatim. `readback: confirmed` only means the prompt's first line, or Claude Code's collapsed `[Pasted text #N +M lines]` indicator with the matching line count, was on screen; landing is proven by the hook record alone. From a product or surface window, prefix the helper path with the workspace root you were given with `--add-dir` instead of running from the root; the helper finds the workspace from its own location. That is the only transport for this send - not a
   cross-session messaging tool, not a file, not another window - because
   landing is proven by the hook record of a prompt submitted in that window.
   That send is the last thing you do for this target.

Then end your turn. Do not start the next task, do not poll for a reply, and
do not re-send a callback that has already landed.

## What you must return

The report is the deliverable, so write it for a reviewer who did not watch you
work: the outcome, the evidence, the per-anchor answers, the boundary you did
not cross, and the residual risk in one honest paragraph.

## Stop conditions

Stop and report a blocker, without changing code, when the package's goal
contradicts the repository's rules, when the assigned checkout is missing or
not the one described, when the work would require leaving the boundary, or
when a required piece of evidence cannot be produced.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.