# Agent Workflow Bundle — Delegate a bounded AI task > Self-contained build artifact generated from the canonical public Workflow and its referenced public assets. ## Agent instruction Use this bundle as the operating procedure for the user’s task. Execute the ordered steps end-to-end and apply each embedded asset where it appears. Do not merely summarize the workflow. Do not claim completion until the workflow’s success signal and embedded verification requirements have been checked. Everything required by the public workflow is embedded below; do not make the user manually provide the referenced Skill, Prompt, or Template files again. ## Workflow contract - source: workflows/delegate-bounded-ai-task - canonical human page: https://wbeen-personal-kb.vercel.app/workflows/#workflow-delegate-bounded-ai-task - lifecycle: stable - version: 1.0.0 - intended outcome: Another agent can execute the bounded task and the result can be reviewed against observable evidence. - success signal: The task has a bounded scope, an observable acceptance check, and a reviewable result. ### Known limitations - "This is an editorial route - not an agent execution service." - The prompt target is a retrieval asset; Prompt Hotbar still owns prompt copy and recommendation. ## Ordered execution ## Step 1 — clarify **Action:** Define the boundary and acceptance checks **Why now:** Make the task safe to hand off **Embedded asset:** skills/scope-acceptance-criteria — Scope & Acceptance Criteria Convert an intended outcome into explicit scope, exclusions, observable acceptance criteria, and a smallest safe next action. ### Inputs - Desired outcome - Known constraints and exclusions - Stakeholders or intended users - Available evidence and verification surfaces ### Outputs - In-scope behavior - Explicit non-goals - Observable acceptance criteria - Evidence plan and stop conditions ### Guardrails - Do not turn assumptions into acceptance criteria without labeling them. - Keep non-goals visible so scope cannot silently expand. - Prefer observable evidence over subjective completion language. - Stop when required authority or evidence is unavailable. ### Verification - Another person can tell what is in scope and what is not. - Each acceptance criterion has an observable check or explicit limitation. - The next action is small enough to execute without reopening the whole request. ### Source instructions ## What it does Scope & Acceptance Criteria turns an intention into a bounded, reviewable work packet. It makes the desired outcome, exclusions, evidence, and stop conditions explicit before implementation begins. ## When to reach for it Use it when a request can be interpreted in several ways, when more than one agent or person will touch the work, or when approval depends on evidence rather than a persuasive summary. ## What one run does 1. Restate the desired outcome in user-observable terms. 2. Separate committed scope from assumptions and follow-up ideas. 3. Name explicit non-goals and boundaries. 4. Write acceptance criteria that can be checked. 5. Identify evidence, dependencies, and a stop condition. ## Common failure modes - Writing implementation tasks before agreeing on the outcome. - Hiding out-of-scope work in vague acceptance language. - Using “looks good” as the only verification criterion. - Continuing after a missing dependency or authority should have stopped the work. ## It’s working if A different agent can execute or review the work packet without inventing missing scope, and every acceptance criterion points to an observable result. ## Where it fits This is a **Clarify**-phase skill. It follows source extraction or a handoff when needed and creates the boundary that Execute and Verify work can rely on. ## Step 2 — execute **Action:** Retrieve an invocation brief through the existing prompt asset layer **Why now:** Keep Prompt Hotbar in its retrieval role **Embedded asset:** prompts/agentic-handoff-brief — Agentic Handoff Brief Package the current state of a task so another agent (or a future you) can continue without re-deriving context. ### Input required - task context - current progress ### Output format structured markdown brief ### Safety notes - Strip credentials, internal URLs, and personal identifiers before handing off. ### Source instructions ## Purpose Work that spans multiple agents or sessions loses context at every boundary. A handoff brief makes the boundary explicit and cheap to cross. ## When to use Before ending a working session, or before delegating a task to another agent. ## Inputs - The task context and whatever progress exists so far. ## Prompt ```text You are writing an Agentic Handoff Brief. Summarize the current task so a different agent can continue without asking questions. Use exactly these sections: ## Goal ## Current state ## Constraints and decisions already made ## Next actions (ordered) ## Open questions Rules: 1. Be concrete: file paths, names, exact terms — no "as discussed". 2. Strip credentials, internal URLs, and personal identifiers. 3. Keep it under 300 words. ``` ## Expected output A markdown brief with the five sections above, under 300 words. ## Safety notes - Strip credentials, internal URLs, and personal identifiers before handing off. ## Related resources - Article: A Prompt Library Is Not Enough ## Step 3 — verify **Action:** Review the result against observable evidence **Why now:** Stop or escalate when evidence is missing **Embedded asset:** skills/evidence-first-review — Evidence-first Review Review AI-assisted work against observable evidence instead of accepting a plausible completion claim. ### Inputs - Claimed result or completion report - Acceptance criteria or intended outcome - Available evidence such as source files, tests, screenshots, logs, URLs, or system state ### Outputs - Verified claims - Unverified or failed claims - Evidence references - Residual risk and recommended next action ### Guardrails - Never upgrade an unobserved claim to verified. - Distinguish source evidence from inference. - Stop and report when required verification access is unavailable. ### Verification - Every approved claim points to observable evidence or an explicit check result. - Failed or unavailable checks remain visible in the final review. - The next action is clear without rereading the full work log. ### Source instructions ## What it does Evidence-first Review changes the review question from “does this sound finished?” to “what can I actually verify?” It is designed for AI-assisted work where confident completion language can arrive before the underlying state has been checked. ## When to reach for it Use it at a verification or approval boundary: after implementation, after a migration, before a release, or whenever an agent reports that a task is done. ## What one run does 1. Extract the material claims from the completion report. 2. Map each claim to an observable check. 3. Inspect the available evidence. 4. Mark each claim as verified, failed, or unresolved. 5. Report residual risk and the smallest next action. ## Common failure modes - Treating a successful command as proof of the entire user-visible outcome. - Repeating an agent’s own completion summary as evidence. - Hiding unavailable checks inside a generally positive verdict. - Expanding scope during review instead of separating follow-up work. ## It’s working if A reviewer can see exactly why a claim is accepted, what remains uncertain, and what should happen next without reconstructing the whole session. ## Where it fits This is a **Verify**-phase skill. It pairs naturally with a scoped implementation workflow. A public-safe publishing skill may become a downstream step once that capability is actually published. ## Workflow completion The workflow is successful when: The task has a bounded scope, an observable acceptance check, and a reviewable result. Report the task result, the evidence used to verify it, and any unresolved limitation. If a required verification step cannot be performed, say so instead of treating the workflow as complete.