AgentSkillsCN

sakasegawa-blog-writer

以逆濑川风格撰写技术博客文章。当用户提出相关主题或想要撰写的内容时，我们会进行网络调研，从而生成既技术精准又易于阅读的文章。适用于用户要求撰写博客文章、技术文章、Zenn 文章，或说出“写篇文章”“写博客”“技术文章”“解说文章”“总结文章”等表述时。

SKILL.md
--- frontmatter
name: sakasegawa-blog-writer
description: 技術ブログ記事を逆瀬川スタイルで執筆する。トピックや書きたい内容を与えられたときにWeb調査を行い、技術的に正確かつ読みやすい記事を生成する。Use when user asks to write a blog post, article, tech blog, Zenn article, or says "記事を書いて", "ブログ書いて", "技術記事", "解説記事", "まとめ記事" etc.

sakasegawa-blog-writer

逆瀬川 (@gyakuse) の文体・構成・思考プロセスを再現して技術ブログ記事を書くスキル。

出力先

記事は以下のリポジトリに Markdown ファイルとして出力する。

  • •リポジトリ: /Users/sakasegawa/src/github.com/nyosegawa/nyosegawa.github.io
  • •出力先: posts/{slug}.md（slug はトピックに基づく英語ケバブケース）
  • •フロントマター形式（Lume Simple Blog テーマ）:
yaml
---
title: "記事タイトル"
description: "記事の説明（1-2文）"
date: YYYY-MM-DD
tags: [タグ1, タグ2]
author: 逆瀬川ちゃん
---
  • •「この記事はCoding Agentを使って執筆されています。」はCSSで自動挿入されるため、記事本文には書かない
  • •記事冒頭の挨拶の後、適切な位置に <!--more--> を入れる（トップページの抜粋範囲を制御するため）

Instructions

Step 1: トピックの理解と調査計画

ユーザーからトピックや書きたい内容群を受け取ったら、まず以下を行う。

  1. •トピックの中核となる「問い」を特定する
    • •例: Context Engineeringの記事なら「なぜContext Engineeringが大事なのか」
  2. •読者が最終的に得るべき理解を定義する
  3. •調査すべき領域をリストアップする
    • •公式ドキュメント、論文、実装コード、価格表など
  4. •Web検索で最新の情報を収集する
    • •特に価格表、APIドキュメント、GitHubの実装は最新を確認すること
    • •論文はarXivのリンクを収集すること

Step 2: 記事構成の設計

以下の構成パターンに従って章立てを設計する。

code
1. 導入 (挨拶 + トピック提示 + この記事でやること宣言)
2. 概念の導入 (定義 → でもふわっとしてるから実例で見よう、という流れ)
3. 具体的な構造・仕組みの解説 (図や表を使って)
4. そこから導かれる制約や課題 (前章の知識が伏線になる)
5. 実践的な対処法・実装例 (実コードやOSSの例を引用)
6. まとめ (短く、2-3行のbullet)
7. Appendix (深い技術的背景。本編から参照される)
8. References (リンク集)

重要: 章単位の接続を強く意識する。前の章で提示した情報が次の章の議論の前提になるように設計する。読者が「なるほど、だからこうなるのか」と思える流れにする。

Step 3: 執筆

references/style-guide.md を必ず読んでから執筆すること。文体ルールはすべてそこに記載されている。

執筆時の思考プロセス:

  1. •各章の冒頭で、前章とのつながりを示す一文を入れる
    • •「さて、このCacheの安さを見ることでContext Engineeringで避けたいことが見えてきます」のように
  2. •技術的な概念は「なぜそうなっているか」から説明する
    • •仕組み→制約→解決策の順
  3. •数値やデータは表で見せる。表は説得力の源泉
  4. •難しい概念は噛み砕くが、正確性は絶対に犠牲にしない
    • •論文の内容を説明するとき、simplifyしすぎない
  5. •コード例はOSSの実装を引用するのが望ましい。架空のコードより実在のコードのほうが価値がある

Step 4: レビューと調整

書き上がったら以下をチェックする。

  1. •章の接続: 各章の終わりが次の章の導入になっているか
  2. •伏線回収: 序盤で触れた概念が後半で活きているか
  3. •文体の一貫性: references/style-guide.md のルールに従っているか
  4. •技術的正確性: 数値、用語、リンクが正しいか
  5. •読みやすさ: 音読して気持ちよく読めるリズムか

Step 5: 公開

記事が完成したら、以下の手順で公開する。公開前に必ずユーザーの確認を得ること。

  1. •完成した記事の全文をユーザーに提示する
  2. •ユーザーに以下を確認してもらう:
    • •記事の内容に問題がないか
    • •タイトル・タグ・description が適切か
    • •公開してよいか
  3. •ユーザーから承認を得たら、ブログリポジトリで以下を実行する:
bash
cd /Users/sakasegawa/src/github.com/nyosegawa/nyosegawa.github.io
# OGPカード画像を生成（新規記事分のみ自動生成される）
python3 scripts/gen-og-images.py
# 記事とOG画像をまとめてコミット
git add posts/{slug}.md og/{slug}.png
git commit -m "Add post: {記事タイトル}"
git push origin main
  1. •push が完了したら、公開 URL を伝える:
    • •https://nyosegawa.github.io/posts/{slug}/

重要: ユーザーの明示的な承認なしに git push しないこと。

調査の方針

何を調査し掘り下げるかの判断基準:

  • •価格やコスト: 必ず最新の公式価格表を取得する。コスト比較は読者にとって最も実用的な情報
  • •実装詳細: GitHubのOSS実装を確認する。「こういうツールはこうなっている」と具体的に示す
  • •論文: 関連する論文はarXivから探す。ただし全部は紹介しない。記事の文脈に合うものだけを選ぶ
  • •ベンチマーク・数値: 可能な限り定量的なデータを入れる。計算例を自分で作るのもよい

調査しないもの:

  • •ふわっとした定義の羅列(定義はサラッと触れてすぐ実例に行く)
  • •網羅的なツール比較(記事の主張に関係するものだけ)

Troubleshooting

文体が硬くなりすぎる場合

原因: 敬体に統一しようとしている 解決: 敬体と常体を混ぜてよい。文の流れに合っていればいい。「〜です」の後に「〜だからだ」が来ても問題ない

章のつながりが弱い場合

原因: 各章を独立して書いている 解決: 前の章の最後の話題を次の章の冒頭で拾う。「さて」「ここで」「このように」等の接続を使う

技術的に浅くなる場合

原因: わかりやすさを優先しすぎている 解決: Appendixに深い内容を逃がす。本編では「Appendixを参照」と書いて、本編自体はちょうどいい深さを保つ