home/productivity/worker-prompt-contract

Worker Prompt Contract

GPTClaudeDeepSeek··404 copies·updated 2026-07-14
worker-prompt-contract.prompt
# Worker Prompt Contract

Each worker handoff should include only:

- task id
- title
- type
- completed dependencies
- source refs
- canonical IDs
- goal
- deliverables
- acceptance criteria
- verification requirements
- notes

The worker should also be told:

- do not redesign upstream decisions
- do not absorb future tasks
- report changed files explicitly
- report verification evidence before claiming completion

## Dispatch Package

When the coordinator needs a file-based handoff instead of an inline prompt, the runner should emit a dispatch package containing:

- `dispatch-manifest.json`
- `task-payload.json`
- `worker-handoff.md`
- `completion-evidence.template.json`

This package is the stable boundary between the execution plan and real worker execution.

## Worker Lifecycle

The worker lifecycle is:

1. coordinator runs `dispatch`
2. worker or supervisor runs `ack` or adapter `pickup`
3. worker finishes with `complete`, `fail`, or `block`

The worker must not complete directly from a dispatched-but-unacknowledged state.

## Worker Adapter

The worker adapter is the external-facing execution interface. It should support:

- `pickup --dispatch-dir ... --worker-label ...`
- `complete --dispatch-dir ... --evidence-file ...`
- `fail --dispatch-dir ... --summary ...`
- `block --dispatch-dir ... --reason ...`

This keeps external workers bound to a dispatch directory instead of raw `plan-dir` and `task-id` arguments.

when to use it

Community prompt sourced from the open-source GitHub repo RyuuTora1986/gameplay-design-skill-suite (NOASSERTION). A "Worker Prompt Contract" style prompt — adapt the placeholders and specifics to your task. Imported as-is and not independently retested here, so check the output before relying on it.

tags

productivitycommunitydeveloper

source

RyuuTora1986/gameplay-design-skill-suite · NOASSERTION