Writely puts an OpenAI writing assistant into any text box on the web

Notion AI's idea, applied to every editor on the web

Writely is a browser extension that puts a writing assistant into the place you are already typing. The project presents itself as an alternative to Notion AI that goes beyond it, and the difference in scope is the whole point: Notion AI lives inside Notion, while Writely attaches itself to text fields on any page you visit, so it works in a social network reply box, an article editor, a mail composer or a document on a wiki.

The listed use cases are concrete rather than abstract. It writes emails, writes articles, browses social platforms such as Twitter and Weibo so you can reply to users, and writes stories on Zhihu. The three stated features are a writing assistant available on any editor page, and a translation and reading aid that the project claims reduces reading time and improves comprehension.

The distribution is unusually broad for a small extension. It is published on the Chrome Web Store, as a Firefox Add-on and as an Edge Add-on, and the project carries a beta label in its title. The licence is MIT, the primary language is TypeScript, the default branch is main, and the repository is not archived with the last push on 2026-10-20. The homepage is writely.miao-ya.com, and the documentation exists in both English and a Chinese version at README-CN.md.

The intended user is a writer or office worker who lives in web based editors and would rather not switch to a separate assistant tab for every paragraph.

The mechanism is a W icon that appears next to your selection

The interaction has three steps and no chat window. You select text on a page, a small W icon appears near the mouse, and clicking it opens the assistant for that selection. Everything the extension does is scoped to what you highlighted, which is why the same mechanism works in a tweet box, a mail field and a long form editor without per-site configuration.

Behind that, the assistant is backed by an OpenAI GPT model, and the requests go out under your own key. Configuration is part of the install: you obtain an OpenAI API key, click the extension icon in the browser toolbar, open the Settings icon, and enter your details there. The key is therefore stored in your browser profile, and the traffic goes to the provider you chose rather than to a server run by the project, which is the privacy advantage of this arrangement and also its risk, since a browser extension with a stored key is exactly the kind of thing extension policies scrutinise.

Two details in the repository layout support the multi browser claim. There is a manifest.json for the Chromium family and a separate manifest.firefox.json, which is the usual way to ship one extension to two extension systems with the right differences, and the src/ directory holds the extension code.

A React front end on tsup, with a patched dependency tree

The build stack is visible in the package metadata, and it tells you a lot about the shape of the project. The package is named writely and is built with tsup, with the development script running tsup in watch mode and the build script running it for production, both through cross-env with a raised old space size setting:

"dev": "cross-env NODE_ENV=development NODE_OPTIONS=--max-old-space-size=8192 tsup --watch",
"build": "cross-env NODE_ENV=production NODE_OPTIONS=--max-old-space-size=8192 tsup",
"postinstall": "patch-package",
"prepare": "husky install"

The interface is React 18 with antd components and tailwindcss for styling, and the repository carries tailwind.config.cjs, postcss.config.js and tsconfig.json alongside tsup.config.ts. Internationalisation runs through i18next with the browser language detector and react-i18next bindings, which is why the project can ship both English and Chinese text.

The interesting dependency is the pair around OpenAI:

"openai": "^4.2.1",
"react": "^18.2.0",
"tailwindcss": "^3.2.7",
"tsup": "^6.7.0",

The openai client is listed among the package dependencies rather than hand rolled HTTP calls, so the request handling and the model call are the SDK's job. Alongside it sit lodash-es, markdown-it with markdown-it-highlightjs for rendering the assistant's markdown output, rangy types for text selection handling, swr for data fetching, uuid for identifiers, unstated-next and ahooks for state, react-draggable for movable panels and emoji-picker-react for the emoji panel in the UI.

The patches/ directory together with the patch-package postinstall step is the detail worth noting. It means the project carries local modifications to one of its dependencies and applies them after every install, so a fresh clone depends on that patch step running rather than on the published package alone.

The configuration flow is four steps and one API key

There is no configuration file to write and no account to create. The documented flow is: get an OpenAI API key from the platform, open the extension from the browser toolbar, open the Settings screen, and fill in the configuration. After that, the W icon appears whenever you select text on a page.

The project keeps the setup walkthrough in images rather than text, and the screenshots in the README cover the toolbar menu and the settings panel. That is a small thing, but it means the exact fields in the settings panel are only visible in the images, so the wording of each option, and whether you can pick a model or a base URL, is not something the README states in words.

The same applies to the behaviour of the assistant itself. The feature list says the product can perform query translation and assist reading, and the demo files in DEMO.md show the interface in motion, but the prompt templates, the available commands and the exact output format are not written down in the README. A user therefore has to learn the tool by trying it and reading the demos, which is normal for a beta extension and unusual for a project that otherwise has a fairly conventional engineering setup.

The i18n stack explains one thing that the README does not spell out: the extension is localised, so the interface language follows your browser, and the Chinese and English READMEs are documentation rather than a sign of two separate builds.

Version numbers that do not agree, and a quiet release history

The package metadata and the tag history tell different stories. The package declares itself like this:

"name": "writely",
"version": "1.0.0",
"license": "MIT",

The published releases are a different numbering scheme. The most recent tags are v0.0.31, v0.0.30 and v0.0.29, with the newest released on 2025-02-23 and the two before it on the same day and the day before. There has not been a tagged release since, even though the last push to main was on 2026-10-20, more than a year later, and the README still carries the beta label in its title.

That is not a criticism of the work, it is a fact about what you install. The extension listings on the three stores are what most people run, and those correspond to the tagged versions, while the repository head has moved on with a 1.0.0 version string that no tag reflects. Anyone building from source is running code that has never shipped as a release.

The MIT licence is permissive and lets you use, modify and redistribute the code, with the notice and licence text kept intact. Nothing in the repository states a support commitment for the extension stores, and the Discord link in the README is the only stated channel for questions.

Where the extension is the wrong tool

The clearest limitation is the dependency on a paid external API under your own key. Every rewrite is a request you are billed for, the extension does nothing useful without a valid key, and the key lives in your browser profile. On a managed machine where storing provider credentials in a browser extension is not permitted, the tool is simply unavailable, and there is no local model path described in the README.

The second limitation is the scope of the selection model. Because the assistant only sees what you highlighted, it cannot use the surrounding page the way an assistant embedded in a document can. A request that depends on context outside the selection, such as rewriting a paragraph to match the tone of the section above it, will not work without pasting that context into the selection. This is the concrete sense in which the project claims to go beyond Notion AI, and it is also the sense in which it is narrower: reach is wider, context is thinner.

The third is beta status combined with an unmaintained release trail. There is no public issue tracker referenced in the README for bug reports, only a Discord server, and no version of the extension is documented as tested against a particular browser release.

The fourth is the extension platform itself. Anything that needs to work in a native application, in a code editor that is not a web page, or in a locked down browser profile is out of scope by design.

Editorial conclusion

Adopt Writely if you write in web based editors all day and want a rewrite or translation action on your selection without opening a separate chat window, and if you are comfortable supplying your own OpenAI API key. Do not adopt it if you need Notion AI's built in context over your whole page, or if your key policy forbids storing a provider key in a browser extension, and do not treat it as a finished product because the README still labels it beta. Before you install, confirm that the extension store listing you use is the one this project publishes, since the same name could be reused, and check the version mismatch first: package.json says 1.0.0 while the newest tag is v0.0.31 from 2025-02-23, so you are running unreleased code from the main branch.

Frequently asked questions

Official sources

1. anc95/writely on GitHub
2. License: MIT
3. Project website
4. README
5. Releases