mcpField
W
write-release-notes

write-release-notes

github.com/tldrawドキュメント51.1k328 回インストール今日更新
リポジトリ

write-release-notes について

公開済みtldraw SDKのリリースノートを作成するスキルです。メンテナーやコントリビューター向けに、PRやパッチリリースの情報収集、変更の分類、破壊的変更の移行手順を扱います。

主な機能

  1. 01リリースとマージ済みPRの情報収集
  2. 02mainにマージされたPRの選別
  3. 03機能、API変更、修正の整理
  4. 04破壊的変更の移行ガイド作成
  5. 05リンク、クレジット、章立ての確認

活用シーン

  1. 01SDKのリリースノート作成
  2. 02リリース対象のマージ済みPR整理
  3. 03API変更と不具合修正の記録
  4. 04破壊的変更に伴う移行手順の作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tldraw/tldraw --skill write-release-notes

インストール後、Claude Code で/write-release-notesを入力して読み込まれたか確認します。

詳細

リリースノートを作成する

このスキルは、公開された tldraw SDK リリースについて、完全なリリースノート記事を作成する方法を扱います。

場所

すべてのリリースファイルは apps/docs/content/releases/ にあります。

ファイル目的
next.mdx次回リリースに向けた変更を蓄積します
vX.Y.0.mdx公開済みリリース（パッチ追加を除き、変更不可）

手順

1. リリースを特定する

バージョン番号を取得し、GitHub リリースを探します:

gh release view v4.3.0

これにより、リリース日、タグ、および GitHub からのリリースノートが表示されます。

2. リリース内のすべての PR を探す

前回のリリースと今回のリリースの間にマージされた PR を一覧表示します:

# Find commits between releases
git log v4.2.0..v4.3.0 --oneline --merges

# Or use gh to list PRs
gh pr list --state merged --base main --search "merged:2024-01-01..2024-02-01"
3. PR の詳細を取得する

各 PR について、完全な詳細を取得します:

gh pr view <PR_NUMBER> --json title,body,labels,author,baseRefName

確認する項目:

  • PR 本文の ### Release notes セクション
  • PR 本文の ### API changes セクション
  • カテゴリを示すラベル（api、bugfix、improvement など）
  • PR に「breaking」が含まれているかどうか

重要: baseRefName が main である PR のみを含めてください。フィーチャーブランチ（例: default-shape-customization）にマージされた PR はまだリリースされていません — フィーチャーブランチ自体が main にマージされたときに含まれます。

4. パッチリリースを探す

このマイナーバージョンのパッチリリースを一覧表示します:

gh release list | grep "v4.3"

各パッチリリースについて、その PR を探します:

git log v4.3.0..v4.3.1 --oneline --merges
5. 記事を作成する

スタイルガイドに従って apps/docs/content/releases/vX.Y.0.mdx を作成します。

  1. バージョン、日付、キーワードを含む frontmatter を作成します
  2. ハイライトを要約した 1〜2 文の導入文を作成します
  3. 主要な機能と破壊的変更について、特集セクションを作成します
  4. API の変更、改善、バグ修正を一覧表示します
  5. 該当する場合は、パッチリリースのセクションを追加します
  6. GitHub リリースへのリンクを追加します
6. すべての破壊的変更についてマイグレーションガイドを作成する

記事内のすべての 💥 にはマイグレーションレシピが必要です。tldraw-migrate スキルはこれらのレシピを利用して動作します — バージョン固有の知識はそれを導入した破壊的変更のそばにあるべきであるため、このスキルは自身の SKILL.md にレシピを意図的に複製していません。レシピが欠けている場合、アップグレードを行うエージェントやコントリビューターは、型定義からそれを逆解析しなければなりません。

受け入れられる形式は 2 つあります:

独自の特集セクションを持つ破壊的変更の場合（名前変更、置き換えられた API、新しいパターンなど）、そのセクションの下に <details><summary>Migration guide</summary> ブロックを追加します。変更前と変更後のコードを含め、サイレントコンパイルの罠（型チェックが拒否しない props、省略可能な新しいパラメータを持つシグネチャなど）について明示してください:

### 💥 Custom themes with display values

[Description of what changed and why]

<details>
<summary>Migration guide</summary>

`getDefaultColorTheme()` and `DefaultColorThemePalette` have been removed. Use `editor.getCurrentTheme().colors[colorMode]` instead:

```tsx
// Before
const theme = getDefaultColorTheme({ isDarkMode })

// After
const theme = editor.getCurrentTheme()
const colors = theme.colors[editor.getColorMode()]
```

</details>

API 変更リスト内の 1 行の 💥 エントリの場合、箇条書き自体にレシピを含める必要があります — 置き換え先の名前と注意事項をインラインで記載してください:

  • ✅ 💥 TLDrawShapeSegment.points をヘルパー getPointsFromDrawSegment(segment, scaleX, scaleY) に置き換えて、セグメントのポイントがシェイプの現在のスケールを尊重するようにします。
  • ❌ 💥 TLDrawShapeSegment.points を削除します。（置き換え先がない → 読者は推測するしかない）

置き換え先なしで削除されたシンボルはドキュメントのバグです — 公開された代替手段を見つけるか、本当に存在しない場合はそのことを明示的に記載して、読者が名前変更を探すのではなく呼び出し箇所を削除すべきだと分かるようにしてください。

特殊なケース — @public → @internal への降格: これらはコンパイルは通りますが、公開型からは消えます。シンボルをインポートしていた利用者にとっては依然として破壊的変更です。削除と同様に扱ってください: 💥 を付け、公開された置き換え先を明記し、降格されたシンボルを再公開するためにモジュール拡張に頼らないよう読者に明示的に伝えてください。

7. 検証する

以下を確認してください:

  • すべての重要な PR が反映されている
  • PR リンクが正しく、適切にフォーマットされている
  • コミュニティコントリビューターがクレジットされている
  • 破壊的変更が 💥 でマークされている
  • すべての 💥 にマイグレーションガイドのブロックまたはインラインの置き換え先がある（grep -nE '💥' apps/docs/content/releases/<file>.mdx を実行し、各箇条書き/セクションを確認してください）
  • セクションが正しい順序になっている

参考資料

  • スタイルガイド: リリースノートの記事に含めるべき内容とそのフォーマット方法については、../shared/release-notes-guide.md を参照してください。

コメント

Markdown 対応