記事・ライティング

プロジェクトのアウトライン（目次・章立て）を読み込んで、文体・トーン・執筆方針を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ではユーザーの確認を経て修正を適用します。

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サブトピックで、タイトルは簡潔で技術内容と結果を端的に表します。コードは言語指定必須、前後説明付き、必要最小限、実動作コードです。

記事タイトル・スラッグ・筆者情報から、ブログ記事ファイルとフォルダ構造を一括作成できます。 記事メタデータ（公開日、タグ、カテゴリー）をMarkdown形式で自動設定し、すぐに編集を始められる状態にします。 日付形式（YYMMDD）を自動計算し、ファイル名に適切に反映させます。 アイキャッチ画像を配置するフォルダを自動作成し、.gitkeep で構造を保持できます。 既存タグの参考リストを提示し、新規タグか既存タグかを判断しやすくします。 ブログをよく更新する育児系・生活系ブログの筆者 複数筆者でブログを管理しており、ファイルネーミング規則を統一したい編集者 毎回ファイル構造やメタデータを手入力するのが面倒だと感じているブロガー 「新しい記事書きたい」と言うだけで、雛形を整えて欲しい方 このスキルは、ユーザーから「新しいブログ書きたい」「記事を作りたい」などの依頼を受けると、6つの情報をユーザーに確認します。(1)日本語の記事タイトル、(2)URLに使う英数字ハイフン形式のスラッグ（例: tokyo-trip）、(3)筆者（ぢぴ氏またはパパ氏）、(4)公開日（YYYY-MM-DD形式、省略時は今日）、(5)カンマ区切りのタグ、(6)カテゴリー（日記・速報・小言から選択）。その後、日付をYYMMDD形式に変換し、筆者に応じてファイル名を決定します（ぢぴ氏: content/posts/YYMMDD-{スラッグ}.md、パパ氏: content/posts/papashi-YYMMDD-{スラッグ}.md）。最後に、Front Matterを含むMarkdownファイルを作成し、static/images/posts/{YYMMDD-スラッグ}/ ディレクトリを作成して .gitkeep を置きます。完了後、ファイルパス、画像配置方法、参考リソース（/write-guide、/preview）を案内します。

ブログのテーマをヒアリングしながら、Zenn互換のMarkdown記事を対話的に構成・執筆できます。 Playwright CLI でブラウザスクリーンショットや動画を自動撮影し、手順や操作フローを画像で記録できます。 読者像・記事のゴール・トーン（チュートリアル/解説/体験記など）を確認し、読みやすい構成を自動生成します。 セクション、コード例、アウトラインをテンプレート化した上で、Zenn Topics タグも自動提案します。 完成後のファイルを blog-output/ に整理して出力し、Zennへの投稿準備が完了します。 エンジニアで、使った技術や知見をZennに記事化したいが、構成や見出しに迷う方 ソフトウェアの紹介・チュートリアル記事を書く際に、スクリーンショット撮影を自動化したい方 技術ブログを継続的に書きたいが、毎回ゼロから構成を考えるのが負担な方 デモ動画やスクリーンショットが豊富で、わかりやすい記事を短時間で完成させたい方 ブログ記事作成は5つのフェーズで進みます。Phase 1（ディスカッション2-3回）では記事ゴール・想定読者・記事種別を対話で確認、Phase 2（アウトライン確定）では構成・撮影計画を表形式でユーザーに提示し承認を得ます。Phase 3（素材撮影）では Playwright CLI でスクリーンショット・動画・GIF を撮影、blog-output/NNN/ ディレクトリに連番で整理します。ffmpeg は GIF変換に必要。Phase 4（記事執筆）で Zenn互換Markdown を生成、Phase 5（完了）でファイルパスと概要を報告します。入力パラメータはテーマ・方向性・対象URL で、短い指示でも Phase 1 から対話を開始し、不足情報を補います。

