コンテンツにスキップ

ドキュメント生成の自動化

ソースコードを保守されるドキュメントに変えます。OpenCode はモジュールを読み、公開 API を抽出し、ドキュメントサイトにそのまま置けるリファレンス文書を書きます。

このレシピを使う場面

  • API リファレンスが常にコードより遅れているとき。
  • オンボーディング文書が現在のモジュール構造を反映する必要があるとき。
  • 多数の文書ページで一貫した書式が欲しいとき。

前提条件

  • 正確性のため、型付き関数/クラス(TypeScript、Go など)のコードベース。
  • プロジェクトで OpenCode を設定済み。

手順

  1. ソースを指定する

    ドキュメント化するモジュールと出力先を OpenCode に伝えます。

    src/services/ のすべてのエクスポート関数を文書化してください。それぞれについて、シグネチャ、パラメータ、戻り型、1 行の例を含むセクションを書き、docs/reference/services.mdx に出力してください。

  2. 書式を設定する

    frontmatter と構造を指定し、出力がドキュメントシステムに合うようにします。

    ---
    title: Services Reference
    description: API reference for the services module.
    ---
  3. 正確性を確認する

    OpenCode は真でない挙動を推論することがあります——各説明をコードと照合し、特にエッジケースを検証します。

  4. ビルドに組み込む

    生成ページをサイドバー/ドキュメントパイプラインに追加し、公開されるようにします。

  5. 更新を予定する

    大きな変更後に同じプロンプトを再実行し、ドキュメントを同期させます。

主要なプロンプト

src/services/ のすべてのエクスポートシンボルを読み、Markdown リファレンスを生成してください。それぞれにシグネチャ、パラメータ説明、戻り型、具体例を含めてください。挙動をでっち上げないでください——不明な場合は「要確認」と記載してください。

よくある落とし穴

  • でっち上げられた挙動:生成された説明は常に実際の実装と照合してください。
  • 古いドキュメント:生成された文書はすぐに腐ります——プロンプトをリリースプロセスの一部にしてください。
  • プライベートな内部:実装詳細が漏れないよう、内部/非エクスポートのシンボルは明示的に除外します。

関連ドキュメント

  • ルール — OpenCode がすべてのタスクで従うプロジェクトレベルの指示
  • エージェント — 繰り返しワークフロー用のカスタムエージェント設定

関連レシピ

関連ドキュメント

次のステップ