Editor workflow: per-entry 'Ready to publish' flag + 'Publish all marked' action (beyond branches)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- github, typescript
- 領域
- content
調査の方向性
Start with PREVIEW.md and the existing branch-picker and branch-based editing flow described in the issue; trace how GitHub-mode saves and the GitHub App handle branches and pull requests. Done means a decided, in-product draft-to-publish workflow that covers the ready status, staged-entry view, publishing action, and any smaller-scope configuration option, with appropriate validation and tests.
索引モデルが issue の本文から書いたものです。
説明
Use case
We run a marketing site on Keystatic in GitHub mode. Editors make 5–20 small content edits throughout the day (typo fixes, copy tweaks, swapping a tagline, adding a testimonial, etc.). Today, every Save commits straight to main, which:
- Triggers a fresh production build per Save (Cloudflare Workers Build, in our case — but the same applies to Vercel, Netlify, etc.).
- Clutters git history with one micro-commit per change ("Update Hero", "Update Hero", "Update Hero", …).
- Means a typo in any save ships to production immediately.
What's already possible
We know about branchPrefix + branch-based editing — we use it, and PREVIEW.md in our repo documents a workflow where editors pick a long-lived cms/staging branch in the picker, save many times, then merge a PR to publish.
That does solve the deploy-per-save problem, and we recommend it as the answer today. Thank you for that primitive — it's the foundation.
The UX gap
Non-technical editors still need to:
- Remember to flip the branch picker to
cms/stagingbefore every session (easy to forget; defaults tomain). - Leave Keystatic and go to GitHub to open + merge the PR to publish.
- Understand what "merge a PR" means.
For technical users this is trivial. For marketing/content editors who have never opened a PR, it's the bottleneck — they often default to editing on main because the picker is right there.
Proposed feature
A first-class "draft → publish" workflow built on top of the existing branch primitive, expressed in admin-friendly language:
- A per-entry "Ready to publish" flag in each entry's Save dialog (or as a toggle in the entry form). When unchecked, Save commits to a staging branch. When checked + Save, the entry is marked as ready in the staging branch.
- A dashboard surface listing entries currently staged (changed on the staging branch vs.
main), with their "Ready to publish" status. - A single "Publish all ready" / "Publish all changes" button that merges the staging branch into the production branch (i.e. opens + auto-merges the PR via the GitHub App).
- Optional: a
defaultBranchconfig (e.g."cms/staging") so the picker doesn't default tomain— this alone would already remove a big footgun.
The branch primitive stays exactly as it is; this is purely a UX layer on top, so technical users who prefer raw branches lose nothing.
Why this isn't easily DIY-able
We can — and probably will — build a custom admin page that lists open cms/* branches and exposes a merge button via the GitHub App token. But:
- Re-implementing the auth Keystatic already does on a sibling route is non-trivial.
- It's a separate admin surface that editors have to remember exists.
- It drifts as Keystatic evolves.
A first-class flow inside Keystatic itself would be a much better fit, and would benefit every team running Keystatic at any reasonable editing volume.
Smaller-scope wins, if a full design is out of scope
Either of these alone would already be a big improvement:
defaultBranchconfig option — pickcms/stagingso editors don't accidentally land onmain.- A "Publish to production" action in the branch picker when the current branch is
cms/*— one click to open + merge the PR (instead of leaving Keystatic).
Happy to test any of this on a live editorial site if useful.
- 主要言語
- TypeScript
- スター
- 2.5k
- フォーク
- 176
- 平均マージ
- 5時間 46分
- マージ済み PR（30日）
- 3
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
Thinkmill/keystatic のほかの issue
-
Incorrect Dutch translations: “Save” is translated as “Redden”対応中かも @MilindChatrabhuji が 4 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
Typo/Grammar on Website Homepage対応中かも @Punith1117 が 150 日前に担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信
-
Array field: no visible edit button on rows and no close button in the "Edit item" dialog対応中かも @bacarndiaye が 10 日前に担当しました。 オープン
難易度 3/5 半日 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
-
Feature: post-save "publishing" notice / `onCommit` hook so editors know changes aren't live yetオープン
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
メンテナーはふだん 1 日以内に返信
Thinkmill/keystatic の issue をすべて見る
似ている issue
-
bug ready-for-agent
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
PhyberApex/kuroshiro#1687 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
microsoft/monaco-editor#5563 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
bug
難易度 1/5 1時間未満 初心者へのやさしさ 86/100
awslabs/visual-asset-management-system#937 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100