Qiita CLI moves article publishing into your editor and your git history

What the tool does and who it is for

Qiita CLI is described as a tool that lets you write, preview and publish articles on Qiita from your local environment, and the reasoning given is that using it makes writing and posting articles easier with the editor you already use. That is the whole proposition. Qiita's normal workflow is browser based, which means your article lives in a web editor and your drafts live in a browser tab. Qiita CLI inverts that: the article becomes a Markdown file in a directory you control, the preview happens in a local server, and the publish step pushes a file to the service. The tool is published on npm under the scoped name @qiita/qiita-cli, and the repository description is in Japanese, with an English README alongside. The README also asks for stars and, more pointedly, asks readers who have written an article with the CLI to post it to Qiita, on the reasoning that posted articles help many people and share knowledge. The project is maintained by Qiita Inc., the company behind the service, so this is a first-party tool rather than a third-party client.

Installing it, and the package name warning

The setup has a prerequisite and a warning, and the warning is worth repeating. Qiita CLI requires Node.js 22.22.1 or later. The README marks the npm package name that Qiita officially provides as @qiita/qiita-cli, and warns that anything else installs a different package, so check before installing.

npm install @qiita/qiita-cli --save-dev

You run that in the directory where you want to manage Qiita content. Confirming the install works is one command.

npx qiita version

And updating later is the same package with a tag.

npm install @qiita/qiita-cli@latest

The project also links the Qiita terms of service and privacy policy, noting that using Qiita CLI or Qiita Preview means you are treated as having agreed to them.

init, tokens and login

The init command generates the scaffolding the rest of the workflow depends on.

npx qiita init

It creates a .gitignore, a GitHub Actions workflow file, which the README points at through the item about managing articles with GitHub, and a user settings file called qiita.config.json. Next you issue a token, by visiting the Qiita token settings page while logged in and setting the token permissions to read_qiita and write_qiita. You then register that token with the login command.

npx qiita login

The command prompts for the issued token and prints a greeting with your user name once it is registered. Registering the token links your Qiita account, and from that point article retrieval, posting and updating all become available. The token is used both for the CLI login and for the GitHub-based article management, so it is the single credential the whole setup revolves around.

Preview and the file layout on disk

Writing happens with a local preview server, and running the preview command downloads the articles you have already posted to Qiita.

npx qiita preview

The default preview URL is http://localhost:8888. Article content is managed one article per Markdown file, and the article files must be inside a public directory.

.
└─ public
   ├── newArticle001.md
   └── newArticle002.md

That directory requirement is a design decision rather than a convention, and it matters because the GitHub Actions workflow and the .gitignore generated by init assume the same layout. The preview server is also where the interactive buttons live, since the README points you at a button for creating a new article on the Qiita Preview screen and a button for posting an article.

Front matter, creating and publishing

Every article file starts with a YAML front matter block between --- markers holding the article settings, and the README shows the full set of fields the tool understands. They cover title, tags, private or public visibility, the update timestamp and UUID that are filled in automatically on posting, the organization to associate the article with, slide mode, an ignorePublish switch that excludes a file from the publish command, and the two fields for linking a posting campaign, where agreeing to the campaign terms is required if a campaign UUID is given.

Creating an article is a command naming the base name of the file, and publishing takes the same base name. A single command applies every article in the directory at once.

npx qiita publish --all

The --force option, with -f as an alias, pushes the file contents to Qiita regardless of what the service thinks has changed.

Slides in Marp format, and the beta-only caveat

Slides are supported through Marp format Markdown, and the README is explicit about who can use them. The slide feature is only available to users on the beta version of Qiita. For everyone else, running pull, preview or publish means slides are not synchronised, and the slides do not appear in the preview. The publish --all command posts only the articles without the slides, and naming a slide file explicitly produces an error. Slide files live under a slides directory inside public, alongside the article files, and a file with marp: true in its front matter is treated as a slide while one without it is treated as an article.

.
└─ public
   ├── newArticle001.md
   └── slides
       ├── newSlide001.md
       └── newSlide002.md

Slide front matter carries title, id, updated_at, description, ignorePublish, a visibility block and marp, while any other key such as theme or paginate is passed through to Marp as a directive. Visibility takes public, only_me, url or members_only, and members_only requires the url_names of the users or organizations to share with. One constraint is stated plainly: a slide that has been made public cannot be returned to another visibility level.

GitHub Actions publishing and the deletion rule

The init command generates a GitHub Actions workflow so that committing to a branch publishes the articles. The setup is three steps: create a repository on GitHub, store the issued Qiita token as a secret named QIITA_TOKEN in the repository settings for Actions, and push the whole directory that init ran in. By default a commit to main or master triggers the publish and update automatically, and the condition for the run lives in the generated .github/workflows/publish.yml. The last thing to know is the deletion behaviour, and it is the sharpest edge in the tool. Articles cannot be deleted from Qiita CLI or Qiita Preview, and removing a Markdown file from the public directory does not delete the article on Qiita, which can only be done on the Qiita site itself. So the git history and the service can drift, and the file you removed is still up there. The environment sample file shows the other knobs the tool reads, with QIITA_DOMAIN, QIITA_TOKEN, QIITA_CLI_ITEMS_ROOT and the XDG cache and config paths, plus optional asset URL overrides for the article stylesheet, the embed init script and the favicon. The releases are v1.11.0 on 2026-10-20, v1.10.0 on 2026-07-30 and v1.9.1 on 2026-07-13, and the last push was on 2026-10-20.

Editorial conclusion

Adopt Qiita CLI if you already publish to Qiita and want Markdown files in version control with a local preview loop. Skip it if you write rarely, since the setup cost of a token, an init and a preview server outweighs the benefit for one article a year. Before you automate publishing, read the deletion rule, because the tool cannot remove an article from Qiita, only the file, and the front matter field that ignores a file on publish is the one to set when you are still drafting.

Frequently asked questions

Official sources

1. increments/qiita-cli on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases