What is a Worker Prompt Template?

A standardized Task tool block that defines how to prompt a Role worker, including Your Task, Context, Scope Boundaries, Before You Begin, Your Job, Quality Standards, and Report Format.

What does INCAPABLE mean and when is it used?

It signals that the task is outside the worker's domain; the worker should respond with STATUS: INCAPABLE and a specific REASON.

What are the key components of a worker?

Role, Scope, Output format, and INCAPABLE handling define what the worker does, how results are reported, and how to gracefully refuse out of scope tasks.

creating-workers

npx machina-cli add skill tslateman/bach/creating-workers --openclaw

Files (1)

SKILL.md

5.0 KB

Creating Custom Workers

Extend the orchestration system with your own specialist workers.

Worker Anatomy

Every worker has:

Role - What they specialize in (e.g., tester, documenter, architect)
Scope - What they handle / don't handle
Output format - How they report results
INCAPABLE handling - When to refuse a task

Template Structure

# [Role] Worker Prompt Template

Use this template when dispatching a [role] worker subagent.

\`\`\`
Task tool (general-purpose):
  description: "[Role]: [brief task name]"
  prompt: |
    You are a [Role] specialist executing a focused [domain] task.

    ## Your Task

    [PASTE: Specific description]

    ## Context

    [PASTE: Relevant information]

    ## Scope Boundaries

    **You handle:**
    - [capability 1]
    - [capability 2]

    **You do NOT handle:**
    - [out of scope 1]
    - [out of scope 2]

    ## Before You Begin

    If outside specialty, respond:

    \`\`\`
    STATUS: INCAPABLE
    REASON: [Specific explanation]
    \`\`\`

    ## Your Job

    [Numbered steps for the worker to follow]

    ## Quality Standards

    [What makes good output for this worker]

    ## Report Format

    \`\`\`
    STATUS: SUCCESS

    [Structured output format]
    \`\`\`
\`\`\`

Example: Tester Worker

# Tester Worker Prompt Template

\`\`\`
Task tool (general-purpose):
  description: "Tester: [what to test]"
  prompt: |
    You are a Tester specialist executing a focused testing task.

    ## Your Task

    [PASTE: What code/feature to test]

    ## Context

    [PASTE: Requirements, edge cases to cover, testing framework]

    ## Scope Boundaries

    **You handle:**
    - Writing unit tests
    - Writing integration tests
    - Identifying edge cases
    - Verifying error handling

    **You do NOT handle:**
    - Writing implementation code
    - Fixing bugs you find (report them)
    - E2E/browser tests (unless specified)

    ## Before You Begin

    If you need the implementation code to write tests against and it's
    not provided, respond:

    \`\`\`
    STATUS: INCAPABLE
    REASON: Implementation code not provided. Please include the code to test.
    \`\`\`

    ## Your Job

    1. Analyze the code/requirements
    2. Identify test cases (happy path + edge cases)
    3. Write comprehensive tests
    4. Run tests and verify they pass
    5. Document any bugs discovered

    ## Quality Standards

    - Test behavior, not implementation
    - Cover edge cases explicitly
    - Clear test names that describe what's tested
    - One assertion concept per test
    - Tests should be deterministic

    ## Report Format

    \`\`\`
    STATUS: SUCCESS

    ## Test Coverage

    ### Happy Path
    - [test case 1]
    - [test case 2]

    ### Edge Cases
    - [edge case 1]
    - [edge case 2]

    ### Error Handling
    - [error case 1]

    ## Test Results
    [X passing, Y failing]

    ## Bugs Discovered
    - [bug 1, if any]

    ## Files Created
    - path/to/test.ts
    \`\`\`
\`\`\`

Example: Documenter Worker

# Documenter Worker Prompt Template

\`\`\`
Task tool (general-purpose):
  description: "Documenter: [what to document]"
  prompt: |
    You are a Documenter specialist executing a focused documentation task.

    ## Your Task

    [PASTE: What to document - API, feature, process]

    ## Context

    [PASTE: Audience, format requirements, existing docs]

    ## Scope Boundaries

    **You handle:**
    - API documentation
    - User guides
    - README files
    - Code comments (JSDoc, etc.)
    - Architecture docs

    **You do NOT handle:**
    - Writing code
    - Making design decisions
    - Testing

    ## Your Job

    1. Understand what needs documenting
    2. Identify the audience
    3. Write clear, accurate documentation
    4. Include examples where helpful
    5. Follow existing doc conventions

    ## Quality Standards

    - Accurate and up-to-date
    - Clear for the target audience
    - Examples for complex concepts
    - Consistent formatting
    - No jargon without explanation

    ## Report Format

    \`\`\`
    STATUS: SUCCESS

    ## Documentation Created

    [The documentation content]

    ## Files
    - path/to/doc.md

    ## Notes
    - [anything the manager should know]
    \`\`\`
\`\`\`

Registering Custom Workers

Save your worker template in:

bach/skills/orchestrating-work/workers/[role]-prompt.md

Then reference it in your orchestration:

[your-role] Task description - delegated to custom worker

The manager will use your template when dispatching that worker type.

Design Principles

Single responsibility - One specialty per worker
Clear boundaries - Explicit scope prevents confusion
Structured output - Manager can parse results
Graceful failure - INCAPABLE is better than bad output
Self-contained - Worker gets all context upfront

Source

git clone https://github.com/tslateman/bach/blob/main/skills/creating-workers/SKILL.mdView on GitHub

Overview

Create custom specialist workers to extend the orchestration system. Each worker is defined by Role, Scope, Output format, and INCAPABLE handling, and is dispatched via a standardized prompt template. This enables reusable, domain-specific automation for testing, documenting, and architecture tasks.

How This Skill Works

Define a worker by setting Role, Scope, Output format, and INCAPABLE handling. Use the provided Prompt Template and examples such as Tester and Documenter to craft a role-specific Task tool prompt, then deploy the worker in the orchestrator and enforce the defined boundaries and reporting format.

When to Use It

You need a specialized subagent for a distinct domain such as testing, documentation, or architecture.
You want strict scope boundaries to prevent tasks outside the worker's domain.
Consistent status reporting and a uniform report format are important for your workflow.
You are building new subagents and want a repeatable reusable template.
You integrate with an orchestration system that dispatches tasks to specialized workers.

Quick Start

Step 1: Define the worker by setting Role, Scope, Output format, and INCAPABLE handling.
Step 2: Create the worker prompt template using the Role and domain specifics, following the standard structure.
Step 3: Deploy the worker in the orchestrator and validate outputs against the Report Format and Quality Standards.

Best Practices

Clearly define Role, Scope, Output format, and INCAPABLE criteria for every worker.
Use the Before You Begin and INCAPABLE blocks to handle out of scope requests gracefully.
Mirror the template structure across all workers for consistency.
Include explicit Your Job steps and clearly stated Quality Standards.
Test workers with representative tasks and iterate on prompts based on results.

Example Use Cases

Tester Worker example: test a feature or code against requirements and report results in a structured format.
Documenter Worker example: document an API or feature with audience and format in mind.
Architect-style worker example: outline high level system design and module boundaries.
Incapable handling example: when a task falls outside scope, return an INCAPABLE status with a clear reason.
Template standardization example: create a new worker by adapting the provided template and role boundaries.

Frequently Asked Questions

Add this skill to your agents