Knowledge OSで知識を蓄積しながら記事を自動作成

プロジェクトのアウトライン（目次・章立て）を読み込んで、文体・トーン・執筆方針をAIと対話形式で決定できます。 カジュアル/フォーマルの選択、一人称の表記（私/僕など）、語尾のスタイルなど細かい執筆ルールを対話の中で確定させられます。 参考にしたい記事のURLやスタイル例を提示することで、目指すトーンを具体的に共有できます。 決定した方針を「write-plan.md」に構造化して保存し、実際の執筆フェーズで一貫性のある文章を生成できるようにします。 ユーザーが明示的に同意するまで次のステップに進まず、納得できる執筆方針が確定するまで修正・調整を繰り返せます。 記事やブログ、ドキュメントを執筆する前に、文体ルールを明確にしておきたいライター・エディター 複数の執筆者がいるプロジェクトで、統一された文体・トーンを保ちたいチーム AIによる自動執筆の品質を高めたい方（方針が明確なほど生成結果が良くなる） 執筆方針の決定プロセスを記録として残しておきたい方 Phase 1 執筆準備スキルはアウトラインを読み込み、文体・トーン・執筆方針を対話形式で決定してwrite-plan.mdに保存します。プロジェクト名（$ARGUMENTS）必須で、未指定の場合は案内して終了します。context.md・goal.md・outline.mdを読み込み、不在の場合は該当フェーズを案内します。ユーザーに文体・トーン（カジュアル/フォーマル、一人称表記、語尾スタイル）、参考スタイル（任意のURL・説明）、特別な制約（文字数目安、フォーマット要件）を聞きます。回答は構造化前にoutput/$ARGUMENTS/write/input-log.mdに原文のまま記録してから、write-plan.mdへ統合・保存します。write-plan.mdはテンプレート（templates/write-plan.md参照）に従い、文体方針・アウトライン章と記事セクション対応表・執筆上の注意点（独自価値・避けるべきこと）を含めます。保存後、整理内容をユーザーに提示して同意確認し、追加・修正要望があれば反映します。ユーザーが明示的に同意したら「Phase 1完了」と伝え、Skillツール（write-body、$ARGUMENTS引数）を起動して実行フェーズに移行します。

売れるアイデアを「拾って」設計：お客さんの脳内にある「売れる世界」を探し出し、その世界で求められる隠れた提案を考える。クリエイティブに「生み出す」のではなく「拾う」ことで、実際に売れるコンセプトを発掘します。 ベネフィットを引き出して訴求：商品の特徴やメリットではなく、お客さんが本当に欲しい「嬉しい未来」を定義。「ということはつまり法」やターゲット分析で、刺さるベネフィットを導き出します。 ターゲット別に訴求トーンを切り替え：関心度別に「タイプ①（購入意欲高）→シンプルにオファー」「タイプ②（検討客）→差別化を強調」「タイプ③（非関心）→ベネフィットに徹する」と3種類の訴求を使い分けます。 キャッチ・リード・ボディの構成を一気通貫で設計：13の表現法に基づいたキャッチコピー、引き込むリード、説得するボディまで、段階的に読者の感情を動かす文章構成を組み立てられます。 広告・LP・DM等、文章だけで売る案件を手がける営業やコピーライター：アイデア発掘から執筆まで、体系立てたプロセスで効率的に売れるコピーを作りたい人。 ベネフィット抽出やターゲット別訴求を素早く出したい人：複数の商品やキャンペーンで繰り返し使える、実践的な設計フレームワークが欲しい人。 成約率を高めたい事業者：心理トリガーやオファー設計の技術を学び、非対面・非接触でもバカ売れさせる仕組みを構築したい人。 商品の価値をうまく言語化できていない人：特徴の羅列ではなく、お客さんの「欲しい気持ち」に直結するコピーを書きたい人。 セールスコピー設計ガイドは、「見て、読んで、買ってもらえるコトバの作り方」を体系化。基本は①セールスコピーは売れるアイデアを探して表現する技術であること②売れるアイデアは「拾うもの」で、3ステップ（脳内の売れる世界を探す→隠れた提案を考える→魅力的に語る）で完成すること③お客さんはベネフィット（嬉しい未来）にお金を払うこと。ベネフィット導出は「ということはつまり法」か「ターゲット像の明確化」で実施。ターゲットは関心度で3タイプ（①購入意欲高：ブランド力・信頼・超強力オファーで判定、シンプル訴求→②検討客：差別化要因で判定、違いを強調→③非関心：最高解決策提案）に分類し、各タイプのドンピシャ訴求トーンを変える。コピー構成はキャッチ（初心者4ステップ法と13の表現法）→リード→ボディの段階的構成で、読者感情を掴んでから説得へ導きます。

ブログ記事の文体・トーン、記事構成、可読性、文法をサブエージェントで並列チェックし、4つの視点からの指摘を一度に確認できます。 筆者の執筆スタイルガイドに基づいてレビューされるため、ブレのない統一感のある記事になります。 修正前にユーザーが結果を確認して承認できるため、自動修正による誤りや過度な変更を防げます。 git の最近変更ファイルから対象記事を自動検出できるため、ファイルパスを毎回指定する手間がなくなります。 公開前の最終品質チェック手段として、執筆後の工数削減になります。 ブログ記事を定期的に執筆しており、公開前に品質チェックを自動化したい ブロガーやテックライター 複数の執筆者がいるチームで、文体やトーンの統一を効率的に管理したい 編集者やマネージャー 執筆直後に見落とした文法やスタイルの問題を素早く指摘してもらいたい 執筆者 _posts/ ディレクトリ内の MDX 形式のブログ記事を管理・運営している プロジェクト ユーザーがファイルパスを指定した場合はそれを対象とし、指定がない場合はgit diff --name-onlyとgit statusで最近変更された_posts/*.mdxファイルを探します。複数見つかった場合はユーザーに選択を求めます。ワークフローは3フェーズで実行されます。Phase 1では Agent tool で4つのサブエージェント（文体・トーンチェッカー、記事構成チェッカー、可読性チェッカー、textlintチェッカー）を同時起動し、各観点からリサーチのみを実施します。全サブエージェント共通でスタイルガイド（writing-style-guide.md）を参照させ、ファイル編集は厳禁とします。文体・トーンチェッカーは「です・ます」調の一貫性、一人称の統一、控えめな表現、口語的ニュアンス、自己開示スタイル、語尾の単調さを評価します。記事構成チェッカーは記事タイプ（技術移行、ツール作成、学習記録、問題解決、アップデート報告、振り返り）を判定し、該当パターンに必要な構成要素の有無をチェックします。可読性チェッカーは段落長、文の複雑さ、リスト活用、コードブロック配置などを評価します。Phase 2では4つのサブエージェントの結果を統合してユーザーに提示します。Phase 3ではユーザーの確認を経て修正を適用します。