changelog
プロジェクトの変更ログを自動的に維持する
変更ログの更新は時間がかかり、エラーが発生しやすいです。このスキルは、コミット、PR、リリースを分析し、IdeaVimフォーマットに従って正確でユーザー中心の変更ログエントリを自動的に生成します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「changelog」を使用しています。 Update changelog for commits since last release
期待される結果:
- ## 2.29.0, 2024-01-15
- ### Features:
- * Added support for `g;` and `g,` commands to navigate through change list
- * Implemented `:history` command to show command history
- ### Fixes:
- * [VIM-3456] Fixed visual block mode with wrapped lines
- * [VIM-3458] Fixed `ci"` in strings with escaped quotes
- ### Merged PRs:
- * [850] by contributor: Add surround plugin improvements
「changelog」を使用しています。 Convert changelog to HTML for marketplace
期待される結果:
- <b>Features:</b><br>
- * Added support for <code>g;</code> and <code>g,</code> commands<br>
- * <a href="https://youtrack.jetbrains.com/issue/VIM-3456">VIM-3456</a> Fixed visual block mode<br>
セキュリティ監査
安全This is a pure documentation skill containing only markdown instructions. It provides guidelines for maintaining the IdeaVim changelog and contains NO executable code, network calls, or file operations. All 110 static findings are false positives from the analyzer misinterpreting markdown code block syntax as shell commands and documentation URLs as network indicators.
リスク要因
⚙️ 外部コマンド (59)
🌐 ネットワークアクセス (21)
📁 ファイルシステムへのアクセス (1)
品質スコア
作れるもの
リリース文書の自動化
ユーザー向け変更についてコミットとPRを自動的に分析することで、最小限の労力でプロジェクトの変更ログを更新します。
リリースノートの標準化
確立されたパターンに従い、issueやPRの適切な参照を含む一貫性のあるプロフェッショナルなリリース文書を作成します。
コミュニティの貢献を文書化
外部の貢献者を適切に認知し、内部変更であっても彼らのPRを自動的に変更ログに含めます。
これらのプロンプトを試す
今後の2.29.0リリースのためにIdeaVimの変更ログを更新します。最後に文書化されたバージョン以降のコミットを確認し、すべてのユーザー向け変更を含めます。
[To Be Released]セクションをmasterブランチからの最近のコミットで更新します。ユーザー可視の機能とバグ修正に焦点を当てます。
PR #1234を確認し、変更ログエントリが必要かどうか判断します。必要であれば、変更ログフォーマットに従って適切なエントリを作成します。
最新の[To Be Released]の変更ログエントリをbuild.gradle.kts changeNotesセクション用のHTMLフォーマットに変換します。
ベストプラクティス
- コミット前に生成された変更ログエントリの正確性と明瞭さを必ず確認してください
- 修正や新機能を説明 때는、具体的なコマンドや機能の例を含める
- 新しいIntelliJ統合については、関連するドキュメントやJetBrainsブログへのリンクを含める
回避
- ユーザーに影響しない内部リファクタリングやコードクリーンアップを含めない
- 何）が修正されたかを指定せずに「バグを修正しました」といった曖昧な説明を避ける
- 手動レビューステップをスキップ never - 自動化された変更ログでも人間の検証が必要