IBM Bob の Skills を、Open Liberty で試してみた

本記事で作成したアプリとSkillsは以下のリポジトリに公開しています。
https://github.com/ktgrryt/bob-skills-demo

IBM Bob で Skills の機能を触ってみました。

Skills は、Bob に新しいワークフローや専門タスクを教えるための 再利用可能な指示セット で、いわば「Bob に覚えさせるレシピ」のような仕組みです。Bob の公式ドキュメントでも、Skills は一貫性のある反復作業や、コードレビュー・テスト・ドキュメント化のような専門化された作業に向いていると説明されています。

この記事では、以下を試します。

• IBM Bob の Skills とは何か をざっくり理解する。
• 実際に Skill を作る
• Skills とスラッシュコマンドの違い を整理する。

IBM Bobを試す

30日間の無料トライアルでは、IBM Bob の利用に必要なクレジット”Bobコイン”を、40Bobコイン分ご利用いただけます。
お申し込みはこちらから行えます。
Bobコインの追加が必要な場合は、こちらから少額よりご購入いただけます。

Skills とは？

IBM Bob の Skills は、Bob に特定のワークフローを実行させるための再利用可能な指示セットです。
単発のプロンプトとは異なり、毎回同じ手順・同じ観点で作業してほしい場合に適しています。

公式ドキュメントでも、Skills のメリットとして、再利用しやすいこと、一貫した品質を保ちやすいこと、専門的な作業を定義できること、チームで共有しやすいこと、補助ファイルをまとめて持たせられることが挙げられています。

また、Skills は Advanced mode でのみ利用可能 です。
これは、Skill に基づくワークフローを実行する際に、Bob が必要なツールへアクセスできるようにするためです。

Skills は毎回手動で呼び出す必要はありません。
Bob は、ユーザーの依頼内容と Skill の description をもとに、どの Skill を使うべきかを自動で判断して適用できます。

Open Liberty で検証用のプロジェクトを作成する

今回は Open Liberty をベースに試しました。
Open Liberty は、軽量でクラウドネイティブな Java アプリケーションやマイクロサービスの開発・実行に向いたランタイムです。
起動の速さ・低メモリ・live reload / dev mode による高速な反復開発、そして Jakarta EE / MicroProfile の modular な feature 構成 が特徴です。

今回は、Open Liberty の Start ページから雛形プロジェクトを作成しました。Start ページでは、Build Tool / Java SE Version / Jakarta EE / MicroProfile のバージョンを選んでスタータープロジェクトを生成できます。今回は Java 21 を選択しています。

検証用のアプリを作る

OpenLibertyはこちらから雛形をダウンロードして、簡単にプロジェクトを作成できます。
https://openliberty.io/start/

今回はJava 21を使用します。

Generate Projectを押すとzipファイルがダウンロードされるので、展開してBobで開きます。

今回は診断系のSkillを作成するので、以下の指示を出してわざと起動しないアプリケーションを作ってもらいました。

現在開いているのはLibertyのプロジェクトの雛形です。
検証のため、あえていくつかの問題を入れて、起動しないサンプルアプリを作成してください
ただし、追加した問題に関する説明はコードには含めないでください。

アプリが完成したらプロジェクトのディレクトリで./mvnw liberty:devを実行し、アプリを起動しようとしてみます。

無事にエラーが出て、起動に失敗しました。
（なお、画面に出ているエラーはBobが意図的に仕込んだ問題ではなく、私のPC上でポート競合が発生していたことが原因でした…。）

(Option) /initを実行

今回の本題からは逸れますが、/initのコマンドでAGENTS.mdファイルを作っておきます。

このコマンドは現在のプロジェクトを分析し、Bobが理解しやすい形で構造化されたプロジェクトコンテキストを AGENTS.md として自動生成してくれます。

/init を実行しておくことで、Bobはプロジェクトの全体像やルールを最初から把握した状態で動けるようになります。

Skill を作ってみる

Skills は、プロジェクト配下の .bob/skills/、もしくは ユーザーのホーム配下の ~/.bob/skills/ に作成します。
プロジェクトローカルに置けばそのリポジトリー専用、ホーム配下に置けばグローバルに使えます。もし同名 Skill が両方にある場合は、プロジェクト側が優先 されます。

