spec-loop-setup-doc-rendering

タスクファイルや用語集ファイルのレンダリングを設定または修正する際に使用します。

エージェント専用の動作は、このファイルに記載してください。vscode-setup.md と jetbrains-setup.md は共有のセットアップ資料として扱い、エージェントのポリシー指示を記載する場所にはしないでください。

セットアップ資料の内容をそのまま言い換えるだけにしないでください。まず、コマンドやアクセス可能なプロジェクト内の設定から自分で証拠を集めたうえで、次の点を報告してください。

• すでに動作していること
• 不足していること、または壊れていること
• 直接確認できていないこと

直接確認したあと、レンダリングをエンドツーエンドで検証するため、小さな Markdown と AsciiDoc の検証ファイルの作成を提案してください。これらの検証ファイルでは、現在のワークフローで使用が想定されている種類の図を扱い、少なくとも 1 つのクラス図を含めてください。シーケンス図、コンポーネント図、Mermaid の用語集図など、関連するほかの種類も含めてください。

定型的な確認をユーザーに任せるより、直接確認することを優先してください。

選択したセットアップ手順に従ってください。

• JetBrains の手順では、PlantUML の検証の一環として、command -v dot と dot -V で Graphviz を確認してください。
• VS Code のローカル専用 PlantUML 手順では、command -v java と java -version で Java を、command -v dot と dot -V で Graphviz を確認し、設定されているローカルの plantuml.jar のパスがあれば test -f で確認してください。
• VS Code のサーバーベース手順では、ヘルパースクリプトによる確認を優先し、トラブルシューティングでローカル専用手順が必要だと判断されない限り、Java、Graphviz、ローカルの plantuml.jar の確認は実行しないでください。

glossary.adoc や Spec Loop の AsciiDoc 用語集形式の明示的な使用など、現在のプロジェクトの状態を踏まえて、AsciiDoc のサポートが必要かどうかを判断してください。

.idea/、.vscode/、ワークスペースファイルなど、プロジェクト内の証拠を優先してください。

VS Code、Cursor、およびその他の VS Code ベースの IDE では、サーバーベースのセットアップ手順、スキルのディレクトリ、対応するエディター CLI が利用できる場合、ヘルパースクリプトによる確認手順を優先してください。

ユーザーが明示的に確認を許可しない限り、プロジェクトのディレクトリ内にとどまってください。プラグインや IDE の設定をプロジェクト内のファイルから確認できない場合は、エディター設定用の外部ディレクトリを調べる前に許可を求めてください。

プラグイン、拡張機能、IDE の設定、エディターの設定を変更する前に、確認を求めてください。

ユーザーの意図が明らかな誤字の修正や、簡単な一語の曖昧さの解消だと明確に分かる場合は、率直に確認してください。そのために形式的な確認の枠組みを持ち出さないでください。

VS Code、Cursor、およびその他の VS Code ベースの IDE では、vscode-setup.md を読んでください。 JetBrains IDE では、jetbrains-setup.md を読んでください。

ここに実在するセットアップ資料だけを使用してください。