Skip to main content
Kiwi workflows are validated ordered definitions. They describe what each step requires and how Kiwi accepts its report; they do not launch workers, call a referenced skill, or route work automatically.

​
Default Development workflow

The bundled Development definition defines this sequence:
  1. Plan
  2. Implement
  3. Verify
  4. Independent review
  5. Human acceptance
  6. Handoff
Use the file as the starting point for a project. A published revision is immutable. A run pins the chosen workflow ID and revision; later publications do not alter its contract.

​
Definition contract

The root object uses schema_version 1, a nonempty workflow_id and name, a positive input revision, topology “ordered”, an inputs list drawn from request_text and request_reference, input_rule “at-least-one-request-input”, steps, rework, and terminal_outcome. Each step declares a unique id, name, depends_on, allowed_actor_kinds, eligible_roles, instructions, skill_ref, required_outputs, acceptance, and candidate_bound. skill_ref is required and must be either null or a nonempty string. It is a reference in the workflow; Kiwi does not invoke the skill. depends_on must list exactly the preceding step, so branching and cycles are rejected. An output may set a nonnegative integer minimum_items. The submitted list must meet that minimum. Required outputs must be present and nonempty where applicable; undeclared output fields are rejected.

​
Supported acceptance modes

The Development contract requires a Plan step with scope, acceptance_criteria, and at least one required check; a preceding accepted Plan; a candidate-producing Implement with candidate_ref, summary, and handoff_notes; and exactly one candidate-bound required-check gate. Independent review requires candidate_ref, verdict, and findings. Human acceptance requires candidate_ref and qa_notes. Final Handoff requires candidate_ref, delivery_ref, and summary. Check the bundled definition for exact actor, role, and output declarations.

​
Plan check assignment

Plan output names are snake_case. Fields inside each check definition are camelCase:
For a checker report, set permittedOrigins to checker_reported, use the credential’s actual nonsecret reporterId in authorizedReporterIds, and include this check ID in allowed_check_ids when the Admin issues the credential. The credential record id is a different value. A human QA reporter needs an eligible project Admin or Reviewer role and must also be listed in authorizedReporterIds. This schema has no separate QA-assignee field.

​
Publish and version

Use the project’s Workflows area to import or edit a definition and publish it. Kiwi validates the definition and stores a new immutable server-assigned revision. The revision number in the imported JSON does not choose or overwrite the next published revision. Plan approval establishes the active check definitions. Check results bind to the accepted Plan revision, current implementation attempt, Verify attempt, and candidate. Rework preserves prior attempts as history while invalidating affected candidate-dependent evidence. See Runs and history and Retries and recovery.