今回はこちらの記事で以前作っていたスラッシュコマンド /liberty-doctor を参考にしてSkillを作成しました。

/liberty-doctor は、ざっくり言うと次のような用途のコマンドです。

• Liberty が起動しない
• liberty:dev の様子がおかしい
• server.xml / configDropins / bootstrap.properties が散らばっていて把握しづらい
• messages.log のどこを見ればよいか分からない
• feature が多すぎて、まず何を確認すればよいか整理したい

つまり、Open Liberty / WebSphere Liberty の “入口診断” をするための runbook です。

これをそのまま 1 ファイルのスラッシュコマンドとして持つこともできますが、Bob の Skills は 補助ファイルを同梱できる ので、こういう長めの診断フローは Skill 化との相性が良さそうでした。公式ドキュメントでも、SKILL.md はコアの手順に集中させ、細かいチェックリストや参考資料は supporting files に分けることが勧められています。

今回はプロジェクト専用に、Liberty Doctor という Skill を作りました。

bob-skills/
└── .bob/
    └── skills/
        └── liberty-doctor/
            ├── SKILL.md
            ├── discovery-guide.md
            ├── log-patterns.md
            └── output-template.md

公式ドキュメントによると、Skill の基本は フォルダー + SKILL.md です。SKILL.md は YAML front matter と、その後ろに続く指示本文で構成され、必須フィールドは name と description です。
特に description は、Bob が「この Skill を使うべきか」を判断する材料なので、曖昧にせず具体的に書く必要があります。

また、Skill には SKILL.md 以外にも 補助ファイルを同梱 できます。
公式でも、チェックリスト、テンプレート、リファレンス資料、設定例、スクリプト、スタイルガイドなどを置けると説明されています。
Skill が有効化されると、Bob はそれらの補助ファイルも読めるようになります。

1. SKILL.md

---
name: Liberty Doctor
description: Open Liberty / WebSphere Liberty の起動失敗、dev mode の異常、設定の散在、未解決変数、ポート競合、アプリ配置不整合、feature の過多や矛盾を横断的に診断する。server.xml、configDropins、bootstrap.properties、build 設定、messages.log をもとに、次に確認すべきポイントを整理したいときに使う。
---

あなたは Open Liberty / WebSphere Liberty のアーキテクト兼「Liberty Doctor」です。

目的は、以下のような状況で、プロジェクト全体の入口を最短で整理し、
「次にどこを見るべきか」「何が起動阻害の候補か」を実用的に提示することです。

- Liberty が起動しない
- `liberty:dev` / dev mode の挙動がおかしい
- `server.xml` / `configDropins` / `bootstrap.properties` が散らばっていて把握しにくい
- ログはあるが、どのエラーを優先して見るべきかわからない
- feature が多く、整理や切り分けの入口がほしい

このスキルでは、必要に応じて以下の supporting files を読むこと。

- `discovery-guide.md`
- `log-patterns.md`
- `output-template.md`

## 基本スタンス

- **広く浅く・即効性重視**で診断する
- **質問は最小限**にする
- **ファイル編集はしない**。必要なら差分案・修正案の提示までに留める
- **重い処理は強制しない**。フルビルド・サーバ起動・長時間 dev mode 実行は避ける
- ただし、**軽量な読み取り系の確認**は積極的に行う
  - ファイル探索
  - 設定ファイルの読解
  - ログ抽出
  - 参照先ファイルの存在確認
  - ポート利用状況の確認（可能なら）
- 断定しすぎず、**根拠ファイルやログに基づいて候補化**する

## 実行フロー

### 1) 対象構成を探索する

まず Liberty 関連の構成を探す。  
優先順位や観点は `discovery-guide.md` を参照すること。

確認対象の例:

- `src/main/liberty/config/server.xml`
- `config/server.xml`
- `wlp/usr/servers/*/server.xml`
- `configDropins/defaults/`
- `configDropins/overrides/`
- `bootstrap.properties`
- `jvm.options`
- `server.env`
- `liberty.env`

また、ビルド構成も探す:

