Skill-Builder: スキル作成用メタスキル

確立されたパターンに従う新しいエージェントスキルを作成するのを支援します。スキル設計のガイド、スキャフォルディングの生成、完全性の検証が役割です。

コア原則

スキルは機能チェックリストではなく、診断フレームワークである。

スキルは問題空間を診断し、状態を特定し、介入手段を提供します。スクリプトはランダム化と構造を提供し、LLMは判断を提供します。各要素がそれぞれ得意なことをします。

スキルの構成要素

すべてのスキルには以下のコンポーネントがあります:

skill-name/
├── SKILL.md           # 診断フレームワーク + ドキュメント
├── scripts/           # Deno TypeScript ツール
│   └── *.ts
├── data/              # JSON データセット (必要に応じて)
│   └── *.json
└── references/        # サポートドキュメント (オプション)
    └── *.md

SKILL.md の構造

---
name: skill-name
description: 動作動詞で始まる1文の説明
license: MIT
metadata:
  author: your-name
  version: "1.0"
  maturity_score: [0-20]                          # オプション
---

# スキル名: サブタイトル

[役割説明]。あなたの役割は[具体的な機能]です。

## コア原則
**診断の本質をとらえた太字の声明。**

## 状態
### 状態 X1: 名前
**症状:** ユーザーが気付くもの
**重要な質問:** 尋ねるべきこと
**介入:** 適用するフレームワーク/ツール

[各状態について繰り返す]

## 診断プロセス
1. ステップ1
2. ステップ2
...

## 重要な質問
### カテゴリA について
- 質問?
- 質問?

## アンチパターン
### [問題名]
**問題:** 説明
**修正:** ソリューション

