The development assistant

Governance that installs into your project.

Every coding agent in your project follows its own rules, drifts its own way, and you find out in review. AIQT 1.1.0 puts one governance core where every agent actually reads, in the repository itself. One wizard sets it up, one doctor verifies it, and a write guard keeps every update inside a single directory you can inspect. 1.1.0 is next, in development; the pack it installs is open source and readable today.

(Accuracy = Integrity = Quality = Trust) > Progress > Speed > Cost
Read the pack on GitHub Technical details

In your project

What it does

The development assistant installs the same governance core that runs the chat assistant: the priority ordering above, the disciplines that apply it, and one universal skill. Then it generates the file each coding agent expects, so every agent that touches your project reads the same standard.

Root instructions file

The project-level instructions file your primary coding assistant loads on every session, generated from the governance core and your configuration.

Agents file

The agents file that agent-driven tools expect, carrying the same ordering and disciplines, so a subagent works under the same rules as the session that spawned it.

Editor rules

Rules files for editors that read them, so in-editor assistance answers to the same standard as the terminal.

One source, many surfaces

Each generated file derives from one core. Update the core, regenerate, and every agent surface moves together; no file drifts to its own private version of the rules.

The five rules

How the five rules operate while you work

A standard you cannot see being applied is a promise, not a standard. The five rules are how the assistant applies the ordering, change by change, in the 1.1.0 design, and each one produces something you can see in the console. They are scoped to issues the active work detects or causes, not to your whole backlog, so following them never turns one change into a cleanup crusade.

  1. The first rule of AIQT is: you talk about AIQT.

    When a guardrail catches something (it blocks, flags, or refuses an action), the assistant surfaces it in the console: which guardrail, and what it caught. Silent passes are not surfaced, so the console carries signal, not a firehose.

  2. The second rule of AIQT is: you talk about AIQT.

    The assistant reminds itself that it must always follow AIQT: a short "AIQT check" self-reminder, at least once per change, self-acknowledged, so that the standard was applied is itself something you can see.

  3. The third rule of AIQT is: fix issues.

    An issue detected or caused by the active work, and within the current change's scope, is fixed before that change merges.

  4. The fourth rule of AIQT is: fix other issues.

    An issue detected or caused by the active work but outside the current change's scope is fixed in the next change (the current change finishes first).

  5. The fifth and final rule of AIQT is: fix underlying issues, and share the fix.

    When the assistant caused the issue through a guardrail gap, it also creates or fixes a guardrail so it should not recur, additive to rules three and four: the instance is still fixed. Then, if your configuration permits and with your permission, the new guardrail can go back to the AIQT project as a seed PR, so every developer's assistant improves. Sharing is opt-in; the details are on the technical details page.

Self-learning

It self-learns: new guardrails, created as it goes

The fifth rule is where AIQT gets better on its own. When a gap lets an issue through, the assistant does not just fix the one instance; it writes a new guardrail so that shape of issue is caught from then on. Your setup self-learns: every gap it hits becomes a guard it keeps.

Everything it learns stays yours by default. A new guardrail is created and runs locally the moment the gap is found; sharing it back to every other developer is a separate, opt-in step, covered under seed PRs.

Setup

Setup and verification

Installing is a prompt, not a build. You give your coding assistant a short setup prompt; it fetches the pack from GitHub and walks you through the rest.

  1. Give your assistant the setup prompt. Paste the AIQT setup prompt into your coding assistant. It downloads the pack from the guardrails repository on GitHub, with no manual clone or install to run yourself.
  2. Follow the installation prompt. A wizard walks you through setup, creating .aiqt/ and the file each coding agent expects, and asking the few choices that are yours to make.
  3. The doctor verifies it. It confirms the install is present and consistent. This is the ordering applied to the tool itself: "installed" means a check actually ran, and the doctor is that check.

Go deeper

The mechanics, in full

Want the detail: the project-practice files AIQT sets up, the config file you own, how a new guardrail can travel back, the CI integration, and per-language depth? It is all on the technical details page.

Availability

The same core, and where 1.1.0 stands

Available now

The governance core, and the chat assistant

Everything 1.1.0 installs already exists as the pack: the ordering, the disciplines, and the universal skill. The chat assistant (1.0.0) runs this core today, so the standard your project will adopt is the one you can hold a chat assistant to right now, and the pack is open to read in full.

Next

The development assistant (1.1.0)

In development. The wizard, the doctor, the write guard, the generated agent files, the CI integration, the findings loop, the five-rule workflow, the per-guardrail configuration, and seed PRs described here and on the technical details page are the 1.1.0 design, and we ship it when it does what these pages say it does. Until then, the best way to evaluate AIQT is the way we would want you to: read the source.

AIQT is published under CC BY-SA 4.0, and improvements come back under the same licence. Rolling it out across an organization is covered on Teams & Enterprise.