bklit-changelog

Bklit Changelog スキル

bklitui.com/changelog 用のリリースノートを作成します。Markdown 記事を 1 つと、抽象的な単色 SVG カバーを 1 つ以上用意します。完成したエントリーは、コミットログではなく、短く自信に満ちたプロダクト紹介として読めるものにします（目安は Linear の変更履歴です）。

ファイルの場所

内容	パス
エントリー（1 エントリーにつき .mdx ファイル 1 つ）	apps/web/content/changelog/YYYY-MM-DD-<slug>.mdx
カバー画像	apps/web/public/changelog/YYYY-MM-DD-<slug>.svg
カバー生成スクリプト	.agents/skills/bklit-changelog/scripts/cover.mjs
スキーマ（フロントマター）	apps/web/source.config.ts → changelog
ローダー／並べ替え／検索テキスト	apps/web/lib/changelog.ts
フィード、レール、記事、画像	apps/web/components/changelog/
ルート	apps/web/app/(site)/(home)/changelog/ — /changelog、/changelog/page/<n>、/changelog/<slug>、/changelog/rss.xml
SEO（メタデータ、JSON-LD）	apps/web/lib/changelog-seo.ts
Open Graph カード	apps/web/lib/changelog-og.tsx → /api/og/changelog/<slug>

ルートのスラッグは、ファイル名から .mdx を除いたものです。各エントリーには、専用のパーマリンク、サイトマップエントリー、RSS アイテム、BlogPosting JSON-LD、暗い背景に合わせてカバーを明るく再配色した Open Graph カードが自動的に用意されます。ほかに登録作業は必要ありません。フィードには 1 ページあたり 20 件のエントリーが表示され、「新しい／古い」リンクが付きます。また、アドレスバーは閲覧中のエントリーに応じて更新されます。

ワークフロー

1. 事実を集めます。 週次のまとめを書く場合は、マージされたものをすべて一覧にします。git log --since=<date> --oneline を実行し、各 PR の本文を読みます。大きな機能はそれぞれ独立したエントリーにし、残りは 1 つの 修正と改善 エントリーにまとめます（グループ分けした箇条書き：チャート／インストール／ドキュメントとサイト）。マージされた PR（git log --grep="(#NNN)"、gh pr view NNN）と、言及する各 API のドキュメントページを読みます。コードブロックに記載する各 prop 名について、apps/web/content/docs を grep して確認し、決して推測で追加しないでください。
2. スラッグと日付を決めます。 YYYY-MM-DD-short-kebab-name の形式にし、マージされた日付を指定します。同じ日に複数のエントリーがある場合は、date に UTC 時刻を追加します（2026-10-22T18:00:00Z）。時刻が遅いものほど先に並びます。
3. カバーを作成します（下記の カバー画像 を参照）。
4. 記事を書きます（下記の 執筆 を参照）。
5. 確認します。 pnpm dev を起動し、/changelog と /changelog/<slug> をライトテーマとダークテーマの両方、およびスマートフォン幅で確認します。本文中の単語を検索し、インデックスに登録されていることを確かめます。

フロントマター

---
title: Jittered scatter plots
description: Spread overlapping points into a readable strip plot, with deterministic offsets.
date: 2026-10-22
image: /changelog/2026-10-22-scatter-jitter.svg
imageAlt: Columns of dots scattered around vertical guide lines
tags: [scatter-chart, breaking]
---

• title — 動詞ではなく機能名にします。「リニアゲージ」「帯とトレンドライン」など。文頭のみ大文字にし、末尾にピリオドを付けず、6 語以内にします。
• description — 100 文字以内の 1 文にします。SEO と検索に使用します。ユーザーが新たにできるようになったことを説明します。
• image／imageAlt — public/ 以下のカバーパスを指定します。alt には機能ではなく、図形を説明します（「目盛りのある半円…」など）。
• tags — 小文字のケバブケースにします。該当する場合はチャートのスラッグ（bar-chart など）を含め、破壊的変更には breaking を付けます。タグは検索対象です。

執筆

構成：

1. リード段落（1～3文）。 新機能と、それが重要な理由を伝えます。前に見出しを置かず、「お知らせできることをうれしく思います…」のような表現も使いません。
2. アイデアごとに##セクションを設けます。 各セクションは1～3個の短い段落で構成します。見出しは名詞または短いフレーズにします（「ホバーがポイントに追従」「新しいデフォルト」）。
3. 最後にドキュメントページへのリンクを置きます。 こちらの[散布図のドキュメント](/docs/components/scatter-chart)をご覧ください。

コード：まずは文章で説明します。 ユーザーができるようになったことを言葉で説明し、プロパティを文中に記載します（showValue、exit={false}）。各項目のコードブロックは最大1つとし、そのスニペット自体がニュースである場合（インストールコマンドや、多くの作業を置き換える1行のAPIなど）に限ります。ほとんどの項目ではコードブロックは不要です。コードはドキュメントへのリンクで確認できます。

スタイル：

