第10章

スキルの作成と変更

この章では、スキルファイルの構造を学び、skill-lifecycle-managerとskill-creatorを活用して独自のカスタムスキルを作成・登録する一連の流れを実習します。

本章で学ぶこと
  • スキルファイルの形式と構造
  • YAMLフロントマター各フィールドの意味
  • ボディの記述パターン(Overview、When to Use、Steps、Outputs、Examples)
  • skill-lifecycle-managerの使い方(6ステップ)
  • skill-creator(Claude Codeプラグイン)の使い方
  • 演習: 簡単なカスタムスキルの作成

スキルを再考する

第4章の復習

第4章「マルチエージェントハーネスの概念」で、スキルについて初めて学びました。スキルとは「エージェントが実行できる再利用可能なワークフロー」のことです。スキルは名前・説明・トリガー・ステップの4要素で構成され、特定のキーワードや状況によって自動的に有効化されます。

復習すると、スキルの核心要素は次の4つでした。

  • 名前(Name) — スキルを識別する固有の名前(例: researchhtml-buildpdf-export
  • 説明(Description) — このスキルが何をするのか、どのステップを踏むのかについての詳細説明
  • トリガー(Trigger) — スキルが自動的に有効化される条件(キーワード、コマンドパターン、パイプライン段階)
  • ステップ(Steps) — スキルが実行する具体的な手順(順番に定義)

スキル vs エージェント(もう一度)

第9章でエージェントの作り方を学びました。スキルの作り方を学ぶ前に、2つの概念の違いをもう一度しっかり整理しましょう。

エージェント(Agent)

  • 作業を遂行する「誰が」
  • 役割・権限・ツールを持つAIアシスタント
  • たとえ: 料理人(従業員)
  • ファイルの場所: agents/<name>.md

スキル(Skill)

  • 実行される「何を」
  • 再利用可能なワークフロー手順
  • たとえ: レシピ
  • ファイルの場所: skills/<name>/SKILL.md
初心者向けのたとえ: スキルは「料理のレシピ」です。エージェント(料理人)がそのレシピに従って料理(作業)を行います。1人の料理人が複数のレシピを持てるように、同じレシピを複数の料理人が共有することもあります。レシピが明確なら、どの料理人が作っても結果は一定になります。

スキルのオーナーシップ層

スキルはエージェントと違って独立して存在します。スキルは複数のレイヤーに定義でき、各レイヤーは異なるスコープと影響範囲を持ちます。

L0 — ワークスペース(Workspace)

  • 場所: skills/<name>/SKILL.md
  • 範囲: すべてのプロジェクトで使用可能
  • 優先度: 最も高い(優先度1)
  • 例: syncsecurity-scan

L1 — 共通テンプレート(Common Template)

  • 場所: templates/common/skills/
  • 範囲: そのテンプレートから派生したプロジェクト
  • 優先度: L0の次(優先度2)
  • 例: テンプレート共通の検証スキル

L2 — variantテンプレート(Variant Template)

  • 場所: templates/co-*/skills/
  • 範囲: そのvariantからスキャフォールディングされたすべてのプロジェクト
  • 優先度: L1の次(優先度3)
  • 例: co-deck専用スキル

L3 — プロジェクト(Project)

  • 場所: .claude/skills/または.gemini/skills/
  • 範囲: そのプロジェクトのみ
  • 優先度: 最も低い(優先度4)
  • 例: プロジェクト専用フック

核心ルール

  • 同じスキルが複数の場所にあれば優先度1が使われる
  • L0スキルはグローバルに共有される
  • L2スキルはvariant専用、L3スキルはプロジェクト専用
  • 重複定義は避けるのが原則

なぜ自作するのか?

システムにはすでに多彩なスキルが用意されています。しかしプロジェクトの要件が多様化すると、既存スキルではカバーできないワークフローが生まれます。たとえば:

  • 文書品質レビュー — 生成された文書の一貫性と完成度をレビューするスキル
  • 自動デプロイ — 完成した成果物を特定のサーバーへ自動配置するスキル
  • カスタムレポート生成 — プロジェクト固有の形式でレポートを作るスキル
  • 定期ヘルスチェック — プロジェクト全体の状態を定期的に点検するスキル

このようなワークフローが必要になったら、自分でカスタムスキルを作ってシステムに追加できます。スキルは1つのマークダウンファイルなので、いくつかのルールを守れば誰でも作れます。

スキルはエージェントと違って独立して存在します。複数のエージェントが同じスキルを参照できます。たとえばsyncスキルは主にPMエージェントが使いますが、必要なら他のエージェントも参照できます。

スキルファイル形式

ファイルの場所

スキルファイルはプロジェクトルートのskills/ディレクトリに保存します。エージェントと違い、スキルには専用のフォルダがあります。フォルダ名がそのままスキル名になり、その中にSKILL.mdファイルが入ります。

skills/
├── sync/
│   └── SKILL.md              # 同期スキル
├── security-scan/
│   └── SKILL.md              # セキュリティ検査スキル
├── meeting-facilitation/
│   └── SKILL.md              # 会議進行スキル
├── research/
│   └── SKILL.md              # リサーチスキル
└── my-reviewer/              # ★ 私たちが作るスキル
    └── SKILL.md

ファイル構造: フロントマター + ボディ

SKILL.mdファイルは2つの部分で構成されます。ファイル上部にYAMLフロントマター(メタデータ)があり、その下にマークダウンボディ(実行指示)が続きます。YAMLフロントマターは---3つの記号で始まり、終わるブロック内に書きます。

skills/<name>/SKILL.md YAMLフロントマター(メタデータ) --- name: my-reviewer status: active owner: pm metadata: type: quality --- 区切り線の下からボディ マークダウンボディ(実行指示) ## Overview ## When to Use ## Steps ## Expected Outputs ## Examples ## Notes(任意) フロントマター = スキル識別情報 / ボディ = エージェントが従う実行手順

この構造のポイントは次のとおりです。

  1. YAMLフロントマター---区切りの間に、スキルの識別情報(名前、状態、説明、オーナー、バージョン、メタデータ)を書きます。システムはこの情報でスキルを認識・管理します。
  2. マークダウンボディ — フロントマターの下に、エージェントが従うべき実行手順をマークダウン形式で書きます。Overview(概要)、When to Use(使用条件)、Steps(実行ステップ)、Expected Outputs(期待される成果物)、Examples(使用例)のセクション構成が推奨されます。
スキルはエージェントと違って独立して存在します。複数のエージェントが同じスキルを参照できます。たとえばsecurity-scanスキルはPMエージェントが呼び出すこともできれば、スペシャリストエージェントが直接参照することもできます。

フロントマターの記述

必須フィールドと任意フィールド

YAMLフロントマターには、スキルを識別・管理するための複数のフィールドがあります。必須フィールドと任意フィールドに分かれます。

フィールド 必須 説明
name 必須 スキル固有の名前 my-reviewer
status 必須 active / draft / deprecated active
description 必須 スキルの詳細説明(PMがディスパッチ時に参照) "Reviews document quality..."
owner 必須 保守責任者(エージェントまたは役割) pm
version 必須 バージョン番号(セマンティックバージョン推奨) "1.0.0"
metadata.type 任意 automation / quality / lifecycle quality
metadata.triggers 任意 自動有効化のトリガーキーワード一覧 ["review document", "check quality"]

フィールド詳細解説

  1. name — スキル固有の識別子です。フォルダ名と一致させてください。skills/my-reviewer/SKILL.mdならnameはmy-reviewerです。ケバブケース(kebab-case)を使いましょう。
  2. status — スキルの現在の状態です。active(使用中)、draft(執筆中)、deprecated(使用停止)のいずれかです。新しいスキルはまずdraftで始め、検証が済んだらactiveに変更するのが良いでしょう。
  3. description — スキルの詳細説明です。PMはどのスキルをディスパッチするか決めるときこの説明を参考にするので、明確かつ具体的に書いてください。「何をするか」だけでなく「どのステップを踏むか」も含めるとなおよいでしょう。
  4. owner — このスキルを保守管理する責任を持つエージェントまたは役割です。たとえばPMが管理するスキルならpmを、自動化関連のスキルならautomation-engineerを指定します。
  5. version — スキルのバージョン番号です。セマンティックバージョニング(Semantic Versioning)形式(MAJOR.MINOR.PATCH)を推奨します。例: "1.0.0""1.1.0""2.0.0"
  6. metadata.type — スキルの分類です。automation(自動化)、quality(品質管理)、lifecycle(ライフサイクル管理)のいずれかを選びます。スキル一覧の絞り込みや整理に便利です。
  7. metadata.triggers — スキルが自動で有効化されるトリガーキーワードの一覧です。ユーザーがこれらのキーワードを含む依頼をすると、PMがそのスキルをマッチングしてディスパッチします。トリガーは具体的なほど正確にマッチします。

フロントマターの例

次は実際に使えるフロントマターの例です。

---
name: my-reviewer
status: active
description: Reviews document quality and provides structured feedback. Checks readability, consistency, and completeness of markdown documents.
owner: pm
version: "1.0.0"
metadata:
  type: quality
  triggers:
    - "review document"
    - "check quality"
    - "quality review"
---
初心者向けのコツ: descriptionはPMがスキルを選ぶとき参考にするので、「文書の可読性・一貫性・完成度をレビューし、構造化されたフィードバックを提供します」のように具体的に書きましょう。「文書をレビューする」のような短く曖昧な説明より、長く具体的な説明が良いのです。

ボディコンテンツの記述

ボディ構造の推奨パターン

フロントマターの下にあるマークダウンボディは、エージェントが実際に従うべき実行手順書です。ボディは次の5つのセクションで構成するのが推奨されます。

  1. Overview(概要) — スキルの目的と範囲を1〜2段落で説明します。「このスキルは何のためのものか」「どこまでを対象とするか」を明確にします。
  2. When to Use(使用条件) — このスキルがいつ有効化されるべきか、トリガー条件を説明します。どんな状況・どんな依頼・どんなファイル状態で実行されるのか具体的に書きます。
  3. Steps(実行ステップ) — エージェントが従うべき詳細な手順を番号付きの順序で書きます。各ステップは明確で曖昧さがあってはなりません。「ファイルを読み → レビューし → 結果を書け」というように具体的に指示します。
  4. Expected Outputs(期待される成果物) — スキル実行完了後にどのファイルや成果物が生成されるべきか明示します。ファイル名・パス・形式を含めると、次のエージェントが結果を活用しやすくなります。
  5. Examples(使用例) — 実際の使用場面を例示します。ユーザーがどんな依頼をしたときにこのスキルがどう実行されるのか、具体例を挙げます。

各セクションの書き方のコツ

Overviewセクションでは、スキルの存在理由を説明します。読者(またはエージェント)が「なぜこのスキルを使うのか」を理解できるように書きましょう。

## Overview

このスキルはマークダウン文書の品質を総合的にレビューします。
可読性・一貫性・完成度の3つの観点から文書を評価し、
構造化されたフィードバックを提供します。

When to Useセクションでは、明確なトリガー条件を示します。

## When to Use

ユーザーが次のような依頼をするときに有効化されます:
- 「文書をレビューして」
- 「文書の品質を確認して」
- 「品質レビューをして」

また、他のエージェントが文書完成後に品質レビューを
必要とするとき、PMが自動的にディスパッチすることも
できます。

Stepsセクションは最も重要な部分です。エージェントが従う手順を明確に書きましょう。

## Steps

1. **対象ファイルの確認** — レビューする文書ファイルのパスを確認します。
2. **文書の読み込み** — 対象ファイルを読み込み内容を分析します。
3. **可読性レビュー** — 文の長さ、段落構成、見出し階層を検査します。
4. **一貫性レビュー** — 用語の使用、書式スタイル、日付形式を検査します。
5. **完成度レビュー** — 欠落セクションや不完全な文を確認します。
6. **フィードバック作成** — レビュー結果を構造化された形式にまとめます。

Expected Outputsセクションでは、成果物を明示します。

## Expected Outputs

- レビューレポート(stdout またはファイル出力)
- 問題リスト(項目ごとの深刻度: 警告/修正推奨/エラー)
- 改善提案リスト

Examplesセクションでは、具体的な使用例を示します。

## Examples

**例1:** ユーザーが「この文書をレビューして」と依頼
→ 対象文書を読み込み、5項目を点検したうえで、
  構造化されたフィードバックを提供します。

**例2:** PMがハンドブック執筆完了後に自動ディスパッチ
→ 完成したHTMLファイルのマークダウンソースをレビューし、
  執筆ガイドラインの遵守状況を報告します。
Stepsセクションはエージェントが従うべき「手順書」です。 明確に、順番どおりに書きましょう。曖昧な指示(「文書をよくレビューせよ」)より具体的な指示(「すべてのh2セクションを順に読み、各セクションに本文があるか確認せよ」)が良いのです。エージェントは指示に忠実に従うので、指示が正確なほど成果物の品質が上がります。

skill-lifecycle-managerの利用

skill-lifecycle-managerとは?

skill-lifecycle-managerは、スキルの作成・検証・保守を案内する管理スキルです。第9章で学んだagent-lifecycle-managerのスキル版と考えてください。新しいスキルを作るときこのスキルの指示に従えば、漏れなく正しい構造でスキルを書けます。

このスキルの核心的な役割は次のとおりです。

  • 新しいスキル作成時に必要なステップを案内
  • フロントマターフィールドの正しい記述の確認
  • システム登録(AGENTS.md、VERSION_MANIFEST.md)手順の案内
  • 検証スクリプト実行の手順提供

6ステップのプロセス

skill-lifecycle-managerは、スキル作成を6段階で案内します。各ステップを順に守れば完成度の高いスキルが作れます。

skill-lifecycle-manager 6-Step プロセス Step 1 ディレクトリ作成 skills/<name>/ Step 2 フロントマター記述 YAMLメタデータ Step 3 ボディ記述 実行手順書 Step 4 システム登録 AGENTS.md + VERSION_MANIFEST Step 5 検証スクリプト実行 skill-lifecycle-audit.ts Step 6 有効化テスト 実際の依頼でテスト 各ステップの詳細: Step 1: skills/<name>/ディレクトリを作成します。名前はケバブケースを使います。 Step 2: SKILL.mdのYAMLフロントマターを書きます。name、status、description、owner、versionを必須入力します。 Step 3: Overview、When to Use、Steps、Expected Outputs、Examplesセクションを順に書きます。 Step 4: AGENTS.mdのSkillsテーブルとdocs/VERSION_MANIFEST.mdにスキルを登録します。 Step 5: bun scripts/skill-lifecycle-audit.tsを実行し、フロントマターと構造を検証します。 Step 6: PM経由で実際の依頼によりスキルが正常動作するか確認します。トリガーキーワードでテストします。 検証に失敗したらStep 2〜3に戻って修正 → 再検証を繰り返します。全ステップ合格後にstatusをdraftからactiveへ変更します。

各ステップの詳細ガイド

  1. スキルディレクトリの作成skills/<name>/フォルダを作ります。名前はケバブケース(小文字+ハイフン)を使います。例: skills/my-reviewer/。その中に空のSKILL.mdファイルを作成します。
  2. フロントマターの記述 — 先ほど学んだ必須フィールド(name、status、description、owner、version)と任意フィールド(metadata.type、metadata.triggers)を書きます。最初はstatusをdraftにします。
  3. ボディの記述 — Overview、When to Use、Steps、Expected Outputs、Examplesセクションを書きます。Stepsセクションは特に明確に、番号付きの順序で書いてください。
  4. システム登録 — AGENTS.mdのSkillsテーブル(§6)にスキルを追加し、docs/VERSION_MANIFEST.mdにバージョン情報を記録します。このステップを経て初めてシステムがスキルを認識します。
  5. 検証 — bun scripts/skill-lifecycle-audit.tsスクリプトを実行し、フロントマターのフィールド漏れ、ファイル構造エラー、必須セクション欠落などを自動検査します。エラーがあれば修正して再検証します。
  6. 有効化テスト — PM経由で実際の依頼によりスキルをテストします。たとえば「文書の品質をレビューして」と依頼し、スキルが正しくトリガーされ実行されるか確認します。すべてのテストに通ったらstatusをactiveに変更します。

skill-creatorプラグイン

skill-creatorとは?

skill-creatorは、Claude Codeプラグインとして提供される高度なスキル作成ツールです。SKILL.mdを手動で書くだけでなく、このプラグインを活用すればより効率的にスキルを作成・改善できます。

主な機能

skill-creatorは次の機能を提供します。

  • スキル生成 — 対話形式のガイドで新しいSKILL.mdをゼロから書きます。フロントマターのフィールドを一つずつ尋ね、ボディセクションの構成を提案します。
  • スキル修正 — 既存スキルの内容を改善します。トリガーをより具体的にしたり、Stepsセクションをより明確に磨いたりできます。
  • トリガー改善 — スキルのトリガーキーワードを分析し、より正確にマッチするよう改善案を提案します。

テスト駆動の反復執筆

skill-creatorの最も強力な機能はテスト駆動反復執筆(Test-Driven Iterative Authoring)です。次のように進みます。

1. スキルの下書き作成 — skill-creatorが対話形式でフロントマターとボディの草案を生成します。
2. トリガーテスト — 草案をもとに、意図したキーワードでスキルが正しくマッチするかテストします。
3. 結果分析 — マッチング結果を確認し、false positive(意図しないマッチ)やfalse negative(マッチ漏れ)がないか分析します。
4. トリガー修正 — 分析結果をもとにトリガーキーワードやdescriptionを修正します。
5. 再テスト — 修正版でもう一度テストします。満足いくまで2〜5を繰り返します。

Claude Code CLI環境での利用

skill-creatorはClaude Code CLI環境でプラグインとして動作します。Claude Desktop App環境では、直接ファイルを編集する方式で代替できます。

Claude Code CLI環境

  • skill-creatorプラグイン使用可能
  • 対話式のスキル生成・修正
  • トリガーテストの自動化
  • 反復執筆ワークフロー対応
  • 別冊B参照

Claude Desktop App環境

  • 直接ファイル編集で代替
  • 本章で学んだ手動方式を使用
  • PM経由でテスト
  • 検証スクリプトを手動実行
  • 初心者におすすめ
skill-creatorはClaude Code CLI環境向けの高度なツールです。Claude Desktop Appでは直接ファイル編集で代替できます。本章で学んだ手動方式(フロントマター+ボディを自力で書く)は、どちらの環境でも使える基本の方法です。

登録とデプロイ

登録場所

スキルの執筆が終わったら、システムがスキルを認識できるよう2か所に登録する必要があります。このステップを省略すると、PMはスキルを見つけられずディスパッチしません。

  1. AGENTS.md Skillsテーブル(§6) — ワークスペースルートのAGENTS.mdファイルにあるSkillsテーブルに、スキル名・ファイルの場所・バージョン・状態を追加します。このテーブルがスキルのレジストリ役を果たします。
  2. docs/VERSION_MANIFEST.md — スキルのバージョン情報と状態を記録します。バージョンの変更履歴を追跡し、どのスキルが有効か一目でわかります。VERSION_MANIFEST.mdはスキルバージョンのSSOT(Single Source of Truth)です。

AGENTS.md登録例

AGENTS.mdのSkillsテーブルに次のように追加します。

| my-reviewer | `skills/my-reviewer/SKILL.md` | quality | Checks readability, consistency, completeness | active | 1.0.0 |

VERSION_MANIFEST.md登録例

- **name:** my-reviewer
  **path:** skills/my-reviewer/SKILL.md
  **version:** 1.0.0
  **status:** active
  **owner:** pm
  **type:** quality

デプロイ: sync-skills.ts

L0(ワークスペース)スキルはsync-skills.tsスクリプトですべてのテンプレート(L1)とプロジェクト(L2)へ同期できます。このスクリプトを実行すると、ワークスペースのスキルがすべての子プロジェクトに複製されます。

# スキル同期スクリプトの実行
bun scripts/sync-skills.ts
L0(ワークスペース)スキルはすべてのプロジェクトで使えます。一方、L2(プロジェクト)スキルはそのプロジェクトでのみ使われます。最初にスキルを作るときはL0に登録して、すべてのプロジェクトで活用できるようにするのがおすすめです。

演習: 独自のカスタムスキルを作る

演習の目標

この演習では「文書レビュースキル(my-reviewer)」を自分で作ります。これまで学んだフロントマター記述・ボディ記述・システム登録・検証の一連の過程を直接体験します。

演習ステップ

  1. Claude Desktop Appでプロジェクトを開く — Claude Desktop Appを起動し、作業中のプロジェクトを開きます。プロジェクトルートにskills/フォルダがあるか確認します。
  2. ディレクトリ作成skills/my-reviewer/フォルダを作り、その中にSKILL.mdファイルを作成します。
  3. フロントマターの記述 — SKILL.mdファイルの上部にYAMLフロントマターを書きます。下の例を参考にしてください。
  4. ボディの記述 — フロントマターの下にOverview、When to Use、Steps、Expected Outputs、Examplesセクションを書きます。
  5. AGENTS.mdへの登録 — AGENTS.mdのSkillsテーブルにmy-reviewerスキルを追加します。
  6. 検証スクリプトの実行bun scripts/skill-lifecycle-audit.tsを実行してスキル構造を検証します。エラーがあれば修正します。
  7. PM経由のテスト — Claudeに「文書の品質をレビューして」と依頼し、スキルが正しく動くか確認します。

ファイル全文の例

以下は完成したskills/my-reviewer/SKILL.mdの全文です。そのまま使うか、必要に合わせて修正して活用してください。

---
name: my-reviewer
status: active
description: >
  Reviews document quality and provides structured feedback.
  Checks readability, consistency, and completeness of
  markdown documents. Outputs a structured review report
  with severity levels and improvement suggestions.
owner: pm
version: "1.0.0"
metadata:
  type: quality
  triggers:
    - "review document"
    - "check quality"
    - "quality review"
    - "문서 검토"
    - "품질 확인"
---

## Overview

This skill performs a comprehensive quality review of
markdown documents. It evaluates documents from three
perspectives: readability, consistency, and completeness,
then provides structured feedback with actionable suggestions.

Scope: markdown (.md) files in the project workspace.

## When to Use

Activate this skill when:
- The user requests a document review
- A document has been newly created or significantly revised
- PM dispatches quality review as part of a pipeline gate
- The user asks to "check quality" or "review document"

## Steps

1. **Identify target file** — Confirm the file path of the
   document to review. If not specified, ask the user.
2. **Read the document** — Load the full content of the
   target file.
3. **Readability check** — Evaluate sentence length,
   paragraph structure, heading hierarchy, and overall
   flow. Flag sections that are hard to follow.
4. **Consistency check** — Verify terminology usage, format
   style, date format, heading capitalization, and list
   formatting across the entire document.
5. **Completeness check** — Identify missing sections,
   incomplete sentences, broken references, and unresolved
   TODO markers.
6. **Generate review report** — Compile findings into a
   structured report with severity levels:
   - INFO: minor suggestions
   - WARNING: recommended improvements
   - ERROR: issues that must be fixed

## Expected Outputs

- Structured review report (stdout)
- Issue count by severity (INFO / WARNING / ERROR)
- Prioritized improvement suggestions

## Examples

**Example 1:** User says "review document"
→ Read the specified file, run all 3 checks,
  output a structured review report.

**Example 2:** PM dispatches after handbook chapter
  completion
→ Review the chapter HTML source, check authoring
  guideline compliance, report findings.
スキル完成後、PMに「文書の品質をレビューして」と依頼して正常動作するか確認しましょう。 もしスキルがトリガーされない場合は、フロントマターのtriggersフィールドにそのキーワードが含まれているか、AGENTS.mdにスキルが登録されているかを確認してください。トリガーマッチングはキーワードと完全一致に近いほどよく動きます。

検証チェックリスト

スキル執筆完了後、次のチェックリストで最終確認しましょう。

確認項目 確認内容
ファイルの場所 skills/my-reviewer/SKILL.mdにファイルがありますか?
必須フィールド name、status、description、owner、versionがすべて書かれていますか?
ボディセクション Overview、When to Use、Steps、Expected Outputs、Examplesがありますか?
AGENTS.md登録 Skillsテーブルにスキルが追加されましたか?
VERSION_MANIFEST バージョン情報が記録されましたか?
動作テスト トリガーキーワードで正しく動作しますか?
本章のまとめ
  • スキルはエージェントが遂行する再利用可能なワークフローです。エージェントが「誰」なら、スキルは「何をするか」を定義します。
  • SKILL.mdはYAMLフロントマター(メタデータ)とマークダウンボディ(実行指示)の2部構成です。
  • フロントマターフィールド: name、status、description、owner、versionが必須で、metadata.typeとmetadata.triggersは任意です。
  • ボディはOverview、When to Use、Steps、Expected Outputs、Examplesセクション構成が推奨されます。
  • skill-lifecycle-managerは、ディレクトリ作成 → フロントマター → ボディ → 登録 → 検証 → テストの6ステッププロセスを案内します。
  • skill-creatorは、Claude Code CLI環境でテスト駆動反復執筆を支援する高度なツールです。
  • 登録はAGENTS.md SkillsテーブルとVERSION_MANIFEST.mdの2か所で行います。
次章予告: 第11章では、ここで作ったエージェントとスキルを組み合わせて独自のエージェントチームを編成する方法を学びます。チームの目的を定義し、必要なエージェントとスキルを組み合わせ、チームのワークフローを設計する全過程を実習します。