What Gator can do

Gator does not replace your coding agent. It gives that agent a maintained understanding of the repository and a disciplined way to change it.

What Gator can do

Gator helps AI agents work with the context, discipline, and continuity of an experienced engineer—not only within one repository, but across a system of related repositories.

Figure 1 — every agent reads the same .gator/ layer before it changes code, and updates it as it works. Pre-commit checks keep the layer and the code in step.

Work with any capable coding agent. Gator is vendor-agnostic. Codex, Claude Code, Cursor, Gemini, and other agents can read the repository’s Gator guidance, learn the project’s conventions, and orient themselves before changing code.
Give agents durable project context. Charters, procedures, tripwires, decisions, and reference notes live in .gator/ inside the repository. Agents do not need to rediscover the system from raw source files at the start of every session.
Keep the map aligned with the code. Gator’s workflow requires agents to update the relevant charter when they change code. Pre-commit checks verify that code changes and their documented understanding stay together.
Make CLI work safer and more focused. When an agent works through tools such as Databricks, Snowflake, GCP, Azure DevOps, or a project-specific CLI, it can use the repository’s known procedures, risks, and tripwires. The result is more deliberate work and fewer context-free commands.
Create shareable technical explanations. Gator gives agents standard templates for HTML documents, reference notes, procedures, blueprints, and other repository-native artifacts. They can turn codebase understanding into clear material for colleagues, reviewers, and future agents.
Fit alongside your existing setup. Gator keeps its knowledge layer in .gator/. It does not take ownership of CLAUDE.md, AGENTS.md, GEMINI.md, or other harness-specific files. It is designed to compose with the tools and repository conventions a team already uses.
Grow with the team. Gator works well as a lightweight local workflow. When needed, its more advanced capabilities—such as Gator Loop for governed multi-agent work and Enterprise features for organization-scale evidence and oversight—are available without changing the core model.

A home for each system you operate

Gatorized repositories are not just code containers. They are durable homes for system knowledge.

Create a home for each system you operate. A Gatorized repository does not have to be an application source tree. It can be the operating home for a technical system or domain: Databricks administration, cloud infrastructure, data-platform operations, release engineering, security controls, or an internal developer platform.
Over time, its charters capture the parts that are usually scattered across people’s memory: how the system is structured, which CLI operations are safe, known failure modes, required approvals, environment-specific tripwires, and the procedures that work. An agent entering that repository can work from this accumulated operational understanding instead of treating every request as a fresh investigation.
Use charters to make a domain-scale monorepo navigable. A domain repository may contain scripts, configuration, procedures, runbooks, architecture notes, links to external systems, and operational decisions. Gator does not require it to be small or uniform. Charters give the agent a progressive map: start with the domain, narrow to the relevant area, then inspect the specific implementation or procedure.

Example: Databricks administration

A databricks_administration repository can become the durable operating manual for your Databricks estate. It holds the scripts, procedures, risks, conventions, and hard-won operational knowledge that normally live across terminals, tickets, and a few experienced people’s heads.

When an agent works in that repository, it does not begin as a generic Databricks assistant. It begins with your environment’s known constraints, safe procedures, and accumulated lessons.

The goal is not to give every agent access to every secret. It is to give it the right earned context: the map, the procedures, the tripwires, and the lessons that let an experienced operator work quickly without working blindly.

Across a system of repositories

A system does not always need a swarm to be understood. It needs durable context at every repository boundary.

Figure 2 — one agent moves between Gatorized repositories. Each repository carries its own map and evidence at its boundary.

Work across repositories with shared context. When related repositories are Gatorized, an agent can orient itself in each one using the same structured surfaces: charters, mission, roadmap, procedures, tripwires, and Git history. That gives it a practical system-level view for changes that cross service, application, infrastructure, data, or deployment boundaries.
Use one capable agent across the system. Many “agentic workflow” designs reach first for a controller agent and a fleet of specialized subagents. Gator supports a simpler default: one agent can move between Gatorized repositories while retaining a structured way to understand each boundary, identify dependencies, and record decisions. Use specialized agents when the work is genuinely parallel or needs independent review—not merely because the system spans multiple repositories.
Keep cross-repository decisions inspectable. The relevant understanding stays with each repository rather than being trapped in one orchestrator’s conversation or a central memory service. Each repo carries its own charters and evidence, while Gator’s fleet and Enterprise capabilities can provide broader visibility when needed.

The Dashboard and the vault

Figure 3 — work goes into the repository and through Git. The vault is an optional side folder for files that must never be committed. The Dashboard shows both, read-only.

Inspect, don’t edit

The agent changes the repository. The Dashboard helps the human understand and govern those changes.

Explore the repository through a read-only Dashboard. Gator Dashboard is a local, read-only view of the codebase and its knowledge layer. It lets you inspect charters, procedures, artifacts, threads, documentation, loop records, and repository structure without mixing review with editing.
Because the underlying repository is Git-backed, the Dashboard can show the current state as well as prior versions and history. You can ask: What did this charter say before the last change? When did this procedure appear? Which commit introduced this decision? The answer remains grounded in the repository’s own history.

The Dashboard is intentionally not an IDE or a second agent chat. It is the Architect’s inspection surface. Keep an agent session open in another window or tab to propose and make changes; use the Dashboard to understand the system, review the knowledge layer, inspect evidence, and decide what should happen next.

Keep sensitive files out of Git (optional)

Most work belongs in the repository, reviewed through Git. The vault is for the files that never should be committed.

Use the vault for material that must not be committed. Gator Vault (.gator/vault/) is an optional, repository-local folder for files that should never enter Git: CSV extracts, personal or other sensitive data, plans that are not ready to share, diagrams and documents that are not ready for publication, and large files such as PDFs and datasets.
Git ignores the vault, so its contents never reach a commit, a push, or the repository’s history. Unlike an arbitrary local folder, the vault sits beside the repository it belongs to and is visible in the Dashboard on your machine, so you can review it alongside the knowledge layer.

The vault is not the normal drafting path. Code, charters, procedures, and documentation are drafted and changed in the repository itself and reviewed through Git as usual. If something in the vault later becomes safe to share, rewrite it into the right shared surface—an artifact, procedure, thread, or reference note—and commit it deliberately.