TeaQL Agent Kit
A model-first coding harness that turns business intent into verified, typed application boundaries.
Per-dimension scores and reasoning
Evidence shows: README describes runtime governance including mandatory identity, intent auditing, capability sandbox, and graph mutability control, which reflect least privilege and external effects control. User confirmation is mentioned as asynchronous human review but not explicit confirmation for critical actions. Data flow transparency is partially addressed via inspectable model and evidence chain. Sensitive data handling, dependency security, and rollback are not mentioned. Source attribution references external repos but without version pinning. Deductions: no evidence for sensitive data handling, dependency security, rollback; user confirmation and data flow transparency are thin.
Evidence shows: README is internally consistent, describing a model-first, evaluate, generate, implement, verify workflow, so self-consistency is adequate. Dependency availability references external repos and online services but without version pinning or availability guarantees. Failure messages are mentioned as evaluation errors and repair guidance but no concrete examples. Deductions: dependency availability lacks version pinning; failure messages lack concrete examples.
Evidence shows: README clearly identifies target audience (developers and coding agents) and scenarios (model-driven software development), so audience and scenarios are well handled. Capability boundaries are described via runtime governance and generation service but not explicitly limited. Trigger precision is defined in SKILL.md with mandatory execution order but no specific trigger conditions. Environment fit mentions Java and Rust runtimes but no environment requirements. Deductions: capability boundaries, trigger precision, and environment fit are not detailed.
Evidence shows: README provides clear information architecture including skills, references, and examples. Install notes provide npx command. Naming stability references multiple repos but without version pinning. Examples and FAQ: multiple examples provided but no FAQ. Known limitations: Forge does not claim full parity, but not comprehensive. License is MIT, well handled. Versioning and changelog: not provided. Maintenance responsibility: security contact email provided but no explicit maintainer. Deductions: naming stability, known limitations, versioning, and maintenance responsibility are incomplete.
Evidence shows: Output usability is good with generated typed APIs and runnable examples. Marginal value claims a unique model-mediated approach but no comparative data. Cost benefit: no performance or cost data. Deductions: marginal value and cost benefit lack evidence.
Evidence shows: Claim traceability references external repos and online services but without version pinning. Cross-source corroboration references multiple external repos but no independent verification. Fact-inference separation distinguishes descriptions and inferences but not explicitly. Deductions: claim traceability, cross-source corroboration, and fact-inference separation are insufficient.
- This repository primarily contains documentation and prompts rather than executable code, so security and reliability assessments are based on static review without actual runtime testing.
- Dependencies on external services and repositories are not version-pinned, which may affect reproducibility and supply chain security.
- No mention of sensitive data handling, dependency security scanning, or rollback mechanisms; evaluate before use.
What does this agent do, and when should you use it?
TeaQL Agent Kit is a model-mediated workflow for agentic software development. It asks an agent to save business intent as a KSML domain model, evaluate that model deterministically, and repair reported issues before implementation begins. The TeaQL Generation Service can turn a validated model into Java or Rust typed domain libraries and separate editable application workspaces. The workflow also supplies model-aware assistance and treats compilation, tests, runtime checks, and audit results as completion evidence. It is best suited to teams prepared to adopt TeaQL's modeling, generation, and runtime-governance approach rather than a general-purpose coding assistant.
Its published Skill is named build-teaql-app. The workflow creates and saves a KSML XML model for business objects, fields, constants, relationships, modules, and storage; evaluates it; and uses the returned Errors, Warnings, Suggestions, and repair guidance to revise the model. After validation, the TeaQL Generation Service generates typed entities, relation metadata, queries, null-safe expressions, graph persistence, checker and behavior hooks, repository registration, documentation, and a Java or Rust application workspace. Application code works through the generated surface, such as Rust's Q::merchants() with purpose(), comment(), and execute_for_list(&ctx). The final stage verifies implementation with compilation, tests, runtime results, and policy checks.
- A Java team using domain-driven design that wants a reviewable domain model before regenerable typed application contracts are produced.
- A Rust team building data-heavy software that wants to use typed Q and E APIs for queries and relation-graph persistence.
- An engineering organization that requires coding agents to submit a saved KSML model, evaluate it, and regenerate when the domain contract changes.
- A business-data application that needs UserContext, query purpose and comments, and write audit descriptions to travel with execution.
- A team that wants human reviewers to inspect a model asynchronously while the agent continues generation, implementation, testing, and repair.
What are this agent's strengths and limitations?
- KSML is a saved, inspectable intermediate representation, providing a concrete review point between requirements and code.
- Deterministic model evaluation returns errors, warnings, suggestions, and current repair guidance instead of relying on an agent to retain a large rule catalog.
- Generated Java and Rust domain libraries are separated from editable application workspaces, allowing the model-derived contract to be regenerated.
- Runtime APIs carry identity, read purpose and comments, write audits, and explicitly granted external capabilities.
- Adoption requires teams to learn and maintain KSML models and to follow a model-before-implementation development sequence.
- The fullest documented output depends on the TeaQL Generation Service; the open-source teaql-forge-rs implementation is explicitly described as not claiming full feature parity.
- This repository publishes the Skill rather than runnable applications; Java and Rust examples live in separate repositories with independently evolving toolchains and releases.
- The supplied documentation does not describe offline or self-hosted deployment for the evaluator or Generation Service, nor does it specify authentication, pricing, or service guarantees.
How do you install or deploy this agent?
The documented installation command is: npx skills add teaql/teaql-agent-kit --skill build-teaql-app. It requires npx, network access, and a filesystem where models and generated workspaces can be saved. The documentation does not state whether an account, API key, or other credential is required.
How do you use this agent?
After installation, ask a coding agent with a prompt such as: Use $build-teaql-app to first draft and save a complete KSML model, then evaluate and repair it before generating a runnable TeaQL application: [your business requirement]. The prescribed order is to save a complete model, evaluate and repair it, generate the application, implement within the generated contract, verify the result, and report evidence. The Generation Service's /latest/ endpoint presents the current demo, and the documentation notes that it may evolve.
How does this agent compare with similar options?
Compared with a conventional “requirement → agent → code → test → repair” coding-agent loop, TeaQL inserts an inspectable KSML model, deterministic evaluation, and a generated typed contract before implementation. The trade-off is stronger process discipline and reliance on the TeaQL model-and-generation ecosystem.