AI DevKit
A local-first control plane that standardizes setup, supervision, memory, and engineering workflows across coding agents.
- Source repo
- codeaholicguy/ai-devkit
- Stars
- ★ 1.7k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- TypeScript
- FA score
- 61/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- A development team using Claude Code, Codex CLI, and Gemini CLI that wants one project configuration for skills, rules, and MCP setup.
- Not a fit if
- Solo developers using one coding agent who don't need multi-agent orchestration
- Teams unwilling to review and maintain generated config and docs/ai artifacts
- Source review
- 61/100 · Some gaps
What does this agent do, and when should you use it?
AI DevKit is a local-first operating layer for AI coding tools. A project-level .ai-devkit.json reconciles configuration and can install rules, skills, and MCP settings for the selected tools. Its CLI exposes ai-devkit agent list, agent detail, agent console, and agent send for inspecting, supervising, and messaging running sessions. @ai-devkit/memory stores project decisions, conventions, and reusable fixes in local SQLite, with retrieval through MCP and the CLI. The package also installs composable skills centered on dev-lifecycle, producing requirements, design, planning, implementation, and testing artifacts for teams managing more than one coding agent.
npx ai-devkit@latest init creates .ai-devkit.json, configuration directories for the chosen agents, and a phased docs/ai/ document structure in the project. ai-devkit agent list and ai-devkit agent console expose running sessions, while ai-devkit agent send "..." --id <agent-name> --wait routes a prompt to a session; --stdin accepts piped output and --group targets saved groups where supported. ai-devkit memory store writes titled, tagged, scoped knowledge to local SQLite, and ai-devkit memory search --query "..." retrieves it. dev-lifecycle guides requirements, design, planning, implementation, testing, and review; verify requires fresh test or build output before completion claims.
- A development team using Claude Code, Codex CLI, and Gemini CLI that wants one project configuration for skills, rules, and MCP setup.
- An engineering lead with several local coding sessions who needs a terminal console plus a way to send test logs and follow-up work to a named session.
- A backend team maintaining long-lived conventions, such as returning DTOs from REST handlers, that wants agents to retrieve them when relevant.
- A team building a sensitive feature such as Google OAuth login that wants requirements, design, and planning artifacts before implementation.
- A maintainer who needs agents to support completion claims with current test or build output before release review.
How do you install or deploy this agent?
From a project directory, run npx ai-devkit@latest init. The wizard lets you select agents and workflow components, then writes project-local files intended for review and commit. Source installation is documented as: git clone https://github.com/Codeaholicguy/ai-devkit.git, followed by cd ai-devkit && npm install && npm run build.
How do you use this agent?
After initialization, run ai-devkit agent list to inspect running sessions or ai-devkit agent console for the live terminal UI. To dispatch work and wait for the response, run ai-devkit agent send "run the tests and report back" --id <agent-name> --wait. Store a convention with ai-devkit memory store --title "API handlers return DTOs" --content "REST handlers should return response DTOs instead of domain entities." --tags "api,backend" --scope "repo:codeaholicguy/ai-devkit", then retrieve it with ai-devkit memory search --query "API response convention".
What are this agent's strengths and limitations?
- A single
.ai-devkit.jsonreconciles rules, skills, and MCP setup across multiple supported coding tools. agent console, session inspection, andagent sendprovide an operational surface for live sessions and cross-session prompt or log routing.- Local SQLite memory is retrieved when needed, avoiding the need to carry every project convention in each prompt.
dev-lifecycleandverifyconnect staged engineering artifacts with fresh verification evidence.
- Remote control is not available for every listed tool; the README marks opencode as testing and shows no remote control for several tools.
- Initialization writes agent configuration, skill directories, and
docs/ai/workflow artifacts into the repository, which teams must be willing to review and maintain. - CLI initialization, session control, and memory retrieval require a shell, filesystem access, npm, and a local runtime environment.
- The README declares MIT, while the supplied repository metadata lists the license as unknown; adopters should confirm the license status.
How does this agent compare with similar options?
Compared with static instruction files such as CLAUDE.md, .cursor/rules, and AGENTS.md, AI DevKit adds cross-tool setup reconciliation, live-session visibility and control, session messaging, searchable local memory, and verification gates. It is not presented as a replacement for Claude Code, Codex CLI, Cursor, Gemini CLI, or opencode; it configures and coordinates those tools.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| AI DevKit This agent | 61 · Some gaps | CLIFree + model costs | ★ 1.7k | today | TypeScript | Codex · Claude Code |
| Beacon | 79 · Good | CLIFreemium | ★ 3.4k | today | Go | Codex · Claude Code |
| Foremerge | 76 · Good | CLIFree | ★ 432 | 1d ago | Rust | Codex · Claude Code |
| Yardlet | 80 · Good | Desktop appFree | ★ 35 | today | Swift | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
The README describes local configuration, SQLite memory, and no telemetry, and mentions communication features such as agent send and Telegram. The SKILL.md files provide commands for reading session context and sending messages, making data flows fairly visible (2). However, the candidate can access session context and send content to agents or external channels; the sample does not show permission isolation or per-action confirmation, so least privilege, user confirmation, and external-effect controls are only partially supported (1 each). Sensitive-data handling is limited to local storage and a no-telemetry claim, with no encryption, retention, or access-control detail (1). Dependency security has no lockfile review or dependency-risk discussion in the packet (1). Project-local generated files can be reviewed and committed, supporting some recovery (2). The plugin manifest names an author, repository, and license, but publisher identity is unverified, so attribution is only partly traceable (2).
The README's multi-agent control, memory, and skills broadly align with the exported APIs. CI lists formatting, lint, build, and test steps, while the supplied tests cover memory-dashboard APIs and error responses, supporting reasonable self-consistency (2). Multiple harnesses, daemon, messaging channels, and remote skill sources create external dependencies; the packet does not describe availability guarantees or offline degradation (1). Dashboard tests include invalid ports, missing routes, and browser-open failures, showing explicit error paths, though coverage is limited (2).
The README gives concrete audiences and scenarios involving multiple terminals and providers, shared team configuration, remote control, and memory retrieval (3). It also states that the product is not an LLM, a replacement for existing agents, or a hosted service, and distinguishes configuration support from remote control; however, the sample does not fully establish skill and integration boundaries (2). Skills include trigger descriptions; orchestration is limited to ongoing multi-agent coordination and setup checks status first. The packet does not show all skills or automatic-trigger rules, so precision is partial (2). Node requirements, npm setup, CLI use, and agent-specific directories show some environment fit, but cross-platform and unsupported-harness constraints are unclear (2).
The README is organized around scenarios, installation, commands, skills, and limitations; package entry points and CI add structure, though the full architecture is outside the packet (2). It gives npx initialization and source-build steps, but upgrade, uninstall, and environment-specific instructions are limited (2). Command, skill, and package names are reasonably stable in the sample, though the number of product names and remote-integration boundaries leave room for ambiguity (2). The README includes extensive command examples, a workflow walkthrough, FAQ-like comparisons, and a 'what it is not' section (3). It states several non-goals and marks some agent integrations as testing or lacking remote control, but security and operational limitations are incomplete (2). Both LICENSE and package metadata specify Apache-2.0 (3). A version is visible and the README links a changelog, but its contents are not supplied, so version history is only partly verifiable (2). The plugin manifest names an author and contact email, but gives no clear maintenance team, support commitment, or update policy; publisher identity is unverified (1).
CLI examples, a project configuration layout, skill workflows, and verification gates provide an actionable path (2). Shared configuration, session management, cross-agent messaging, and searchable local memory offer concrete added capabilities; the sample does not show end-to-end implementation evidence for most of them (2). Local operation and shared configuration may reduce repeated setup, but maintaining multiple harnesses, channels, and skills adds cost, and the packet does not quantify either side (2).
Some README claims can be cross-checked against skill commands, exported APIs, tests, and CI, but most product capabilities are not directly expanded in the supplied source files (2). The README aligns with tests, package entry points, and CI on the memory dashboard and module structure; multi-agent control and skill effects remain mostly documented claims (2). CI clearly lists intended commands and tests state their coverage, but README claims about support, behavior, and workflow capabilities described as blocking are not consistently distinguished as demonstrated, implemented, or verified, warranting a lower score (1).
- Remote control, agent send, and Telegram/Slack channels can transmit session content to other agents or external services; the packet does not explain authorization, access control, or sensitive-content filtering.
- No telemetry and local storage are README claims; the supplied source is insufficient to independently confirm all network traffic, memory protections, or the full data lifecycle.
- CI describes test procedures and the supplied tests show some coverage intent; this review did not run a build or tests and is not runtime verification.
Maintain this project? Add the FARS badge to your README
[](https://followagents.com/en/agents/ai-devkit)<a href="https://followagents.com/en/agents/ai-devkit"><img src="https://followagents.com/badge/ai-devkit.svg" alt="FARS review"></a>Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
[email protected] 0.72.0
Release notes excerpt
What's Changed - Closed duplicate-name holes in agent start: the daemon re-imports the legacy registry under the start lock and treats a live pid as name-in-use even when tombstoned, so duplicates are rejected with a clear name_in_use error and names are reusable after agent kill. ([#418](https://github.com/codeaholicguy/ai-devkit/pull/418)) - Kept waiting agents from decaying to idle: harness session parsers now treat a session whose last message came from the assistant as waiting, regardless of the idle timer. ([#423](https://github.com/codeaholicguy/ai-devkit/pull/423)) …View on GitHub ↗ -
[email protected] 0.71.0
Release notes excerpt
What's Changed - Migrated interactive agent start into the devkitd daemon via a new agent.start RPC (tmux and herdr runtimes); daemon.db is now the agent registry, and @ai-devkit/daemon-client adds startAgent() and structured DaemonRpcError. ([#406](https://github.com/codeaholicguy/ai-devkit/pull/406)) - Added multi-agent orchestration, troubleshooting, and permissions docs, and fixed README setup, skill count, and harness table. ([#404](https://github.com/codeaholicguy/ai-devkit/pull/404)) …View on GitHub ↗ -
[email protected] 0.70.1
Release notes excerpt
What's Changed - [86d46ac](https://github.com/codeaholicguy/ai-devkit/pull/372) Fixed devkitd parsing ps rows with padded columns on Linux, which left agent list permanently empty; empty daemon answers are now cross-checked against local detection. - [de852a6](https://github.com/codeaholicguy/ai-devkit/commit/de852a6) Moved Telegram bot token validation into channel-connector's shared validateTelegramBotToken, redacting the bot token from debug output. …View on GitHub ↗
FAQ
Does it replace my coding agent?
Is project memory hosted remotely?
Can I operate an agent from my phone?
ai-devkit channel start telegram --agent <agent-name> --daemon.Which tools have documented remote control?
Thanks — we use this to improve the page.