- Maven: `pom.xml`, `mvnw`, `.mvn/`
- Gradle: `build.gradle`, `build.gradle.kts`, `gradlew`

さらにログも探す:

- `wlp/usr/servers/*/logs/messages.log`
- `wlp/usr/servers/*/logs/console.log`
- `wlp/usr/servers/*/logs/ffdc/`

`server.xml` が複数ある場合は、もっとも実運用に近そうなものを選ぶ。  
どうしても絞れない場合のみ、短い質問を 1 回だけ行う。

### 2) 設定の散らばりを可視化する

次を短く整理する:

- メインの `server.xml`
- `configDropins/defaults`
- `configDropins/overrides`
- `<include>` / `<includeOptional>` の参照先

特に次の観点で、「どこに何が書かれているか」を整理する:

- HTTP / HTTPS 設定
- SSL / keystore / truststore 関連
- アプリ配置定義
- 変数参照とその定義元候補

`configDropins/overrides` がある場合は、`server.xml` を上書きしている可能性を必ず指摘する。

### 3) ビルド設定と Liberty プラグインを軽く確認する

Maven または Gradle を判定し、Liberty 関連プラグインや dev mode 利用の痕跡を軽く確認する。

重視するのは断定ではなく、以下のような「ズレの候補」である:

- Liberty プラグインの設定が見当たらない
- `server.xml` の場所とビルド設定の期待がずれていそう
- dev mode 前提の構成だが、その痕跡が弱い
- Maven / Gradle が併存し、主系統が曖昧

### 4) feature を簡易診断する

`featureManager` を抽出し、現在の feature 一覧を確認する。  
ただし、このスキルでは feature の深掘り・最小化までは行わない。

次のような兆候があれば、「feature 整理が次の論点」として示す:

- feature 数が多い
- プロファイル feature がある
- `generated-features.xml` がある
- feature 関連エラーがログにある
- 不要 feature を減らしたい意図が見える

その場合は必ず次の文言で案内する:

> feature の最小化や generated-features.xml との差分に基づく安全な整理は `/liberty-feature-min` が得意です。いまの診断結果を踏まえて、次は `/liberty-feature-min` を実行してください。

### 5) ポート競合とバインド系を確認する

可能な範囲で、以下の設定や周辺定義を確認する:

- `httpPort`
- `httpsPort`
- `adminPort`
- `defaultHttpEndpoint`

`${...}` 参照で書かれている場合は、未解決変数の確認に回す。

環境的に可能であれば、対象ポートが既に利用中かどうかも確認する。  
競合が疑われる場合は、ポート番号・分かる範囲のプロセス情報・典型対処を簡潔に示す。

### 6) アプリ配置・デプロイ設定を確認する

次の定義を列挙して確認する:

- `<application>`
- `<webApplication>`
- `<enterpriseApplication>`
- `<springBootApplication>`

見る観点:

- `location`
- 参照先ファイルが存在するか
- 相対パス解決が不自然でないか
- `dropins` 利用の有無
- `contextRoot` の衝突が疑わしくないか
- loose application / plugin 連携前提のズレがないか

### 7) 未解決変数を確認する

`server.xml`、dropins、include 先、`bootstrap.properties` などから `${...}` を抽出し、
以下の候補に定義がありそうか確認する:

- `bootstrap.properties`
- `server.env`
- `liberty.env`
- `jvm.options` の `-D...`
- 環境変数

定義が見当たらない、名前が似ているが揺れていそう、初期化順に依存しそう、などの候補を挙げる。

### 8) ログから起動失敗原因の候補を整理する

もっとも新しい `messages.log` を優先して確認する。  
末尾付近のエラーや起動失敗を示すメッセージを短く抜粋する。

ログ解釈では `log-patterns.md` を参照し、たとえば次のカテゴリで整理する:

- feature 解決 / 依存
- ポート使用中
- アプリ配置ミス
- SSL / keystore / truststore
- データソースや外部接続
- Java バージョン / 互換性
- 権限問題

ログが無い、または古い場合は、そのこと自体を所見として明示する。

## 出力ルール

出力形式は `output-template.md` に従うこと。  
必ず以下を含める:

