V16 / BUNDLED SCENARIO

Plan a project as a persistent Kanban workflow

Plan a project as a persistent Kanban workflow: 2 ordered steps in Lilith V16, using kanban_prepare_operation. Read the exact bundled XML and its input and exit contracts.

V16Pinned source · 6df58cd3ed86Exit: copy

Use this scenario

Run

Run kanban_project scenario.

Use run_scenario with the saved scenario name and string-valued inputs. Required values are requested before execution.

View invocation JSON
JSON
{
  "scenario_name": "kanban_project",
  "inputs": {
    "name": "your name",
    "kind": "your kind",
    "prd": "your prd",
    "repair_limit": "25"
  }
}
SCENARIO BLUEPRINT

Read the workflow.

kanban_project4 INPUTS / 1 TOOLS / 2 STEPS
01

Inputs

PARAMETERS
InputRequirementDefault value
nameRequiredNo default
kindRequiredNo default
prdRequiredNo default
repair_limitOptional25
02

Agent instructions

SYSTEM PROMPT

Use the approved-scope PRD to delegate architecture to fresh saved subagents. Host code turns the validated component contracts into detailed dependent cards and enforces plan approval, sequential work, repair bounds and separate execution/publication decisions. Never claim tests or publication from a plan receipt. A changed scope requires a new plan and host decision.

03

Tool access

CAPABILITIES
04

Ordered steps

EXECUTION
  1. 01
    NESTED SCENARIO / FRESH CHILD

    project_design ↗

    • name = {{name}}
    • kind = {{kind}}
    • prd = {{prd}}

    Save output as design.

  2. 02
    BOUND OPERATION / HOST EXECUTED

    kanban_prepare_operation

    • name = {{name}}
    • kind = {{kind}}
    • prd = {{prd}}
    • architecture = {{design.architecture}}
    • repair_limit = {{repair_limit}}

    Save output as board.

05

Return to main

COPY EXIT

Return the real board receipt and next host decision unchanged.

The final text returns without model rewriting. Bound operation scenarios return application results; pending changes still require host approval.

EVERY XML ELEMENT / IN FILE ORDER

Every part, briefly.

Short explanations of every element and chat step in this scenario.

  1. 01
    <scenario>

    Names and versions the workflow.

    Writing example ↗
  2. 02
    <inputs>

    Declares input values.

    Writing example ↗
  3. 03
    <input>name

    Requires a supplied value.

    Writing example ↗
  4. 04
    <input>kind

    Requires a supplied value.

    Writing example ↗
  5. 05
    <input>prd

    Requires a supplied value.

    Writing example ↗
  6. 06
    <input>repair_limit

    Provides an optional value.

    Writing example ↗
  7. 07
    <systemPrompt>

    Sets the child's instructions.

    Writing example ↗
  8. 08
    <tools>

    Defines available capabilities.

    Writing example ↗
  9. 09
    <allow>kanban_prepare_operation

    Grants an existing tool.

    Writing example ↗
  10. 10
    <steps>

    Orders the chat turns.

    Writing example ↗
  11. 11
    <run>

    Invokes a fresh saved child scenario.

    Writing example ↗
  12. 12
    <input>name

    Binds a named operation or child input.

    Writing example ↗
  13. 13
    <input>kind

    Binds a named operation or child input.

    Writing example ↗
  14. 14
    <input>prd

    Binds a named operation or child input.

    Writing example ↗
  15. 15
    <tool>kanban_prepare_operation

    Executes a declared host operation.

    Writing example ↗
  16. 16
    <input>name

    Binds a named operation or child input.

    Writing example ↗
  17. 17
    <input>kind

    Binds a named operation or child input.

    Writing example ↗
  18. 18
    <input>prd

    Binds a named operation or child input.

    Writing example ↗
  19. 19
    <input>architecture

    Binds a named operation or child input.

    Writing example ↗
  20. 20
    <input>repair_limit

    Binds a named operation or child input.

    Writing example ↗
  21. 21
    <exit>

    Returns the output unchanged.

    Writing example ↗