執筆前の文体やトーンをAIと対話で決められる

売れるアイデアを「拾って」設計：お客さんの脳内にある「売れる世界」を探し出し、その世界で求められる隠れた提案を考える。クリエイティブに「生み出す」のではなく「拾う」ことで、実際に売れるコンセプトを発掘します。 ベネフィットを引き出して訴求：商品の特徴やメリットではなく、お客さんが本当に欲しい「嬉しい未来」を定義。「ということはつまり法」やターゲット分析で、刺さるベネフィットを導き出します。 ターゲット別に訴求トーンを切り替え：関心度別に「タイプ①（購入意欲高）→シンプルにオファー」「タイプ②（検討客）→差別化を強調」「タイプ③（非関心）→ベネフィットに徹する」と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ではユーザーの確認を経て修正を適用します。

LIFULL KEELチームの相原さんのテックブログ文体を忠実に再現した技術記事を執筆できます。 記事作成前に複数の参考ブログ記事（MCP、ログ・メトリクス欠損、経路最適化、Platform Engineering、AI開発、eBPFなど）をWebFetchで取得して文体を分析し、執筆時に自動的に再現します。 語尾表現、導入の型、セクション構成、課題の述べ方、技術用語の扱い、コード例の挿入方法、成果報告トーン、特徴的な語彙・比喩などを8つの観点から詳細に分析・適用できます。 自己紹介→背景宣言→課題説明→アプローチ→実装詳細→成果知見→まとめの標準構成で、読者が実務に活かせる技術ブログを効率よく執筆できます。 自社のテックブログで相原さんのような親しみやすく技術的に正確な記事を書きたい開発者 Platform Engineering、インフラ、観測性などの技術トピックを実務的かつ読みやすく執筆したいエンジニア 既存のブログ記事スタイルガイドを形式化し、複数ライターで統一したい技術組織 技術的な正確さと読み手への親近感のバランスを取った記事を書きたい技術ライター 本スキルは相原さんのテックブログ文体を再現するため、事前に2つ以上の参考記事（比較的安全にMCPサーバを動かす、ログ・メトリクス欠損、経路最適化ミドルウェア、LLMを利用したPlatform Engineering、OpenAI Assistants API無限スケール化、eBPF可観測性）をWebFetchして文体分析します。分析基準は8観点です。(1)文末表現：です/ます vs だ/である、バリエーション、(2)導入の型：自己紹介、背景述べ方、目的宣言、(3)セクション構成：見出し粒度・順序・命名、(4)課題述べ方：客観から入るか主観から入るか、(5)技術用語扱い：初出補足、英日使い分け、(6)コード例：前後の説明とコード量、(7)成果報告トーン：控えめか具体的数値伴うか、(8)特徴的語彙・比喩。記事構成は導入（自己紹介＋背景＋目的）→背景・課題→アプローチ→実装・詳細→成果・知見→まとめの6セクションです。見出しはH1タイトル、H2大セクション、H3サブトピックで、タイトルは簡潔で技術内容と結果を端的に表します。コードは言語指定必須、前後説明付き、必要最小限、実動作コードです。