- 対象として確定した `server.xml`
- 見つかった主要設定ファイル
- 見つかったログ
- 上位 3 件の所見
- すぐ試せる最小アクション
- 必要最小限の追加質問

## 話し方

- 実務で使える粒度で、短く要点をまとめる
- ログは必要な箇所だけ短く引用する
- 断定よりも、根拠付きの候補化を優先する
- 「次に何を見るべきか」を明確にする

2. discovery-guide.md

# Liberty Doctor Discovery Guide

このファイルは、探索順序と優先順位を揃えるための補助資料である。
診断時はここを参照し、無駄な探索を減らすこと。

## 1. server.xml の候補優先順位

複数の `server.xml` がある場合は、以下の順で優先する。

1. `src/main/liberty/config/server.xml`
2. `config/server.xml`
3. `wlp/usr/servers/*/server.xml`
4. その他の `**/server.xml`

判断材料:

- Maven/Gradle の Liberty プラグイン設定と整合していそうか
- ソース管理対象らしい場所か
- 一時生成物やローカル runtime 配下ではないか
- 同階層に `bootstrap.properties` や `configDropins` があるか

どうしても判断できない場合だけ、短く質問する。

## 2. まず見るべき設定ファイル

### Liberty 設定
- `server.xml`
- `configDropins/defaults/`
- `configDropins/overrides/`
- `bootstrap.properties`
- `jvm.options`
- `server.env`
- `liberty.env`

### ビルド設定
- `pom.xml`
- `mvnw`
- `.mvn/`
- `build.gradle`
- `build.gradle.kts`
- `gradlew`

### ログ
- 最新の `messages.log`
- 対応する `console.log`
- `ffdc/` の有無または件数

## 3. 設定の散らばりで最初に整理する観点

### ネットワーク
- `httpPort`
- `httpsPort`
- `adminPort`
- `defaultHttpEndpoint`

### セキュリティ
- SSL 関連設定の場所
- keystore / truststore 参照
- パスワードの変数参照

### アプリ配置
- `<application>`
- `<webApplication>`
- `<enterpriseApplication>`
- `<springBootApplication>`
- `dropins` の使用有無
- `location` の存在確認

### 変数
- `${...}` の参照
- 定義元候補
- 名前揺れや未定義の可能性

## 4. Maven / Gradle の見方

### Maven らしさ
- `pom.xml`
- `mvnw`
- `.mvn/`
- `liberty-maven-plugin`
- `liberty:dev` を示す README や設定

### Gradle らしさ
- `build.gradle`
- `build.gradle.kts`
- `gradlew`
- Liberty プラグイン適用
- `libertyDev` 相当の痕跡

両方ある場合:
- wrapper の有無
- `target/` または `build/` の痕跡
- README や CI 設定
を見て主系統を推定する。

## 5. feature の簡易所見として扱うもの

以下は「断定」ではなく「怪しい兆候」として扱う。

- feature が多すぎる
- `webProfile` などプロファイル feature がある
- `generated-features.xml` がある
- `mp*` が多いのに関連設定が見当たりにくい
- Jakarta / Java EE 世代の混在が疑われる

3. log-patterns.md

# Liberty Doctor Log Patterns

このファイルは、messages.log や console.log の所見を分類するための補助資料である。
必ずしも断定には使わず、「どのカテゴリの問題か」を整理するために使うこと。

## 1. feature 解決 / 依存

### 典型シグナル
- `CWWKF*`
- feature の依存解決失敗
- 互換性のない feature 組み合わせ
- 必要 feature が足りないように見えるメッセージ

### 伝え方
- feature セットが広すぎる、または不整合の可能性がある
- 厳密整理は `/liberty-feature-min` が適している

## 2. ポート競合

### 典型シグナル
- address already in use
- bind 失敗
- socket open 失敗
- endpoint 起動失敗

### 伝え方
- 競合していそうなポート番号を示す
- そのポートを別プロセスが使っている可能性を示す
- ポート変更 / プロセス停止 / Docker / 別 Liberty の確認を提案する

## 3. アプリ配置ミス

### 典型シグナル
- アーカイブが見つからない
- `location` が無効
- 相対パスが不正
- 同じ `contextRoot` が衝突している可能性

