القائمة
このリポジトリで、PR作成前に変更内容に合ったコミットメッセージやPR文面を提案するときに使います。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | write-commit-for-pr |
| description | このリポジトリで、PR作成前に変更内容に合ったコミットメッセージやPR文面を提案するときに使います。 |
このドキュメントは、Pull Request（PR）とコミットメッセージを一貫した品質で作成するためのAIエージェント向け指示書です。
このスキルは、コミットタイトル/本文、PRタイトル/本文を「提案する」ことが目的です。
git commit の実行コミットやPRの実行は、ユーザーが提案内容を確認・承認してから行ってください。
変更が誰に影響するかを明確にします。
| 対象者 | 説明 | 例 |
|---|---|---|
| 📖 読者 | 本書を読んでTypeScriptを学ぶ人 | コンテンツ追加・改善、誤り修正、サイトUI |
| ✍️ 執筆者 | 本書の執筆・改善に貢献する人 | 開発環境、執筆ガイド、ビルド設定、依存関係更新 |
[変更の要約]（日本語、「〜しました。」形式）
| ❌ 悪い例 | ✅ 良い例 | 理由 |
|---|---|---|
| Update docs | 「型ガード関数」のサンプルコードを改善しました。 | 具体性がある |
| Fix bug | Prettierチュートリアルでコメントが表示されない問題を修正しました。 | 何を修正したか分かる |
| Add feature | 「オブジェクトのスプレッド構文」ページを追加しました。 | 何を追加したか分かる |
| Refactoring | 開発環境をBun + Devboxに刷新しました。 | 技術的な変更内容が分かる |
| 対象者 | タイトル例 |
|---|---|
| 📖 読者 | 「オブジェクトのスプレッド構文」ページを追加しました。 |
| 📖 読者 | 「型ガード関数」のサンプルコードから declare を除去しました。 |
| 📖 読者 | JSXページにてReact固有の説明であることを明記しました。 |
| ✍️ 執筆者 | コードブロックの言語指定ガイドラインを追加しました。 |
| ✍️ 執筆者 | 開発環境をBun + Devboxに刷新しました。 |
コミット本文とPR本文は、どちらもこのテンプレートに沿って書きます。 コミット本文だけを読んでも変更の意図と価値が分かるように、コミット本文でも対象者、Problem、Solution、Value、Issueの関連付けを省略しないでください。
## 対象者
- [ ] 📖 読者
- [ ] ✍️ 執筆者
## Problem
<!-- 何が問題だったか / 何が不足していたか / どんな課題があったか -->
## Solution
<!-- その問題をどう解決したか -->
## Value
<!-- この変更によって、対象者にどんなメリットがあるか -->
---
Close #xxx
該当するものにチェックを入れます。複数該当する場合は複数チェックしてOKです。
以下の観点で記述します：
書き方のコツ:
具体的に何をしたかを記述します：
この変更によって対象者が得られるメリットを記述します：
必ず Close #xxx または Closes #xxx でIssueを関連付けます。
これによりPRマージ時にIssueが自動でクローズされます。
## 対象者
- [x] 📖 読者
## Problem
配列のスプレッド構文は紹介されていましたが、オブジェクトのスプレッド構文が紹介されていませんでした。実務ではオブジェクトのスプレッド構文も頻繁に使用されるため、読者が網羅的に学べない状態でした。
## Solution
「オブジェクトのスプレッド構文」ページを新規追加しました。
- オブジェクトの作成・コピー・マージ
- 浅いコピーの注意点
- 分割代入と残余パターン
- 配列のスプレッド構文ページとの相互リンク
## Value
読者がオブジェクトのコピーやマージの実践的なパターンを体系的に学べるようになります。
---
Close #828
## 対象者
- [x] 📖 読者
## Problem
「型ガード関数」のサンプルコードで `declare const input: number | string;` を使用していました。`declare` は本書の後半で解説される構文であり、初心者がこのページを読んだ時点では未学習のため、コード例の意図が理解しづらい状態でした。
## Solution
`declare` を使わず、関数引数として `input: number | string` を受け取る形式に変更しました。
```ts
// Before
declare const input: number | string;
if (isString(input)) { ... }
// After
function example(input: number | string) {
if (isString(input)) { ... }
}
```
読者が declare を学習していなくてもコード例を理解でき、コピペして動作確認もできるようになります。
Close #1068
#### 例3: 開発環境改善（執筆者向け）
```markdown
## 対象者
- [x] ✍️ 執筆者
## Problem
- 依存関係のインストール（Yarn）に時間がかかっていました
- 環境構築手順が複雑で、新規コントリビューターが参加しにくい状態でした
- CIワークフローが複数に分散しており、メンテナンスしづらい状態でした
## Solution
開発環境を刷新しました。
- YarnからBunへ移行（インストール高速化）
- Devbox導入（環境構築の簡素化）
- GitHub Actionsを1つのワークフローに統合
## Value
- 執筆者の開発体験が向上します（高速なビルド、簡単な環境構築）
- 新規コントリビューターが参加しやすくなります
---
Close #1047
## 対象者
- [x] 📖 読者
## Problem
「Prettierの自動整形を無効にする」セクションで、`// prettier-ignore` コメントの使い方を説明していますが、肝心の `// prettier-ignore` がブラウザ上で表示されていませんでした。これは `@typescript/twoslash` パッケージがこのコメントを自動削除する仕様によるものです。
## Solution
- コードブロックから `twoslash` を削除しました
- Prettierによる自動整形を防ぐためHTMLコメントを追加しました
## Value
読者が `// prettier-ignore` の正しい書き方を確認できるようになります。
---
Close #1062
このプロジェクトはチケット駆動が原則です。PRを作成する前に：
唐突なPRはマージされずにクローズされる可能性があります。