AI-KIT: An Open-Source Starter Kit for AI Coding Agents and Persistent Project Context

AI coding agents are most useful when they understand the codebase in front of them—not only the last prompt in a chat window. That is the problem AI-KIT is built to solve. It is an open-source, offline starter kit that installs durable project context, stack-aware engineering guidance, client-specific configuration, and reviewable workflows into an application repository. Rather than asking developers to re-explain architecture, conventions, test commands, and permission boundaries every time they open a new assistant session, AI-KIT gives those details a structured home. 1

The project targets a familiar modern development reality: one team may move between Codex, Claude Code, Cursor, GitHub Copilot, Gemini CLI, Aider, and other AI coding tools while working across several languages and services. A useful AI development workflow cannot depend on one client remembering everything forever. It needs portable instructions, verified facts, and an explicit way to keep the human team in control.

AI-KIT packages that approach into a preview-first installer and a set of reusable project documents. The result is not another hosted chat interface or a black-box agent platform. It is a practical AI coding agent toolkit that developers can review, install, version with their projects when appropriate, and adapt to the tools they actually use. The repository is MIT licensed and currently documents a Python 3.10+ implementation with no installer dependencies. 1

The real bottleneck in AI-assisted development is context, not prompts

Most developers have felt the reset problem. An AI assistant can produce a convincing answer in a fresh conversation, yet it may not know the module boundaries, local conventions, environment constraints, risky commands, or the test suite that determines whether the answer is actually correct. That gap often leads to repetitive prompt engineering, overconfident changes, and small regressions that a human must unwind.

AI-KIT treats project knowledge as engineering material. It installs a concise PROJECT_CONTEXT.md for verified facts, module maps, runnable commands, contracts, and open questions. It also provides documents for decisions, changelog entries, a project wiki, and agent skills. The intended workflow is straightforward: gather facts from the repository, bootstrap them with evidence, use them during work, then synchronize important changes after the task is complete. 1

That distinction matters. A large unstructured prompt can become stale quickly. AI-KIT instead encourages a living reference layer that is small enough to inspect, specific enough to guide a coding agent, and explicit about what is still unknown. New conversations can start from the same project reality instead of an improvised summary of the previous chat.

For teams that use AI coding agents across more than one repository, this creates a more repeatable operating model. The agent has a place to learn which checks are relevant, which architectural decisions are already settled, which parts of the codebase are sensitive, and where a human approval is required.

What AI-KIT is—and what it deliberately is not

At its core, AI-KIT is an offline instruction and installer distribution. It copies project instructions, reusable skills, and optional client configuration into an existing application project. It can inspect local manifests to draft context, but the bootstrap workflow is designed to verify those drafts against the repository and runnable checks. 2

That scope is intentionally different from a hosted autonomous coding service. AI-KIT does not ship a live model provider adapter, silently call an LLM, deploy an application, or turn a recommendation into an unverified model switch. Its routing helper works offline and provides a reasoned recommendation; whether a specific model is active remains something the developer confirms in the selected client. 3

This is a sensible design choice for engineering teams that value control. It keeps credentials, model selection, client activation, and external integrations in their own explicit workflows. It also means the toolkit can sit alongside existing tools instead of forcing a new vendor runtime into the development environment.

Persistent project memory for AI coding assistants

The central promise of AI-KIT is simple: stop re-explaining the project to every new AI chat. The kit’s project memory model covers more than a generic repository summary. It is designed to record verified purpose, module facts, real commands, architectural decisions, and unresolved questions.

For example, an AI agent working in a mixed monorepo may need to know that a Go service lives in api/, a Laravel application lives in web/, and each module has different test commands and safety constraints. AI-KIT supports module-specific facts and path-scoped guidance, so the assistant can load the relevant rules instead of treating every directory as the same stack. 1

The kit also makes continuity an explicit responsibility. Its documented engineering loop is plan → implement → test → review → document, with bootstrap, review, and context-sync workflows available as named skills. That gives AI-assisted development a lifecycle that is easier to review than a loose sequence of chat prompts. 1

The benefit is not merely better recall. Good context creates a clearer handoff between people and tools. A developer can see what the agent was told, challenge an assumption, update a decision record, and start the next session with less hidden state.

Stack-aware rules, without turning every repository into a template

Generic instructions are rarely enough for production code. A Laravel change may require authorization policies, bounded transactions, after-commit jobs, and migration caution. A Go service may require context propagation, timeout handling, error wrapping, and race detection. A Rust library, a .NET service, a Java build, or a Terraform module each carry different correctness and release concerns.

