AI Factory: A Shell-Based Skill Installer for Spec-Driven AI Coding
You want to build with AI, but setting up the right context, prompts, and workflows takes time. AI Factory handles all of that so you can focus on what matters — shipping quality code.
At a glance
- What is it?
- AI Factory is a Shell CLI that installs prompt skills and MCP configuration into whichever AI coding agent you already use. Its value is in the workflow it imposes (plan, implement, verify), and its main risk is that the skills it installs are code you did not write.
- Who is it for?
- Adopt AI Factory if your team already runs an agent like Claude Code or Codex CLI and wants a repeatable plan-then-implement loop instead of ad-hoc prompting. Skip it if you need a build system, a hosted service, or a guarantee that the skills it pulls in are audited, since the README itself points you at a two-level security scan for external skills.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem AI Factory targets: agent setup, not agent capability
AI Factory does not build an AI agent. It assumes you already have one, and it assumes the agent is underused because nobody wrote down what good work looks like. The README frames the gap directly: "You want to build with AI, but setting up the right context, prompts, and workflows takes time." The package's job is to install that context. The audience is a developer who has Claude Code, Cursor, Codex CLI, Gemini CLI or one of the other listed agents open in a terminal or editor, and who currently types feature requests into a chat box with no shared convention for planning, committing, or reviewing. The repository topics name the intended discipline: spec-driven-development. That phrase is the whole thesis. A plan file that the agent reads and updates is treated as more reliable than an agent improvising its way through a repository. Whether that holds depends on the quality of the generated plan, which the tooling does not itself validate.
What the installer actually writes into your project
The mechanism visible in the material is an installer plus a set of skill files. Running the wizard asks which agent you use, installs relevant skills, and configures MCP servers. The README lists a .ai-factory.json file and a config.yaml with a documented key reference and a skill read/write matrix, which suggests skills declare which paths they may touch rather than having unrestricted access. Agent support is handled by "agent transformers," a term the README uses only in the skills.sh disclaimer, so the exact transformation each agent receives is not described in the supplied material. Codex CLI and Codex app differ enough that they use $aif style invocations instead of /aif. There is also a bundled set of Claude subagents and what the docs index calls a "baseline Codex native agent-file bundle, including managed Codex config." The data flow is therefore: wizard reads your choices, writes skill files and MCP entries into agent-specific locations, and the agent then resolves slash commands such as /aif-plan against those files. Anything beyond that, including how conflicts between an existing skill and a newly installed one are resolved, is not stated in the README.
Install commands and the flags that skip the wizard
Two installation paths are documented. The npm route is npm install -g ai-factory, and mise users can run mise use -g npm:ai-factory. Initialization is either interactive or flag-driven: ai-factory init for the wizard, or ai-factory init --agents claude,codex --mcp playwright,github to bypass it. A --skills flag exists for the same purpose. The README also notes that ai-factory update and ai-factory upgrade are CLI commands, with details pushed to docs/getting-started.md rather than shown inline. Once installed, the entry point inside the agent is /aif, or $aif on Codex. The documented workflow commands are /aif-explore for requirements, /aif-grounded for a verified answer before changing anything, /aif-plan to create a branch and build a step-by-step plan, /aif-improve to refine it, /aif-implement to execute tasks and commit at checkpoints, /aif-fix for bugs, /aif-ci github for pipeline scaffolding, and /aif-docs for README and docs generation. There is a second, lighter install path: npx skills add lee-to/ai-factory --skill '*'. The README is explicit that this installs skill files only, and that the CLI commands, MCP auto-configuration, agent transformers and the wizard are not available that way. If you want the installer, the npm package is the only route described.
The /aif-fix to /aif-evolve loop is the most interesting design choice
Most of the command list is conventional: plan, implement, document, scaffold CI. The part worth attention is the feedback path. The README says /aif-fix lets the agent "learn from every fix and gets smarter over time," and the docs index describes /aif-fix patches feeding into /aif-evolve to generate "smarter skill rules." That means the tool writes back into its own skill definitions based on bug fixes. It is a genuinely different posture from a static prompt library, and it is also the part with the least visible control surface. The supplied material does not describe how a generated rule is reviewed, versioned, or reverted, nor what happens when a rule derived from one bug fix conflicts with a rule derived from another. Plan files and "self-improvement patches" are mentioned in the docs index, which implies the patches are at least inspectable artifacts rather than silent edits. Treat that as an assumption to verify against docs/evolve.md and docs/plan-files.md before enabling the loop on a repository where a bad rule could affect many future changes.
Where AI Factory is the wrong tool
The skills.sh path is the clearest boundary. If you install via npx skills add lee-to/ai-factory --skill '*', you get skill files and nothing else. No wizard, no MCP configuration, no transformers. A team that wants the installer's MCP wiring will be disappointed by that route, and the README says so rather than letting you discover it. The second boundary is agent coverage by depth rather than breadth. The list of supported agents is long, but the documentation set names Claude subagents and a Codex agent-file bundle specifically, and the invocation syntax diverges for Codex. Breadth of names in a README is not the same as equal support, and the material does not claim it is. Third, this is a Shell project that shells out to package managers and writes files into your repository. It is not a sandbox and it does not appear to be a service. If your constraint is that no third-party prompt content may enter the repo without review, the two-level security scanning described in docs/security.md is the relevant control, and the README's own framing of external skills as something needing scanning is a signal about where the trust boundary sits.
How it differs from a general-purpose agent framework
The closest comparison in the material is the author's own pointer to HLV, described as the option to try "if AI Factory feels too simple for your goals." That is a useful admission: AI Factory is deliberately a thin layer over an agent you already chose. A framework that hosts its own agent runtime owns the execution loop, the tool permissions and the model calls. AI Factory owns none of those. It writes skill files, configures MCP servers, and hands control back to Claude Code or Codex. The practical difference is where debugging happens. With a self-hosted framework you debug the framework. With AI Factory you debug the plan file and the prompt, and the failure modes are agent failure modes: a plan that missed a dependency, a command that resolved to the wrong file, a generated rule that overfits. That thinness is the point, and it is also the reason the tool cannot fix a weak agent.
Maintenance, licensing and what to check before adopting
The README states the licence as MIT, which permits commercial use and modification, though the repository metadata supplied here lists the licence as unknown, so confirm the LICENSE file on the 2.x branch rather than trusting either signal alone. Nothing in this material constitutes legal advice. On maintenance: releases are frequent and recent, with 2.18.1 on 2026-08-14 and a push to 2.x on 2026-09-07, and the README links a CI workflow on the 2.x branch. Frequent releases cut both ways for a tool that writes into your repository. Every upgrade can change skill files, and the README separates ai-factory update from ai-factory upgrade without explaining the difference in the supplied text, which is the first thing to read in docs/getting-started.md. The upgrade cost is not the CLI install. It is re-reading the diff of what the skills now do, especially if /aif-evolve has been generating rules. Pin a version, keep .ai-factory.json and config.yaml in version control so the diff is visible, and treat a skill change as a code change.
Editorial conclusion
Adopt AI Factory if your team already runs an agent like Claude Code or Codex CLI and wants a repeatable plan-then-implement loop instead of ad-hoc prompting. Skip it if you need a build system, a hosted service, or a guarantee that the skills it pulls in are audited, since the README itself points you at a two-level security scan for external skills. Before rolling it out, run ai-factory init in a scratch repository with --agents and --mcp set explicitly, then read docs/security.md and docs/config-reference.md to see what the wizard writes into your project.
Community notes