Examples¶

These examples combine Kedi features into reviewable programs. Read the focused language pages first when you need a complete rule rather than a guided scenario.

Choose an Example¶

Runnable Conventions¶

Unless a page shows a directory tree, save its complete listing as program.kedi and run:

kedi program.kedi

The examples use groq:qwen/qwen3-32b to make backend selection explicit. Replace it with a model configured for your environment. Provider credentials are read by the selected adapter; never place API keys in a .kedi source file.

Syntax Used in Examples¶

• <value> substitutes an existing value into prompt or return text.
• <python_expression> evaluates Python and renders its result as text.
• [field: Type] in a >> block asks the model for a typed output.
• [name: Type] = expression performs a deterministic assignment.
• =python_expression`` returns the native Python value.
• [text] << prompt captures the raw model text; bare << is not an operator.

These distinctions matter. Use a typed output when a model must infer a value, Python when the answer is deterministic, and a native Python return when the caller should receive an object rather than its string representation.

Verification¶

Documentation CI parser-checks every kedi fence. Package manifests are parsed as package.kedi; a fence with a different required filename can declare file=..., and an intentionally non-parseable fragment must declare no-parse. This proves syntax and AST construction only. Imports, compilation, provider schemas, credentials, and adapter capabilities still require their documented file context and runtime tests against the production backend.