redamoon ブログ執筆・仕上げワークフロー
When to Use
- ブログ記事を書き始めるとき、書き足すとき
- 書いた記事を読者目線で読み直したいとき
- ブログ記事の執筆・編集が完了したとき
- 「記事をチェックして」「品質チェックして」「推敲して」と依頼されたとき
- ブログ用のMarkdownファイルを仕上げるとき
- 投稿先プラットフォーム（はてなブログ / note）を指定されたとき
Instructions
概要
このスキルは、ブログ記事の執筆から投稿前の仕上げまでを1つのワークフローとしてまとめたものです。工程は2つのフェーズに分かれます。
- フェーズA（執筆サイクル）: 執筆モード・読者モード・編集者モードの3つをサブエージェントとして回し、原稿そのものの質を上げる
- フェーズB（仕上げ）: textlint とプラットフォーム別フォーマットの機械的チェックを当てる
原稿の内容が固まる前にフェーズBを走らせても、書き換えでやり直しになります。フェーズAを先に回します。
ユーザーが「差し替えして」「差し替えをするように」と指示した場合は、提案文を示すだけでなく、対象部分を実際に差し替える（ApplyPatchを使ってMarkdownファイルを書き換える）ことを基本とします。
ワークフロー全体の流れ
フェーズA: 執筆サイクル（サブエージェントで回す）
┌─→ 執筆モード（blog-writer）: 書く・書き足す・申し送りに対応する
│ ↓ 原稿
│ 読者モード（blog-reader）: 新しいコンテキストで初見の読者として読む
│ ↓ 離脱ポイント・詰まり
│ 編集者モード（blog-editor）: 規範を当てて赤入れする
│ ↓ 要修正・推奨・任意
└─── 修正を適用（要修正が残る間くり返す。最大3周）
↓ 要修正 0件
フェーズB: 仕上げ（機械的チェック）
Step 1: textlintチェック（自動修正 → 残りエラー修正）
↓
Step 2: フォーマット確認（プラットフォーム別に分岐）
├── はてなブログ → hatena-formatter サブエージェント
└── note → note-formatter サブエージェント
↓
結果サマリーを報告
フェーズA: 執筆サイクル
3つのモードを、それぞれ独立したサブエージェントとして起動して回す。指示は modes/ の各ファイルをそのまま渡す。
| モード | サブエージェント名 | 指示ファイル | 使うスキル | 出すもの |
|---|---|---|---|---|
| 執筆モード | blog-writer |
modes/writer.md |
cognitive-rhythm-writing ＋ プラットフォームスキル |
原稿、開いたままの緊張 |
| 読者モード | blog-reader |
modes/reader.md |
なし（読書体験のみ） | 離脱ポイント、詰まり、置いていかれた前提 |
| 編集者モード | blog-editor |
modes/editor.md |
japanese-prose-revision ＋ cognitive-rhythm-writing |
要修正・推奨・任意の指摘と修正案 |
モードを分ける理由
一つのコンテキストで書いて読んで直すと、書き手の意図が読者の詰まりを埋めてしまい、初見の読者がどこで止まるかが見えなくなる。3つを分けるのは、この補完を切るためである。
- 読者モードは必ず新しいコンテキストで起動する。 渡してよいのは記事本文と想定読者の設定だけで、執筆の意図や前周回の指摘は渡さない
- 執筆モードには規範を渡さない。 規範を意識しながら書くと手が止まり、初稿が痩せる。規範は編集者モードで当てる
- 編集者モードには読者モードの申し送りを渡す。 読者が詰まった位置が、規範のどの項目に対応するかを特定させる
一周の手順
- 投稿先プラットフォーム、想定読者、対象ファイルを確定する（不明なら先にユーザーへ確認する）
blog-writerを起動する。初稿がすでにある場合は、前周回の申し送りへの対応から始めさせるblog-readerを新しいコンテキストで起動する。記事本文と想定読者だけを渡すblog-editorを起動する。記事本文と読者モードの報告に加えて、プラットフォームやジャンルのスキルが例外として明示している書き方を申し送りとして渡す（note 2スキルの二人称の許容、x-post-writingの呼びかけと reply 誘導など）。渡さないと、そのジャンルでは正しい書き方が基本規範を根拠に赤入れされる- 編集者モードの修正案を適用する。要修正はすべて処理し、推奨は採否を判断する
- 各モードの報告をユーザーに提示してから、次の周へ進むか判断する
周回の終了条件
次のいずれかを満たしたらフェーズBへ進む。
- 編集者モードの 要修正が0件、かつ読者モードの 離脱ポイントが0件
- 3周しても収束しない場合。このときは残った指摘をユーザーに提示し、判断を仰ぐ
同じ指摘が2周続けて残る場合は、その場で直そうとせず、構成そのものを見直す候補としてユーザーに報告する。
サブエージェントが使えない環境
サブエージェント機能がないエージェントでは、同じ指示を順に自分で適用する。ただし読者モードだけは、記事本文と想定読者以外を意図的に無視して読み、執筆の意図で補完しないようにする。この切り替えができない場合は、読者モードの精度が落ちることをユーザーに伝える。
フェーズB: 仕上げ
原稿の内容が固まってから実行する。
Step 1: textlintチェック
1-1. 自動修正の実行
npx textlint --fix "対象ファイルパス"
1-2. 残りエラーの確認
npx textlint "対象ファイルパス"
1-3. 手動修正が必要なエラーへの対応
自動修正できなかったエラーについて、以下の情報を整理する。
- 行番号
- エラー内容
- ルール名
- 修正案
修正案を適用し、再度 npx textlint を実行してエラーが0件になるまで繰り返す。
Step 2: フォーマット確認（プラットフォーム別）
投稿先のプラットフォームに応じて、対応するフォーマッターのサブエージェントを呼び出す。
プラットフォームの判定
- ユーザーが「はてなブログ」「note」と明示した場合はそれに従う
- 明示がない場合はユーザーに確認する
- ファイル名に
blog_プレフィックスがある場合ははてなブログをデフォルトとする
はてなブログの場合
hatena-formatter サブエージェントを呼び出す。主なチェック項目は以下のとおり。
- 見出しがh3（
###）から始まっているか - h1（
#）、h2（##）が使われていないか - 見出しの階層が守られているか（h3 → h4 → h5の順）
-
[:contents]が記事冒頭（フロントマター直後）にあるか - コードブロックに言語指定があるか
- 段落ごとに空行が入っているか
noteの場合
note-formatter サブエージェントを呼び出す。主なチェック項目は以下のとおり。
- 見出しがh2（
##）とh3（###）のみで構成されているか - 最初の見出しがh2（
##）になっているか（h3から始まっていないか） - h1、h4以降が使われていないか（h1→h2、h4以降→h3に変換）
- テーブル記法が使われていないか（noteでは非対応）
- はてなブログ固有記法（
[:contents]、フォトライフ記法）が含まれていないか - 段落ごとに空行が入っているか
問題があれば修正する。内容（文章そのもの）は変更しない。
結果サマリー
全工程の完了後、以下の形式で結果を報告する。
## 記事仕上げ結果
### 執筆サイクル
- 周回数: X周
- 読者モード: 離脱ポイント X件 → 0件 / 詰まり X件 → 0件
- 編集者モード: 要修正 X件（すべて対応）/ 推奨 X件（Y件を採用）
- 未解決のまま残した指摘: ...（なければ「なし」）
### textlint
- 初回エラー数: X件
- 自動修正: X件
- 手動修正: X件
- 最終エラー数: 0件
### フォーマット（プラットフォーム: はてなブログ / note）
- 修正箇所: X件（または「問題なし」）
注意事項
フェーズA
- 読者モードは新しいコンテキストで起動する。執筆の意図や前周回の指摘を渡さない
- 執筆モードに規範スキルを渡さない。規範は編集者モードで当てる
- 編集者モードは指摘と修正案を出す。適用の判断はワークフロー本体（またはユーザー）が行う
- 3周で収束しない場合は、その場で直し続けず、残った指摘をユーザーに提示する
- 各モードの報告を提示してから次のモードへ進む
フェーズB
- フェーズAで内容が固まってから走らせる。原稿を書き換える予定が残っているうちは実行しない
- textlintのエラーが0件になるまでStep 1を繰り返す
- フォーマット修正では記事の内容を変えない