# Synkra AIOX: an agent-orchestration framework that keeps its intelligence in the CLI > AIOX Core is an npm-distributed framework of planning and development agents for full stack work. Its architecture ranks the CLI above dashboards, and its real ceiling is how many lifecycle hooks your IDE exposes. **SynkraAI/aiox-core** — Synkra AIOS: AI-Orchestrated System for Full Stack Development - Core Framework v4.0 - Repository: https://github.com/SynkraAI/aiox-core - Website: https://github.com/allfluence/aios-core - Stars: 3,125 · Forks: 965 - Language: JavaScript - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/synkraai-aiox-core ## The planning-to-story gap AIOX Core is aimed at Two failure modes dominate AI-assisted development. The first is planning inconsistency: every prompt session produces a different quality of specification, so the architecture drifts. The second is context loss: the person or model writing code never sees the reasoning behind the plan. AIOX Core is built around the claim that both come from the same root, namely that planning and implementation are not connected artefacts. The framework answers with two phases. In the first, dedicated planning agents (the README names analyst, pm and architect) collaborate with a human to produce PRD and architecture documents. In the second, an agent called sm (Scrum Master) converts those documents into development stories that carry context, implementation detail and architectural guidance inside the story file itself. The intended reader of that file is the dev agent. The audience is therefore narrow but specific: teams that already accept an agentic workflow and want the artefacts to be reviewable documents rather than chat transcripts. If you write code alone and never produce a PRD, the two-phase structure is overhead you will not recover. ## CLI First, observability second, UI third The README states a priority hierarchy explicitly: CLI First, Observability Second, UI Third. The CLI is described as the place where execution, decisions and automation happen. Observability exists to watch what the CLI is doing, and the UI is for occasional management such as a Kanban board or story management. Three derived principles follow from that ordering. The CLI is the source of truth and dashboards only observe it. New functionality must work entirely through the CLI before it gets a UI. And the UI must never be a requirement for operating the system. This is a genuine architectural position, not marketing. It means an SSE dashboard, logs and a timeline are downstream consumers of CLI state, so removing the UI cannot break the workflow. The cost is that anyone who prefers clicking through a board will find the framework's centre of gravity elsewhere. The repository layout supports the claim: bin/ holds five entry points (aiox, aiox-core, aiox-minimal, aiox-graph and aiox-delegate), while the UI-facing assets sit in public/ and a vercel.json at the root. ## Hook parity decides how much of AIOX Core you actually get The most useful table in the README is the one comparing IDE hook parity against Claude Code. It is also the part most likely to disappoint a new user, because it makes the framework's capability conditional on the editor. Claude Code is listed as the reference implementation with complete parity, giving maximum context automation, guardrails and auditing. Gemini CLI is rated high, with native events covering pre and post tool automation and session events. Codex CLI is partial: some automation depends on AGENTS.md, /skills and MCP. Cursor and GitHub Copilot are both marked as having no equivalent lifecycle hooks, which the README says reduces pre and post tool automation and pushes those integrations toward repository instructions and MCP in VS Code. AntiGravity is described as workflow-based rather than hook-based. Read that as a compatibility contract. If you adopt AIOX Core inside Cursor, you are getting the agents and the file conventions but not the event-driven automation layer. The README points to docs/ide-integration.md for the detailed impacts and workarounds, and that file is worth reading before you plan a rollout. ## Installing AIOX Core and reaching first value Prerequisites are Node.js 18.0.0 or newer (the README recommends v20 or above), npm 9.0.0 or newer, and optionally the GitHub CLI for team collaboration. The package has moved to the scoped name @aiox-squads/core, the successor to the unscoped aiox-core, but the README states the CLI commands including aiox-core are preserved during the transition. For a new project, the documented command is: ```bash # novo projeto npx aiox-core init meu-projeto # projeto existente cd seu-projeto npx aiox-core install ``` After installation you pick an IDE or CLI and an activation path. The README gives these: Claude Code uses /agent-name; Gemini CLI goes through /aiox-menu and then /aiox-; Codex CLI uses /skills and then aiox-; Cursor, Copilot and AntiGravity are told to follow the limits and workarounds in docs/ide-integration.md. The next step is to activate one agent and confirm the greeting, then run one initial command such as *help to validate first value. The README defines first value as a binary: agent activation, a valid greeting and a useful initial command output within ten minutes or less. Configuration lives in a .env file copied from .env.example. That template groups keys by purpose, including DEEPSEEK_API_KEY for the claude-free command, OPENROUTER_API_KEY for multi-model routing, ANTHROPIC_API_KEY, OPENAI_API_KEY, EXA_API_KEY for agent web search, CONTEXT7_API_KEY for library documentation lookup, the three Supabase keys, GITHUB_TOKEN, and more below the truncated section. The file carries its own warning not to commit real credentials. Platform-specific installation notes exist for macOS, Windows and Linux under docs/installation/, and an installation troubleshooting guide sits at docs/guides/installation-troubleshooting.md. ## Where the framework stops being the right tool The hook table is the first limitation, and it is structural rather than temporary. Cursor and GitHub Copilot are marked as having no equivalent lifecycle hooks, so the guardrail and audit automation that Claude Code users get is simply absent there. A team standardised on Copilot should treat AIOX Core as a set of agents and file conventions, not as an orchestration layer. The second limitation is the licence. The repository metadata reports NOASSERTION, while the README badge and badge link both point at an MIT licence. Those two signals disagree. The LICENSE file in the repository root is the thing to read, and a team with legal review requirements should resolve the discrepancy before shipping the framework inside a product. The third is operational. The framework depends on external API keys for several capabilities, and the .env.example lists DeepSeek, OpenRouter, Anthropic, OpenAI, Exa and Supabase. Running the full set is a recurring cost and a credential-management surface. There is no documented offline mode in the README, so plan for network dependencies. Finally, the CLI-first principle cuts both ways. Anyone who wants a browser-based control plane will find that the UI is deliberately tertiary and never a requirement for operation. ## AIOX Core against a plain Claude Code agent setup The obvious alternative is not another orchestration framework but the thing AIOX Core wraps: Claude Code's own agents and skills, configured by hand. The difference is in where the structure lives. A hand-rolled setup keeps prompts and instructions in whatever files you choose, and the workflow exists in the habits of the team. AIOX Core instead ships the structure: named agents with fixed roles, a two-phase planning-to-story pipeline, a .claude/ directory containing agents, commands, skills, rules and hooks, and an installer that writes those into your repository. That is a real trade. You gain repeatability and reviewable artefacts, since a story file can be read by a human before the dev agent touches it. You lose flexibility, because the agent roles and the phase ordering are prescribed, and you inherit an upgrade path you do not control. The package.json shows that path is non-trivial: it exposes installer modules including enterprise-detector, enterprise-manifest-loader, enterprise-rollback and enterprise-upgrader, which implies upgrade and rollback are handled by dedicated code rather than a simple version bump. If you dislike that, a hand-configured Claude Code project with your own AGENTS.md is the honest alternative. ## Maintenance, releases and what an upgrade touches The repository is not archived and the last push was on 2026-09-10. Recent releases are v5.4.1 and v5.4.0, both on 2026-08-15, and v5.3.0 on 2026-07-11. That is a regular release cadence, and the CHANGELOG.md at the root is where the details live. Upgrade cost deserves attention before adoption. The package ships a large file list into your project, including bin/, scripts/, packages/, .aiox-core/, and a .claude/ subtree with CLAUDE.md, settings.json, agents, commands, skills, rules and hooks. An install therefore writes into directories you may already have customised. The presence of enterprise-rollback and enterprise-upgrader modules in the package exports suggests the project anticipated this, but the README does not document rollback, so verify the behaviour yourself on a branch before upgrading a working repository. The npm namespace transition adds a second consideration. @aiox-squads/core is the successor to the unscoped aiox-core, and the README says CLI commands are preserved during the transition. Pin your dependency to the scoped name and check the CHANGELOG before moving versions, because the two names may not track each other indefinitely. ## Repository layout as a signal of scope The top-level entries say a lot about what this project is trying to be. Alongside the usual .github/, docs/ and tests/, there are directories for .claude/, .codex/, .cursor/, .gemini/, .grok/, .kimi/ and .antigravity/, plus .synapse/ and squads/. That is a multi-editor integration surface maintained in one repository, which explains the hook-parity table: the framework is trying to meet each tool where it is. There are also directories that suggest ambitions beyond the core framework, including governance/, audits/, pro/ and outputs/. A workspace configuration in package.json points at packages/*, so the repository is a monorepo with the CLI, the installer and related modules split out. For an evaluator, the practical question is which of those directories are shipped to your project and which are development-only. The files array answers part of it: bin/, scripts/, packages/, .aiox-core/ and the .claude/ subtree ship, while tests/, audits/ and governance/ do not. ## Conclusion AIOX Core fits teams already working inside Claude Code or Gemini CLI who want planning documents and story files produced by named agents instead of ad hoc prompts, and who can live with the CLI as the source of truth. Skip it if your editor is Cursor, Copilot or AntiGravity and you expected the same automation, because the README states those platforms have no equivalent lifecycle hooks. Before committing, run npx aiox-core install in a scratch repository and confirm that one agent activates, greets you and returns useful output from *help inside ten minutes, which is the project's own definition of first value. ## FAQ ### How do I install Synkra AIOX Core? Use npx aiox-core init meu-projeto for a new project, or cd into an existing project and run npx aiox-core install. Both commands require Node.js 18.0.0 or newer and npm 9.0.0 or newer. ### Which IDEs and CLIs does Synkra AIOX Core support? The README lists Claude Code, Gemini CLI, Codex CLI, Cursor, GitHub Copilot and AntiGravity. Hook parity differs sharply: Claude Code is the reference with complete parity, Gemini CLI is rated high, Codex CLI is partial, and Cursor and Copilot are marked as having no equivalent lifecycle hooks. ### What is the difference between the aiox-core and @aiox-squads/core packages? The README states that @aiox-squads/core is the successor to the unscoped aiox-core, and that the content is the same framework. The new namespace reflects the consolidation of squads under @aiox-squads/*, and the CLI commands including aiox-core are preserved during the transition. ## Sources - [Issues](https://github.com/SynkraAI/aiox-core/issues) - [Project website](https://github.com/allfluence/aios-core) - [README](https://github.com/SynkraAI/aiox-core/blob/main/README.md) - [Releases](https://github.com/SynkraAI/aiox-core/releases) - [SynkraAI/aiox-core on GitHub](https://github.com/SynkraAI/aiox-core) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/synkraai-aiox-core