OfficeCLI

A single-binary CLI that gives AI agents full read/write control over Word, Excel, and PowerPoint files — no Office installation, no dependencies, and a built-in HTML/PNG renderer that closes the render-look-fix loop.

28.8Kstars
2Kforks
Apache License 2.0
C#

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
80/100Excellent
Development Activity96
Maintenance100
Community60
Maturity24
Momentum40

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
82/100Excellent
Architecture92
Code Quality66
Innovation90
Learning Curve80

Dependency Health

Score based on the health, technical quality, freshness, and vulnerability profile of runtime dependencies.How we score it →
96/100Excellent
Library Repo HealthN/A
Library Technical QualityN/A
Version Staleness90
Vulnerabilities100
Dependency Footprint100

OfficeCLI is a single-binary command-line tool that gives AI agents and developers full programmatic control over Word (.docx), Excel (.xlsx), and PowerPoint (.pptx) files — without requiring Microsoft Office, LibreOffice, or any other Office suite to be installed. Built in C# on .NET and published as a self-contained, trimmed executable for macOS, Linux, and Windows, it replaces the usual pattern of scripting python-docx/openpyxl/python-pptx (or shelling out to a headless Office install) with a single CLI surface that reads, creates, analyzes, and edits every element of an Office document — text, styles, formulas, charts, pivot tables, images, diagrams, and more — through one consistent selector syntax.

Every document type is modeled as the same universal DOM: a tree of DocumentNode objects addressed with XPath-like paths such as /slide[1]/shape[1] or /Sheet1/A1:C10, so an agent that has learned to add, get, set, move, or remove an element in one format already knows the pattern for the other two. A built-in HTML/PNG rendering engine reproduces the document with high fidelity, closing the render → look → fix loop that lets an agent visually verify a slide deck or spreadsheet it just generated rather than editing blind. A watch command opens a live browser preview over SSE that refreshes after every command, and a resident/session process model keeps large documents open in memory across many small edits instead of re-parsing gigabyte-scale OOXML packages on every CLI invocation.

Beyond the CLI itself, OfficeCLI ships a Model Context Protocol (MCP) server, Node.js and Python SDKs that wrap the binary as a library, and a family of packaged “skills” (SKILL.md files) that teach coding agents like Claude Code, Cursor, and GitHub Copilot how to use it — installed automatically via officecli install or a one-line curl. The project is entirely free and Apache-2.0 licensed, with releases cut multiple times a week and a build matrix covering eight OS/architecture combinations, reflecting its stated goal of being the default way AI agents create and edit Office documents rather than a thin wrapper around an existing library.

What You Get

  • Full read/write/create access to .docx, .xlsx, and .pptx through one unified CLI and document DOM model
  • Built-in HTML and PNG rendering so agents can visually inspect a document instead of guessing at layout
  • A live watch preview server (SSE-based) that refreshes in the browser on every edit
  • Node.js and Python SDKs, plus a Model Context Protocol (MCP) server, for embedding OfficeCLI in agent pipelines
  • Ready-made “skills” (SKILL.md packages) that auto-teach Claude Code, Cursor, Codex, and other coding agents how to drive it
  • A resident/session process model that keeps large documents open in memory for fast, repeated edits

Common Use Cases

  • An AI coding agent generating a slide deck, financial model, or academic paper end-to-end from a natural-language brief
  • Automating repetitive Office document generation (invoices, reports, dashboards) in a CI pipeline with no Office license or GUI automation
  • Bulk-editing hundreds of existing Word/Excel/PowerPoint files (rebranding, data refreshes, formatting fixes) via scripted batch commands
  • Extracting structured data (tables, formulas, charts) from Office files for downstream processing without opening the file in a desktop app
  • Building an internal MCP-connected assistant that creates and edits company Office documents on request

Under The Hood