## 利用可能なツール
### script.ts
それが何をするかの説明。
\`\`\`bash
deno run --allow-read scripts/script.ts [args]
\`\`\`

## 相互作用の例
**ユーザー:** "問題説明"
**アプローチ:**
1. アクション
2. アクション

## 実行しないこと
- 境界のリスト
- スキルが決して行わないこと

## 統合グラフ

### インバウンド (他のスキルから)
| ソーススキル | ソース状態 | リード先状態 |
|--------------|-----------|--------------|
| [skill] | [state] | [state] |

### アウトバウンド (他のスキルへ)
| この状態 | リード先スキル | ターゲット状態 |
|---------|----------------|----------------|
| [state] | [skill] | [state] |

### 補完的なスキル
| スキル | 関係性 |
|--------|--------|
| [skill] | どのように関連しているか |

スキルタイプ

タイプD: 診断スキル

目的: 問題を特定し、介入を推奨する パターン: 状態 → 質問 → 介入 例: story-sense, worldbuilding, conlang

重要な特性:

• 症状/質問を伴う問題状態
• 介入ツールへのクロスリファレンス
• 「実行しないこと」セクションで境界を強制
• 他のスキルへの状態遷移をマッピングする統合テーブル

タイプG: ジェネレータスキル

目的: パラメータから構造化出力を生成する パターン: パラメータ → 生成 → 出力 例: story-senseの関数、conlangの音韻体系

重要な特性:

• デフォルト値付きの入力パラメータ
• オプショナルシーディング付きのランダム化
• 複数の出力形式 (人間向け、JSON、簡潔版)
• 品質レベル (スターター → 包括的)

タイプU: ユーティリティスキル

目的: 他のスキルをサポートし、インフラストラクチャを構築する パターン: 入力 → 分析/変換 → レポート 例: list-builder, skill-builder

重要な特性:

• メタレベルの操作
• 品質メトリクスと検証
• テンプレートとスキャフォルディング
• クロススキル適用性

タイプO: オーケストレータスキル

目的: 複数のスキルを自律ワークフローに調整する パターン: 入力 → マルチパス評価ループ → 洗練された出力 例: chapter-drafter

重要な特性:

• 複数のサブスキルを順序付けて呼び出す
• 品質閾値に達するまで反復する
• 作業単位全体でコンテキストを蓄積する
• 人間のチェックポイントなしで自律的に動作する

必須フロントマター:

metadata:
  orchestrates:           # 調整するサブスキル
    - skill-one
    - skill-two
  pass_order:             # 評価シーケンス
    - skill-one
    - skill-two
  pass_weights:           # スキルごとの重み (合計100)
    skill-one: 50
    skill-two: 50
  max_iterations: 3       # パスごとの反復制限
  global_max_iterations: 50  # 総キャップ

詳細は skills/fiction/orchestrators/README.md を参照してください。

スキル成熟度スコアリング (24点)

スキルはフレームワーク24点システムと並行して24点スケールで評価されます。

完全性 (11点)

チェック	点数	基準
コア原則	1	診断の本質をとらえた太字の声明
状態	2	診断スキルの場合3-7状態 (ジェネレータ/ユーティリティはN/A)
状態コンポーネント	2	各状態の症状、重要な質問、介入
診断プロセス	1	ステップバイステップのプロセスが文書化されている
アンチパターン	2	問題/修正の構造を持つ3以上のアンチパターン
例	2	スキル適用を示す2以上の実例
境界	1	「実行しないこと」セクション

品質 (5点)

チェック	点数	基準
自己完結的	1	他のスキルを読まずに使用できる
タイプ+モード宣言	1	必須フロントマターフィールドが存在
状態命名	1	スキル略語にマッチする一貫した状態プレフィックス
統合マップ	1	他のスキルへの接続を文書化
ツール文書化	1	すべてのスクリプトに使用ドキュメントがある

ユーザビリティ (4点)

チェック	点数	基準
出力永続化	1	カスタマイズされた (ボイラープレートではない) 永続化セクション
段階的開示	1	一目で使用できるクイックリファレンスセクション
決定木	1	一般的なシナリオのルーティング論理
実行可能性	1	各診断の明確なネクストステップ

実行インテリジェンス (4点) — 新規

チェック	点数	基準
推論要件	1	拡張思考がタスクに利益をもたらす場合を指定
実行戦略	1	順序付きvs並列化可能な作業を文書化
サブエージェントガイダンス	1	専門サブエージェントを生成する場合を特定
コンテキスト管理	1	トークン使用量と最適化戦略を文書化

成熟度レベル

レベル	スコア	説明
ドラフト	0-8	コア要素が不足
開発中	9-14	機能するが不完全
安定	15-20	本番環境対応
戦闘テスト済み	21-24	ケーススタディ + 完全な実行インテリジェンス

必須メタデータ

タイプ (必須)

すべてのスキルはフロントマターでそのタイプを宣言する必要があります:

metadata:

タイプ	定義	必須セクション
diagnostic	問題を特定し、介入を推奨する	状態、診断プロセス、アンチパターン
generator	パラメータから構造化出力を生成する	パラメータ、生成ロジック、出力形式
utility	他のスキルをサポートし、インフラを構築する	プロセス、テンプレート、検証
orchestrator	複数のスキルを自律ワークフローに調整する	オーケストレーションループ、パス基準、反復制限

モード (必須)

すべてのスキルはフロントマターでそのモードを宣言する必要があります:

metadata:

モード	定義	ユーザー関係
diagnostic	問題状態を特定して推奨する	エージェントが診断、ユーザーが決定
assistive	コンテンツを作成せずにガイド	エージェントが質問、ユーザーが作成
collaborative	ユーザーと並行して作業	エージェントが作成、ユーザーがガイド
evaluative	既存作業を評価する	エージェントが査閲、ユーザーが対応
application	リアルタイムコンテキストで動作	エージェントが実行、ユーザーが参加
generative	パラメータから出力を作成する	エージェントが作成、ユーザーが選択

複合モード (例: diagnostic+generative) は、スキルが複数の機能を実行する場合に許可されます。

オプショナルメタデータ

metadata:
  maturity_score: 15

状態命名規則

状態は一貫した命名パターンに従う必要があります:

規則: {ABBREV}{NUMBER}: {State Name}

ルール:

1. 略語はスキル名から派生した1-3文字の大文字
2. 番号は0 (「Xが存在しない」状態) または1から開始
3. 状態名は説明的で、単なる番号ではない
4. サブ状態は既存状態の間に挿入する場合は小数記法を使用 (4.5, 5.75)

標準略語:

スキル	略語	例
story-sense	SS	State SS1: Concept Without Foundation
dialogue	D	State D1: Identical Voices
conlang	L	State L1: No Language
worldbuilding	W	State W1: Backdrop World
revision	R	State R1: Overwhelmed
endings	E	State E1: Arbitrary Ending
character-arc	CA	State CA1: Static Character
scene-sequencing	SQ	State SQ1: Scene-Only Pacing
brainstorming	B	State B1: Convergent Ideas
research	RS	State RS1: No Research
requirements-analysis	RA	State RA1: Vague Requirements
system-design	SD	State SD1: No Architecture
chapter-drafter	CD	(オーケストレータ - 状態ではなくパススコアを使用)

新しいスキルは未使用の略語を取得し、ここに文書化する必要があります。

統合グラフ要件

すべてのスキルは他のスキルへの接続を文書化する必要があります。

必須形式:

## 統合グラフ

### インバウンド (他のスキルから)
| ソーススキル | ソース状態 | リード先状態 |
|--------------|-----------|--------------|
| story-sense | SS5: Plot Without Purpose | D4: No Subtext |

### アウトバウンド (他のスキルへ)
| この状態 | リード先スキル | ターゲット状態 |
|---------|----------------|----------------|
| D6: Pacing Mismatch | scene-sequencing | SQ2: Sequel Missing |

### 補完的なスキル
| スキル | 関係性 |
|--------|--------|
| character-arc | 声は変身を反映 |
| worldbuilding | 言語は文化を反映 |

要件:

• 最小1つのインバウンドまたはアウトバウンド接続
• 補完的なスキルリストはコンテキスト用
• 状態レベルの特異性 (単なるスキル間ではなく)
• 双方向文書化 (AがBを参照する場合、BはAを参照すべき)

実行インテリジェンス要件

スキルはClaudeコードでの最適な実行方法を文書化すべきです。

推論要件セクション

拡張思考 (ultrathink) がスキルに利益をもたらす場合を文書化します:

## 推論要件

### 標準推論
- 初期診断と症状マッチング
- 単純な状態特定
- スクリプト実行と出力解釈

### 拡張推論 (ultrathink)
以下の場合に拡張思考を使用:
- マルチフレームワーク統合 - [理由: 複数のモデルを同時に保持する必要]
- 複雑なワールドビルディングシステム - [理由: 多くの相互依存変数]
- 状態間のカスケード分析 - [理由: 2次効果が複合する]

**トリガーフレーズ:** "深い分析"、"包括的なレビュー"、"マルチフレームワーク統合"

なぜこれが重要か: LLMは完了報酬バイアスを持つため、目に見えるゴールに向かって急ぎます。拡張思考は出力前に推論時間を配分し、複雑なタスクの品質を向上させます。これはLLMプロセス設計フレームワーク原則と一致しています。

実行戦略セクション

順序付きvs並列化可能な作業を文書化します:

## 実行戦略

### 順序付き (デフォルト)
- 診断は介入の前に完了する必要あり
- フレームワーク選択前に状態特定

### 並列化可能
- 複数のスクリプト実行 (エントロピー + 関数) は同時実行可能
- 複数フレームワーク間の研究は並列化可能
- 使用場面: タスクが独立しており結果をマージできる場合

### サブエージェント候補
| タスク | エージェントタイプ | 生成する場合 |
|--------|------------------|------------|
| コードベース探索 | Explore | スキルがプロジェクトコンテキストを必要とする場合 |
| フレームワーク研究 | 汎用 | 3以上のフレームワーク間で統合する場合 |

コンテキスト管理セクション

トークン使用量と最適化を文書化します:

## コンテキスト管理

### おおよそのトークン使用量
- **スキル基盤:** ~2k トークン
- **完全な状態定義付き:** ~4k トークン
- **スクリプト インライン付き:** ~8k トークン (デバッグ時以外は回避)

### コンテキスト最適化
- スクリプトをインラインで含めるのではなくオンデマンドでロード
- フレームワークドキュメント全体を埋め込むのではなく名前で参照
- 一般的なケースにはクイックリファレンスセクションを使用

### コンテキストが逼迫した場合
- 優先: 現在の状態診断と直近の介入
- 延期: 統合グラフ、完全なアンチパターンリスト
- 削除: スクリプトソースコード、歴史的な例

アンチパターン要件

すべてのスキルは一般的な間違いを文書化する必要があります。

最小要件:

• 診断スキルの場合は3つのアンチパターン
• ジェネレータ/ユーティリティスキルの場合は2つのアンチパターン

必須構造:

### {アンチパターン名}
**パターン:** 問題のある動作がどのように見えるか
**問題:** これがなぜ害をもたらすか
**修正:** どのように解決するか
**検出:** [オプション] これが発生していることを認識する方法

一般的なアンチパターンカテゴリ:

カテゴリ	例名
スコープクリープ	The Kitchen Sink, The Mission Creep
深さの欠如	The Surface Treatment, The Checklist
間違ったレベル	The Bottom-Up Edit, The Premature Optimization
ユーザー関係	The Puppet Master, The Passive Recipient
統合	The Orphan Skill, The Boundary Ignorer

スクリプトパターン

標準スクリプトテンプレート

#!/usr/bin/env -S deno run --allow-read

/**
 * スクリプト名
 *
 * それが何をするかの説明。
 *
 * 使用方法:
 *   deno run --allow-read script.ts [args]
 */

// === INTERFACES ===
interface ResultType {
  field: string;
  // ...
}

// === DATA ===
const DATA: Record<string, string[]> = {
  category: ["item1", "item2"],
};

// === UTILITIES ===
function randomFrom<T>(arr: T[], count: number = 1): T[] {
  const shuffled = [...arr].sort(() => Math.random() - 0.5);
  return shuffled.slice(0, Math.min(count, arr.length));
}

// === CORE LOGIC ===
function generate(/* params */): ResultType {
  // 生成ロジック
}

// === FORMATTING ===
function formatResult(result: ResultType): string {
  const lines: string[] = [];
  // 出力をフォーマット
  return lines.join("\n");
}

// === MAIN ===
function main(): void {
  const args = Deno.args;

  // ヘルプ
  if (args.includes("--help") || args.includes("-h")) {
    console.log(`スクリプト名

