Zenn
🌐

DevinにDevinが参照するドキュメントを整備してもらう

に公開
Devin
tech

前書き

前回の記事「DevinのKnowledgeで共通ルールを整備する」では、Devinの出力をより安定させるために、共通ルールとなるDevinのKnowledgeを整備しました。
このKnowledgeによって、日本語での応答の固定化、作業ブランチの命名規則の統一、Gitリポジトリ接続時の初期確認などを自動化することができ、概ね意図通りの動作をするようになったと感じています。

今回は、さらにDevinの出力を安定させるため、プロジェクト毎のコンテキストをDevinが参照できる仕組みを作ります。
具体的には、リポジトリ内にdocsディレクトリを作成し、その中にプロジェクト単位のドキュメントをDevinに整備してもらうという試みです。

なぜプロジェクト内にdocsを置くのか

現在、私はシステム開発においてDevinとCursorを併用しています。
DevinにせよCursorにせよ、プロジェクトに関するドキュメントを管理し、それらを参照してもらう上で、プロジェクト内にドキュメントを置いておくのが現状では安くて立派（シンプルで効率が良い）な方法だと考えています（個人の主観です）。

Devinにドキュメントを整備してもらう

Laravelプロジェクトを例に、実際にDevinにドキュメントを整備してもらいます。

各ファイルのPHPDocを整備する

まず、Devinに対して以下の指示を行いました。

@Devin 以下の仕事をしてください

- leaveanest/hoge repoに接続してください。

- hogeはLaravelを使用しています。全てのファイルを確認し、PHPDocを書くべき全てのファイルのPHPDocを整備してください。

- 既にコードに書かれている日本語のコメントは削除せず、残したまま整備してください。

- 作業ブランチ名は devin/maintenance-phpdoc としてください。

- 作業完了後、fugaブランチに対してプルリクエストを出してください。

この指示により、Devinは指定されたリポジトリに接続し、全てのファイルを確認して必要なPHPDocを整備し、プルリクエストを作成してくれました。

作成されたプルリクエストを確認し、問題がなければマージします。

プロジェクト単位のドキュメントを作成する

次に、プロジェクトの運用をドメイン知識のないエンジニア(Devin)に依頼することを想定し、用意しておくと良いドキュメントの作成をDevinに依頼しました。具体的な指示は以下の通りです。

@Devin 以下の仕事をしてください。

- leaveanest/hoge repoに接続してください。

- 関連するリポジトリ全てに接続してください。

- このプロジェクトの運用をドメイン知識のないエンジニアに依頼すると仮定し、用意しておくと良いドキュメントにはどのようなものがあるか考え、docsディレクトリにドキュメントの作成を行ってください。

- 作業ブランチ名は devin/maintenance-docs としてください。

この指示の結果、Devinはdocsディレクトリ内に以下のMarkdownファイルを作成しました。

  • docs/README.md: プロジェクト概要、環境構築、開発ワークフロー、デプロイ手順などの基本情報
  • docs/ARCHITECTURE.md: システムアーキテクチャ、コンポーネント構成、ディレクトリ構造の説明
  • docs/API.md: APIエンドポイントの詳細な説明とサンプルレスポンス
  • docs/DEPLOYMENT.md: デプロイ手順と環境設定の詳細ガイド
  • docs/TROUBLESHOOTING.md: 一般的な問題とその解決方法

これらのドキュメントを、プルリクエスト内のコメントでの指示や手修正を加えて完成させ、マージしました。

作成したドキュメントをDevinに読んでもらう

作成したプロジェクト単位のドキュメントをDevinが参照できるように整備します。
と言っても、前回の記事で作成したKnowledgeで設定は既に組み込み済みです。
具体的には、Gitリポジトリへの接続時のルールとして、docsディレクトリが存在する場合はその配下のファイル全ての内容を確認するようにという指示を追加してあります。

タイトル: Gitリポジトリへの接続時のルール

内容:

  • Gitリポジトリへの接続時、最初に必ず以下の内容を確認した上で次のStepに移ってください。
    • プロジェクト全体のディレクトリ構造の確認
    • リポジトリ名に docs が含まれている場合、全てのファイルの内容を確認
    • Readme.mdが存在する場合、内容を確認
    • docs ディレクトリが存在する場合、docs ディレクトリ以下のファイル全ての内容を確認

これらのルールは全てのリポジトリにピン留めしてあります。これにより、DevinがGitリポジトリに接続する際、自動的にdocsディレクトリ内のドキュメントを読み込むようになり、プロジェクトのコンテキストを理解した上でタスクに取り組むことが期待できます。

次のステップ

今回は、Devinがプロジェクト毎のコンテキストを参照するための第一歩として、リポジトリ内にdocsディレクトリを作成し、必要なドキュメントをDevinに整備してもらいました。

次回はCursor用のProject Ruleを整備し、Devinもそれに従うように環境を整備していく予定です。これにより、DevinとCursorの両方で一貫した開発体験が得られるようにしていきたいと考えています。

Discussion