AIOX Core: CLI-first agent orchestration with a two-phase planning pipeline
Synkra AIOS: AI-Orchestrated System for Full Stack Development - Core Framework v4.0
At a glance
- What is it?
- Synkra AIOS packages a set of planning and development agents behind a CLI, with an explicit CLI-first hierarchy and a hook parity table that tells you which IDE features you actually get. The design is opinionated and the hook coverage is uneven across editors.
- Who is it for?
- Adopt AIOX if you work primarily in Claude Code or Gemini CLI and want planning and development agents that write their output into story files rather than chat history. Do not adopt it if Cursor, Copilot or AntiGravity is your only editor and your workflow depends on pre/post tool automation, because the README states those platforms have no equivalent lifecycle hooks.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly JavaScript, 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 planning gap AIOX is aimed at
Most AI coding assistance fails in two places. The first is planning inconsistency: ask an assistant to produce a PRD and you get a different shape of document each time, with sections that do not line up against each other. The second is context loss: the developer agent that eventually writes code never sees the reasoning that produced the task list. AIOX names both problems explicitly and positions itself against "geracao generica de tarefas de IA", generic AI task generation. The target user is a full stack developer or small team already comfortable in a terminal, who wants the specification artifacts to be durable files rather than conversation state. The README frames the whole system around a hierarchy: CLI First, Observability Second, UI Third. That ordering is not decoration. It states that the CLI is the source of truth, that dashboards only observe, and that a new feature must work entirely through the CLI before it gets any interface at all.
Two-phase planning and the story file as the handoff artifact
The mechanism the README describes is a two-phase pipeline. In phase one, dedicated planning agents (analyst, pm, architect) collaborate with the human to produce PRD and architecture documents. The README attributes the quality of those documents to prompt engineering plus human-in-the-loop refinement, which is a claim about process rather than a measurable property. In phase two, the sm agent, the Scrum Master, converts those plans into development stories. The important detail is what a story contains: complete context, implementation details, and architectural guidance embedded directly in the story file. That is the actual data flow. The plan does not live in a chat window that gets truncated; it lives in a file the dev agent opens. The README states this two-phase approach is what eliminates planning inconsistency and context loss. Treat that as the project's stated rationale, not a verified outcome. What can be observed from the material is the artifact design: the handoff between planning and implementation is a file, which makes it reviewable and diffable in a way a conversation is not.
Installation and the first ten minutes
The README gives two entry points. For a new project: npx aiox-core init meu-projeto. For an existing one: cd into the project and run npx aiox-core install. Prerequisites are Node.js >=18.0.0 with v20+ recommended, and npm >=9.0.0. GitHub CLI is listed as optional and only needed for team collaboration. After install, activation depends on your editor. Claude Code uses /agent-name. Gemini CLI uses /aiox-menu followed by /aiox-<agent>. Codex CLI uses /skills and then aiox-<agent-id>. Cursor, Copilot and AntiGravity are directed to docs/ide-integration.md for limits and workarounds. The README defines first-value in binary terms: agent activation, a valid greeting, and one initial command (such as *help) producing useful output within ten minutes. That is a reasonable acceptance test to run yourself before evaluating anything else. Note the namespace transition: @aiox-squads/core is the successor to the unscoped aiox-core package, and the README states the CLI commands, including aiox-core, are preserved during the transition.
Hook parity is the real constraint, and it is not uniform
The most useful part of the README is the hook compatibility table, because it is where the project admits its own limits. Claude Code is listed as the reference with complete parity: maximum context automation, guardrails and auditing. Gemini CLI is rated high, with native events covering pre/post tool and session automation. Codex CLI is partial, with some automation depending on AGENTS.md, /skills, MCP and the operational flow. Cursor and GitHub Copilot are listed as having no equivalent lifecycle hooks, which the README translates into less pre/post tool automation and a focus on rules, MCP and repository instructions. AntiGravity is described as workflow-based rather than hook-based. Read that table before you read anything else. If your team standardizes on Cursor, the advanced automation the project advertises is not the automation you will get. The README points to docs/ide-integration.md for detailed impacts and mitigation, which is where the specifics live.
Where AIOX is the wrong tool
AIOX assumes you want a structured, document-heavy planning phase before code. If your work is exploratory, or the task is a one-file fix, the PRD and architecture stage is overhead with no payoff. The CLI-first premise also cuts the other way: the README states the UI must never be a requirement for operating the system, so anyone expecting a primary graphical workspace is looking at the wrong project. The UI layer is explicitly tertiary, limited to kanban, settings and story management. There is a second, harder constraint. The licence field for this repository is NOASSERTION, while the README carries an MIT badge and links to a LICENSE file. Those two signals disagree. Before you depend on the licence terms for anything commercial, read the LICENSE file in the repository directly rather than trusting the badge. The repository metadata also lists the primary language as JavaScript, while the topics include TypeScript, so confirm which you are actually consuming.
How this differs from a single general-purpose coding agent
The obvious alternative is a general-purpose coding agent driven by a single system prompt, where you describe the task and it writes code. The difference is not model quality, it is where the intermediate reasoning is stored. A single-agent flow keeps plan and implementation in the same context window, which is cheap until the window fills or the session ends. AIOX splits the roles and forces the output of the planning phase into PRD, architecture and story files, then hands those files to the dev agent. That costs you a planning phase and a set of documents to maintain. You get a reviewable trail and a story file that a different person, or a different session, can pick up cold. The trade is real in both directions: more ceremony, more durable context. For a solo developer on a small change, the single-agent approach is faster. For a team where two people touch the same feature across days, the file-based handoff is the part that matters.
Upgrade and maintenance surface
The release history shows a fast cadence: v5.3.0 in July 2026, then v5.4.0 and v5.4.1 on the same day in August 2026. Two releases within roughly an hour of each other suggests the second was a fix for the first. That is a normal pattern, but it means you should not pin to a brand new minor version on a Friday. The maintenance cost that matters more is the namespace migration. The README states @aiox-squads/core succeeds the unscoped aiox-core package and that CLI commands are preserved during the transition, which reduces the immediate breakage but leaves two names in circulation. Any internal documentation, CI script or onboarding guide your team writes should reference the scoped package and note the old name, or you will field the same question repeatedly. Beyond that, the upgrade surface is the agent prompts and story templates themselves. The README attributes planning quality to prompt engineering, so prompt changes between versions can alter the shape of your generated PRDs and stories. Diff a generated story after upgrading rather than assuming the output is stable.
Editorial conclusion
Adopt AIOX if you work primarily in Claude Code or Gemini CLI and want planning and development agents that write their output into story files rather than chat history. Do not adopt it if Cursor, Copilot or AntiGravity is your only editor and your workflow depends on pre/post tool automation, because the README states those platforms have no equivalent lifecycle hooks. Before committing, run npx aiox-core install in one real repository, activate a single agent, and confirm that first-value definition yourself: agent activation, a valid greeting, and one initial command with useful output inside ten minutes.
Community notes