OpenClaw Sprint System

This doc defines the minimum process OpenClaw needs to run real engineering work with low supervision and high traceability.

The principle is simple: autonomy comes from documentation quality, not vibes.

Sprint Packet Contract

Every active sprint should have one packet. The packet can be Markdown, but it must contain all of the following.

Required Header

Sprint ID
Sprint Name
Start Date
Owner
Reviewer Lead
Verifier Lead
Status

Required Body

Objective: one paragraph
In Scope: the work actually intended
Out of Scope: explicit non-goals
Linked Decisions / Proposals / Huddles
Autonomy Class: A0 to A4
Acceptance Criteria
Test and Verification Plan
Documentation Plan
Blockers and Dependencies
Task Cards
Exit Criteria

Task Card Contract

Every buildable task needs:

Task ID
Title
Owner
Reviewer
Status
Scope
Files or systems in scope
Acceptance criteria
Test expectation
Risks or boundary notes

If those fields do not exist, the task is not ready for autonomous execution.

Suggested Sprint Cadence

Use a short cadence. For OpenClaw, one-week sprints are a good default because the system is still changing quickly.

Recommended ceremony order:

Intake triage
Sprint planning
Design huddle if required by autonomy class
Build and review
Verification and release readiness
Retro

When A Huddle Is Required

Use a huddle before work starts when a task touches:

architecture
external interfaces
schema or storage contracts
auth or security
permissions or trust boundaries
governance process
organism layer mapping

Huddles are for readiness and design pressure-testing. They are not decrees.

Kanban Rules

Use one board with these states:

Intake
Ready
In Sprint
In Build
In Review
In Verify
Blocked
Done
Retro

State Semantics

Intake: raw idea or request
Ready: clear enough to schedule
In Sprint: committed to the current sprint
In Build: an agent is implementing
In Review: code or artifact review in progress
In Verify: tests, acceptance, or rollout checks in progress
Blocked: waiting on an external condition
Done: accepted and documented
Retro: lessons that should improve the next sprint

Definition Of Ready

A task is ready only if:

scope is bounded
owner and reviewer are assigned
autonomy class is known
acceptance criteria are written
dependencies are named

Definition Of Done

A task is done only if:

the implementation exists
review passed
verification evidence exists
docs were updated if needed
risks or follow-up items were recorded

Minimal Meeting Outputs

Intake Output

normalized title
one-sentence outcome
initial autonomy class guess
routing note

Sprint Planning Output

chosen scope
rejected scope
task owners
acceptance criteria
blocker list

Huddle Output

design options considered
preferred option
unresolved risks
escalation needs

Review Output

findings
acceptance or rejection
follow-up fixes if needed

Retro Output

what slowed agents down
what caused rework
what docs or skills must be improved

Recommended File Layout

Inside the OpenClaw workspace, keep the operating surfaces predictable:

OPENCLAW-ENGINEERING-OS.md
OPENCLAW-KANBAN.md
OPENCLAW-SPRINT-001.md
OPENCLAW-SPRINT-002.md
skills/sprint-delivery/SKILL.md

If you later add automation, it should update those files instead of inventing a second hidden process.

Default Trust Model

Use this rule:

builders may deliver within A1 and A2
reviewers and verifiers must be separate from the builder role
A3 requires huddle
A4 requires governance

That gives you speed without pretending every task is equally safe.

Metrics That Matter

Track:

cycle time from Ready to Done
review rejection rate
escaped regressions
percentage of tasks with complete sprint packet fields
documentation freshness
blocker age

Do not optimize for raw message count or sheer agent activity.

Why This Matters

Without a sprint system, OpenClaw becomes a stream of partially scoped requests and improvised agent behavior.

With a sprint system, it becomes a coding organization that can make local decisions quickly because the higher-order thinking was already written down.