前回で検索ページのあと、あるある詳細ページのデザインを詰めました

トップ・検索・詳細——見た目と UX の土台は一通り整ってきました
次は 中身（あるある）をどう増やして公開するか になります

サイトは静的のまま、DB もサイト内投稿フォームもありません
中身は entries.json に追記 — ただし JSON を直しただけでは本番は変わらない（公開の回と同じく PR → マージ → CI）

コンテンツ更新の経路（GitHub）

%%{init: {'flowchart': {'rankSpacing': 28, 'nodeSpacing': 16, 'padding': 10}}}%% flowchart LR S1[entries.json 編集] --> pr_box subgraph pr_box [PR] direction TB P1[draft / published] P2[feature ブランチ] end pr_box --> S3[レビュー] --> S4["マージ<br/>CI ビルド"]

PR に DevRev タスクをひも付け、マージでタスクも閉じる — この型を AI と人の分業 で1件通して確かめました（手順の内訳は次の見出しから）

サイトの About では GitHub Issue が投稿の標準入口（サイト構成の回）— DevRev Issue は社内だけ で、外部には見せない想定です

入口	順番（要点）
自分（Computer）— 今回実走	DevRev Issue 起票 → あるある下書き（`entries.json`・draft）→ PR（Issue 連携でステージ更新）→ マージ → サイト更新
外部（運用案・未実走）	GitHub Issue で提案 → 採用判断 → Computer が裏取り・`draft`・DevRev Issue → PR → マージ → サイト更新。Git に慣れた人は直接 PR も可（採用後は同じ社内フロー）

GitHub Issue → DevRev Issue は GitHub Issues スナップイン で取り込む予定 — 外部は投稿受け口、作業の正本は DevRev のまま
詳細は ComputerとDevRev Issueで、あるある公開を管理する

Computer と Cursor — フロー上の受け渡し

最初から「書く AI」と「実装 AI」を二股に設計したわけではありません
DevRev でタスクと下書き、リポジトリでコードと PR — 公開パイプラインを1件通すうちに、担当がこの境界に乗りました

%%{init: {'flowchart': {'rankSpacing': 28, 'nodeSpacing': 16, 'padding': 10}}}%% flowchart LR comp["Computer（DevRev）<br/>裏取り・あるある下書き"] -->|entries.json + タスク| cur["Cursor（コード）<br/>実装・PR・draft 表示"]

受け渡しの単位は entries.json の差分と DevRev タスク に固定 — あとから読んでも「いまどこまで終わったか」が追いやすいです
1件ドッグフーディングで スキーマの食い違い が出たのも、この境界の話（深掘りは後の見出し）

DevRev の Issue は 非同期の伝言板 としても使えます — 詰まりをコメントで渡し、人は確認と承認に寄せる

下書きは `status` で draft と published を分ける

下書きは entries.json の各エントリに status フィールド を足すだけです

flowchart LR E[entries.json の1件] E --> D{status} D -->|draft| P[dev / PUBLIC_SHOW_DRAFTS のみ] D -->|published| B[本番ビルドに含める]

個別 Markdown 化や CMS は 今回はやらない
1ファイル追記で回る最小変更にしました

あるある1件の型（抜粋）

フィールド	ルール（短く）
`slug`	英小文字ハイフン、重複不可
`title`	症状ベースの一言
`symptom` / `cause` / `fix`	原因・対処は裏取り必須、推測で書かない
`frequency`	あるある度 1–3、深刻度ではない
`status`	下書きは `draft`、公開で `published`

想定フロー

status と型が決まったあと、あるある1件を増やすときの手順 を次の4段に固定しました
図は全体像だけ — 各ステップで「誰が何をするか」を少し補足します

%%{init: {'flowchart': {'rankSpacing': 28, 'nodeSpacing': 16, 'padding': 10}}}%% flowchart LR S1["1 下書き"] --> S2["2 目視"] --> S3["3 PR"] --> S4["4 マージ"]

