TypeScript · Frontend · Backend

juejin-cli: A CLI Workflow That Humans and AI Agents Can Rely On for Publishing

By 浪遏 · Nov 11, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

For developers automating content pipelines, juejin-cli demonstrates a concrete pattern for making CLI interfaces consumable by AI agents: stable schemas, structured error output, and write receipts that make recovery explicit. Its separation of 'submitted' from 'published' also serves as a reminder that async review flows need their own success semantics.

Summary

Publishing a technical post to Juejin involves repetitive steps: picking categories, uploading images, creating drafts, choosing columns, and confirming acceptance. juejin-cli packages those steps into a CLI that both humans and AI agents drive through the same commands. It generates a machine-readable schema from Commander definitions, returns JSON results that hand off draft IDs to the next command, and records operation receipts so timeouts never get mistaken for failed writes.

Beyond the core publish flow, the tool now schedules daily check-ins via launchd, Task Scheduler, or systemd timers, and handles lottery draws with explicit `--allow-spend` flags. Batch publishing preflights an entire directory before writing and skips completed articles. A recent release cut unnecessary tag lookups by stopping on exact matches. The author's key design rule: never auto-replay a write after a timeout; verify the remote state first using the receipt.

Takeaways

— juejin-cli generates its agent-facing schema from the same Commander command definitions as the CLI itself, so help text and machine descriptions never drift apart.

— The `--json` mode writes a single JSON document to stdout on success and error documents to stderr with a non-zero exit code, giving agents a stable way to read draft IDs or failure reasons.

— Writes are never automatically retried after a timeout; instead, the tool records an operation ID, stage, and known draft/column IDs so the caller can check remote state before deciding the next step.

— Tag resolution now stops iterating through tag pages as soon as it finds an exact name match, eliminating unnecessary reads during draft preparation.

— Directory-level batch publishing preflights all Markdown files for errors before writing, skips articles already confirmed complete, and halts when the result of a previous write is unknown.

— Scheduled check-in separates 'execute once' from 'when to execute': the CLI runs the check-in, while launchd, Task Scheduler, or systemd user timers invoke it daily at a user-chosen local time.

— Free single draws and paid single draws share one API endpoint, so the caller must explicitly pass `--allow-spend` to accept ore deduction for paid draws.

— A lottery configuration endpoint that returns HTTP 200 with an empty body was worked around by loading the official page and using its in-page security SDK to make the protected request.

— The 0.2.0 release passed 57 offline tests and archive installation checks; reward writes for check-in and lottery still require live-account verification.

— The author distinguishes four different success points: API return, draft save, submission acceptance, and reader visibility, and tracks them separately in acceptance tests.

Conclusions

Separating 'execute once' from 'when to execute' keeps the CLI surface simple while offloading schedule complexity to the operating system, a pattern worth copying for any periodic automation task.

The write-receipt recovery flow makes the unavoidable uncertainty of network timeouts a first-class part of the API design, forcing callers to reconcile state instead of blindly retrying.

The decision to lock automated tests to draft creation after one submission was rejected by review shows that mocking success at the API level is not enough; review outcomes must be treated as separate failure modes.

Using frontmatter for publishing metadata keeps the article file self-contained, which is a pragmatic way to let both humans and agents treat the Markdown file as the single source of truth.

Concepts & terms

operation receipt

A record of a write attempt that logs an operation ID, the processing stage, and any known draft or column IDs. It lets a caller or agent recover from a timeout by checking the remote state instead of guessing whether the write happened.

dry-run

A mode that previews what an action would do without actually performing it. juejin-cli uses it to show platform results for commands like draft creation or lottery draws before the user commits to the real operation.

From the discussion

Featured comments

HummingBird 1 likes

Can it check in?

浪遏

It's supported now—welcome to try it out on the official site.

HummingBird → 浪遏

Awesome awesome awesome.

See top comments, translated →

Source: juejin.cn ↗ Google Translate ↗ Backup ↗