AXEA
AtlasX Engineering Architect — Spec-driven development for AI coding agents
AXEA (AtlasX Engineering Architect) is a spec-driven development kernel for AI coding agents, built by AtlasX Technologies Inc.
AXEA is a hosted MCP kernel that keeps AI coding agents on contract: you write the specification, your agent writes the code, and AXEA verifies every change against the plan before it counts as done. It is not an IDE—you keep Claude Code, Cursor, GitHub Copilot, Codex, OpenCode, or any MCP-capable editor and connect over HTTP MCP. Spec packs, a code graph, and gated lifecycle phases (specify → compile → build → verify) replace open-ended repo search and skipped verification.
AXEA by AtlasX Technologies Inc. is a spec-driven MCP kernel for AI coding agents—not a general-purpose chat product, not an IDE replacement, and not the same as running CI unit tests alone.
Company: AtlasX Technologies Inc.. MCP: https://api.axea.dev/mcp. GitHub: https://github.com/AtlasX-Technologies-Inc/AXEA
- Compiled spec packs for each change
- AST code graph search and blast-radius impact
- Gated lifecycle: specify, compile, build, verify
- Hosted HTTP MCP kernel for AI coding agents
- Verification against WHEN/THEN scenarios (not only unit tests)
- Optional enterprise sealed sidecar (source stays in your VPC)
Full AXEA documentation corpus
Philosophy & Getting Started
Why spec-driven development transforms AI coding agents from guessing to contracting.
AXEA makes spec-driven development usable for daily software engineering when AI agents write the code.
The usual developer sequence:
idea → rough ticket → code → hope it works → document later (maybe)
The AXEA sequence:
idea → specify requirements → write verification scenarios → design → implement → verify against spec → archive
The spec is first. It states what the system SHALL do, not how. It is plain language, reviewed like code, and kept as a first-class record next to the implementation. Verification scenarios beside it say how you will know it is correct.
Lifecycle & State Transitions
The 7-step deterministic state machine: drafting through archivable.
Every significant piece of work is a change: a named unit that tracks which specs it touches, which artifacts exist, and which lifecycle step it is in.
drafting → designing → ready → implementing → verifying → done → archivable
Approval gates (spec approval before code, signoff before archive) are optional project policies. Verification is NEVER optional.
Redesign from any state:
Requirement changes, new information, or mistakes mid-lifecycle do not require abandoning work. A change can return to designing. Approvals are cleared and artifacts must be re-validated before returning to ready.
Published Kernel Tools
The 17 remote tools exposed by the AXEA Cloud MCP endpoint.
Subscribers connect their IDE via MCP. The kernel publishes 17 tools for lifecycle navigation, artifact authoring, graph search, and governance:
• axea / next: Turn bundle compiler providing scoped instructions for the current phase only.
• status: Real-time change state, gate statuses, and artifact completeness.
• context / list_specs: Assembled spec pack and spec catalog.
• write_artifact / artifact_get / validate_artifact: Authoritative persistence and full-body reads.
• edit_change / create_change / transition: Scope edits and enforced step progression.
• graph_search / impact / graph_reindex: Code graph queries, blast radius, and stale-index refresh across TS, JS, Go, Python, and PHP.
• record_scenario / approve_spec / approve_signoff: Verify evidence and optional human gates.
Building Blocks & Traceability
Changes, Specs, Selectors, Workspaces, and Traceability IDs.
Traceability IDs ensure end-to-end accountability across the entire change lifecycle:
• REQ-<AREA>-<nnn>: Formal system requirement (SHALL / MUST).
• AC-<AREA>-<nnn>: Acceptance criteria.
• TC-<AREA>-<nnn>: Test / verify scenario (GIVEN / WHEN / THEN).
The Traceability Chain:
Business Intent → Product Requirement → System Requirement → Architecture Decision → Implementation Task → Test Case → Verification Result.
Bring Your Own Skills (BYO)
How to add company-specific domain rules without breaking the core lifecycle.
Company skills may add domain rules (payment SDK standards, Jira ticket formats, house coding conventions). They must not reimplement Discover → Archive.
Place them where your preferred IDE already loads skills:
• Agents Skills / portable: .agents/skills/<name>/SKILL.md
• Claude: .claude/skills/<name>/SKILL.md
• GitHub Copilot: .github/skills/<name>/SKILL.md
• Codex: .codex/skills/<name>/SKILL.md
• OpenCode: .opencode/skills/<name>/SKILL.md
Do not name a company skill axea, axea-design, axea-implement, axea-verify, or axea-archive. Those are official kernel prompts.