mirror of
https://github.com/dtzp555-max/openclaw-agent-workflow.git
synced 2026-07-21 21:15:11 +00:00
feat: initial agent-workflow skill (v1.0.0)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Claude Sonnet 4.6
@@ -0,0 +1,143 @@
|
|||||||
|
# openclaw-agent-workflow
|
||||||
|
|
||||||
|
A lightweight JIRA-like workflow skill for OpenClaw agents. Prevents the three most common failure modes in multi-step agent tasks:
|
||||||
|
|
||||||
|
- **Silent disappearance** — agent stops responding with no explanation
|
||||||
|
- **Status opacity** — user has no idea what the agent is doing or how far along it is
|
||||||
|
- **Lost context on failure** — when something breaks, nobody knows what was tried or where it stopped
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## The Problem
|
||||||
|
|
||||||
|
When an OpenClaw agent handles a complex, multi-step task by dispatching sub-agents, things can go wrong silently:
|
||||||
|
|
||||||
|
```
|
||||||
|
User: "Migrate the database schema and update all dependent services"
|
||||||
|
Agent: "On it!"
|
||||||
|
...
|
||||||
|
[10 minutes of silence]
|
||||||
|
...
|
||||||
|
Agent: "Done!" ← Did it actually finish? Was anything skipped?
|
||||||
|
```
|
||||||
|
|
||||||
|
Or worse:
|
||||||
|
|
||||||
|
```
|
||||||
|
Agent: "On it!"
|
||||||
|
...
|
||||||
|
[silence forever]
|
||||||
|
...
|
||||||
|
User: "Hello?"
|
||||||
|
```
|
||||||
|
|
||||||
|
This skill solves that by giving agents a shared protocol for state transitions, progress reporting, and timeout handling.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## How It Works
|
||||||
|
|
||||||
|
Every task moves through defined states with evidence requirements:
|
||||||
|
|
||||||
|
```
|
||||||
|
planned → dispatching → in_progress → reviewing → done
|
||||||
|
↓
|
||||||
|
blocked → (resolved) → in_progress
|
||||||
|
```
|
||||||
|
|
||||||
|
Worker agents report back at key moments (`accepted`, `milestone`, `blocked`, `done`). If 10 minutes pass without a report, the main agent marks the task as `launch_failure` and alerts the user.
|
||||||
|
|
||||||
|
A live `CURRENT_STATE.md` file tracks all active, completed, blocked, and failed tasks.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Installation
|
||||||
|
|
||||||
|
Copy this skill into your OpenClaw project:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cp -r openclaw-agent-workflow/ ~/.openclaw/skills/
|
||||||
|
```
|
||||||
|
|
||||||
|
Or reference it directly in your agent's skill path. Then include it in your agent configuration:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"skills": ["openclaw-agent-workflow"]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
|
||||||
|
### Starting a tracked task
|
||||||
|
|
||||||
|
When the main agent receives a multi-step task, it should:
|
||||||
|
|
||||||
|
1. Create a task entry in `CURRENT_STATE.md` with state `planned`
|
||||||
|
2. Dispatch to a worker agent with the task ID
|
||||||
|
3. Wait for the worker's `accepted` report before proceeding
|
||||||
|
4. Forward `milestone` and `blocked` reports to the user
|
||||||
|
5. Verify the `done` report before marking the task complete
|
||||||
|
|
||||||
|
### Worker agent behavior
|
||||||
|
|
||||||
|
Workers follow the reporting protocol in `SKILL.md`. Every worker must:
|
||||||
|
|
||||||
|
- Send `accepted` within 10 minutes of receiving a task
|
||||||
|
- Send `milestone` after each significant step
|
||||||
|
- Send `blocked` immediately when stuck
|
||||||
|
- Send `done` with a full summary when finished
|
||||||
|
|
||||||
|
### Example interaction
|
||||||
|
|
||||||
|
```
|
||||||
|
User: Refactor the auth module and update all callers
|
||||||
|
|
||||||
|
[TASK T-001] Dispatched → worker agent
|
||||||
|
Plan:
|
||||||
|
- Audit current auth module
|
||||||
|
- Define new interface
|
||||||
|
- Rewrite module
|
||||||
|
- Update callers
|
||||||
|
- Run tests
|
||||||
|
|
||||||
|
[TASK T-001] Progress: Auth module audit complete (12 callers found)
|
||||||
|
Next: Defining new interface
|
||||||
|
|
||||||
|
[TASK T-001] Progress: New interface defined
|
||||||
|
Next: Rewriting module
|
||||||
|
|
||||||
|
[TASK T-001] BLOCKED
|
||||||
|
Reason: CallerX uses internal auth state not exposed by new interface
|
||||||
|
Tried: Checked all public methods, reviewed git history
|
||||||
|
Waiting on: Decision — expose the state or refactor CallerX separately
|
||||||
|
|
||||||
|
User: Refactor CallerX separately
|
||||||
|
|
||||||
|
[TASK T-001] Progress: Blocker resolved, resuming module rewrite
|
||||||
|
...
|
||||||
|
|
||||||
|
[TASK T-001] DONE
|
||||||
|
Summary: Auth module refactored, 12 callers updated, CallerX refactored separately
|
||||||
|
Artifacts: src/auth/index.ts, src/auth/interface.ts, tests/auth.test.ts (+11 files)
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Files
|
||||||
|
|
||||||
|
| File | Purpose |
|
||||||
|
|---|---|
|
||||||
|
| `SKILL.md` | Full protocol definition — states, evidence rules, timeouts, report formats |
|
||||||
|
| `openclaw.plugin.json` | Skill registration metadata |
|
||||||
|
| `CURRENT_STATE.md` | Live task state (auto-managed by agents, created on first use) |
|
||||||
|
| `examples/task-tracking-example.md` | Complete worked example |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## See Also
|
||||||
|
|
||||||
|
- `SKILL.md` — full protocol specification
|
||||||
|
- `examples/task-tracking-example.md` — end-to-end worked example with all report types
|
||||||
@@ -0,0 +1,185 @@
|
|||||||
|
# OpenClaw Agent Workflow Skill
|
||||||
|
|
||||||
|
This skill enforces a lightweight JIRA-like workflow for multi-step agent tasks, preventing silent failures and status opacity.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Workflow States
|
||||||
|
|
||||||
|
| State | Meaning |
|
||||||
|
|---|---|
|
||||||
|
| `planned` | Task defined, not yet dispatched |
|
||||||
|
| `dispatching` | Main agent sending task to worker agent |
|
||||||
|
| `in_progress` | Worker agent actively executing |
|
||||||
|
| `blocked` | Worker cannot proceed without external input |
|
||||||
|
| `reviewing` | Worker done, main agent verifying output |
|
||||||
|
| `done` | Task verified and complete |
|
||||||
|
|
||||||
|
### State Transition Rules
|
||||||
|
|
||||||
|
```
|
||||||
|
planned → dispatching : main agent sends task
|
||||||
|
dispatching → in_progress : worker sends "accepted" report
|
||||||
|
in_progress → blocked : worker hits unresolvable blocker
|
||||||
|
in_progress → reviewing : worker sends "done" report
|
||||||
|
blocked → in_progress : blocker resolved
|
||||||
|
reviewing → done : main agent verifies and closes
|
||||||
|
reviewing → in_progress : main agent rejects, worker resumes
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Evidence Rules
|
||||||
|
|
||||||
|
A state upgrade is only valid when the following evidence exists:
|
||||||
|
|
||||||
|
| Transition | Required Evidence |
|
||||||
|
|---|---|
|
||||||
|
| `dispatching → in_progress` | Worker emits `accepted` report with task echo |
|
||||||
|
| `in_progress → reviewing` | Worker emits `done` report with artifact reference or summary |
|
||||||
|
| `blocked → in_progress` | Blocker resolved message from worker or user |
|
||||||
|
| `reviewing → done` | Main agent confirms output matches success criteria |
|
||||||
|
|
||||||
|
**No state may be skipped.** A task cannot go from `in_progress` directly to `done` without a `reviewing` step.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Timeout Rules
|
||||||
|
|
||||||
|
| Condition | Action |
|
||||||
|
|---|---|
|
||||||
|
| Worker silent for **10 minutes** after dispatch | Mark state as `launch_failure`, report to user |
|
||||||
|
| Worker silent for **10 minutes** during `in_progress` | Escalate to `blocked`, report to user |
|
||||||
|
| Blocker unresolved for **30 minutes** | Report stale block to user, ask for guidance |
|
||||||
|
|
||||||
|
When a timeout fires, main agent must:
|
||||||
|
1. Update `CURRENT_STATE.md` with the timeout event
|
||||||
|
2. Notify the user with the last known state and elapsed time
|
||||||
|
3. Await user instruction before retrying or canceling
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Worker Agent Reporting Protocol
|
||||||
|
|
||||||
|
Worker agents MUST report back at these moments:
|
||||||
|
|
||||||
|
### 1. `accepted` — Task received and understood
|
||||||
|
```
|
||||||
|
REPORT accepted
|
||||||
|
task_id: <id>
|
||||||
|
echo: <one-line restatement of the task>
|
||||||
|
plan: <bullet list of planned steps>
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. `milestone` — Significant progress checkpoint
|
||||||
|
```
|
||||||
|
REPORT milestone
|
||||||
|
task_id: <id>
|
||||||
|
step_completed: <what just finished>
|
||||||
|
next_step: <what is starting now>
|
||||||
|
artifact: <file path or output reference, if any>
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. `blocked` — Cannot proceed
|
||||||
|
```
|
||||||
|
REPORT blocked
|
||||||
|
task_id: <id>
|
||||||
|
blocker: <clear description of what is blocking>
|
||||||
|
tried: <what was already attempted>
|
||||||
|
needs: <what is needed to unblock>
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4. `done` — Task complete
|
||||||
|
```
|
||||||
|
REPORT done
|
||||||
|
task_id: <id>
|
||||||
|
summary: <what was accomplished>
|
||||||
|
artifacts: <list of files created/modified>
|
||||||
|
success_criteria_met: true|false
|
||||||
|
notes: <any caveats or follow-up items>
|
||||||
|
```
|
||||||
|
|
||||||
|
Workers that do not send any report within 10 minutes of accepting a task are considered to have silently failed.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Main Agent User-Reporting Protocol
|
||||||
|
|
||||||
|
Main agent reports to the user at these moments:
|
||||||
|
|
||||||
|
### On dispatch
|
||||||
|
```
|
||||||
|
[TASK <id>] Dispatched → worker agent
|
||||||
|
Plan: <summary of steps>
|
||||||
|
```
|
||||||
|
|
||||||
|
### On milestone (forwarded from worker)
|
||||||
|
```
|
||||||
|
[TASK <id>] Progress: <step_completed>
|
||||||
|
Next: <next_step>
|
||||||
|
```
|
||||||
|
|
||||||
|
### On block
|
||||||
|
```
|
||||||
|
[TASK <id>] BLOCKED
|
||||||
|
Reason: <blocker>
|
||||||
|
Tried: <what was attempted>
|
||||||
|
Waiting on: <what is needed>
|
||||||
|
```
|
||||||
|
|
||||||
|
### On completion
|
||||||
|
```
|
||||||
|
[TASK <id>] DONE
|
||||||
|
Summary: <what was accomplished>
|
||||||
|
Artifacts: <list>
|
||||||
|
```
|
||||||
|
|
||||||
|
### On timeout / launch failure
|
||||||
|
```
|
||||||
|
[TASK <id>] TIMEOUT — no response for 10 minutes
|
||||||
|
Last state: <state>
|
||||||
|
Action needed: retry / cancel / investigate
|
||||||
|
```
|
||||||
|
|
||||||
|
Main agent should NOT silently proceed to the next task after a failure. Always surface the failure to the user.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## CURRENT_STATE.md Update Triggers
|
||||||
|
|
||||||
|
Main agent must update `CURRENT_STATE.md` whenever:
|
||||||
|
|
||||||
|
1. A new task is created (`planned`)
|
||||||
|
2. A task is dispatched (`dispatching`)
|
||||||
|
3. A worker report is received (any report type)
|
||||||
|
4. A timeout fires
|
||||||
|
5. A task reaches `done`
|
||||||
|
|
||||||
|
### CURRENT_STATE.md Format
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# Current Workflow State
|
||||||
|
Last updated: <ISO timestamp>
|
||||||
|
|
||||||
|
## Active Tasks
|
||||||
|
|
||||||
|
| ID | Title | State | Last Event | Owner |
|
||||||
|
|---|---|---|---|---|
|
||||||
|
| T-001 | <title> | in_progress | milestone: step 2/4 | worker-a |
|
||||||
|
|
||||||
|
## Completed Tasks (last 5)
|
||||||
|
|
||||||
|
| ID | Title | Completed At | Artifacts |
|
||||||
|
|---|---|---|---|
|
||||||
|
| T-000 | <title> | <timestamp> | <paths> |
|
||||||
|
|
||||||
|
## Blocked Tasks
|
||||||
|
|
||||||
|
| ID | Title | Blocker | Since |
|
||||||
|
|---|---|---|---|
|
||||||
|
|
||||||
|
## Failed / Timed Out Tasks
|
||||||
|
|
||||||
|
| ID | Title | Failure Reason | Since |
|
||||||
|
|---|---|---|---|
|
||||||
|
```
|
||||||
@@ -0,0 +1,276 @@
|
|||||||
|
# Task Tracking Example
|
||||||
|
|
||||||
|
A complete end-to-end walkthrough of the openclaw-agent-workflow protocol.
|
||||||
|
|
||||||
|
**Scenario:** User asks the main agent to add a new payments feature, which requires backend API work, database migration, and frontend integration.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step 1 — User Request
|
||||||
|
|
||||||
|
```
|
||||||
|
User: Add a Stripe payments integration. We need a backend API endpoint,
|
||||||
|
a database table for payment records, and a frontend checkout form.
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step 2 — Main Agent: Task Planning
|
||||||
|
|
||||||
|
Main agent creates the task and updates `CURRENT_STATE.md`:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# Current Workflow State
|
||||||
|
Last updated: 2026-03-19T10:00:00Z
|
||||||
|
|
||||||
|
## Active Tasks
|
||||||
|
|
||||||
|
| ID | Title | State | Last Event | Owner |
|
||||||
|
|-------|-----------------------------|------------|--------------------|--------|
|
||||||
|
| T-001 | Stripe payments integration | planned | created | main |
|
||||||
|
```
|
||||||
|
|
||||||
|
Main agent reports to user:
|
||||||
|
|
||||||
|
```
|
||||||
|
[TASK T-001] Dispatched → worker agent
|
||||||
|
Plan:
|
||||||
|
- Create payments database table (migration)
|
||||||
|
- Implement /api/payments POST endpoint
|
||||||
|
- Add Stripe SDK and webhook handler
|
||||||
|
- Build frontend checkout form component
|
||||||
|
- Write integration tests
|
||||||
|
```
|
||||||
|
|
||||||
|
State in `CURRENT_STATE.md` updated to `dispatching`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step 3 — Worker Agent: Accepted Report
|
||||||
|
|
||||||
|
Worker agent receives the task and immediately sends:
|
||||||
|
|
||||||
|
```
|
||||||
|
REPORT accepted
|
||||||
|
task_id: T-001
|
||||||
|
echo: Implement Stripe payments integration — DB migration, backend API, frontend form
|
||||||
|
plan:
|
||||||
|
- Run database migration to create payments table
|
||||||
|
- Install and configure stripe SDK
|
||||||
|
- Implement POST /api/payments endpoint
|
||||||
|
- Add Stripe webhook handler
|
||||||
|
- Build CheckoutForm React component
|
||||||
|
- Write integration tests
|
||||||
|
```
|
||||||
|
|
||||||
|
Main agent receives this, updates state to `in_progress`:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
| T-001 | Stripe payments integration | in_progress | accepted | worker-payments |
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step 4 — Worker Agent: First Milestone
|
||||||
|
|
||||||
|
Worker completes the database migration:
|
||||||
|
|
||||||
|
```
|
||||||
|
REPORT milestone
|
||||||
|
task_id: T-001
|
||||||
|
step_completed: Database migration created and applied — payments table live
|
||||||
|
next_step: Installing Stripe SDK and configuring API keys
|
||||||
|
artifact: db/migrations/20260319_create_payments.sql
|
||||||
|
```
|
||||||
|
|
||||||
|
Main agent forwards to user:
|
||||||
|
|
||||||
|
```
|
||||||
|
[TASK T-001] Progress: Database migration complete
|
||||||
|
Next: Stripe SDK setup
|
||||||
|
```
|
||||||
|
|
||||||
|
`CURRENT_STATE.md` updated:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
| T-001 | Stripe payments integration | in_progress | milestone: migration done | worker-payments |
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step 5 — Worker Agent: Blocked Report
|
||||||
|
|
||||||
|
Worker hits an issue with API key configuration:
|
||||||
|
|
||||||
|
```
|
||||||
|
REPORT blocked
|
||||||
|
task_id: T-001
|
||||||
|
blocker: Stripe API keys not present in environment. STRIPE_SECRET_KEY and
|
||||||
|
STRIPE_WEBHOOK_SECRET are missing from .env and CI secrets.
|
||||||
|
tried:
|
||||||
|
- Checked .env.example — keys not documented
|
||||||
|
- Checked CI config — no Stripe secrets configured
|
||||||
|
- Checked team docs wiki — no setup guide found
|
||||||
|
needs: Stripe API keys (test mode) added to .env and CI secrets
|
||||||
|
```
|
||||||
|
|
||||||
|
Main agent updates state to `blocked` and reports to user:
|
||||||
|
|
||||||
|
```
|
||||||
|
[TASK T-001] BLOCKED
|
||||||
|
Reason: Stripe API keys missing from environment
|
||||||
|
Tried: Checked .env, CI config, and team docs
|
||||||
|
Waiting on: STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET (test mode keys)
|
||||||
|
```
|
||||||
|
|
||||||
|
`CURRENT_STATE.md` updated:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Blocked Tasks
|
||||||
|
|
||||||
|
| ID | Title | Blocker | Since |
|
||||||
|
|-------|-----------------------------|--------------------------------|----------------------|
|
||||||
|
| T-001 | Stripe payments integration | Missing Stripe API keys in env | 2026-03-19T10:18:00Z |
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step 6 — User Resolves Blocker
|
||||||
|
|
||||||
|
```
|
||||||
|
User: I've added the Stripe test keys to .env and GitHub secrets.
|
||||||
|
STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET are set.
|
||||||
|
```
|
||||||
|
|
||||||
|
Main agent relays to worker. Worker resumes:
|
||||||
|
|
||||||
|
```
|
||||||
|
REPORT milestone
|
||||||
|
task_id: T-001
|
||||||
|
step_completed: Stripe SDK installed and configured — keys verified working
|
||||||
|
next_step: Implementing POST /api/payments endpoint
|
||||||
|
artifact: src/lib/stripe.ts
|
||||||
|
```
|
||||||
|
|
||||||
|
State returns to `in_progress`. `CURRENT_STATE.md` blocker row removed.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step 7 — Worker Agent: More Milestones
|
||||||
|
|
||||||
|
```
|
||||||
|
REPORT milestone
|
||||||
|
task_id: T-001
|
||||||
|
step_completed: POST /api/payments endpoint implemented with idempotency key support
|
||||||
|
next_step: Adding Stripe webhook handler
|
||||||
|
artifact: src/api/payments.ts
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
REPORT milestone
|
||||||
|
task_id: T-001
|
||||||
|
step_completed: Stripe webhook handler implemented and verified locally
|
||||||
|
next_step: Building CheckoutForm React component
|
||||||
|
artifact: src/api/webhooks/stripe.ts
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
REPORT milestone
|
||||||
|
task_id: T-001
|
||||||
|
step_completed: CheckoutForm component built with card element and error handling
|
||||||
|
next_step: Writing integration tests
|
||||||
|
artifact: src/components/CheckoutForm.tsx
|
||||||
|
```
|
||||||
|
|
||||||
|
Main agent forwards each to user with brief updates:
|
||||||
|
```
|
||||||
|
[TASK T-001] Progress: /api/payments endpoint done
|
||||||
|
[TASK T-001] Progress: Webhook handler done
|
||||||
|
[TASK T-001] Progress: CheckoutForm component done — writing tests
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step 8 — Worker Agent: Done Report
|
||||||
|
|
||||||
|
```
|
||||||
|
REPORT done
|
||||||
|
task_id: T-001
|
||||||
|
summary: Stripe payments integration complete. Backend API endpoint with idempotency,
|
||||||
|
webhook handler for payment confirmation events, database migration for
|
||||||
|
payment records, and CheckoutForm frontend component with error handling.
|
||||||
|
All integration tests passing.
|
||||||
|
artifacts:
|
||||||
|
- db/migrations/20260319_create_payments.sql
|
||||||
|
- src/lib/stripe.ts
|
||||||
|
- src/api/payments.ts
|
||||||
|
- src/api/webhooks/stripe.ts
|
||||||
|
- src/components/CheckoutForm.tsx
|
||||||
|
- tests/integration/payments.test.ts
|
||||||
|
success_criteria_met: true
|
||||||
|
notes: Webhook endpoint needs to be registered in Stripe dashboard before going to prod.
|
||||||
|
See src/api/webhooks/stripe.ts line 3 for the expected URL path.
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step 9 — Main Agent: Review
|
||||||
|
|
||||||
|
Main agent checks the artifacts, verifies tests pass, confirms success criteria:
|
||||||
|
|
||||||
|
- Database migration exists and applies cleanly
|
||||||
|
- API endpoint matches spec
|
||||||
|
- Webhook handler registered at correct path
|
||||||
|
- Frontend component renders and submits
|
||||||
|
- Tests all green
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step 10 — Main Agent: Report Done to User
|
||||||
|
|
||||||
|
```
|
||||||
|
[TASK T-001] DONE
|
||||||
|
Summary: Stripe payments integration complete — API, webhook, DB migration, checkout form
|
||||||
|
Artifacts:
|
||||||
|
- db/migrations/20260319_create_payments.sql
|
||||||
|
- src/api/payments.ts + webhook handler
|
||||||
|
- src/components/CheckoutForm.tsx
|
||||||
|
- Integration tests passing
|
||||||
|
|
||||||
|
Note: Register the webhook URL in your Stripe dashboard before deploying to prod.
|
||||||
|
Path: /api/webhooks/stripe
|
||||||
|
```
|
||||||
|
|
||||||
|
`CURRENT_STATE.md` final state:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# Current Workflow State
|
||||||
|
Last updated: 2026-03-19T11:05:00Z
|
||||||
|
|
||||||
|
## Active Tasks
|
||||||
|
(none)
|
||||||
|
|
||||||
|
## Completed Tasks (last 5)
|
||||||
|
|
||||||
|
| ID | Title | Completed At | Artifacts |
|
||||||
|
|-------|-----------------------------|----------------------|----------------------------------------|
|
||||||
|
| T-001 | Stripe payments integration | 2026-03-19T11:05:00Z | payments.sql, payments.ts, +4 files |
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Summary
|
||||||
|
|
||||||
|
This example demonstrates:
|
||||||
|
|
||||||
|
| Protocol Event | What Happened |
|
||||||
|
|---|---|
|
||||||
|
| Task created | Main agent created T-001, reported plan to user |
|
||||||
|
| `accepted` report | Worker echoed task back, state → `in_progress` |
|
||||||
|
| `milestone` reports | User saw progress at each step, never wondered "is it still running?" |
|
||||||
|
| `blocked` report | User was immediately informed of the blocker with full context |
|
||||||
|
| Blocker resolved | State returned to `in_progress` without user having to chase |
|
||||||
|
| `done` report | Full artifact list and caveats surfaced to user |
|
||||||
|
| Main agent review | State only moved to `done` after main agent verified the work |
|
||||||
|
|
||||||
|
No silent disappearances. No mystery. Every state change has evidence.
|
||||||
@@ -0,0 +1,27 @@
|
|||||||
|
{
|
||||||
|
"name": "openclaw-agent-workflow",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"description": "Lightweight JIRA-like workflow for multi-step agent tasks. Prevents silent failures and status opacity by enforcing state transitions, evidence rules, timeout handling, and structured reporting protocols.",
|
||||||
|
"skill_file": "SKILL.md",
|
||||||
|
"author": "OpenClaw",
|
||||||
|
"tags": ["workflow", "task-tracking", "agent-coordination", "multi-step", "reliability"],
|
||||||
|
"state_file": "CURRENT_STATE.md",
|
||||||
|
"states": [
|
||||||
|
"planned",
|
||||||
|
"dispatching",
|
||||||
|
"in_progress",
|
||||||
|
"blocked",
|
||||||
|
"reviewing",
|
||||||
|
"done",
|
||||||
|
"launch_failure"
|
||||||
|
],
|
||||||
|
"timeout_minutes": {
|
||||||
|
"dispatch_to_accepted": 10,
|
||||||
|
"in_progress_silence": 10,
|
||||||
|
"blocked_stale": 30
|
||||||
|
},
|
||||||
|
"report_types": ["accepted", "milestone", "blocked", "done"],
|
||||||
|
"examples": [
|
||||||
|
"examples/task-tracking-example.md"
|
||||||
|
]
|
||||||
|
}
|
||||||
Reference in New Issue
Block a user