連載全体の無料回・有料回の配置戦略を提案できます。初回無料→以降有料、交互型、マガジン一括型など複数パターンから最適設計を選択。 1記事内で「ここから有料」の境界線を引く設計支援。無料部分で信頼構築し、有料部分で一次情報・深掘り内容を配置するメリハリを実現。 コンテンツの希少性と外部導線に基づいた価格設定の提案。フォロワー数に依存しない、実データ根拠の課金戦略。 マガジン構成の検討。複数記事を効率的にバンドル販売し、読者の継続購入を促進。 noteで連載記事を書く予定の著者・ライター。無料・有料の切り分けで悩んでいるとき。 個人ブランドで情報発信・マネタイズしたい人。初期段階から「有料記事の人」として認知を確立したい。 インタビュー記事やレポート企画を連載する人。ai-interview-articleスキルと組み合わせて、企画から課金設計まで一貫対応。 noteでの収入を増やしたい執筆者。フォロワー数ではなく「ここでしか読めない内容」で売上を作る戦略を知りたい。 基本原則：無料は集客・信頼構築、有料は回収・一次情報提供という役割分離。フォロワー数は購入判定に相関しない。購入決定要因は「コンテンツ希少性」「外部導線」「無料部分の質」の3要素。最初から「有料記事も書く人」として認知されることが長期的に有利。3つの配置パターン：(A) 初回無料→以降有料（推奨）、(B) 交互型（無料で定期拡散・新規呼び込み）、(C) マガジン一括型（バンドル割引）。判断フロー：一次情報の有無→外部導線の有無→連載長を踏まえてパターン選択。1記事内設計は無料エリアに「共感・問いかけ」「変化の物語」「ベネフィット提示」の3要素を入れ、有料ラインはその後に配置。無料部分の充実が有料転換の鍵となります。

公開前の品質チェックを自動実行：記事のタイトル重複確認、ですます調の統一性、見出しフォーマットなどを一括チェックして問題箇所を報告します。 記事ファイルの内容検証：articles.jsonとの照合により既存記事との重複を検出し、類似タイトルがないか事前に警告します。 tone（文体）と表現ルールの自動チェック：指定カテゴリの記事に対して一人称トーン、禁止フレーズ、キャリア年数の具体的記述などを検査します。 Markdown形式の整合性確認：ProseMirrorエディタとの互換性問題（見出しの段落結合など）を事前に検出し、修正提案を自動生成します。 公開後の業務フローをガイド：チェック完了後、下書き投稿からkimnyによる最終確認・公開まで、各フェーズの手順を管理・案内します。 note記事の編集者・ライター：公開前の煩雑なチェック作業を自動化し、修正箇所を素早く把握できます。 編集フロー管理者：複数著者の記事品質を統一的に管理し、公開ガイドラインへの準拠を確保します。 ブランド・SNS運用チーム：記事の重複投稿を防ぎ、tone統一による一貫したブランドボイスを維持できます。 コンテンツ品質保証担当者：自動チェックで基本的な問題を事前に排除し、手動レビューの効率を高めます。 フロー全体：write課ドラフト受領→conductor公開GO→Phase 1公開前チェック（自動、Chrome不要）→Phase 2下書き投稿→Phase 3kimny確認・公開（手動）→Phase 4公開後処理。 Phase 1（自動チェック）：(1-1)articles.jsonとの重複確認【タイトル完全一致でBLOCK、類似度80%以上でWARNING、note_id一致でBLOCK、statusが"published"または"unpublished"の記事のみ照合対象】、(1-2)Cat1（AIトレンド/Claude Code運用）カテゴリ記事のですます調チェック【ですます調統一、kimny一人称トーン、キャリア年数を具体数字で非使用、スタートアップ創業者口調の回避、MUEDをブランド名として使用、架空エピソード非含】、(1-3)h2見出し整合性チェック【正しいMarkdownフォーマット確認、見出し前後の空行確認、ネスト構造チェック、修正提案を自動生成】。Phase 1レポート出力形式：重複チェック/ですます調/h2見出しの各セクションで✅PASS/❌BLOCK/⚠️WARNING判定を記載し、最終判定GO/NEEDS FIXを提示。NEEDS FIXの場合は修正内容を示して再チェック、GOの場合はPhase 2へ。 Phase 2：note-article-postスキルに委譲。Phase 3：kimnyが手動で下書き→公開を実施。