Architecture OfficeCLI’s architecture centers on a single cross-format abstraction: every Word, Excel, and PowerPoint document is exposed as a tree of DocumentNode objects through the IDocumentHandler interface, which layers semantic (view as text/outline/stats), query (get/query/set/add/remove/move/copyFrom), and raw XML access on top of the same three-layer contract for every format. Program.cs dispatches from a thin command-line entry point into format-specific handlers under Handlers/Word, Handlers/Excel, and Handlers/Pptx, while cross-cutting concerns — atomic crash-safe disk writes (a temp-file-then-swap pattern), a resident/session process model for keeping large documents open across edits, a watch server pushing live HTML previews over SSE, an MCP server exposing the same commands as JSON-RPC tools, and a batch executor for scripted multi-step edits — live in a well-organized shared core layer used by every handler. Selectors resolve XPath-like paths to concrete document parts, and structured exceptions carry a machine-readable code, correction suggestion, and help pointer back to the caller, so the abstraction is explicitly designed around being driven by an AI agent rather than a human clicking through a GUI. Changing the core document/selector contract would ripple through every handler and every SDK, since Word, Excel, and PowerPoint editing, the CLI, the MCP server, and the Node/Python SDKs all sit on top of it.

Tech Stack The CLI is written in C# targeting .NET, built on the DocumentFormat.OpenXml library for reading and writing the underlying OOXML packages, with System.CommandLine handling argument parsing. It publishes as a self-contained, trimmed, single-file executable for macOS, Linux, and Windows across both x64 and arm64 (including an Alpine/musl target), so end users need no separate .NET runtime or Office installation. Distribution runs through platform-native channels — Homebrew, npm (a thin Node wrapper that downloads the matching native binary post-install), and PyPI — plus first-class Node.js and Python SDKs that wrap the binary over stdio for programmatic embedding, and an MCP server for direct tool-calling integration. A resident/session model uses named pipes for fast repeated edits, and a suite of embedded resources (help schemas, watch-mode CSS/JS, chart style templates, and packaged agent “skills”) ship inside the single binary rather than as loose files on disk.

Code Quality No dedicated unit test project exists in the public repository — the contributing guide tells contributors that tests, style, and docs are handled by the maintainer in post-merge cleanup, so there is no visible unit-test suite to inspect. What CI does verify is broader and end-to-end: a release build matrix compiles the CLI across eight OS/architecture targets, a dedicated smoke workflow exercises both SDKs on all three operating systems through the real install script and a live pipe round-trip, and a parity check guards the packaged “skill” files against corruption. Error handling is deliberate rather than an afterthought — a dedicated exception type carries a machine-readable error code, a corrective suggestion, and valid-value lists specifically so an AI agent, not a human, can recover from a failure without intervention, and nullable reference types are enabled project-wide. Inline documentation is abundant: public types and non-obvious methods carry detailed doc comments explaining not just what the code does but why, which meaningfully lowers the cost of a newcomer’s first contribution despite the absence of unit tests.

What Makes It Unique OfficeCLI’s core bet — a CLI-native, agent-first interface to OOXML documents, distributed as a dependency-free single binary — is a genuinely distinct position rather than a repackaging of existing document libraries. Instead of asking an agent to write and debug several separate document libraries, each with its own API and no shared mental model, it exposes one selector-addressed document model across all three formats and closes the loop with a built-in HTML/PNG renderer so an agent can visually confirm the result of its own edit — a render-look-fix cycle that text-only document libraries have no equivalent for. The live watch preview server, the MCP server, and the auto-installing “skill” packages that teach coding agents how to use the tool are all built specifically around how AI coding agents, not humans, consume a CLI, which is an unusual and consistent design choice across the whole project rather than a single novel feature bolted onto a conventional tool.

Self-Hosting

Licensing Model Apache License 2.0 — a permissive open-source license with an explicit patent grant. All features are available in every build; there is no separate paid or “enterprise” tier.

Self-Hosting Restrictions None found — OfficeCLI ships as a single self-contained binary with no license server, license key, or phone-home requirement gating any command.

Enterprise Features None — the project has no commercial edition, paid tier, or gated feature set as of this writing; the maintainer’s companion desktop app (AionUi) is a separate open-source project, not a paid upsell.

License Key Required No.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search