[【katanaで実験中】リリースノート自動化feat.Clineの概要と使い方 - DocBase](https://smarthr-inc.docbase.io/posts/3721805) ---- このドキュメントでは、Clineを用いたkatanaのリリースノート自動化環境のセットアップ手順を説明します。 ## 現在できること - PRのURLや番号を渡すと、それを参照してリリースノートを書いてくれます - PR内にほかのPRやJIRAへのリンクがあると、それも参照します。 - 指示は`.clinerules`に記載されています。 - `docs/`の中にテンプレや過去のリリースノート、ライティングガイドライン、ユビキタス言語等が入っていて、適宜それらを参照します。 - 作成したリリースノートのPRを作成できます。monjoのローカルリポジトリを使います。 ## 関連するファイルの構造 - `.local`: ユーザー個別の設定などを入れる想定。.gitignore追加済み - `.clineconfig.yml`: ユーザー個別の設定ファイル。いまはmonjoのパスを記載 - `.clinerules`: Clineへのインストラクション - `.clineignore`: Clineに読ませないファイルを指定 - `docs` - `release-note` - `drafts`: Clineが書いたリリースノートが入る場所。.gitignoreに追加済み - `release-note-guidelines`: SmartHR Design Systemからパクってきたガイドラインが入っている - `release-note-samples`: monjoからパクってきた過去のリリースノートが入っている - `release-note-template.md`: リリースノートのテンプレ - `terms` - `objects.csv`: ユビキタス言語からパクってきたオブジェクト用語集 - `properties.csv`: ユビキタス言語からパクってきたプロパティ用語集 - `screens.csv`: ユビキタス言語からパクってきた画面名用語集 - `.textlint_idiomatic_usage.yml`: textlint-rule-preset-smarthrからパクってきた辞書 ## セットアップ手順 VSCodeとClineをセットアップ済みの場合は、4までスキップしてください。 ### 1\. Visual Studio Codeのインストール ``` brew install code ``` ### 2\. GitHub Copilotのセットアップ GitHub Copilotの利用権限がない場合は、申請して権限をもらいます。 GitHub Copilotの拡張機能もインストールしてください。 [https://marketplace.visualstudio.com/items?itemName=GitHub.copilot](https://marketplace.visualstudio.com/items?itemName=GitHub.copilot) ### 3\. Clineのインストールと設定 Visual Stuido Codeの拡張機能「Cline」をインストールします。 [https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev](https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev) Clineの設定や注意事項については、下記のDocBaseを参照してください。 [VSCodeでCline+Claudeをシュッと使用する方法 - DocBase](https://smarthr-inc.docbase.io/posts/3707341) ### 4\. 対応ブランチの取り込み katanaの`staging`ブランチを取り込みます。 このブランチには、Clineを利用する際の各種設定ファイルが含まれます。 ### 5\. MCP Serverのインストール VSCodeの左のClineアイコンを押してClineを開き、拡張機能アイコンを押してMCP ServersのMarketplaceを開きます。 [](https://image.docbase.io/uploads/22e6a84e-2ebe-4832-9b45-b1b82f7b5de7.png) 「Atlassian」と「GitHub」を探してインストールします。 AtlassianとGitHubのAccess Tokenが必要になります。 Clineから「設定情報教えてケロ」と言われるかもしれませんが、セキュリティ的に気になりはあるので、設定ファイルに人力で入力するほうがいいかもしれません。 MCP Serverの設定ファイルは、MCP Severs画面に移動→**［Installed］**タブを押す→**［Configure MCP Servers］**を押すと出ます。 AtlassianのAPI Tokenは以下のURLから発行します。 [https://id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens) GitHubのPersonal access tokenは以下のURLから発行します。 [https://github.com/settings/tokens](https://github.com/settings/tokens) 権限は`repo`と`read:org`、それと、`read:discussion`、`project`あたりもあると良さそうです。 --- 以上でセットアップは完了です。 ## 使い方 ### リリースノートを書いてもらう Clineを'Act'モードにし、下記のようなプロンプトを入れます。 ``` 下記のPull Requestをもとにリリースノートを作成してください。 * https://github.com/kufu/katana/pull/3370 * https://github.com/kufu/katana/pull/3344 ``` #### 注意事項や課題 - Clineの作成するリリースノートは、フォーマットに従っていなかったり、事実誤認があることがあるので、目視レビューを必ずしてください。 - 作業ブランチはどこでも大丈夫ですが、stagingが無難そうです（リリースノートを書くタイミングで、リリース対象のコードを参照できるため） - リリースPR（`https://github.com/kufu/katana/pull/3099` みたいな）を貼って、その中からユーザー影響のある変更だけをピックアップしてくれると一番良いのですが、現状はあまりうまく判断してくれません。いまのところは、ユーザー影響のあるPRを人間が選別して、個別に貼ってあげるのがよいとおもいます。 - 各リリースのLabelに「改善」「不具合修正」などつけておくと精度が上がるかも？ ### monjoのブランチ作成/commit/push Clineに「monjoにpushして」とお願いすると、monjoのローカルリポジトリに移動してブランチ作成/commit/pushまでしてくれます。 - monjoローカルリポジトリが準備済（`git clone`と`pnpm i`までしてある）の必要があります。 - `.local/clineconfig.yml`に`monjo_dir`というkeyで、monjoローカルリポジトリのパスを指定する必要があります（ファイルがなければたぶん聞いてきます） ### monjoのPull Requestをつくってもらう monjoにpushしたあとに「Pull Requestをつくって」などとお願いすると、monjoのPR作成まで代行してくれます。 ## 実験・検証にあたってのお願い 3〜4月の期間でkatanaで実験していくにあたり、下記のお願いをしたいです🙏 - Clineの動作検証や改善をしていくにあたり、「Clineがどのような結果を出力したか」「どういうトラブルがあったか」というのを記録しておくのが重要になります。 - そのため、実験中は、リリースノートを下記のようなワークフローで実施お願いしたいです。 #### 1\. commitまではClineの原稿はそのままにする Clineが出した最初の原稿のコミットを検証用の資料として残したいので、リリースノートを作成してもらったあとは、内容に特に修正を加えず、monjoへのcommitまで進めてください。 #### 2\. 原稿の修正はmonjo上で、最初のcommit後に行なう Clineが書いた原稿に修正が必要な場合は、上記のcommit後に、あらためて修正・commitしてください。 :tiamini: monjoにもすでに`.clinerules`があり、中にライティングガイドラインが入っているので、Clineに「ライティングガイドラインに従ってレビューして」とお願いするのもよいと思います（任意）。 必要な修正が軽微な場合は、pushしたあとにPR上で修正するのでもよいです。 #### 3\. レビュアーはPdE1名、UXライター1名 レビューのプロセスは通常と同じです。PRを作成したら、PdE1名をレビュアーに指定し、Slack Workflow `/review-uxw-talemane` でレビュー依頼してください。 AIを使う場合、作成者がレビュアーを兼ねてるような部分もあるので、将来的にはPdEのレビュアー指定は要らなくなりそうな気もしますが、実験期間ということもあり、いったん指定してください。 #### 4\. なんかうまく動かなかった場合 自動化プロセスになんらかの問題が生じた場合は、PRに詳細を記載しておいていただけると助かります！ ## Cline 珍プレー集 - [UUIDっぽい何かを生成してCIから怒られる](https://github.com/kufu/monjo/pull/7532) - [  Build software better, together GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to o... ](https://github.com/) - [ NO IMAGE GitHub Copilot - Visual Studio Marketplace Extension for Visual Studio Code - Your AI pair programmer ](https://marketplace.visualstudio.com/items?itemName=GitHub.copilot) - [ NO IMAGE Cline - Visual Studio Marketplace Extension for Visual Studio Code - Autonomous coding agent right in your IDE, capable of creating/editing files, runn... ](https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev) ### 参照元メモ - [プロダクト開発におけるAI活用事例集](https://smarthr-inc.docbase.io/posts/3721224) - [（WIP）yabumi：ユーザー向けリリースノートの手引き](https://smarthr-inc.docbase.io/posts/3725461) - [20250312 テック定例](https://smarthr-inc.docbase.io/posts/3726368)