AI-KIT includes documented profiles for Go, PHP, Laravel, Filament 5, Moodle, Python, Rust, .NET, Java, Terraform/Helm, frontend projects, and libraries or SDKs. Its installer can detect supporting evidence from manifests and configuration files, then draft relevant module context for later confirmation. 1

The important word is relevant. In a multi-stack codebase, not every rule should be injected into every task. AI-KIT’s guidance is intended to be scoped by module and path, limiting unrelated instructions while retaining shared requirements such as security or Git authorization. This is a practical answer to a common AI coding problem: too little context produces shallow suggestions, while too much unrelated context makes a tool slower and less precise.

Developers can also choose conventions deliberately. AI-KIT documents both owner-specific conventions and a standard mode for following the project’s existing rules. That makes it useful for personal workflows while preserving an escape hatch for teams that already have their own technical standards. 2

One project context, 11 AI clients

AI-KIT’s portability is a major reason to look at it. The project documents adapters for 11 AI clients: Codex, Claude Code, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, Roo, Aider, Kimi, and Manus. Each client receives the kind of entry point it can actually use, such as AGENTS.md, CLAUDE.md, native rule folders, Copilot instructions, GEMINI.md, or Aider conventions. 1

This is more valuable than a long compatibility badge. Different coding agents discover instructions differently, and some clients need a manual check before a native rule is considered active. AI-KIT calls that out instead of pretending that copying a file automatically proves runtime behavior. Its adapter documentation also describes how existing files are preserved or reported as conflicts rather than casually overwritten. 4

For organizations testing several AI coding assistants, this means the source of truth can remain in the repository. A team can keep the same project memory and engineering expectations while changing the interface used to access an assistant. Developers no longer need to maintain one disconnected prompt collection for Claude Code, another for Cursor, and a third for a CLI agent.

Preview-first installation and safer upgrades

Installing AI guidance into an existing repository should never feel like running an opaque generator. AI-KIT takes a preview-first approach. The initial install command reports proposed writes, preserved files, detected stacks, detected clients, conflicts, and warnings before it applies changes. The same command is then repeated with --apply only after review. 1

A typical local workflow looks like this:

git clone https://github.com/tigusigalpa/ai-kit.git
cd ai-kit

# Preview only: nothing is written to the application project.
python scripts/install.py /absolute/path/to/my-app \
  --preset solo --agent codex --agent claude

# Apply after reviewing the preview, then run a health check.
python scripts/install.py /absolute/path/to/my-app \
  --preset solo --agent codex --agent claude --apply --check

The target application should live outside the AI-KIT distribution itself. After installation, developers bootstrap the context in their chosen AI client—for example, with /ai-kit-bootstrap in Claude Code or $ai-kit-bootstrap in Codex. Other tools can use the repository’s bootstrap prompt. 1

The upgrade behavior deserves special attention. AI-KIT documents rules for preserving project-owned documents and local changes. When a managed instruction has been adapted locally, the toolkit presents it as a reviewable candidate instead of overwriting the edit. Similarly, switching an agent adapter requires explicit review; selected adapters are not silently deleted just because a later command omits them. 2

This is exactly the kind of operational discipline an open-source AI development toolkit should have. Teams can adopt assistance incrementally, inspect the diff, and retain ownership of their repository rather than treating generated configuration as disposable magic.

Guardrails that keep developers in charge

Useful automation must respect authorization boundaries. AI-KIT’s core guidance says that commits and pushes require an explicit user request, and that permission to commit does not imply permission to push. The optional guard settings for Claude Code can ask before actions such as committing, pushing, destructive Git commands, Docker cleanup, and detected migrations. 1

The repository is careful not to market those rules as an absolute security boundary. They are confirmation mechanisms and project guidance, not a substitute for access controls, reviews, or a secure execution environment. That honesty is refreshing in a field where AI tooling often blurs the line between “policy written in a prompt” and “policy enforced by a system.” 2

The same principle extends to secrets and verification. AI-KIT provides client ignore and denial guidance for common sensitive files, while its engineering rules ask agents to report unavailable checks as unverified instead of claiming success. The goal is a more inspectable collaboration pattern: the AI assistant can accelerate research and implementation, while developers retain control over privileged operations and acceptance criteria. 1

Adaptive model routing that does not pretend to be automatic

Model selection has become part of software engineering economics. A trivial classification task and a difficult distributed-systems diagnosis should not automatically consume the same model capability, latency tier, or reasoning budget. AI-KIT addresses this with an adaptive routing policy that maps work to a 0–6 capability ladder.

