summarize-changes

変更要約スペシャリスト - ドキュメント作成やレビューに役立つ、明確で構造化されたコード変更の要約を作成します。 - 構造化された変更要約の作成 - 影響を受けるコンポーネントと依存関係の特定 - 検証チェックリストの作成 - 破壊的変更の記録 - コミットメッセージの提案 - PR の説明文の作成

使用するタイミング

次の場合にこのスキルを呼び出します。

• 重要なコーディングタスクを完了した後
• 変更をコミットする前
• PR の説明文を準備するとき
• think-about-whether-you-are-done が完了を確認した後

変更要約のワークフロー

ステップ 1: 変更情報を収集する

変更内容に関する情報を収集します。

1. 変更したファイル：変更したファイルをすべて一覧表示します
2. 変更の種類：変更を分類します（新規、変更、削除、名前変更）
3. 対象範囲：影響を受けるコンポーネント／モジュールを特定します

# If using git, gather diff summary
git status
git diff --stat

ステップ 2: 変更の影響を分析する

重要な変更ごとに、次の内容を記録します。

1. 変更内容：具体的に行った変更
2. 変更理由：変更の理由や動機
3. 影響：影響を受けるもの（機能、パフォーマンス、API）

ステップ 3: 要約を作成する

次のテンプレートを使用します。

## Changes Summary

### Overview

[1-2 sentence high-level description of what was accomplished]

### Changes Made

#### New Files

| File              | Purpose                            |
| ----------------- | ---------------------------------- |
| `path/to/file.ts` | Description of what this file does |

#### Modified Files

| File                  | Changes                  |
| --------------------- | ------------------------ |
| `path/to/existing.ts` | What was changed and why |

#### Deleted Files

| File             | Reason                    |
| ---------------- | ------------------------- |
| `path/to/old.ts` | Why this file was removed |

### Technical Details

**Key Implementation Decisions**:

- Decision 1 and rationale
- Decision 2 and rationale

**Dependencies Added/Removed**:

- Added: `package-name@version` - reason
- Removed: `old-package` - reason

### Breaking Changes

[List any breaking changes or "None"]

### Migration Required

[Any steps needed to adopt these changes or "None"]

### Verification Checklist

- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing performed
- [ ] Documentation updated
- [ ] No console errors
- [ ] Performance acceptable

### Related Issues/Tasks

- Fixes #123
- Related to #456

ステップ 4: コミットメッセージの提案

Conventional Commits 形式のコミットメッセージを作成します。

<type>(<scope>): <description>

<body - what and why>

<footer - breaking changes, issues>

種類：

• feat：新機能
• fix：バグ修正
• refactor：コードの再構成
• docs：ドキュメントのみ
• test：テストの追加
• chore：保守作業

例：

fix(auth): resolve login timeout error

Increased timeout from 5s to 30s for login requests.
The previous timeout was insufficient for users on slow connections.

Fixes #123

ステップ 5: PR の説明（該当する場合）

変更が PR 向けの場合は、要約を詳しく記述します。

## Summary

[Brief description of what this PR does]

## Changes

[List of key changes]

## Testing

[How this was tested]

## Screenshots

[If UI changes]

## Checklist

- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] No breaking changes (or documented)

**バグを修正した後**：

## Changes Summary

### Overview

Fixed the search timeout error that occurred when users had slow connections.

### Changes Made

#### Modified Files

| File                     | Changes                          |
| ------------------------ | -------------------------------- |
| `src/api/search.ts`      | Increased timeout from 5s to 30s |
| `src/api/search.test.ts` | Added test for timeout handling  |

### Technical Details

**Key Implementation Decisions**:

- Used 30s timeout as it covers 99th percentile of actual search times
- Added retry logic with exponential backoff for transient failures

**Dependencies Added/Removed**:

- None

### Breaking Changes

None

### Verification Checklist

- [x] Unit tests pass
- [x] Integration tests pass
- [x] Manual testing performed
- [x] No console errors

### Commit Message

fix(search): increase timeout to handle slow connections

Increased search API timeout from 5s to 30s and added retry logic. Users on slow connections were experiencing frequent timeout errors.

Fixes #456

</usage_example>

<usage_example> 新機能を追加した後：

## Changes Summary

### Overview

Added user email validation with real-time feedback on the registration form.

### Changes Made

#### New Files

| File                               | Purpose                    |
| ---------------------------------- | -------------------------- |
| `src/utils/emailValidator.ts`      | Email validation utilities |
| `src/utils/emailValidator.test.ts` | Tests for email validation |

#### Modified Files

| File                                  | Changes                         |
| ------------------------------------- | ------------------------------- |
| `src/components/RegistrationForm.tsx` | Added validation to email field |
| `src/i18n/en.json`                    | Added validation error messages |

### Technical Details

**Key Implementation Decisions**:

- Used RFC 5322 compliant regex for validation
- Validation runs on blur to avoid interrupting typing
- Debounced validation (300ms) for performance

**Dependencies Added/Removed**:

- None (used built-in regex)

### Breaking Changes

None - additive change only

### Verification Checklist

- [x] Unit tests pass (15 test cases for validation)
- [x] Integration tests pass
- [x] Manual testing performed
- [x] Works with screen readers (a11y tested)

### Commit Message

feat(registration): add email validation with real-time feedback

Added RFC 5322 compliant email validation to registration form. Validation runs on blur with debouncing for smooth UX.

Closes #789

</usage_example>

**関連スキル**： - `thinking-tools` - 要約の前に完了を検証するために使用します - `git-expert` - コミットと PR のワークフローに使用します - `commit-message-guidelines` - Conventional Commits 形式のコミットメッセージに使用します

厳守事項

1. 決して、各項目の変更内容と理由を説明せずにファイル一覧を書かないでください
2. 必ず、レビュー担当者が品質を確認できるよう、検証チェックリストを含めてください
3. 決して、破壊的変更のセクションを省略しないでください。「なし」の場合も明示的に記載してください
4. 必ず、要約に添えるコミットメッセージには Conventional Commits 形式を使用してください
5. 決して、重要なコーディングタスクの後に要約の作成を省略しないでください。必須です

避けるべきパターン

避けるべきパターン	うまくいかない理由	正しい方法
ファイル名だけを列挙する	変更内容や理由が分からない	変更ごとに変更内容と理由を説明する
検証チェックリストを含めない	何をテストすべきかレビュー担当者に分からない	検証項目のチェックリストを必ず含める
破壊的変更のセクションを省略する	互換性の問題にユーザーが不意を突かれる	破壊的変更がない場合も「破壊的変更：なし」と明記する
曖昧なコミットメッセージ（「更新」など）	コミット履歴の追跡可能性が失われる	種類、スコープ、理由を含む Conventional Commits 形式を使用する
時間に追われて要約を省略する	コンテキストが不足し、レビュー時に手戻りが発生する	重要なタスクの後は必ず要約を作成する

メモリプロトコル（必須）

開始前： .claude/context/memory/learnings.md を読みます。

完了後：

• 新しいパターンを発見した場合 -> .claude/context/memory/learnings.md
• 問題が発生した場合 -> .claude/context/memory/issues.md
• 決定した場合 -> .claude/context/memory/decisions.md

中断が発生するものと想定してください。メモリに記録されていないことは、起きていないことと同じです。