### 伝え方
- `location` を確認する
- 相対パスの基準位置を確認する
- build 成果物の生成場所とのズレを疑う

## 4. SSL / keystore / truststore

### 典型シグナル
- keystore が見つからない
- truststore 読み込み失敗
- パスワード不正
- TLS 初期化失敗

### 伝え方
- ファイルパス
- 変数解決
- パスワード定義元
を優先して確認するよう案内する

## 5. データソース / 外部接続

### 典型シグナル
- JDBC 接続失敗
- ドライバ不足
- LDAP / JMS 接続失敗
- 起動中タイムアウト

### 伝え方
- Liberty 自体の起動失敗なのか
- 外部システム接続失敗なのか
を分けて説明する

## 6. Java バージョン / 互換性

### 典型シグナル
- unsupported class version
- bytecode version mismatch
- `javax` / `jakarta` 系の不一致を示唆する症状
- API / runtime の世代差らしいエラー

### 伝え方
- アプリのコンパイル対象
- 実行 Java
- Liberty feature セット
の整合性確認を案内する

## 7. 権限問題

### 典型シグナル
- access denied
- permission denied
- ログ書き込み不可
- ファイル読み込み不可
- ポートオープン不可

### 伝え方
- ファイル権限
- 実行ユーザー
- マウント先や container 権限
の確認を案内する

## 8. ログ引用時のルール

- 長いログをそのまま貼らない
- 重要な 1〜3 行だけ短く引用する
- 引用したログが「どのカテゴリを示すか」を一言で添える
- 不明な場合は「断定できないが、〜系に見える」と表現する

4. output-template.md

# Liberty Doctor Output Template

診断結果は、必ず次の順番で出力する。
読みやすさを最優先し、冗長になりすぎないこと。

---

## 1. 診断対象の確定情報

以下を箇条書きで簡潔に出す。

- 探索ルート
- 対象 `server.xml`
- 見つかった主要設定
  - `configDropins/defaults`
  - `configDropins/overrides`
  - `bootstrap.properties`
  - `jvm.options`
  - `server.env`
  - `liberty.env`
- 見つかったログ
  - `messages.log`
  - `console.log`
  - `ffdc/` の有無

---

## 2. サマリー（結論ファースト）

次の 3 段階で全体感を示す。

- 🟢 問題は大きくなさそう
- 🟡 要確認ポイントあり
- 🔴 起動阻害の疑いが強い

続けて、上位 3 件の所見を出す。  
各所見には、根拠となるファイルまたはログを必ず添える。

### 例
- 🔴 `bootstrap.properties` に見当たらない変数 `${http.port}` を `server.xml` が参照している
- 🟡 `configDropins/overrides` 側に HTTP endpoint の上書き候補がある
- 🟡 最新 `messages.log` にポート使用中らしいエラーがある

---

## 3. 観察結果（カテゴリ別）

以下のカテゴリに分けて、短く要点だけ示す。

### 設定の散らばり
- どこに何が書いてあるか
- overrides が上書きしそうか
- include の参照先はどこか

### ビルド / プラグイン
- Maven か Gradle か
- Liberty プラグインらしき設定
- dev mode 前提とのズレがあるか

### feature（簡易所見）
- feature 一覧の要約
- 多すぎる / generated-features.xml / プロファイル feature の有無

### ポート / デプロイ / 変数
- ポート競合の疑い
- `location` や `contextRoot` の疑い
- 未解決変数の疑い

### ログ起因の失敗候補
- ログの短い引用
- そのログが示すカテゴリ
- 次に確認すべきこと

---

## 4. すぐ試せる次アクション

2〜5 個に絞って提示する。

例:
- `${db.user}` の定義元を `bootstrap.properties` / `server.env` / `jvm.options` で確認する
- 競合している 9080 番ポートを変更するか、利用中プロセスを停止する
- `webApplication location="..."` の相対パス基準を見直す
- `configDropins/overrides` の endpoint 定義を先に確認する

ファイル編集はしない。必要なら修正案だけ出す。

---

## 5. 追加質問（必要最小限）

質問は最大 2 個まで。  
本当に必要なときだけ聞く。