Levels 0 and 1 cover narrow tasks such as extraction and mechanical changes. Level 2 is for substantive engineering. Higher levels address difficult debugging, architecture, concurrency, conflicting evidence, and sensitive correctness. Level 6 is reserved for a diagnosed capability shortfall or a demonstrated reason to escalate. 3

The policy aims to optimize total cost to a correct result—not merely the price of the first request. It explicitly includes the cost of failed calls, tool loops, review, context, and recovery. It also warns against invented savings figures and unsupported confidence claims. 3

The practical helper can classify English or Russian task descriptions, explain the signals behind its recommendation, and write a resolved mapping for a project. But it does not activate a live model by itself, install credentials, or claim that an unsupported client control has been applied. 3 That boundary makes the routing feature more trustworthy: it helps developers make a reasoned decision without disguising advice as execution.

Docker and Kubernetes guidance from the start

AI-generated code often reaches containerization before it reaches production readiness. AI-KIT includes a Kubernetes-ready container contract intended for Dockerfiles, services, and local Docker Compose projects. Its guidance covers multi-stage builds, pinned images, non-root execution, read-only root filesystems, explicit writable volumes, health checks, SIGTERM handling, separated migrations, and minimal Kubernetes manifests. 1

These are not empty checklist items. The container documentation distinguishes local build evidence from a verified Kubernetes deployment and asks teams to check the actual Docker client, daemon, context, image behavior, signals, mounts, and health behavior when those checks are available. 5

AI-KIT also publishes a versioned Docker CLI image, tigusigalpa/ai-kit:1.4.1, for linux/amd64. The image packages the installer and helpers so teams can run the toolkit against a mounted application directory without installing Python on the host. Its documented examples use a read-only container root, dropped capabilities, no runtime network access, a non-root identity, and explicit mounts. 1

That Docker path is useful for organizations that prefer a portable, repeatable way to run developer tooling. It does not supply the application’s own Node, Composer, browser, model runtime, or MCP connection, which keeps the boundary clear: AI-KIT packages its own CLI and resources; the selected coding client and project environment remain separate. 6

Optional workflows for security, documentation, design, and dialogue memory

AI-KIT is intentionally modular. The default installation can stay focused, while developers explicitly opt into additional workflows when they fit the project.

The Context7 option adds guidance for version-aware library documentation lookup, but connection setup and credentials remain separate. The Cloudflare security-audit and Strix options add pinned references and explicit entry points for structured review or scoped testing workflows; installation does not start an audit or a scan. The Web Design option supplies a workflow for turning a brief and annotated references into a visual system, implementation guidance, and UI acceptance criteria, while keeping external tools and deployment outside the installer’s scope. 1

Another distinctive module is shared dialogue context. AI-KIT can import two local conversation sources, group candidate facts and decisions, surface contradictions for review, and export a reviewed reference state for ChatGPT or OpenRouter-style workflows. The documented process is local and review-driven; it does not automatically synchronize accounts or execute API calls. 1

This modular model is good for SEO-friendly developer documentation, but more importantly, it is good engineering. Teams can say exactly which capability is installed, what it does, what it does not do, and what external setup is still required.

Who should use AI-KIT?

AI-KIT is a strong fit for developers and teams who already use AI coding assistants but want less repeated prompting and more predictable project behavior. It is especially relevant when a repository has several modules, several languages, a long-lived architecture, or multiple contributors using different AI clients.

It can also help platform engineers who want to create a lightweight standard for AI-assisted development without adopting a full autonomous-agent platform. The toolkit’s project context, client adapters, preview-first changes, and documented operating boundaries offer a pragmatic layer between a raw chatbot and a company-wide developer platform.

Solo developers can begin with the solo preset and selected clients. Teams can use a shared mode when they want the instructions visible in Git. Projects that need more confirmation points can use the strict preset, while optional modules remain opt-in. 2 The key is to start with a small, reviewable installation and extend it only when the workflow proves useful.

An open-source AI development toolkit built around evidence

The most compelling thing about AI-KIT is not a single feature. It is the product philosophy behind the repository: give AI coding agents durable project context, teach them relevant engineering rules, make risky actions explicit, preserve local customization, and be honest about what has and has not been verified.

That is a better foundation for AI-assisted software development than endlessly refining a one-off prompt. It gives every new coding session a clearer starting point, helps teams carry conventions across tools, and makes the work of an AI assistant easier to inspect.

If your development workflow involves more than one AI chat, more than one stack, or more than one person, explore the repository, review the installer preview, and decide whether its project-memory approach fits your codebase: github.com/tigusigalpa/ai-kit.

References