| name | blog |
| description | Technical blog writing skill that mimics the writing style of Aihara from LIFULL's KEEL team. Use when writing blog entries, technical articles, or drafting blog posts about engineering topics. |
| metadata | {"short-description":"blog, ブログ, テックブログ, 技術記事, technical-writing, 執筆, 記事"} |
- 相原さん（LIFULL KEELチーム）の文体を忠実に再現する
- 技術的に正確でありながら親しみやすいトーンで書く
- 読者が実務に活かせる具体性を重視する
Style Learning (Required)
記事を書く前に、以下のブログ記事から 2つ以上 をWebFetchで取得し、文体を分析すること。
Analysis Criteria
フェッチした記事から以下を抽出し、執筆時に再現する:
| 観点 | 着目点 |
|---|
| 文末表現 | です/ます vs だ/である、バリエーションと使い分け |
| 導入の型 | 自己紹介の定型、背景の述べ方、記事の目的宣言 |
| セクション構成 | 見出しの粒度、順序、命名 |
| 課題の述べ方 | 客観的事実から入るか、主観から入るか |
| 技術用語の扱い | 初出時の補足の仕方、英語/日本語の使い分け |
| コード例の挿入方法 | 前後の説明文、コード量、言語指定 |
| 成果の報告トーン | 控えめか、具体的な数値を伴うか |
| 特徴的な語彙・比喩 | 繰り返し使われるフレーズや表現 |
Article Structure
Introduction
必ず簡潔な自己紹介から始める:
KEELチームの相原です。
続けて1〜2文で背景・文脈を述べ、この記事で何を書くかを端的に宣言する。
Section Layout
| 順序 | セクション | 内容 |
|---|
| 1 | 導入 | 自己紹介 + 背景 + 記事の目的 |
| 2 | 背景・課題 | なぜこの取り組みが必要になったか |
| 3 | アプローチ | 何をどう解決したか |
| 4 | 実装・詳細 | 具体的な技術内容（コード例含む） |
| 5 | 成果・知見 | 得られた結果や運用知見 |
| 6 | まとめ | 振り返りと今後の展望 |
Heading Style
| レベル | 用途 | 例 |
|---|
# | 記事タイトル | 技術的な内容を端的に表す |
## | 大セクション | 「背景」「アプローチ」「まとめ」 |
### | サブトピック | 具体的な技術要素 |
タイトルは技術的内容を簡潔に表現する。動作・結果を具体的に述べ、過度に長くしない:
| Good | Bad |
|---|
| 比較的安全にMCPサーバを動かす | MCPサーバのセキュリティを考慮した安全な運用方法についての包括的ガイド |
| Kubernetesクラスタの可観測性の隙間を埋めるeBPF | eBPFを活用したKubernetesの監視改善のすべて |
| 小さい経路最適化ミドルウェアを実装してあらゆるAZ間通信を削減する | AZ間通信コスト削減プロジェクトの紹介 |
Code Examples
| ルール | 詳細 |
|---|
| 言語指定 | コードブロックには必ず言語を指定する |
| 前後の説明 | コードの前に何をするか、後に補足を入れる |
| 必要最小限 | 本質的な部分のみ示し、冗長なボイラープレートは省く |
| 実際のコード | 擬似コードではなく動くコードを示す |
Anti-patterns
| やらないこと | 理由 |
|---|
| 「〜だ」「〜である」調 | 相原さんの文体ではない |
| 過度な自己アピール | プラットフォーマーとして控えめに |
| バズワードの羅列 | 技術的な正確さを優先 |
| 冗長な前置き | 簡潔に本題に入る |
| 読者への過度な呼びかけ（「皆さん」等） | テック記事として落ち着いたトーンを保つ |
| 絵文字の多用 | 使わない |
| 一人称「私」「僕」 | チーム名や受動態で代替する |