ブログの投稿日時データから、年間の月別投稿数グラフ（monthly）を自動生成できます。 各月の日別投稿数グラフ（daily）も同時に生成され、投稿パターンを視覚化できます。 複数年・複数月のグラフを並行処理で高速に生成し、PNG形式でoutputディレクトリに保存できます。 生成されたグラフファイルを一覧表示して、投稿統計の傾向を一目で把握できます。 新しい記事が追加されたときに、統計データを最新の状態で更新できます。 ブログの投稿頻度や傾向を可視化したいブロガー 継続的に記事を執筆しており、自分のペースを分析したい人 ブログ統計をサイトに表示したい技術ブロガー 執筆活動を数字で把握し、計画を立てたい人 mkdir -p output && podman build -t blog-analytics tools/blog-analytics/でoutputディレクトリを作成し、コンテナをビルドします。その後、存在する全ての年のmonthlyグラフと投稿がある全ての月のdailyグラフを並行生成するワンライナーを実行します。具体的には、blog/[0-9][0-9][0-9][0-9]ディレクトリ配下をループして年別monthlyグラフを生成し、同時に各年の月別dailyグラフを生成します。各実行はpodman run --rm -v ./blog:/data/blog:ro -v ./output:/data/output blog-analyticsコマンドで、--year、--month、--outputオプションを指定します。最後にls -la output/*.pngで生成結果を確認し、output/YYYY-monthly.pngやoutput/YYYY-MM-daily.pngとして保存されたファイルをユーザーに報告します。outputディレクトリは.gitignoreに含まれており、Podman実行環境が必要です。

読者にとって価値のある技術ブログ記事を、構成・内容の質を最優先に執筆・編集できます。 TL;DR（要点）から具体的なコード例・考察までを含む標準的な記事構成を自動生成し、テーマに応じてカスタマイズできます。 textlint による文法チェックと cli lint による Markdown レンダリング検証を自動実行し、品質を保証します。 テーマ（ライブラリ紹介・問題解決・概念解説・チュートリアル）ごとに最適な構成テンプレートを提案できます。 「なぜ」を含めた解説、自分の言葉での考察、動作確認済みのコード例など、技術者・研究者向けの高品質な記事作成をガイドします。 illumination-k.dev での技術情報発信を担当しているブロガーやエンジニア 技術記事の質を高めたい個人ブロガーや企業のテックブログ担当者 ライブラリ紹介・チュートリアル・概念解説など、タイプ別の記事構成を学びたい技術ライター 記事の文法・構成・内容品質を一括チェックして完成度を高めたい執筆者 技術ブログ記事を執筆・編集する際、まず読者が得るもの（記事後に何ができるようになるか）とスコープ（どこまで書くか）をユーザーと確認します。標準的な構成は TL;DR・背景・本題（複数セクション）・まとめとし、テーマに応じて「ライブラリ紹介系」「問題解決系」「概念解説系」「チュートリアル系」の4パターンから選択できます。質に関する原則として「自分の言葉で書く」「なぜを含める」「動くコードを書く」「不正確なことは書かない」を必須とし、「冒頭で期待値設定」「セクション間のつながり」「結論の明確化」「公式ドキュメントへのリンク」「バージョン・日付の明記」を心がけ、「網羅性重視」「前提知識の説明に紙面を割く」「定型的な挨拶」を避けます。執筆手順は（1）pnpm cli template で雛形生成（ai-generated タグ必須）（2）Front-matter 編集（3）構成案を作成してユーザー確認（4）本文執筆（h2 セクション・h3 サブセクション）（5）textlint 実行（6）cli lint 実行（7）snapshot/slack.md へ書き出し（Markdown 機能: 標準 Markdown・KaTeX 数式・GitHub 埋め込み・図表対応）という7ステップです。

著者のペルソナに沿った文体をチェック：記事が55歳の個人事業主プログラマというキャラクターから逸脱していないか確認し、「AI驚き屋」ではなく淡々とした語り口に統一します。 テキスト分析ツール（Linter）で文法・表記をチェック：npx textlint コマンドを実行し、日本語の文法や冗長表現などの機械的な指摘をすべて修正。言葉遣いの不自然さを客観的に検出します。 トーンと文体の一貫性を確保：「ですます調」で統一し、AIっぽい「あなたは」「いるんです」といった表現や先回り感のある文を削除。個人の学習体験として自然に読める記事に仕上げます。 太字や構成を最適化：本当に強調すべき技術用語だけに太字を絞り、冗長な前置きを削って読者を引き込む文章構成に改善します。 Zennで技術記事を連載している個人ブロガー：記事の読みやすさや個性をプロフェッショナルなレベルに高めたい人。 自分の経験を「教える」のではなく「共有したい」ブロガー：押し付けがましくない、自然な語り口で記事を磨きたい人。 複数の記事を管理していて文体の統一に悩む著者：キャラクター設定に沿った一貫した文風を保ちたい人。 初稿は書いたが、言葉遣いや表現が自然かどうか不安な人：客観的なフィードバックで記事の完成度を上げたい人。 Zenn技術記事の校正スキルは、55歳の個人事業主プログラマという著者ペルソナ（新技術にはすぐ手を出すが煽りではなく淡々、Web系は広く浅い、ベテランの落ち着き、OSSへのリスペクト、自分のシステムの限界も認める）に基づいて記事内容をチェックします。校正重点項目は①トーン（「ですます調」統一、先回り感のない表現、AIっぽさ回避、自然な主語、淡々とした事実述べ）②冗長性（前置き削除、不要な説明削除、「調べてみると」の簡潔化）③太字の適切な使用（重要用語・本質的違い・表対比は可、ラベルや普通の名詞は不可）④記事の構成（個人の学習体験順で展開、「人に勧める」ではなく「判断を共有」）です。必須で npx textlint "記事パス" を実行してtextlint-jaの指摘をすべて修正し、防衛的表現や不要な感想を削除。実体験を入れて読者共感を促し、最後に再度Linterで検証します。

記事がAI生成特有の不自然な表現を含んでいないか自動検出し、著者らしい自然な言い換えを提案します。 文体の一貫性（敬語統一、一人称統一、段落構成など）を実地チェックし、読みにくい部分を指摘できます。 誤字脱字・技術用語のスペルミス・マークダウン記法の崩れを一括スキャンして修正案を示します。 見出しの構成、コードブロックの説明、画像の挿入位置、補足・注意の使い方など、読みやすさを総合判定できます。 Zennに技術記事を公開する前に品質チェックしたい執筆者 AIに生成させた記事を人間らしく修正する必要がある人 長編記事の自動校正で作業時間を短縮したい人 記事の下書きから公開まで一貫した品質基準を保ちたい人 Zenn記事レビュースキルは4つの並列サブエージェントで構成。（1）AIくさい表現チェック：「～と言えるでしょう」「～において」「画期的な」「及び」など赤信号表現と「非常に」「一方で」など黄信号表現を検出、著者の自然な文体（「してみました」「いいなーと思い」「かもしれません」など）への修正案提示。（2）文体自然さ：「です・ます」調統一、一人称統一、技術用語初出説明、段落長・文長チェック、接続詞バリエーション確認、「はじめに」と「まとめ」の構成確認。（3）誤字脱字・表記：日本語誤字、技術用語スペルミス、助詞誤り、括弧対応、マークダウン崩れ、全角半角混在、句読点統一。（4）読みやすさ：記事ゴール明確性、見出し粒度、段落長、コードブロック言語指定・説明、画像説明、リンク形式、メッセージボックス活用、前提条件明記、まとめの唐突性チェック。結果はテーブル形式で行番号・現在表現・修正案・重要度を明記し出力します。

Zenn Book 形式の技術書籍とそれに対応するサンプルコードリポジトリの品質を、複数の観点から包括的にレビューできます。執筆後のセルフレビューや、プッシュ前の最終確認に使用します。 スタイルガイドに沿った表現・技術的正確性（AWSサービス名・モデルID・コマンド）・チャプター間の構成整合性を自動チェックし、問題を指摘します。 本文中のコードブロックとサンプルコードリポジトリの対応ファイルが一致しているか、リポジトリ内のコードが実行可能な状態かを検証します。 設計スペック（2026-04-13-ai-agent-book-design.md）との整合性も確認し、計画した内容が実装されているかを保証します。 Zenn Book で技術書籍を執筆・管理している著者 書籍の完成度を高めたい、執筆後のセルフチェックを自動化したい方 サンプルコードとの整合性を保ちながら執筆したい方 スタイルガイドや技術的正確性を一貫して保ちたい方 このスキルは、Zenn Book（books/ai-agent-with-strands-agents/）と GitHub リモートリポジトリ（https://github.com/n-yokomachi/building-ai-agents-on-aws-samples）の2つを対象にレビューを実施します。レビュー観点は5つ：①スタイルガイド準拠（ですます調統一・絵文字不使用・AI特有言い回し排除・略語初出時の正式名称併記・形式名詞のひらがな表記・冗長表現チェック）、②技術的正確性（AWSサービス名表記・モデルID正確性・コマンド/パッケージ名/import文正確性・AWS現行仕様との一致、WebSearch による必要に応じたファクトチェック）、③構成整合性（config.yaml のチャプター存在確認・チャプター間参照の正確性・「はじめに」の章構成表との一致）、④サンプルコード整合性（本文コードブロックとリポジトリファイルの一致・ファイル名パスの正確性・リポジトリ README の章構成一致・コードの実行可能性確認）、⑤設計スペック整合性（docs/superpowers/specs/2026-04-13-ai-agent-book-design.md との一致）です。出力形式は A〜E の各観点ごとに ✅/❌ と指摘内容をリスト化し、最後に PASS/FAIL と要修正件数を報告します。

技術情報を正確に伝えながら、筆者の個性と親しみやすさが光るブログ記事を執筆・推敲できます。 AI生成文章特有の「臭さ」（汎用的な表現・読者との共感不足・曖昧な導入）を排除し、人間味のある文章に改善できます。 自分の経験・課題から始まり、段階的説明と対比を使った分かりやすい本文、明確な結論に至る4段階構成を実現します。 技術ブログを定期更新していて、一貫性のある文体で記事を書きたいブロガー・エンジニア ブログの下書きやAI生成文章をレビュー・推敲する編集者 noteやmediumで技術情報を発信しており、読者との共感を大切にしたい執筆者 記事構成は導入（背景説明）→問題提起→解決策の詳細→まとめの4段階です。導入部は「## はじめに」などの見出しなしで本文から始め、パターンAは自分の経験から、パターンBは具体例から、パターンC（推奨）は時代背景→一般課題→自分の経験の3段構成で共感の土台を作り、最後に記事全体の結論を先出しします。本文では段階的説明・対比による説明（NG例とOK例）・自然に思いつくメタファーを活用します。参考資料として voice-and-tone.md（話し言葉・一人称・問いかけ）、writing-guidelines.md（見出し・導入・結論・対比・メタファー）、ai-police-checklist.md（AI臭さ排除項目）を参照します。

ユーザーの原文やメモを受け取り、過去の投稿スタイルに統一したQiita記事を自動生成できます。 記事の種類（備忘録・Tips系、問題解決系、手順・チュートリアル系など）を自動判定し、最適な構成パターンを適用できます。 タイトルのカテゴリ表記【】、タグの選定、フロントマターの自動設定など、Qiita投稿に必要な形式を整えて public/ ディレクトリに保存します。 文体や見出し構成、コードブロック表記など、過去の記事との一貫性を保ったまま、読みやすい技術記事を生成できます。 技術メモや備忘録をQiita記事として定期的に投稿する開発者 Qiita記事の文体・構成を統一したいが、毎回手作業で調整するのが面倒な人 既存の投稿スタイルを保ちながら、効率的に複数の記事を作成したい執筆者 「記事を書きたい」「技術メモを記事にしたい」といった指示だけで、すぐに投稿可能な形式の記事を作成したい人 public/ 配下に記事を作成する際、references/writing-style.md から文体・構成ルールを読み込み、統一されたスタイルで記事を生成するスキル。ユーザーが「Qiitaに記事を書きたい」「記事作成して」「記事投稿したい」「技術メモを記事にしたい」と言ったときや、public/ ディレクトリ内の .md ファイルを新規作成・編集するときに発動。フロントマターはtitle: 【カテゴリ】記事タイトル、tags: 2-5個、id/updated_at: 空/null の形式で統一。ファイル名は英語のケバブケース。冒頭1-2行で動機を簡潔に、見出しは ## 主体で ### は手順番号付き、コードブロックは言語指定必須、常体基本で敬体は控え目、セクション区切りは ---、記事末尾に「補足」「注意事項」「参考」をまとめる。4つの構成パターン（備忘録系・問題解決系・チュートリアル系・解説系）から適切なものを選択して生成。

単品レビュー・ベストバイまとめ・製品比較の3タイプから選んで、SEO最適化されたアフィリエイト記事をMDX形式で生成できます。 E-E-A-T（Experience、Expertise、Authoritativeness、Trustworthiness）に準拠した信頼できる記事が仕上がり、検索上位を狙いやすくなります。 AffiliateCard コンポーネント（Amazon ASIN連携）を自動挿入でき、そのまま記事を公開できます。 ハルシネーション防止のため、スペック・価格・受賞歴を公式サイトで検証し、根拠のない主張を避けられます。 テック・ガジェットブログ運営者：SEOを意識した高品質な記事を定期的に出したい アフィリエイター：Amazon リンク経由の成約を増やしたい メディア運営チーム：複数記事を効率的に企画・執筆・公開したい コンテンツマーケター：長尾キーワードを狙った記事を体系的に増やしたい 6ステップのワークフロー：(1)記事タイプ決定（単品レビュー/まとめ記事/比較記事）、(2)情報収集と検証（受賞歴・スペック・価格を公式サイトで確認、ASIN取得）、(3)構成設計（H2見出しにロングテールキーワード含め「[製品名] [機能]｜[ベネフィット]」形式で書く、内部リンク2本以上）、(4)執筆（丁寧語で「僕」を一人称、Experience/Expertise/Authoritativeness/Trustworthiness要素を必須記載、表形式でスペック表示、AffiliateCard コンポーネントにASINと価格を指定）、(5)品質チェック（SEOチェック、ハルシネーション確認、デメリット記載確認、pnpm build 成功確認）、(6)公開（git commit & push & PR作成）。

「記事を書きたい」という要望から、ピラミッド原則とSCQAフレームワークに基づき、読者を引き込める技術記事を6フェーズで段階的に完成させられます。 ユーザーと対話しながら進むため、途中で方針修正できし、自分の思いと違う記事になる失敗を防げます。 目的・読者層・構成・執筆・推敲・公開設定が体系的に進むため、品質が安定し、執筆時間を大幅に削減できます。 導入部を SCQA（Situation → Complication → Question → Answer）で設計するため、読者が最初から引き込まれる記事になります。 テック企業のブロガー・エンジニア：定期的に技術記事を公開したい、でも何から始めればいいか分からない 初めてブログを始める技術者：「良い記事」の構成やロジックを学びながら書きたい 社内ナレッジ共有チーム：複数の技術情報を体系的な記事に整理したい Zenn/Qiita 投稿者：アクセス・スター数を伸ばしたい 6フェーズワークフロー：(1) 目的と読者の確認（記事ゴール・想定読者・前提知識・読了後の期待状態を質問で明確化）、(2) SCQA導入部の設計（Situation/Complication/Question/Answer 各要素を定義）、(3) ピラミッド構造でセクション構成（結論を支える3〜5個のキーポイント → 各セクションの詳細トピック を洗い出し）、(4) 各セクションの執筆（セクション単位で執筆 → ユーザーレビュー → 修正を繰り返す）、(5) 全セクション推敲と微調整（全体の流れ・用語の一貫性を確認）、(6) 公開設定（メタディスクリプション、タグ、公開日の確認）。ピラミッド原則は結論を先に述べ、その後に根拠・詳細を階層構造で展開します。

700件以上の構造辞書から関連パターンを自動検索し、記事作成の基礎となる知識を即座に呼び出せます。 記事を書きながら新しいパターンや接続関係を発見し、その都度Knowledge OSに追加することで、辞書を自動的に成長させられます。 メカニズムID（C/T/F/V/PO/TE/E）、メタパターン、アーキタイプなどの構造条件を自動判定し、シナリオ分岐や推奨ポスチャーを記事に組み込めます。 同じ知識を何度も調べ直す手間をなくし、検索→執筆→知識追加のサイクルを効率化できます。 継続的に記事や分析を書く必要があるライター・アナリスト 複雑なパターンや構造を整理しながら学びたい研究者・エンジニア 自分の知識体系を「生きたシステム」として成長させたい人 過去の分析パターンを効率よく再利用したい組織 実行フロー：(1)Knowledge OS検索でパターンやエンティティを特定 → (2)Action Layer適用で構造条件を抽出 → (3)記事作成時に構造→行動→警告を組み込む → (4)Knowledge OS更新で新発見を追加。検索対象はpattern-dictionary.md（メカニズムID）、meta-patterns.md（メタパターン）、archetype-registry.md（アーキタイプ）、pattern-stacks.md、pattern-canon-v1.md、120_Core/（関連エンティティ）、135_Meta/cross-entity-matrix.md（ドメイン横断接続）。Phase 2では040_OS/action-grammar.mdから構造条件（SC-01〜SC-10：escalation-spiral、institutional-erosion、legitimacy-fracture、technological-displacement等）を特定し、142_Action/ファイルからシナリオ分岐、推奨ポスチャー（AP-01〜08）、アンチパターン（ANT-01〜07）、決定シグナルを抽出して記事に適用します。

Zenn 記事公開後、ワンコマンドで X にポストできる。記事ファイルを指定するだけで、URL や ハッシュタグを自動生成し、280文字以内に収まるポスト文を作成します。 YAML frontmatter から自動的にメタデータを取得できる。title、emoji、topics、publication_name、published ステータスなどを読み込み、ハッシュタグマッピングに従って適切なタグを生成します。 記事内容から短いリード文を自動生成できる。記事本文を分析して、読者が「読んでみたい」と思える 50〜80文字のリード文を作成します。 複数のパブリケーション・ユーザーに対応できる。publication_name があれば zenn.dev/{publication_name} 形式の URL、なければ .env の ZENN_USERNAME を使って正しく構築します。 Zenn で記事執筆し、X でも宣伝したいブロガー。毎回手動でポスト文を作成する手間が省け、SNS 連携がスムーズになります。 技術記事を定期的に公開するエンジニア。公開直後に自動的に拡散でき、読者へのリーチが増えます。 複数のパブリケーションで執筆している執筆者。publication_name の有無に関わらず、正しい記事 URL が自動生成されます。 SNS マーケティングを効率化したい編集者・プロデューサー。投稿前のユーザー確認も組み込まれており、品質を損なわず自動化できます。 Zenn 記事を公開後、X にポストするスキル。前提として .env に X API の 4 つの認証情報（X_API_KEY、X_API_SECRET、X_ACCESS_TOKEN、X_ACCESS_TOKEN_SECRET）と ZENN_USERNAME を設定し、npm install 済みであること。記事特定は引数 $ARGUMENTS がある場合は articles/$ARGUMENTS（.md 補完）、なければ git diff でコミット予定の変更ファイルを探し、それでも見つからない場合は最新ファイルを自動選択。YAML frontmatter から title、emoji、topics、publication_name、published ステータスを抽出し、published が false なら警告。URL 構築は publication_name あれば https://zenn.dev/{publication_name}/articles/{slug}、なければ https://zenn.dev/{ZENN_USERNAME}/articles/{slug} とします。topics から最大4個のハッシュタグを CLAUDE.md「topics 一覧」を参照して生成し、末尾に #zenn を固定追加（計最大5個、一覧にない topic は # + 先頭大文字化）。リード文は記事本文から要点を 1〜2 文・50〜80 文字に短縮、「〜をまとめました」など自然な語尾で作成。最終ポスト内容は `{emoji} {title} {リード文} {url} {hashtags} #zenn 形式で組み立て、ユーザー確認後に npx tsx scripts/x-post.ts` で投稿実行。成功時は返されたポスト URL を表示。

はてなブログの記事 URL を指定するだけで、本文全体を Markdown 形式に自動変換して保存できます。 画像は絶対 URL で保持されるため、ローカルに保存後も画像リンクが正しく機能します。 サイドバー、ヘッダー、フッター、広告などの不要な要素を自動削除。本文に集中した Markdown が得られます。 記事タイトル、URL、抽出日時などを YAML フロントマターとして自動付与。ファイル名も記事タイトルから自動生成されます。 複数の記事を順次抽出・保存も可能。出力先ディレクトリもカスタマイズできます。 はてなブログの記事をローカル管理・ポートフォリオ化したい執筆者 複数のはてなブログ記事をまとめて Markdown 化し、別プラットフォームに移行したい方 ブログコンテンツをドキュメント化・アーカイブしたい方 記事メタデータ（タイトル、URL、抽出日）を自動で管理したい方 使用方法: /hatena-md で抽出実行。デフォルト出力先は ./hatena-posts/。カスタム出力先は /hatena-md で指定可能。 機能詳細: はてなブログの記事 URL から本文を抽出し、HTML → Markdown 変換を実行。画像は絶対パスで保持。サイドバー・ヘッダー・フッター・広告を自動除去。 出力形式: YAML フロントマター（title・url・extracted タイムスタンプ）+ 記事本文。ファイル名は記事タイトルから特殊文字を除去・置換した形。 前提条件: Node.js プロジェクトとしてセットアップ済みであることが必須。実行前に npm install と npm run build を完了させる必要がある。