1. 下書き — Computer が裏取りした内容で entries.json に status: draft の1件を追記し、DevRev に 公開用タスク を起票します
ここではまだ本番ビルドに載せません

2. 目視 — 人がローカルまたはプレビューで draft だけ表示 し、文言・スキーマ・表示崩れを確認します
「JSON に書いた＝公開OK」にはしないゲートです

3. PR — 実装側（人または Cursor）が status を published に変えた差分 で PR を出します
コード変更が不要なら 人だけで published PR でもよい — PR には対応する DevRev Issue をひも付け、開いたタイミングでステージが進む運用です

4. マージ — PR がマージされるとホスティング側が 再ビルド し、本番に反映されます
DevRev と GitHub を連携しているので、マージと同時にタスクが completed になる — 「公開したら手でタスクを閉じる」が要らなくなります

1件通して出たズレ — 深掘りより「直すまで」

最初の1件をドッグフーディング したら、机上では見えなかったズレが3つ出ました

スキーマ — 書く側の想定と、本番 entries.json のフィールド名が食い違っていた
サイト — status: draft を書いても、ビルドがフィルタしていなかった（Step 2 の目視が成立しない）
運用 — 人の目視（Step 2）を飛ばして PR まで進めてしまった（ここは AI では直せないので、フローにゲートを明示することにした）

実装側 AI が1件流したときに 詰まりを検知 し、DevRev タスクのコメントで 実装タスクの起票 を依頼しました
コード修正（draft フィルタなど）は Cursor 側で PR にまとめ、人はレビューとマージが中心 — 非同期の受け渡し が回りました

%%{init: {'flowchart': {'rankSpacing': 28, 'nodeSpacing': 16, 'padding': 10}}}%% flowchart LR Impl[実装 AI] -->|詰まりをコメント| Issue[DevRev Issue] -->|起票| Fix[実装タスク] --> PR[修正 PR] Human[人] -->|レビュー・マージ| PR

一度通した流れをスキルに固定

1件通して直したあと、同じ話を 毎回チャットで説明し直す のはもったいなので、Computer 起点用の公開スキルにまとめました
DevRev Computer の入口（下書き追記と Issue 起票まで）— published 化・実装・PR は Cursor 側 で、別物です
運用メモや設計ドキュメントだけだと「読んだつもり」でズレる — 実行時にチェックされるガードレール にしたい、という意図です

スキルに書き込んだのは、だいたい次のような やること / やらないこと です

書き込み先 — サイト本番の entries.json だけ（別経路の JSON とフィールド名が違うので、混同しない）
型 — あるある1件の必須フィールドと、原因・対処は 裏取りなしに書かない
下書き — 追記時は status: draft、公開は Cursor / 人の PR 側（Computer は published にしない）
タスク — 内容が固まったら DevRev に公開用タスクを起票し、実装やマージはここで止める

外部の GitHub Issue / PR の取り込みや採否判断は自動化していない — Computer 起点の下書きと Issue 起票用（GitHub Issues スナップインは別途）
Repo1 の Cursor ルール は実装・PR 向け — 今回スキル化したのは Computer 入口だけ です

次の1件からは、フロー図を口頭で復唱するより 公開スキルに沿って draft 追記 → タスク起票 から始められる状態にしました

今回の HACK+PLUS

見た目が揃ったあと、中身を1件通して運用を固めた 回

HACK（新しい発見）

status + ページ数差 — draft が本番に漏れない最小ガード
1件ドッグフーディング — 机上設計より早い

PLUS（ハマりどころ・次の一手）

Step 2（人間の draft 目視）は 省略しない — 初回は飛ばしたので、次はフロー上で明示する
Pagefind 移行・カテゴリ窓・OGP など サイト機能の残り は別途
あるあるは このフローで増やしていくだけ — 外部は GitHub Issue 本線＋PR任意（未実走）は ComputerとDevRev Issueで、あるある公開を管理する