例:
- `server.xml` が複数あります。今回の診断対象はどちらですか？
- 主に使っているのは Maven と Gradle のどちらですか？

---

## 6. feature 誘導文（必要時は必須）

以下のどれかに当てはまる場合、最後に必ず付ける。

- feature が多い
- `generated-features.xml` がある
- feature 系エラーがログにある
- 不要 feature を減らしたい意図が見える

今回の Skill では、Bob に次のような流れで診断させるようにしました。

1. server.xml や bootstrap.properties などの設定ファイルを探す
2. messages.log を中心に、最新のログから起動失敗候補を拾う
3. ポート競合・未解決変数・アプリ配置ミスをざっくり確認する
4. Maven / Gradle と Liberty プラグインのズレを軽く見る
5. feature は簡易診断だけ行い、深掘りが必要なら別コマンドへ誘導する

いきなり修正せず、まずは「何を見たか」「どこが怪しいか」「次にどこを見るべきか」を、Bob に短く整理してもらう設計にしています。

もともとの /liberty-doctor スラッシュコマンドでもやっていたのはこの入口整理で、Skill 化することで 毎回長い前提を貼らなくても、Bob が同じ診断フローを再利用できるようになりました。

実際に使ってみる

Skill は Advanced mode で試します。Bob の Skills は公式に Advanced mode 専用 です。

新しいチャットを開き、例えば以下のように Bob に依頼します。

OpenLibertyのこのプロジェクトが起動しません。原因を洗い出してください。

この依頼内容だと、Bob は description を見て 「Liberty の診断 Skill が合いそうだ」 と判断し、Liberty Doctor を読み込んでくれます。

スキルの実行結果として、無事にoutput-template.mdで定義した通りのフォーマットで診断結果を報告してくれました！

スラッシュコマンドとの違い

最初は「Skills ってスラッシュコマンドの上位版？」くらいの認識だったのですが、実際にはかなり役割が違います。

一言で書くと、
Slash command は「自分で押す定型ボタン」、
Skill は「Bob に覚えさせる専門知識・手順書」です。

スラッシュコマンドは「自分で押す定型ボタン」

IBM Bob のスラッシュコマンドは、/ を入力して使う 明示的なコマンド起点の仕組み です。組み込みコマンドとして /init、/review、/create-pr などがあり、自作コマンドは .bob/commands/ か ~/.bob/commands/ に Markdown ファイルを置くことで追加できます。
ファイル名がそのままコマンド名になり、必要であれば description や argument-hint を front matter で指定できます。

つまりスラッシュコマンドは、「この操作を今すぐ実行したい」 ときの入口です。
たとえば /review のように、よく使う処理を短い名前で即座に起動できます。
Bob のチャット UI でも、/ を入力すると組み込みコマンドとカスタムコマンドが統合されたメニューが出て、オートコンプリートや曖昧検索で選べます。

Skills は「Bob に覚えさせる専門知識・手順書」

一方 Skills は、ユーザーが毎回 /something と打つものではなく、Bob が依頼内容に応じて裏側で適用する ワークフロー定義 です。
Skill には補助ファイルも含められ、Bob はその Skill を読んだうえで、手順や観点を一定化してタスクを進めます。
ドキュメントでも、Skills は「再利用可能」「一貫した手順」「専門化」「チーム共有」に向いていると説明されています。

自分の理解では、ざっくり次のような使い分けです。

• スラッシュコマンド

  • /review や /create-pr のように、ユーザーが明示的に起動するショートカット。
  • セッション操作や、毎回決まった流れを走らせる時に使う。

• Skills

  • Bobに「こういう時はこの知識・手順で動いてね」と持たせる、再利用可能な知識パック / ワークフロー。
  • 例：「Open Liberty の起動失敗なら、まず設定探索 → ログ確認 → ポート/変数/配置の切り分け、という流れで進めてほしい」

Skills を使ってみてよかった点

1. 毎回の前提説明が減る

同じリポジトリー、同じアーキテクチャ、同じ診断観点で何度も Bob に依頼するなら、Skill 化の効果は大きいです。

今回の例では、

• Open Liberty のプロジェクトであること
• 起動失敗の原因整理をしたいこと
• まずは非破壊・読み取り中心で見てほしいこと
• ログや build 設定も見てほしいこと

