前回で、あるあるを1件、下書きから公開まで流しました

ここまで連載でも「Issue」という語は出てきます — GitHub 側の Issue と DevRev 側の Issue も別物なので、名前が似ている3つを先に分けます

名前が似ている3つを、先に役割で分ける

もの	このプロジェクトでの役割
DevRev Issue	サイト開発・あるある1件の公開・ブログ執筆など作業の正本
GitHub Issue	外部からの「あるある提案」の投稿受け口（サイト構成を決めた回）
GitHub PR	`entries.json` など反映用の変更。DevRev Issue にひも付くコード側の記録（GitHub Issue とは別）

サイト開発・公開作業の管理先は DevRev Issue です
GitHub Issue はサイトの外に置く受け口 — ここを混同すると、どこに何を書けばいいか迷子になります

2つの入口（前回実走した経路と、外部向けの案）

前回の公開フローで 1件通したのは Computer 起点だけ です
Computer は DevRev 上で動く AI で、裏取り・あるある下書き・DevRev Issue の起票 までを担当します（実装と PR は Cursor 側）

外部向けは GitHub Issue を標準入口 にし、慣れた人向けに 直接 PR も任意 で受ける想定です — いずれも 採用判断のあと に Computer が裏取り・draft・DevRev Issue へ進めます（未実走）

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

GitHub Issue → DevRev Issue は GitHub Issues スナップイン で取り込む予定です（執筆時点では未接続）— 外部は投稿受け口、作業の正本は DevRev のまま

%%{init: {'flowchart': {'rankSpacing': 28, 'nodeSpacing': 16, 'padding': 12, 'subGraphTitleMargin': {'top': 0, 'bottom': 18}}}}%% flowchart TB subgraph own [Computer — 前回実走] direction LR O1[DevRev Issue] --> O2[下書き] --> O3[PR] --> O4[マージ] end subgraph ext [外部 — 運用案] direction LR E1[GitHub Issue] --> E2[採用] --> E3[draft + DevRev] --> E4[PR・マージ] end

直接 PR の場合は E1 が PR に読み替えるだけです — 採用後の社内フローは同じです

このサイトで使う DevRev Issue

DevRev の Issue は、作る側・運用する側の作業を Part に結び付けて追う Work の一種 です — Ticket（顧客サポートなど別用途の Work）とは別物 なので、同じ「課題」でも混同しないでください

このサイトでは 1 Issue ≒ 1 作業 の粒度で回しています

要素	ひとことで
Part	その作業が属する製品・領域（あるあるサイト用、ブログ用など）
Stage	今どこまで進んだか（triage → 開発中 → レビュー → 完了など）
Timeline	コメントと変更履歴。前回書いた AI 同士の非同期な伝言板もここです
Issue 本文	何をするか・背景・完了条件

Part は Issue そのものではありません
細かい Part 分割は、必要なときだけで十分です

PR をマージすると DevRev Issue が completed になる

ブランチ名・コミット・PR タイトル / 本文 に DevRev Issue ID を入れると、GitHub の変更と DevRev の作業が結び付きます（この org の GitHub for DevRev 連携）

PR を開く → DevRev の Stage がレビューへ（連携設定による）
マージ     → Issue が completed（※この org の連携設定）

デプロイの回で触れた Issue → PR → マージ は、DevRev Issue 起点 の流れです

「PR をマージすれば Issue が必ず完了する」は DevRev 全体の既定ではありません
このプロジェクトの連携設定 と「1 Issue = 1 作業」の粒度による話です — PR マージ＝サイト配信完了、でもありません（Vercel 反映は別途確認）

PR コメントだけで後から Issue ID を足す運用 は試す余地がありますが、記事では未検証 です
動かない場合は PR 本文へ ID を書いて確認します — コメントだけでステージが進むとは書きません

親子の Issue と、誰が起票するか

親 Issue は公開フロー全体の設計や連載執筆のまとめなど、大きな塊です
子 Issue はあるある1件の公開、draft 表示の実装、記事1本の執筆、といった単位です

担当	Issue まわり
Computer（DevRev 上の AI）	起票、Part、ステージ、あるある内容＋ draft 追記
Cursor（コード側の AI）	実装、Git/PR、起票済み Issue の検証
人間	draft プレビューの目視、マージ判断

Cursor は Issue を新規起票しません — 境界を決めておくと、受け渡しがぶれません

あるある1件が DevRev Issue になる手順

前回の4段フローを、Issue 用語で書き直すと次のようになります

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

2. 目視 — 人がローカルまたはプレビューで draft を確認します
「JSON に書いた＝公開 OK」にはしないゲートです

3. PR — Cursor（または人）が status を published に変えた差分で PR を出します
PR には対応する DevRev Issue をひも付けます

4. マージ — マージでサイトが更新され、連携設定どおり Issue が completed になります

起票時に Issue 本文へ書いておくもの（例）は次のとおりです

slug、下書きの要点、裏取りの出典
Step 2 を誰がいつやるか（公開 PR の前）
公開 PR は Cursor 担当、など

あるある1件 = Issue 1件 — タイトルも「あるある公開: 〇〇」のように、1作業が一目で分かる形にしています

1件通したときに Issue まわりで起きたこと

公開フローを設計した 親 Issue の下に、1件目を公開する Issue を立てて流しました

途中で draft をサイトが表示できない 穴が見つかり、実装用 Issue が割り込みました（親子＝内訳、依存＝順序、は別概念です）

実装側 AI が Timeline で「実装 Issue を起票して」と依頼し、Computer が起票して返信しました
人間はほぼ承認 — 前回で書いた「非同期の受け渡し」の詳細版です

初回はフロー上の Step 2（人間の draft 目視）を省略して公開 PR まで一気に進めてしまいました
次回以降は必須ゲートにします — 図は「守れた理想」ではなく「次に守るフロー」として読んでください

Computer が Issue を起票するタイミング

Computer 起点では、ネタが確定して entries.json に draft を追記するタイミングで、内容と DevRev Issue を同時に残します

外部提案では、GitHub Issue または PR を受け取り、人が採用を決めたあと に進めます
PR が来ただけでは DevRev Issue は起票しません — GitHub Issue はスナップイン取り込み予定です（未接続の間は Computer が DevRev Issue を手起票します）

採用後は Computer が重複・機密・匿名化・schema・裏取りを確認してから draft と Issue を作ります
Cursor は実装・PR・DevRev 上の確認まで — 新規 Issue の起票はしません（プロジェクトルール）

1件通したあと、ガードレールを Computer 起点用の公開スキル に固定しました
実装・PR 用の Cursor ルールとは別物です。GitHub Issues スナップイン も別途 — 手順書だけでなく、実行時に迷わない線引き として残しています

今回の HACK+PLUS

DevRev Issue をはっきりさせた回です

HACK（新しい発見）

Issue / Ticket / GitHub Issue — DevRev 内でも Work の種類が違う
PRマージで Issue が completed — 前回の体感に、GitHub 連携の意味がつながった

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

外部は GitHub Issue 本線＋PR 任意（未実走） — About 文案拡充は別途