Start from an Example

One prompt is enough to start. Paste the prompt below into a coding agent; it will guide modeling, evaluation, generation, and verification. First-run setup may still install the Agent Kit Skill, TeaQL client, language toolchain, or project dependencies. The agent must list proposed installations and network or elevated-permission commands before running them and wait for your approval.

The most direct first evaluation is to give an AI coding agent one small domain and require it to prove the complete model-to-build loop.

This path uses the TeaQL Agent Kit because the exact generation and build commands depend on the selected stack, client version, and generated workspace. The agent must inspect those inputs; it must not guess commands or generated method names.

Expected Outcome

At the end of this exercise you should have:

• a reviewed TeaQL semantic model;
• generated source or a generated workspace;
• a successful build or test result;
• one generated entity and Q request API confirmed through model-aware Assist;
• a record of the commands used;
• no manual edits inside generated output.

Before selecting an example, check the Examples and Evidence Index. It distinguishes current executable fixtures from Model Explorer illustrations and historical reports whose TeaQL/client versions are no longer current.

Completion time depends on whether the selected language toolchain and TeaQL client are already installed. Treat the first run as an evaluation with evidence, not as a timed demonstration.

Before You Start

You need:

• a coding agent that can inspect files and run local commands;
• Git;
• permission to review and approve installation of any missing tools and dependencies;
• network access for the Agent Kit, TeaQL service, package downloads, and source repositories.

The built-in TeaQL client credentials are sufficient for the standard workflow; do not stop to search for an additional API key.

Give the Agent a Bounded Task

This example uses Rust and SQLite. Change only the language in the second line if you want a different runtime; the agent should consult the live target catalog and generated workspace rather than translate method names by guess.

Follow the current instructions from https://github.com/teaql/teaql-agent-kit.
Use Rust and SQLite to build a small school management application with a
Platform, School, and School Type (Primary and Secondary).
Model first, evaluate and repair the model, generate the library and runnable
workspace, then build, test, and run one bounded query and one audited save.
Use model-aware Assist for generated APIs; do not read generated library source
for API discovery. Report exact commands, versions, results, and unresolved gaps.
Before installing tools or dependencies, show me what will be installed and
which commands need network access or elevated permissions; wait for my approval.

The same prompt can be adapted to Java, TypeScript, Go, Python, .NET, or Swift. One prompt starts the process, while model review and installation approval remain explicit human checkpoints.

Review the Model Gate

Do not approve generation until the model demonstrates:

• business names rather than table-oriented names;
• an explicit relationship between the platform and schools;
• a concrete representation for the school type values;
• no empty attributes;
• no unnecessary nested references;
• a clear root and ownership choice where the model requires one.

For a serious project, read the complete project modeling rules before approving structural decisions. The quick example is intentionally small; it is not a template for every tenancy or aggregate design.

Require Evaluation Before Generation

The Rust client exposes this workflow through commands such as:

cargo teaql --help
cargo teaql services
cargo teaql evaluate --input model/main.xml

Generate Rust targets explicitly rather than using a generic generate word. Confirm the current target names with cargo teaql services:

cargo teaql rust-lib-core --input model/main.xml --output generated/rust-lib-core
cargo teaql rust-app-console --input model/main.xml --output generated/rust-app-console

Keep these output directories as siblings: the current console manifest refers to ../rust-lib-core/lib.

A Maven-based Java project that already declares the TeaQL plugin can inspect it with:

mvn teaql:help

For standalone inspection of the locally verified plugin version, use the full coordinate:

mvn io.teaql:teaql-maven-plugin:1.1.1:help -Ddetail=true
mvn io.teaql:teaql-maven-plugin:1.1.1:list-services

Use the installed client's output as the authority for supported flags and goals. TeaQL Maven plugin 1.1.1 evaluates with eval and generates through a single dynamic goal:

mvn io.teaql:teaql-maven-plugin:1.1.1:eval -Dinput=model
mvn io.teaql:teaql-maven-plugin:1.1.1:generate \
  -Dservice=java-app-console \
  -Dinput=model

Select service from the current list-services output. If evaluation or generation produces a Markdown validation report, read it before making any fix, then correct the model or configuration and rerun the same goal.

Inspect the Generated Boundary

After generation, ask the agent to classify files into three groups:

Group	Expected treatment
Model and generator configuration	Source inputs; edit these to change generated contracts.
Generated source or workspace	Derived output; review manifests and build results, but do not read library source for API discovery or patch it by hand.
Application and extension code	Handwritten behavior that uses documented generated APIs and extension points.

The exact directories vary by generator and workspace version. Record the paths produced by the current run instead of copying directory assumptions from an older example.

Verify the Build

Use the wrapper or build command included in the generated workspace. A report that files were generated is not sufficient.

Capture:

• the command and working directory;
• the client, runtime, and toolchain versions visible in the workspace;
• the successful build or test result;
• the generated application path;
• the focused Assist calls used to obtain exact query method names.

If compilation fails because a method does not exist, request focused Assist for that entity, action, and field; report MISSING_ASSIST if it is insufficient. Do not add the guessed method to a generated file.

Run or Prepare the First Query

The application should use the generated API and declare query intent. Request entity-level query Assist, then field-level Assist only for fields actually used. Bound the query and supply non-empty comment and purpose before execution with trusted context. Do not assume a pluralized method name from the model or from this example.

Completion Checklist

• The model was reviewed before generation.
• Evaluation passed, or every reported violation was resolved in the model or configuration.
• Generation used commands supported by the installed client.
• The generated workspace built or passed its relevant tests.
• The generated application path and dependency manifest were recorded.
• Exact generated method names came from current Assist, not guesses or source searches.
• No generated source was manually patched.
• Query examples include both operation comment and business purpose.
• The command log and verification evidence are available for review.

Continue the Evaluation

Make one small field change and follow Regenerate and Review. If any stage fails, use Troubleshoot First Run.