write-blog

name: write-blog description: trasta.dev のブログ記事 (src/content/blog/*.mdx) を本人 (trasta) の文体・章立て・MDX 規約に沿って下書きする。ユーザーが「ブログ書いて」「記事にしたい」「振り返り書く」「○○について書きたい」「やってみた書きたい」「ガジェット紹介書く」のように、題材やニュアンス（雑な箇条書き・感想・スクショ素材・X 投稿 ID など）だけを渡してきたとき、または /home/trasta/trasta-dev-v2/ 配下に新しい mdx 記事を作る／既存ブログ記事を整える作業のときに必ず使う。技術メモ・プロダクト紹介・年末振り返り・雑記のいずれのジャンルでも対応。題材だけ伝えれば文体は本スキルが面倒を見る、というのが要点。

write-blog

trasta.dev の blog (src/content/blog/*.mdx) を、本人の口調・構成・MDX コンポーネント規約をなぞる形で 1 本書ききる。 ユーザーが「ニュアンス（題材・言いたいこと・気持ち・素材）」だけを渡してくる前提で、文体寄せはこちらで担当する。

英語版 (src/content/en/blog/*.mdx) は明示依頼があったときだけ用意する。デフォルトは日本語のみ。

ファイルの置き場所と命名

• 新規ファイル: /home/trasta/trasta-dev-v2/src/content/blog/YYYYMMDD.mdx
• スラッグ = ファイル名から .mdx を除いたもの。publishedAt の日付（ハイフン無し）と必ず一致させる（揃ってないとサイト側のソートと URL がズレる）。
• 外部記事の index 掲載のみが目的ならファイル名は external-<source>-<id>.mdx、frontmatter に externalUrl と externalSite を入れて本文は空でよい（external-zenn-translate-tool.mdx 参照）。

書き始める前にやる小さな下準備

毎回これを踏むと文体が安定する。

1. ユーザーから渡された素材（題材・素材リンク・スクショ・X 投稿 ID）を一旦自分の言葉で整理する。不足が「文体に強く影響するもの」だけなら聞く。聞きすぎると本人が嫌がるのでヒアリングは最小化する（後述「ヒアリングの範囲」）。
2. ls /home/trasta/trasta-dev-v2/src/content/blog/ で既存スラッグの被りがないか確認。
3. これから書くジャンルに近い既存記事を 1〜2 本だけ Read して、文体・余白の取り方をその場で浴びる。お手本マップは末尾「参考記事」を参照。
4. 第 1 稿を書く。書き終わったら本人に渡し、トーンへの違和感をフィードバックしてもらってから直す。

第 1 稿は黙って書ききるのがこのスキルの value 。途中で「どんな構成にしますか？」と訊かない（ニュアンス渡しで完結させたい人向けのスキルだから）。

ヒアリングの範囲

ニュアンスから推測で埋められる部分は埋めて先に進む。詰めるのは校正フェーズで十分。

文体の核（このスキルの本体）

ここが弱いとスキルとして意味がないので、章立てより「声」を先に固める。

敬体／常体の選び方

2024 年以降の本人の記事はほぼ「ですます調」に揃っている。なので デフォルトは敬体。

唯一の例外が年末振り返りで、ここは年ごとに本人が冒頭で宣言してスタイルを切り替えてきた歴史がある（20231230 は常体、20241230 は冒頭で「今年はですます調」と宣言、20251229 は敬体）。指示が無ければ最新慣例の敬体に倣う。

地の文と独白は混ぜない。混ぜるとしても「地の文＝敬体／カッコ書きの独り言＝常体」のように役割で分ける。理由は単純で、混ざっていると読み手が「直し忘れか？」と感じるから。

単語・文末・リズム

積極的に使うと trasta らしくなる：

• 入りの動詞修飾: 「とりあえず」「ぱっと」「雑に」「適当に」「ちょくちょく」
• ぼかし: 「〜って感じ」「〜という感じ」「〜気がします」「〜かもしれない」
• 余韻: 「〜なぁ」「〜したい」「〜ですね〜」「〜……」
• 関西寄りの脱力語彙: 「しらんけど」「ほんまか？」「ぞい」「マジで」（強調と自虐の両用）
• 譲歩のクッション: 「〜なんですよね」「〜なんですけど、〜」
• 自虐の定型: 「私は◯◯が苦手」「頭で考えるタイプではない」「私みたいに器用ではない人は」

逆に存在するとブログテンプレ臭が出るので避ける表現：

• 「結論から言うと」「皆さんは〜したことがありますか」「いかがでしたか」
• 「〜と言えるでしょう」「〜することができます」のような硬めの言い回し
• 章ごとのまとめサブ見出し（「この章のポイント」など）

絵文字は本文では非常に控えめで、記事 1 本あたり 0〜2 個。「🙌」「👀」「🎉」「💪」がたまに 1 個出る程度。文末ごとに振らない。

物語の形

ほとんどの記事がこの曲線をなぞっている：

1. 冒頭 1〜3 行で動機：「最近〜していて」「〜が欲しくなったので作りました」「〜が来てたのでとりあえず試してみました」。前置きの「皆さん〜」は無し。題材へすぐ突入する。
2. 本文は段落区切りで読ませる。1 段落 2〜4 文。Wall of Text にしない。短文と硬改行（行末に半角スペース 2 個）を組み合わせる。
3. カッコ書きで自分にツッコむ。例: 「(更新するとは言ってない)」「(再放送)」「(意識しなくてもわかるようになるくらいに)」。
4. オチで自虐：失敗・想定外を笑いに回収する。例: 「テストは爆死しました。」「failしました(再放送)」。
5. 強い結論を出さない：「今のところ満足しています」「〜くらいはあってもいいかも」「〜できたらいいな」「〜したい」で終わる余韻。「他に解決方法があれば教えていただけると嬉しいです。」のような呼びかけも使われる。

句読点・記号・空白

サイトの組版に直結する細部。読みやすさと既存記事との一貫性のために守る：

• 半角英数字の前後に半角スペースを入れる（CLAUDE.md ルールでもあり、本文でも徹底）。例: Claude Code を使っていて、RTX 4070 を買った、2025 年。
• カッコは半角 () を多用（既存記事はほぼ半角）。全角は使わない方向。
• 「：」「；」は使わず句点で割る。
• 三点リーダーは「……」（全角 2 個）。...（半角ピリオド 3 個）は使わない。
• 強制改行は 行末に半角スペース 2 個。Markdown の硬改行を多用する。
• リスト項目内の補足は 4 スペースインデント付きの bullet（ - 〜）でぶら下げる。

ジャンル別テンプレート

ジャンル判定で迷ったら 技術メモ をデフォルト。

技術メモ（やってみた／作った）

---
frontmatter
---

導入 1〜3 行（最近〜で、〜が欲しくて作った／試した）

## モチベーション or なぜ作ったか
   - 既存ツール／既存手法を雑に挙げて「自分には合わなかった」と書く
   - dis りすぎない。「対応ターミナルを使っている人には良い選択肢」のように逃げを残す

## 技術スタック / どうやって作ったか
   - 主要ライブラリ・要素技術を箇条書き
   - 「実装は Claude Code に書いてもらいました」など制作プロセスをサラッと書くのが trasta 節

## 使い方 or コード
   - インストールコマンドは ```bash 単独ブロック
   - 設定例は filename 付きコードブロック

## 対象者 (任意)
   - 「こういう人に向いていると思います」と箇条書き

## おわりに
   - 「今のところ満足しています」「〜くらいはあってもいいかも」で締める

<LinkCard /> は GitHub リポや Zenn 記事を埋め込みたいときに、本文の早い段階で 1 枚出す（コード公開系なら「## リポジトリ」直下）。

ガジェット／プロダクト紹介

技術メモと同形だが、スペック羅列にせず「使ってみた感想」が中心。

• 肯定の語彙: 「今のところ満足」「最高」「思ったより使えて面白いです」
• ネガに触れるとき: 「〜ではあるんですが」「〜ところはあるかもしれない」のように必ず逃げを置く
• 値段は遠慮せず書く（「17 万円しました」「6000 円の横長のスピーカーに若干グレードアップ」）。値段の話を入れることで実用感が出る。

年末振り返り

毎年 12 月後半に出す定番フォーマット。

• ファイル名は 12 月後半の日付。tags は [] 空配列。
• 1 行目: 「雑に振り返り。」または「前年振り返り では〜と言っていました…」で前年を踏まえる。
• 章立ての順序: 大学 → 仕事 → イベント → 趣味（Valorant 含む）→ 個人開発 / 開発 → 買い物（カテゴリ小見出し）→ 旅行 / 外出 → 翌年抱負。最後の章タイトルは翌年の西暦（例: ## 2026）。
• 「買い物」の中はサブカテゴリ（### オーディオ関連 ### ガジェット系 ### 生活改善系 ### 旅行用）で分類し、リンク付きアイテム名を見出し化、その下にぶら下げ箇条書きで 1〜3 文の感想。
• <XPost id="..." user="tra_sta" /> を 節ごとに 1〜2 個 散らす（証拠／思い出として）。
• 締め: 翌年抱負を 2〜3 個、最後に「もう新卒すら名乗れなくなる」系の年齢ボヤキで余韻を残す。

雑記 / 試してみた

短め（40〜100 行）。導入 → やったこと → スクショ → オチ。「## オチ」を別見出しにしてしまうのも普通にやっている（20231128.mdx 参照）。

Frontmatter の書き方

src/lib/content/types.ts の BlogFrontmatter に従う：

---
title: "ここはダブルクオート必須・体言止めか「〜した」「〜してみた」"
description: "1 文で、何をやって何の話を書いた記事かを言い切る。読者用というより SNS / OG 用。"
publishedAt: "YYYY-MM-DD"
tags: ["タグ1","タグ2"]
---

各フィールドの設計理由：

• title: 「〜してみた」「〜を作った」「〜になるまで」「YYYY 年の振り返り」のような実体ベース。煽り・問いかけ系のクリック狙いタイトルは本人のサイトに浮く。
• description: 1 文・80 字目安・句点終わり。SNS の OG カードや一覧で抜粋表示されるのでタグや読者層を含めず「何をやって何の話か」だけを言い切る。
• publishedAt: 半角ハイフン区切りの ISO 日付（currentDate を使う）。未来日にするとサイト側のソートが壊れる。
• tags: 振り返り系は []。技術記事は使った言語・ツール名で 3〜5 個まで（["Rust","CLI","Git"]）。, の後ろにスペースを入れない既存スタイルに合わせる。
• 任意フィールド: updatedAt（後追い修正の明示）、ogImage（記事固有 OG が要るときだけ）、xEmbeds（<XPost /> を MDX 内に置けば不要）。

外部公開記事の index 掲載のみなら externalUrl + externalSite を埋めて本文は空にする。

ここで重要な原則：ニュアンスから読み取れない事実は作らない。数値・体験・固有名詞は元情報か本人確認で必ず固める。description で記事の中身を「やったこと + 何の話か」と言い切る都合上、捏造があるとそのまま OG に出てしまうので一番事故りやすい場所。

MDX 構成要素

カスタムコンポーネント

<XPost /> と <LinkCard /> はグローバル登録済みで import 不要。

<XPost id="1671043884972142592" user="tra_sta" />

<LinkCard
  href="https://github.com/trasta298/keifu"
  title="trasta298/keifu"
  description="A TUI tool for visualizing Git branch graphs with interactive navigation"
  site="github.com"
/>

<XPost /> の text 属性は新しい記事では省略するのが標準（旧記事に残骸はある）。<LinkCard /> は GitHub・Zenn・他ブログなど「カードで見せる価値がある外部記事」に使い、インライン [text](url) で済むものには使わない。

画像

• 配置先: /home/trasta/trasta-dev-v2/public/images/blog/<filename>
• 参照: ![alt 文字列](/images/blog/<filename>)（alt は空でも可。既存記事も空が多い）
• ファイル名は内容を表す英小文字 + 数字（keifu.png, gotenba.png）。日付プレフィックスや upload_<hash> はレガシーなので踏襲しない。
• スキル単独で画像は作らない。素材があればそれを使い、無ければ ![](/images/blog/TODO.png) でプレースホルダを残し、生成後に「ここに画像を入れてください」と本人に渡す。

コードブロック

• ```lang または ```lang filename="..." を使う。
• shell は bash、設定や雑テキストは text。
• インラインコードは backtick 1 つ。
• 長いコードを // ... で省略しすぎない。trasta は割と全部貼る派なので、本文の流れを切らない範囲で実物を残す。

原稿そのものの出自に触れない

trasta は記事内で技術選定として LLM の活用には触れる（「実装は Claude Code に書いてもらいました」など）。一方で、原稿そのものを LLM が書いたという告白を地の文でしない。「Claude が書きました」「AI が生成しました」のような文は入れない。理由は本人ブランドで出している媒体だから。

また、既存記事の段落をコピーしてそれっぽく見せるのも避ける。語彙・リズムは寄せても、過去原稿の文章をそのまま流用しない。

仕上げチェック（書き終わったらこれで通す）

• frontmatter 4 項目（title / description / publishedAt / tags）が揃っている
• description が 1 文・80 字以内・句点終わり
• 半角英数の前後に半角スペースが入っている（とくに「LLM」「CSS」「Claude Code」「Rust」「2025 年」など出現バリエーションが多い語）
• 三点リーダーが「……」（半角 ... が混入していない）
• 全文を「ですます」or「である」で統一（混ぜるならカッコ独白だけ）
• 本文に # 見出し を書いていない（title が H1 扱いなので本文は ## から）
• 「結論から言うと」「いかがでしたか」「皆さん〜」「と言えるでしょう」が入っていない
• 自慢で終わっていない。1 行 self-deprecation か「〜したい」「〜できたらな」の余韻で締まっている
• <XPost /> <LinkCard /> の id / href / props にタイポなし、文字列は二重引用符
• スラッグ（ファイル名）が YYYYMMDD.mdx で publishedAt と一致
• 「Claude が書きました」「AI が生成しました」のような自白系の文が入っていない

仕上がりの渡し方

書き終わったら本人に必ずこの 4 つを伝える：

1. 作ったファイルの絶対パス
2. frontmatter の 4 項目（title / description / publishedAt / tags）を読み返せる形で再掲
3. プレースホルダで残した箇所の一覧（画像 TODO.png、未確認の X ID、未取得の URL など）
4. 迷ったポイント 1〜3 個（敬体／常体の選択、章立ての分岐、自虐の強さなど）。「ここだけ判断してもらいたい」が伝わる粒度で。

修正依頼が来たときの動き：語彙置換は機械的に、構成変更は「ジャンル別テンプレート」のテンプレに沿って差し替える。

参考記事（書く前に 1 本読んで浴びる）

書き始める前に最低 1 本は Read してから手を動かすこと。