使用方法:
  deno run --allow-read script.ts [options]

オプション:
  --flag     説明
  --json     JSON として出力
`);
    Deno.exit(0);
  }

  // 引数を解析
  const flagIndex = args.indexOf("--flag");
  const flagValue = flagIndex !== -1 ? args[flagIndex + 1] : null;
  const jsonOutput = args.includes("--json");

  // 位置引数検出用のインデックスをスキップ
  const skipIndices = new Set<number>();
  if (flagIndex !== -1) {
    skipIndices.add(flagIndex);
    skipIndices.add(flagIndex + 1);
  }

  // 位置引数を検索
  let positionalArg: string | null = null;
  for (let i = 0; i < args.length; i++) {
    if (!args[i].startsWith("--") && !skipIndices.has(i)) {
      positionalArg = args[i];
      break;
    }
  }

  // 生成
  const result = generate(/* params */);

  // 出力
  if (jsonOutput) {
    console.log(JSON.stringify(result, null, 2));
  } else {
    console.log(formatResult(result));
  }
}

main();

引数解析パターン

// 1. ヘルプチェック最初
if (args.includes("--help") || args.includes("-h")) { ... }

// 2. --flag 値ペアを解析
const flagIndex = args.indexOf("--flag");
const flagValue = flagIndex !== -1 ? args[flagIndex + 1] : defaultValue;

// 3. ブール値フラグ
const boolFlag = args.includes("--bool");

// 4. 消費されたインデックスを追跡
const skipIndices = new Set<number>();
if (flagIndex !== -1) {
  skipIndices.add(flagIndex);
  skipIndices.add(flagIndex + 1);
}

// 5. 位置引数を検索
for (let i = 0; i < args.length; i++) {
  if (!args[i].startsWith("--") && !skipIndices.has(i)) {
    positionalArg = args[i];
    break;
  }
}

データロードパターン

// 外部 JSON ファイルの場合
async function loadData<T>(path: string): Promise<T> {
  try {
    const text = await Deno.readTextFile(path);
    return JSON.parse(text);
  } catch (e) {
    console.error(`Error loading ${path}: ${e}`);
    Deno.exit(1);
  }
}

// スクリプトからの相対パス
const scriptDir = new URL(".", import.meta.url).pathname;
const dataPath = `${scriptDir}../data/file.json`;

出力パターン

// 常に複数の形式をサポート
if (jsonOutput) {
  console.log(JSON.stringify(result, null, 2));
} else if (briefOutput) {
  console.log(formatBrief(result));
} else {
  console.log(formatFull(result));
}

データファイルパターン

シンプルリスト (エントロピー/ランダム化用)

{
  "list_name": [
    "アイデアを刺激するのに十分な詳細を持つ具体的なアイテム",
    "理想的には20-60文字の別のアイテム",
    "アイテムは曖昧ではなく具体的であるべき"
  ]
}

品質閾値:

• スターター: 10-30 項目 (デモのみ)
• 機能的: 30-75 項目 (使用可能)
• 本番: 75-150 項目 (対応準備完了)
• 包括的: 150+ 項目 (参考品質)

構造化データ (複雑な生成用)

{
  "_meta": {
    "description": "このデータが何のためにあるか",
    "usage": "どのように使用するか",
    "source": "どこから来たか (オプション)"
  },
  "category": {
    "item_name": {
      "property": "value",
      "frequency": 0.85,
      "tags": ["tag1", "tag2"]
    }
  }
}

周波数加重データ

{
  "tier_universal": {
    "description": "ほぼすべてのケースで見つかる",
    "items": { "a": { "frequency": 0.95 }, "b": { "frequency": 0.90 } }
  },
  "tier_common": {
    "description": "ほとんどのケースで見つかる",
    "items": { "c": { "frequency": 0.70 } }
  },
  "tier_rare": {
    "description": "珍しいが記録されている",
    "items": { "d": { "frequency": 0.15 } }
  }
}

スキル構築の診断プロセス

新しいスキルを作成する場合:

1. 問題空間を特定する

• このスキルが診断する問題は何か?
• ユーザーが気付くであろう症状は何か?
• これは既存のスキルにどのようにつながるか?

2. 状態を定義する

• 3-7の異なる状態を作成する
• 各状態には: 症状、重要な質問、介入が必要
• 状態は相互排他的だが空間を覆うべき

3. ツールを設計する

• スクリプトがLLM判断より何をより良くできるか?
• ランダム化? 構造生成? 検証?
• スクリプトはどのデータが必要か?

4. 統合をマッピングする

• このスキルはどの他のスキルに接続するか?
• 他のスキルのどの状態がここにつながるか?
• どの状態がここから他の場所につながるか?

5. 完全性を検証する

validate-skill.ts を実行して確認:

• 必須フロントマターフィールド
• すべてのコンポーネントを持つ状態定義
• スクリプトドキュメント
• 統合参照

利用可能なツール

scaffold.ts

スキルディレクトリ構造とテンプレートファイルを生成します。

# 新しいスキルスキャフォルディングを作成
deno run --allow-read --allow-write scripts/scaffold.ts skill-name

# タイプ指定付き
deno run --allow-read --allow-write scripts/scaffold.ts skill-name --type diagnostic

# 書き込みなしでプレビュー
deno run --allow-read scripts/scaffold.ts skill-name --dry-run

validate-skill.ts

スキルの完全性とパターン適合性をチェックします。

# スキルを検証
deno run --allow-read scripts/validate-skill.ts ../worldbuilding

# フィクションクラスター内のすべてのスキルを検証
deno run --allow-read scripts/validate-skill.ts --all

# CI用 JSON 出力
deno run --allow-read scripts/validate-skill.ts ../conlang --json

アンチパターン

フィーチャーリストスキル

問題: スキルは実行できることのリストであり、診断フレームワークではない。 修正: 問題状態周辺に再構成する。ユーザーは何に行き詰まっているか?

キッチンシンク

問題: スキルは多すぎることをしようとし、複数の問題領域をカバーする。 修正: フォーカスされたスキルに分割する。1つのスキル = 1つの診断空間。

スクリプトのないスキル

問題: スクリプトは存在しているがSKILL.mdがそれをいつ使用するかを説明していない。 修正: すべてのスクリプトはSKILL.mdを持つスキルに属する (文書化された目的)。

孤立したスキル

問題: スキルは他のスキルを参照されたり、参照したりしていない。 修正: 統合セクションを追加する。他のスキルから/へ状態遷移をマップする。

クローンスキル

問題: スキルは別の名前の別のスキルの状態を複製している。 修正: マージするか、問題空間を明確に区別する。

検証 (オラクル)

このセクションでは、このスキルが確実に検証できる内容と、人間の判断が必要な内容を文書化します。 背景は organization/architecture/context-packet-architecture.md を参照してください。

このスキルが検証できる内容

• 構造的完全性 - validate-skill.ts は必須セクションが存在することをチェック (高い信頼度)
• 状態命名規則 - {ABBREV}{N}: Name パターンを検証 (高い信頼度)
• フロントマター存在 - 必須タイプ/モードフィールドが存在 (高い信頼度)
• セクション存在 - アンチパターン、統合グラフ、出力永続化が存在 (高い信頼度)
• 状態コンポーネント構造 - 状態ごとに症状/質問/介入が存在 (中程度の信頼度)

人間の判断が必要な内容

• 状態品質 - 状態は相互排他的で包括的か? (意味的)
• 統合精度 - 状態遷移はスキル間で意味があるか? (文脈的)
• アンチパターン有用性 - 実際の失敗モードをキャプチャするか? (経験的)
• 例関連性 - 例は実際のユースケースと一致しているか? (ドメイン知識)
• 境界の適切性 - スコープは1つのスキルに対して正しいか? (設計判断)

利用可能な検証スクリプト

スクリプト	検証内容	信頼度
validate-skill.ts	完全性/品質/ユーザビリティ全体の20点成熟度スコアリング	構造は高、意味論は低
scaffold.ts	生成ファイルが予期された構造に一致	高

オラクル制限

validate-skill.ts スクリプト:

• 検出できない 複製されたスキルカバレッジ (クローンスキルアンチパターン)
• 検出できない スコープクリープ (キッチンシンクアンチパターン)
• 検証できない 統合双方向性 (両スキルを手動でチェック必須)
• セクション存在を報告し品質ではない - セクションが存在していても良くない可能性がある

フィードバックループ

このセクションでは、出力がどのように永続化され、将来のセッションに情報を与えるかを文書化します。 背景は organization/architecture/context-packet-architecture.md を参照してください。

セッション永続化

• 出力場所: skills/{cluster}/{skill-name}/ (ディレクトリ構造)
• 保存内容: SKILL.md, scripts/, data/, templates/
• 命名パターン: スキル名がディレクトリ名になる

クロスセッション学習

• 開始前: この問題空間に対するスキルが既に存在するかをチェック
• 先行スキルが存在する場合: 複製するのではなく拡張する; 統合グラフをチェック
• このスキルを改善するフィードバック:
  • スキル作成中に発見された新しいアンチパターン
  • 見つかった状態命名競合
  • うまく機能した統合パターン

改善トリガー

• validate-skill.ts が一般的な失敗を明かす場合 → 成熟度基準を更新
• スキル作成が苦労する場合 → アンチパターンに追加
• 統合マッピングが不明確な場合 → 統合グラフセクションを改善

設計制約

このセクションでは前提条件と境界を文書化します。 背景は organization/architecture/context-packet-architecture.md を参照してください。

このスキルが想定する内容

• ユーザーは対処する明確な問題領域を持つ (曖昧な「スキルを作成」ではない)
• 問題領域は識別可能な状態を持つ (ユーザーが気付く症状)
• いくつかのオートメーションが可能 (スクリプト + LLM 分割は意味がある)

このスキルが処理しない内容

• フレームワーク開発 (より高い抽象化) - ルート先: フレームワーク開発方法論
• シングルユーススクリプト (診断モデルなし) - ルート先: シンプルスクリプト作成
• 状態のないスキル (純粋なジェネレータ) - ルート先: ジェネレータテンプレート (より単純な構造)

低下シグナル

このスキルが誤用されている兆候:

• 問題空間の3以上の異なる状態を特定できない
• すべての「状態」が実は単一ジェネレータへのパラメータ
• 既存スキルへの接続が意味を持たない (孤立した問題空間)
• 問題空間が既存スキルと大幅に重複

例: 新しいスキルの構築

リクエスト: "対話問題を診断するスキルを作成"

ステップ1: 問題空間を特定する

対話問題はシーンシーケンシング (構造) とキャラクタアーク (変身) とは異なります。これはキャラクターがどのように話すかについてのものです。

ステップ2: 状態を定義する

• D1: 対話なし (物語の概要のみ)
• D2: 同じ声のキャラクター (皆が同じに聞こえる)
• D3: 露骨な対話 (潜在テキストがない)
• D4: 会話する頭 (コンテキストなしの対話)
• D5: 機能のみの対話 (プロット進行、何も明かさない)

ステップ3: ツールを設計する

スクリプト: voice-check.ts - 声の分化質問票を生成 データ: speech-patterns.json - 地域、階級、人格マーカー

ステップ4: 統合をマッピングする

• story-sense ステート 5.5 (対話固有の問題) から
• character-arc へ (声はキャラクター成長を反映)
• worldbuilding へ (言語は文化を反映)

ステップ5: スキャフォルディングを生成

deno run --allow-read --allow-write scripts/scaffold.ts dialogue --type diagnostic

出力永続化

このスキルはセッション間で作業が永続するようにファイルに一次出力を書き込みます。

出力発見

他の作業を行う前に:

1. プロジェクトで context/output-config.md をチェック
2. 見つかった場合、このスキルのエントリを検索
3. 見つからないか、このスキルのエントリがない場合、最初にユーザーに尋ねる:
   • "このスキルビルダーセッションからの出力はどこに保存すべきか?"
   • 提案: skills/{cluster}/{skill-name}/ (標準スキル位置)
4. ユーザーの設定を保存:
   • コンテキストネットワークが存在する場合は context/output-config.md に
   • そうでない場合はプロジェクトルートの .skill-builder-output.md に

一次出力

このスキルの場合、永続化:

• スキルスキャフォルディング - SKILL.md、scripts/、templates/、data/
• 状態定義 - 診断モデル
• スクリプトテンプレート - 生成されたユーティリティスクリプト
• 統合マップ - 他のスキルへの接続

会話 vs ファイル

ファイルに	会話に残す
生成された SKILL.md	問題空間の議論
スクリプトテンプレート	状態定義の反復
データファイルスタブ	統合計画
検証結果	リアルタイムフィードバック

ファイル命名

パターン: skills/{cluster}/{skill-name}/ (ディレクトリ構造) 例: skills/fiction/dialogue/

実行しないこと

• 明確な問題状態なしでスキルを構築しない
• SKILL.mdドキュメントなしでスクリプトを作成しない
• 既存スキルカバレッジを複製しない
• 統合マッピングをスキップしない
• フレームワークを構築する; ユーザーが作成するスキルを決定する

他のスキルとの統合

list-builder (フィクションクラスター) との連携

任意のデータファイルにlist-builder品質基準を使用します:

• マークの前にリスト成熟度を検証
• リストの多様性のために次元フレームワークに従う

クロスクラスタースキル

スキルは他のクラスターのスキルを参照できます:

• 両スキルで統合をドキュメント化
• クロスクラスター参照時は完全パスを使用

クラスタ規則

クラスター内でスキルを構築する場合:

• フロントマターの親スキルに cluster を設定
• スキル間の状態をマッピングする統合テーブルを追加
• クラスターの確立されたスクリプトとデータパターンに従う