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. The AIQT development assistant puts one governance core where coding agents read their instructions, 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. The pack it installs is open source and readable today.
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 each supported agent surface, the root instructions file, the agents file, and the editor rules files, carries 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, and most of them produce something you can see in the console, while the self-check stays an internal discipline that never enters the visible answer. 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. The first two rules echo a famous pair on purpose: you talk about AIQT.
- Every catch is announced.
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.
- Each change gets an internal self-check.
At least once per change, the assistant runs a substantive self-check, recapping how it followed AIQT since the last one. It happens in the assistant's reasoning or thinking channel where the platform provides one, so it stays an internal discipline and never enters the visible answer or a produced deliverable.
- Issues in scope are fixed before the change ships.
An issue detected or caused by the active work, and within the current change's scope, is fixed before that change merges.
- Out-of-scope issues are surfaced, not silently acted on.
An issue detected or caused by the active work but outside the current change's scope is named plainly; the assistant asks before doing additional work rather than expanding scope on its own.
- Underlying gaps become guardrails, and the fix can be shared.
When the assistant caused the issue through a guardrail gap, it also proposes (and, if asked, drafts) a guardrail so it should not recur, additive to rules three and four: the instance itself is still handled under them. 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.
What comes next
Where it goes next: self-learning guardrails
The fifth rule is where AIQT is designed to get better on its own. When a gap lets an issue through, the assistant will fix it and write a new guardrail so that shape of issue is caught from then on. Your setup is designed to self-learn: every gap it hits becomes a guard it keeps. No model is retrained: a new guardrail is a local rule file, listed in your config, and yours to disable or delete.
Everything it learns is designed to stay yours by default. A new guardrail will be created and run 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.
- 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.
- 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. - The doctor verifies it. It confirms that the install is present and consistent. That is what the doctor proves: the files exist, agree with each other, and are current. It does not prove that a given agent loaded them in a given session; the running evidence for that is the named catches you see while you work. 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 are all on the technical details page.
Availability
The same core, and where 1.1.0 stands
The governance core, and the chat assistant
The standard 1.1.0 will install already exists and is readable in full, the pack on GitHub: the ordering, the disciplines, and the universal skill. The chat assistant (1.0.5) 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.
The development assistant (1.1.0)
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.
Contributing an improvement back is Rule 5's voluntary Guardrail-Seed give-back, separate from the software licence. Rolling it out across an organization is covered on Teams & Enterprise.