OfficeDex: a Wails desktop workspace that turns chat into docx, pptx and xlsx files

What OfficeDex tries to replace

The README sets up an analogy rather than a feature list: developers already describe intent and let a model write the program, and OfficeDex applies the same idea to documents. You say you need a Q3 sales analysis report focused on the eastern region with year over year and quarter over quarter charts for a CFO audience, and you get a docx back instead of markdown you then paste into Word. The audience is people who write business documents on a schedule, quarterly reports, kickoff decks, competitive matrices, financial models and survey summaries, and who currently lose time to formatting rather than thinking. The README is explicit about the mechanism it refuses: no intermediate HTML, no copy and paste, no manual formatting. The output is the final file. It runs as a native desktop window on macOS, Windows and Linux rather than in a browser tab, and it can run against your own model or against the OfficeCLI hosted runtime.

How a request turns into a file

Three things stack on top of each other. Generation is conversational: built in scenarios cover quarterly reports, kickoff slides and competitive analysis, free form prompts let you set length, tone and audience, and context persists so you can ask for a risk assessment page to be added after the first draft. A live task stream exposes streaming events, lets the model ask you to decide mid run when it is unsure, and lets you cancel or restart at any point. Then the document side: the README states the app handles OOXML natively and that multiple agents collaborate, one planning structure, one writing content, one handling formatting. Memory is the part that separates it from a one shot generator. The README says it remembers your style and design language across sessions, so the fiftieth report inherits the polish of the first, and it frames that as digitising your style rather than only your text.

Building OfficeDex from a checkout

The repository is a Wails v2 project, so Go and Node are both involved, and package.json is where the real entry points live. Before dev or build, a prefetch script downloads the pinned OfficeCLI binary; package.json records officecliVersion 0.2.121, and release v0.6.7 was cut specifically to bundle OfficeCLI 0.2.121. The predev and prebuild hooks run that fetch automatically.

npm run prefetch:officecli

The normal development loop is a single script that hands off to the Wails toolchain, which starts the Go host and the React front end together.

wails dev

If you only want to work on the front end, the dev:browser script serves the client with Vite on port 3100 and skips the desktop shell.

vite --host=0.0.0.0 --port=3100

The production build is where the platform bias shows.

wails build

That compiles the app and injects the version read out of package.json, then the build script runs two bundling steps that are named for macOS: one stages the pptxgenjs runtime inside the app bundle and one codesigns the bundled OfficeCLI binary. A separate local build script, npm run build:local, runs scripts/build-local-app.sh, and npm run build:pptist builds the embedded editor through scripts/build-embedded-pptist.sh.

What the repository layout says about the moving parts

The file list is unusually revealing for a desktop app. app.go is the Wails binding surface, internal/ and runtime/ hold the Go side, and src/ holds the React client, with a Vite config and a TypeScript config alongside. pptxgenjs_runtime.go means slide generation goes through a Go binding to the pptxgenjs library rather than through the OfficeCLI binary alone, and there is a staged copy of that runtime under scripts. Persistence is modernc.org/sqlite at v1.50.1 with github.com/google/uuid, both listed as direct requirements in go.mod on Go 1.25.0 with wails v2.12.0. Platform specific code is split by filename, app_update_darwin.go against app_update_other.go and a separate app_nap_darwin.go, so update behaviour and sleep handling differ by operating system. Testing is heavier than most desktop apps: there is an e2e directory with a playwright.config.ts plus a long list of Go tests covering cancel persistence, provider login, preview trusted roots and real end to end flows.

Inline preview, memory and the mid task question

Two features are easy to underestimate. Inline preview renders docx, pptx and xlsx inside the window, which removes the open it in Office to see whether it worked step that dominates the loop with CLI generators, and the README pairs it with direct save and one click open. The mid task interaction is the other. Instead of a single turn chat that returns whatever it produced, the app streams status and can ask you to decide when it is unsure, and you can cancel and restart. The comparison table in the README puts the difference plainly: web assistants are cloud first and vendor locked with a manual download, CLI tools save directly but give you no preview and no way to answer a question halfway through, and OfficeDex claims all three of native window, direct save and inline preview. Image input is supported too, so you can paste a screenshot or upload a reference image and have it read as context.

Limits to plan around

Start with time. The README own example states typical generation of 45 to 90 seconds for a twelve page report with four charts, so this is not an interactive editor, it is a batch you wait for. The build chain leans macOS: the two bundling steps in the build script are named for macOS and one of them codesigns the app bundle, so a Windows or Linux packager has to look at the separate local build script instead. The dependency on a fetched binary is the practical one, since prefetch:officecli needs network access at build time and pins a specific OfficeCLI version. On evidence, the README is marketing heavy and publishes no accuracy or benchmark data, so the 45 to 90 second figure and the twelve page example are the project own claims rather than something measured elsewhere.

Compared with running OfficeCLI in a terminal

OfficeCLI is the engine this app wraps, and running it directly is a legitimate alternative that the README comparison table describes under CLI tools. The terminal route saves files directly and accepts any LLM, which is the same freedom OfficeDex advertises, and it scripts well if you generate documents from a pipeline. What it does not give you is the parts that need a window: no inline preview of the generated docx, pptx or xlsx, no streaming status, and no way for the model to stop and ask you a question halfway through a run. It also has no place to keep style memory, so each invocation starts from the prompt you wrote. If you generate documents from CI or from a script and read the result in Word anyway, the CLI is the simpler dependency. If a person is sitting in front of the machine and iterating on a deck, the desktop client earns its keep on preview and mid task interaction alone.

Licence, upkeep and what to verify

OfficeDex is GPL-3.0, with package.json declaring GPL-3.0-only and the repository carrying LICENSE, NOTICE and THIRD_PARTY_NOTICES.md. For internal use that costs you nothing. For redistribution it is a real constraint: a modified build you ship carries copyleft obligations, and since the app bundles a separate OfficeCLI binary plus a staged pptxgenjs runtime and ships third party notices, anyone packaging it should read those files rather than assume the badge. Upkeep looks healthy on the calendar: the last push was on 2026-09-17, and releases v0.6.9 on 2026-08-19, v0.6.8 on 2026-07-28 and v0.6.7 on 2026-07-28 are recent relative to each other. The project also ships DESIGN.md, SECURITY.md and CHANGELOG.md, which is a reasonable sign that the repository is maintained as a product and not as a demo.

Editorial conclusion

Adopt OfficeDex if you produce the same class of document repeatedly and want the output as a real docx, pptx or xlsx you can open and edit, with your own model behind it and the files staying on disk. Do not adopt it if you want a hosted service with nothing to install, or if you plan to redistribute a modified build without reading GPL-3.0 obligations first. Before committing, build it once with npm run prefetch:officecli followed by npm run dev and check that the pinned OfficeCLI 0.2.121 binary downloads in your network, since the whole generation path depends on that fetch.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. officecli/officedex on GitHub
3. Project website
4. README
5. Releases