# publishリファクタリング ## 目的 `.agent/workflows/publish.md` の責務を整理し、以下を実現する。 1. `publish` を「記事を公開可能状態にする」ためのワークフローとして明確化する。 2. スキル名から実行順依存を外し、「1スキル = 1機能」の原則に寄せる。 3. `publish` 完了後の知識整理・派生処理は別ワークフローへ分離する。 4. `publish` 完了後に次のワークフローへ自動で引き継げる構造にする。 ## 現状の問題 ### 1. ワークフローの責務が広すぎる 現状の `publish` は、記事の推敲と画像生成だけでなく、完了後の知識整理まで抱えている。 - 内容監査 - 関連記事追加 - 構成整理 - 文章推敲 - アイキャッチ - 補助画像 - アトミックノート候補化 - Topic coverage 監査 このため、「公開まで」と「公開後の派生処理」の境界が曖昧になっている。 ### 2. スキル名に機能と順番が混在している 例: `review-00-content` この名前には以下が同時に含まれている。 - `review`: 行為 - `00`: `publish` 内の順番 - `content`: 対象領域 問題は、スキル自体の機能と、ワークフロー内の実行順が同じ名前に埋め込まれていること。 その結果、順番変更や再利用時に名前がノイズになる。 ### 3. Phase 1 の責務が混線している 現状の Phase 1 には以下が同居している。 - 関連記事の収集 - 収集結果の本文統合 - YAML と見出し構造の整理 これは本来、別機能である。 ### 4. 依存ルールの参照が不安定 `series_definitions.md` を参照する前提になっているが、現時点では実体が見当たらない。 この状態だと、構成整理・画像生成の両方で前提が崩れている。 ## 基本方針 ### 1. `publish` の完了条件を固定する `publish` は、以下が揃った時点で完了とする。 - 内容に重大な問題がない - 必要な関連記事や根拠が統合されている - YAML と構成が整っている - 本文が読みやすく整っている - 主アイキャッチが挿入されている - 必要な場合は補助画像も挿入されている - 最終的に公開可能な状態になっている 要するに、**画像を含めた記事の仕上げ完了までが `publish`** である。 ### 2. スキルは「1機能 = 1スキル」に寄せる スキル名は、`publish` の順番ではなく、単独で見て意味が通る機能名にする。 順番はワークフロー側で管理し、スキル名には持ち込まない。 ### 3. `publish` 後の処理は別ワークフローに分離する 以下は `publish` の責務から外す。 - 記事からの知識抽出 - Permanent Note 候補作成 - Topic coverage 監査 これらは、仮に失敗しても「記事が公開できるか」とは別問題である。 ### 4. ワークフロー間の handoff を明示する `publish` の末尾に後処理を直接書き足すのではなく、次ワークフローを起動する接続として扱う。 流れ: 1. `publish` が完了する 2. 必要な入力を handoff payload としてまとめる 3. 次ワークフローを起動する ## スキルの再分類 ### A. `publish` の中核スキル 記事を公開可能状態にするために必要な機能。 - 内容監査 - 関連記事収集 - 構成整理 - 文章推敲 - 主アイキャッチ作成 - 補助画像作成 - 最終公開チェック ### B. ユーティリティ 他のスキルの下位で使う補助機能。 - 画像を assets へ移動する - 記事本文へ画像を挿入する ### C. `publish` 後の別ドメイン 知識管理・資産化に関する後処理。 - Permanent Note 候補の抽出 - Brain との統合判断 - Topic coverage の監査 ## 命名方針 ### 原則 - 連番を付けない - ワークフロー依存の順番を名前に含めない - 単独で見て何をするスキルかがわかる名前にする - `review` のような曖昧語より、できるだけ具体的な動詞を使う ### リネーム案 現状の名称から、以下のような機能名へ寄せる。 - `review-00-content` -> `audit-article-content` - `find-related-articles` -> `collect-related-articles` - `review-01-structure` -> `organize-article-structure` - `review-02-text` -> `polish-article-text` - `review-03-eyecatch` -> `create-article-eyecatch` - `review-04-support-visuals` -> `create-article-support-visuals` - `util-image` -> `insert-article-image` 補足: - `util-*` は純ユーティリティとして残してもよいが、呼び出し意図が明確なら `insert-article-image` のような機能名でもよい。 - `find-related-articles` はすでに比較的自然だが、「探す」だけでなく本文へ載せる前提が強いなら `collect-` の方が責務に近い。 ## ワークフロー再構成案 ### `publish` ワークフロー 責務: 記事を公開可能状態にする。 推奨フロー: 1. 内容監査 2. 必要なら関連記事・根拠の補強 3. 構成整理 4. 文章推敲 5. 主アイキャッチ作成 6. 必要なら補助画像作成 7. 最終公開チェック 8. 次ワークフローへの handoff ### `post-publish-knowledge` ワークフロー（新設） 責務: 記事完成後の知識抽出と内部資産化。 候補フロー: 1. 記事から独自概念・再利用可能な気づきを抽出 2. Permanent Note 候補を提案 3. 必要なら Brain 統合を実施 4. Topic coverage を監査 5. 必要なら次の整備タスクへ接続 ## `publish` の内部構成見直し ### Phase の考え方 今後は「Phase 番号」をスキル名に持たせず、`publish.md` の中でのみ順序を定義する。 ### 特に分割すべき箇所 現状の Phase 1 は、少なくとも以下に分ける。 1. `collect-related-articles` 2. `organize-article-structure` 必要なら、関連記事を本文へ統合する作業も別スキル化を検討する。 候補: - `integrate-article-references` ただし、これは `collect-related-articles` の責務に含める設計でもよい。 重要なのは、構成整理と混ぜないこと。 ## Handoff 設計 `publish` 完了後は、次ワークフローへ以下を渡せる構造にする。 - `TargetFile` - 記事タイトル - 記事の要約 - 抽出候補キーワード（2〜3個） - 必要なら `series` / `project` `publish` 側では「後処理を実行しきる」のではなく、「次ワークフローに渡す入力を確定する」ところまでを責務にする。 ## 優先順位つき実施順 ### Step 1. 責務境界を分ける まず `publish` から知識整理系を外し、別ワークフローへ移す。 最初に切り出す対象: - `create-permanent-note` - `refine-my-brain` - `audit-topic-coverage` ### Step 2. 依存ファイルを整備する `series_definitions.md` の扱いを確定する。 選択肢: 1. 実ファイルを作る 2. 参照先を既存の別ルールに変更する 3. スキル側の依存を弱める これは構成系・画像系の両方に影響するため、早めに確定する。 ### Step 3. スキル名を機能名へ寄せる 連番を外し、機能中心の名前へ移行する。 このとき、ワークフロー側の呼び出し名も合わせて更新する。 ### Step 4. Phase 1 を分割する 関連記事処理と構成整理を分離する。 ### Step 5. 共通契約を見直す `提案 -> 承認 -> 実行 -> リフレッシュ` や `implementation_plan.md` の扱いを、`publish` 個別の本文ではなく、共通ルールへ寄せるか検討する。 ## 判断基準 今後、スキルを `publish` に残すかどうかは以下で判断する。 1. その機能は、記事を公開可能状態にするために必要か 2. その機能は、単独でも他ワークフローで再利用できるか 3. その機能は、純粋な下位ユーティリティか 4. その機能は、公開後の派生作業か 判断結果: - 1なら `publish` の中核 - 2なら汎用スキルとして保持 - 3なら `util` として下位に置く - 4なら別ワークフローへ分離 ## 当面の結論 1. 画像関連は `publish` の内側に残す。これは記事の仕上げであり、公開条件の一部である。 2. `publish` の完了は「画像を含めた公開可能状態」に固定する。 3. その後の知識整理は `post-publish` 系の別ワークフローに分離する。 4. スキル名から連番を外し、機能名へ寄せる。 5. スキルの順番はワークフロー側だけで管理する。 ## 次にやること 1. `.agent/workflows/publish.md` から Handoff の知識整理部分を切り出す 2. 新しい `post-publish-knowledge.md` の骨子を作る 3. `publish` 配下のスキル名リネーム方針を確定する 4. `series_definitions.md` の参照先問題を解消する 5. `publish.md` の Phase 1 を分割する