• 二人称、現在形で書きます。「jitterを渡すと、点を分散できます。」
• 形容詞より具体性を重視します。プロパティ、デフォルト値、数値を明記します。
• 破壊的変更には、以前の動作に戻すための正確なプロパティとbreakingタグを記載した、独立した## 新しいデフォルトまたは## 破壊的変更セクションを設けます。
• 問題やユーザーの状況（「多くの行が同じ日付を共有しているとき…」など）から始め、その後に機能を説明します。
• 150～350語にします（修正のまとめは、箇条書きが長くなってもかまいません）。読者が実際に役立てられない内容（リファクタリング、内部的な名称変更、テストの変更）は削ります。
• ##と###のみを使います。ページ上でエントリーのタイトルがすでにh2として表示されるためです。見出しにはアンカーが付きません（1つのページに同じ見出しが複数あるため）。
• サイト内リンクには、ルート相対パス（/docs/...、/charts、/studio）を使います。

カバー画像

カバー画像は、機能をほのめかす抽象的な幾何学模様です。データの形状や動きを表現し、スクリーンショット、ロゴ、UIの装飾、テキストは使いません。Linearのブログアートのように、細い線を使い、余白を大きく取り、1枚につき1つのアイデアを表現します。

技術要件（必須）

サイトでは、カバー画像を前景色の上に重ねるCSSマスク（ChangelogImage）として表示するため、同じファイルをライトモードとダークモードの両方で使用できます。

• viewBox="0 0 1600 900"（16:9）、背景は透明にします。背景のrectは使用しません。
• 黒のみ（#000）で描画します。色や色のグラデーションは使わず、stroke-opacity／fill-opacity（約0.15～0.9）で奥行きを表現します。
• 約160pxの安全な余白を保ち、構図を中央に配置します。
• 線幅は2～3px（ページ上では約40%のサイズで表示されます）、stroke-linecap="round"にします。破線にはstroke-dasharray="6 10"を使います。
• <text>、ラスターの<image>、フィルターやぼかし、外部参照は使いません。ファイルサイズは30 KB未満を目指します。

スクリプトで生成

node .agents/skills/bklit-changelog/scripts/cover.mjs --list
node .agents/skills/bklit-changelog/scripts/cover.mjs <motif> apps/web/public/changelog/<slug>.svg [seed]

出力はモチーフとシード値ごとに決定的に生成されます。構図のバランスがよくなるまでシード値を変えてください。

モチーフ	表現するもの	用途
bar-steps	成長、棒	棒グラフ、棒上のラベル、積み上げ
scatter-jitter	分布	散布図、ストリッププロット、点
band	範囲、包絡線	帯、信頼区間、面の範囲
step-trend	ノイズ中のシグナル	トレンドライン、回帰、予測
gauge	進捗	ゲージ、読み込み、完了
dot-grid	密度	ヒートマップ、コントリビューショングリッド
radial-bars	比較、スコア	ベンチマーク、パフォーマンス、指標
hue-discs	混合、重なり	パレット、テーマ設定、カラーのトークン
halo	ホバー、フォーカス	ツールチップ、ホバー状態、インタラクション
swatches	質感、スタイル	レシピ、パターン、ビジュアルスタイル
rails	構造	サイトとドキュメントのデザイン、レイアウト
migrate	混沌から秩序へ	移行、エージェントスキル、ツール
waves	ギザギザから滑らかへ	修正や仕上げのまとめ

カスタムカバーの描画

ぴったりのモチーフがない場合は、SVGを手書きするか、再利用できるように cover.mjs にモチーフを追加してください。次を出発点にします。

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1600 900" fill="#000" stroke="#000" stroke-linecap="round">
  <g>
    
  </g>
</svg>

絵柄を参考にし、絵そのものは模倣しないでください。 Linear のブログは 雰囲気（細い線、余白、モノクロ）の参考にしますが、Linear の特定のイラストを再現してはいけません。縦線を詰めた棒、ループ状のらせん、ひとつの角から広がる線の扇、カーソル付きの目盛り線は避けてください。代わりに、Bklit 独自の語彙で描きます。チャートの要素（棒、点、帯、弧）、サイトの外枠（レール、リベット、フレーム）、そして機能の実際の形状を使ってください。

よいカバーの特徴：支配的な形がひとつあること。密度、長さ、不透明度のいずれかひとつを変えた反復で動きを生み出すこと。焦点を中央から少しずらすこと。十分な余白を取ること。避けるべきもの：ラベル付きの文字どおりのチャート軸、アイデアの詰め込みすぎ、密度の高いノイズ、塗りつぶしが大きな領域を占めるデザイン（マスク上で灰色の塊に見えます）。

インライン画像

本文中の追加の図にはプレーンな Markdown を使用します。.svg はどれも同じマスク付きフレームでレンダリングされます。

![A stepped line with a straight line running through it](/changelog/2026-10-20-trend-line.svg)

エントリーごとにインライン画像は最大1つとし、説明するセクションの下に配置してください。

チェックリスト

• ファイル名が YYYY-MM-DD-<slug>.mdx で、date が一致している（同日内の順序が重要な場合は時刻も追加）
• 言及したすべての props / コンポーネントが apps/web/content/docs に存在し、コードブロックは最大1つ
• カバーがオリジナルである（参考イラストの再現ではない）
• カバーの SVG が技術的なルールに従っている。ライトモードとダークモードの両方、および OG カード（/api/og/changelog/<slug>）で適切に表示される
• 説明が100文字以内で、タイトルがセンテンスケースになっている
• 破壊的変更には復元用の props と breaking タグを明記している
• ドキュメントへのリンクで終わっている
• pnpm --filter web check-types が成功する（フロントマターはビルド時にスキーマ検証される）