設計思想

zudo-text は、できることを増やすより絞ることを選んだ Markdown エディタです。書くこと以外には手を出さず、書いたものはどこへでも持ち出せる形のまま置きます。画面の形もアプリ側で固定せず、設定データが決めています。日々の操作がこういう形をしているのは、その割り切りから来ています。

書くことだけに絞った道具

zudo-text が引き受けるのは、文章を書いて整えるところまでです。原稿を HTML に組み立ててサイトを作る仕事はしません。それは静的サイトジェネレータやドキュメントサービスがすでにうまくやっていることだからです。

この線引きのおかげで、いま使っている公開の仕組みを変えずに、原稿を書く道具だけを zudo-text に替えられます。書き上がった Markdown を、これまでどおりのやりかたでサイトに流し込めます。

note を 1 本だけ共有用のページとして公開する機能はありますが、これはサイトを作る機能ではなく、リンクを 1 つ渡すための機能です。詳しくは公開にまとめています。

書いたものは、Markdown 本文とその先頭の frontmatter だけでできています。zudo-text だけが読める独自の形式はどこにもありません。

このため、別のエディタに移りたくなったとき、原稿を書き直す必要はありません。同じ Markdown をそのまま渡せます。逆方向も同じで、他のツールで書いた原稿を持ち込んでも、そのまま扱えます。

Claude Code や Codex のようなコーディング用の AI に、workspace のドキュメントを直接編集させることもできます。アプリの画面を操作しなくても、AI 側から書き換えを頼めます。これは MCP連携で設定します。

frontmatter に何を書くかは、エディタではなく workspace が決めます。「日付は date という名前で書くこと」といった決まりを、zudo-text 側から押し付けません。

現実のドキュメントシステムは、公開日を date と呼んだり published と呼んだり pubDate と呼んだりします。zudo-text はそのどれが正しいかを決めず、workspace 側の宣言に合わせて、並び替えや入力補助の振る舞いを変えます。

結果として、使っているドキュメントシステムのフィールド名を、名前を変えずにそのまま使えます。設定のしかたはフロントマターにあります。

新しい機能の候補が出てきたとき、zudo-text は「他のツールがうまくやれることなら取り込まない」という側に倒します。プレビューで公開後の見た目を完全に再現することも、ビルドをアプリ側で回すことも、あえてやりません。

取り込むほど便利になるように見えますが、取り込むほど他のツールと組み合わせにくくなります。迷ったら絞る、というのがこのアプリの選びかたです。

そのぶん、覚えるべき画面と操作は少なく保たれています。使わない機能を避けて通る必要がありません。

画面の形は、ほとんどが設定データから組み立てられています。アプリ上部の toolbar の左側に並ぶ pin も、frame の分割のしかたも、Note Tray toolbar（note が並んだ帯）の位置も、アプリの中に固定で書かれてはいません。

だから、並びが気に入らなければ変えられます。よく使う画面の組み合わせを pin として保存しておけば、ワンクリックで呼び出せます。

Note

設定は workspace の中に保存されます。1 台で整えたレイアウトや配色は、同じ workspace を開いた別の端末にもそのまま現れます。