といった説明を毎回プロンプトに含めなくても、「Libertyが起動しません」だけでBobがスキルに定義された手順を実行してくれます。

2. 補助ファイルを持てる

単なる一文のショートカットではなく、チェックリストやログ分類ガイド、出力テンプレートを同梱できるのが強いです。
今回のように 探索ルール・ログ解釈・出力形式 が分かれている runbook は、1 ファイルに詰め込むより Skill 向きだと感じました。
公式ドキュメントでも supporting files の利用が推奨されています。

3. チーム運用しやすい

Skills はプロジェクト配下に置けるので、リポジトリーで管理してチーム共有できます。
version control に入れて、チーム一貫性を高めることができるのも大きな利点です。

4. ユーザーがスキルの使い方・使いどころを覚える必要がない

以前スラッシュコマンドを作成した記事を書きましたが、上記の通り、これらはユーザーが自分で実行する必要があります。
また、コマンドによっては適切に引数を入力する必要があり、「どういったコマンドをどのタイミングで使うか」ユーザー側で意識する必要がありました。

一方でSkillsの場合、Bobが必要なタイミングで自分から実行してくれるので、現在どういったスキルが利用可能かを覚えておく必要がなく、ユーザー側の負担が少ないと感じました。

注意点

1. description が雑だと期待通りに動きにくい

公式にもある通り、Bob は Skill の description を見て関連性を判断 します。
なので、"Open Liberty skill" のように短すぎる説明だと、「どの場面で使う Skill なのか」が伝わりづらそうです。
今回は「起動失敗」「dev mode」「設定の散在」「未解決変数」「ポート競合」「feature の過多」など、実際の相談ワードを多めに入れました。

2. 1 ファイルに詰め込みすぎない方がよい

これも公式のベストプラクティスに近いですが、SKILL.md はコアの流れに絞り、細かい観点は supporting files に分けたほうが扱いやすいです。
今回は discovery-guide.md、log-patterns.md、output-template.md に役割を分割しました。
公式ドキュメントでも、参考資料やチェックリストは companion files に逃がすことが推奨されています。

3. Skill と slash command は競合ではなく補完関係

今回やってみて思ったのは、スラッシュコマンドを捨てる必要はないということです。
むしろ、

• /liberty-doctor は 明示的に入口診断したいときの起動トリガー
• Liberty Doctor Skill は Bob に同じ診断フローを覚えさせる仕組み

として、両方あってよいと思いました。
Bob の slash commands は .bob/commands/ に置く Markdown ファイルで、description や argument-hint も持てるので、明示起動したい場面では今でもかなり便利です。

まとめ

IBM Bob の Skills は、単なるプロンプト保存機能ではなく、Bob の仕事の進め方をプロジェクトに合わせて標準化する仕組み だと感じました。
特に Open Liberty のように、server.xml、configDropins、bootstrap.properties、messages.log、build plugin など、複数の情報源を横断して見る必要がある対象では、Skills によって「毎回同じ診断観点を説明する手間」をかなり減らせます。

一方で、スラッシュコマンドは明示的な起動コマンド として依然かなり便利です。単発の操作を素早く呼ぶのがスラッシュコマンド、継続的な作業ルールを持たせるのが Skills、という整理で理解すると分かりやすいと思います。

今回の Liberty Doctor は、以前作っていた /liberty-doctor スラッシュコマンドをそのまま移植するのではなく、SKILL.md + supporting files に分解して、Bob が再利用しやすい runbook にし直してみた、というのがポイントでした。
今後は、

• コードレビュー用 Skill
• テスト追加用 Skill
• ドキュメント更新用 Skill

のように分けていくと、Bob を「ただのチャット相手」ではなく、プロジェクトに最適化された相棒 に近づけられそうです。

参考リンク

• IBM Bob Skills docs: https://bob.ibm.com/docs/ide/features/skills
• IBM Bob Slash commands docs: https://bob.ibm.com/docs/ide/features/slash-commands
• Open Liberty Start page: https://openliberty.io/start/
• GitHubリポジトリ: https://github.com/ktgrryt/bob-skills-demo