skill-builder

Skill-Builder：スキル作成のためのメタスキル

確立されたパターンに従って、新しいエージェントスキルを作成するのを支援します。スキルの設計をガイドし、ひな形を生成し、完全性を検証します。

中核原則

スキルとは、機能チェックリストではなく、ツールを備えた診断フレームワークです。

スキルは問題領域を診断し、状態を特定して、介入方法を提示します。スクリプトはランダム化と構造化を担い、LLM は判断を担います。それぞれが最も得意なことを行います。

スキルの構成

すべてのスキルには、次の要素があります。

skill-name/
├── SKILL.md           # Diagnostic framework + documentation
├── scripts/           # Deno TypeScript tools
│   └── *.ts
├── data/              # JSON datasets (if needed)
│   └── *.json
└── references/        # Supporting documentation (optional)
    └── *.md

SKILL.md の構成

---
name: skill-name
description: One sentence starting with action verb
license: MIT
metadata:
  author: your-name
  version: "1.0"
  maturity_score: [0-20]                          # Optional
---

# Skill Name: Subtitle

You [role description]. Your role is to [specific function].

## Core Principle
**Bold statement capturing diagnostic essence.**

## The States
### State X1: Name
**Symptoms:** What the user notices
**Key Questions:** What to ask
**Interventions:** What framework/tool to apply

[Repeat for each state]

## Diagnostic Process
1. Step one
2. Step two
...

## Key Questions
### For Category A
- Question?
- Question?

## Anti-Patterns
### The [Problem Name]
**Problem:** Description
**Fix:** Solution

## Available Tools
### script.ts
Description of what it does.
\`\`\`bash
deno run --allow-read scripts/script.ts [args]
\`\`\`

## Example Interaction
**User:** "Problem description"
**Your approach:**
1. Action
2. Action

## What You Do NOT Do
- List of boundaries
- Things the skill never does

## Integration Graph

### Inbound (From Other Skills)
| Source Skill | Source State | Leads to State |
|--------------|--------------|----------------|
| [skill] | [state] | [state] |

### Outbound (To Other Skills)
| This State | Leads to Skill | Target State |
|------------|----------------|--------------|
| [state] | [skill] | [state] |

### Complementary Skills
| Skill | Relationship |
|-------|--------------|
| [skill] | [how they relate] |

スキルの種類

Type D：診断スキル

目的： 問題を特定し、介入方法を提案します
パターン： 状態 → 質問 → 介入
例： story-sense、worldbuilding、conlang

主な特徴：

• 症状や質問を伴う問題の状態
• 介入ツールへの相互参照
• 境界を明確にする「行わないこと」セクション
• 他のスキルとの対応を示す統合テーブル

Type G：生成スキル

目的： パラメーターから構造化された出力を生成します
パターン： パラメーター → 生成 → 出力
例： story-sense の関数、conlang の音韻論

主な特徴：

• デフォルト値を伴う入力パラメーター
• 任意のシード指定によるランダム化
• 複数の出力形式（人間向け、JSON、簡潔版）
• 品質レベル（スターター → 包括的）

Type U：ユーティリティスキル

目的： 他のスキルを支援し、基盤を構築します
パターン： 入力 → 分析／変換 → レポート
例： list-builder、skill-builder

主な特徴：

• メタレベルの操作
• 品質指標と検証
• テンプレートとひな形
• 複数のスキルに適用可能

Type O：オーケストレータースキル

目的： 複数のスキルを連携させ、自律的なワークフローを実現します
パターン： 入力 → 複数パスの評価ループ → 洗練された出力
例： chapter-drafter

主な特徴：

• 複数のサブスキルを順番に呼び出す
• 品質基準を満たすまで反復する
• 作業単位をまたいでコンテキストを蓄積する
• 人間によるチェックポイントなしで自律的に動作する

必須のフロントマター：

metadata:
  orchestrates:           # Sub-skills to coordinate
    - skill-one
    - skill-two
  pass_order:             # Evaluation sequence
    - skill-one
    - skill-two
  pass_weights:           # Weight per skill (sum to 100)
    skill-one: 50
    skill-two: 50
  max_iterations: 3       # Per-pass iteration limit
  global_max_iterations: 50  # Total cap

アーキテクチャの詳細は skills/fiction/orchestrators/README.md を参照してください。

スキルの成熟度スコア（24点）

スキルは、フレームワークの24点システムに対応した24点満点で評価されます。

完全性（11点）

チェック項目	点数	基準
中核原則	1	診断の本質を捉えた太字の文がある
状態	2	診断スキルは3～7個の状態がある（生成／ユーティリティでは該当なし）
状態の構成要素	2	各状態に症状、重要な質問、介入がある
診断プロセス	1	段階的なプロセスが記載されている
アンチパターン	2	問題／修正の構成で3つ以上のアンチパターンがある
例	2	スキルの適用方法を示す具体例が2つ以上ある
境界	1	「行わないこと」セクションがある

品質（5点）

チェック項目	点数	基準
自己完結性	1	他のスキルを読まずに使用できる
Type+Mode の宣言	1	必須のフロントマターフィールドがある
状態の命名	1	スキルの略称と一致する一貫した状態プレフィックスを使用している
統合マップ	1	他のスキルとの関連を記載している
ツールの説明	1	すべてのスクリプトに使い方の説明がある

使いやすさ（4点）

チェック項目	点数	基準
出力の保存	1	定型文ではなく、スキルに合わせてカスタマイズされた保存セクションがある
段階的な情報開示	1	一目で確認できるクイックリファレンスセクションがある
意思決定ツリー	1	よくあるシナリオの振り分けロジックがある
実行可能性	1	各診断に対して明確な次の手順がある

実行インテリジェンス（4ポイント）— 新規

チェック項目	ポイント	基準
推論要件	1	拡張思考がタスクに有益となる条件を明記している
実行戦略	1	順次実行する作業と並列化可能な作業を記載している
サブエージェントの指針	1	専門のサブエージェントを起動するタイミングを特定している
コンテキスト管理	1	トークン使用量と最適化戦略を記載している

成熟度レベル

レベル	スコア	説明
ドラフト	0-8	中核要素が不足している
開発中	9-14	機能するが不完全
安定	15-20	本番環境で使用可能
実証済み	21-24	ケーススタディと完全な実行インテリジェンスを備えている

必須メタデータ

Type（必須）

すべてのスキルは、フロントマターで type を宣言する必要があります。

metadata:

Type	定義	必須セクション
diagnostic	問題を特定し、介入策を提案します	States、Diagnostic Process、Anti-Patterns
generator	パラメーターから構造化された出力を生成します	Parameters、Generation Logic、Output Formats
utility	他のスキルを支援し、インフラストラクチャを構築します	Process、Templates、Validation
orchestrator	複数のスキルを調整し、自律型ワークフローを構築します	Orchestration Loop、Pass Criteria、Iteration Limits

Mode（必須）

すべてのスキルは、フロントマターで mode を宣言する必要があります。

metadata:

Mode	定義	ユーザーとの関係
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: 基盤のないコンセプト
dialogue	D	State D1: 同じ声
conlang	L	State L1: 言語がない
worldbuilding	W	State W1: 背景としての世界
revision	R	State R1: 圧倒されている
endings	E	State E1: 唐突な結末
character-arc	CA	State CA1: 変化しないキャラクター
scene-sequencing	SQ	State SQ1: シーンだけのペース配分
brainstorming	B	State B1: 収束するアイデア
research	RS	State RS1: 調査なし
requirements-analysis	RA	State RA1: 曖昧な要件
system-design	SD	State SD1: アーキテクチャなし
chapter-drafter	CD	（オーケストレーター — 状態ではなくパスのスコアを使用）

新しいスキルは未使用の略称を割り当て、ここに記載してください。

統合グラフの要件

すべてのスキルは、他のスキルとの接続を記載する必要があります。

必須形式：

## Integration Graph

### Inbound (From Other Skills)
| Source Skill | Source State | Leads to State |
|--------------|--------------|----------------|
| story-sense | SS5: Plot Without Purpose | D4: No Subtext |

### Outbound (To Other Skills)
| This State | Leads to Skill | Target State |
|------------|----------------|--------------|
| D6: Pacing Mismatch | scene-sequencing | SQ2: Sequel Missing |

### Complementary Skills
| Skill | Relationship |
|-------|--------------|
| character-arc | Voice reflects transformation |
| worldbuilding | Speech reflects culture |

要件：

• インバウンド接続またはアウトバウンド接続が最低1つあること
• コンテキスト用に補完的なスキルの一覧を記載すること
• スキル間だけでなく、状態レベルまで具体的に記載すること
• 双方向に記載すること（AがBを参照する場合、BもAを参照する必要があります）

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

スキルは、Claude Code で最適に実行する方法を記載する必要があります。

推論要件セクション

拡張思考（ultrathink）がスキルに役立つ場面を記述します。

## Reasoning Requirements

### Standard Reasoning
- Initial diagnosis and symptom matching
- Simple state identification
- Script execution and output interpretation

### Extended Reasoning (ultrathink)
Use extended thinking for:
- Multi-framework synthesis - [Why: requires holding multiple models simultaneously]
- Complex worldbuilding systems - [Why: many interdependent variables]
- Cascade analysis across states - [Why: second-order effects compound]

**Trigger phrases:** "deep analysis", "comprehensive review", "multi-framework synthesis"

重要な理由： LLM には完了報酬バイアスがあり、目に見える目標へ急いで向かう傾向があります。拡張思考では、出力の前に推論の時間を確保するため、複雑なタスクの品質が向上します。これは、LLM Process Design Framework の原則に沿っています。

実行戦略セクション

逐次作業と並列作業について記述します。

## Execution Strategy

### Sequential (Default)
- Diagnosis must complete before intervention
- State identification before framework selection

### Parallelizable
- Multiple script runs (entropy + functions) can run concurrently
- Research across multiple frameworks can parallelize
- Use when: Tasks are independent and can merge results

### Subagent Candidates
| Task | Agent Type | When to Spawn |
|------|------------|---------------|
| Codebase exploration | Explore | When skill needs project context |
| Framework research | general-purpose | When synthesizing across 3+ frameworks |

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

トークンの使用量と最適化について記述します。

## Context Management

### Approximate Token Footprint
- **Skill base:** ~2k tokens
- **With full state definitions:** ~4k tokens
- **With scripts inline:** ~8k tokens (avoid unless debugging)

### Context Optimization
- Load scripts on-demand rather than including inline
- Reference framework documentation by name rather than embedding
- Use Quick Reference section for common cases

### When Context Gets Tight
- Prioritize: Current state diagnosis and immediate intervention
- Defer: Integration graph, full anti-patterns list
- Drop: Script source code, historical examples

アンチパターン要件

すべてのスキルで、よくある間違いを記述する必要があります。

最小要件：

• 診断スキルではアンチパターンを3つ
• ジェネレーター／ユーティリティスキルではアンチパターンを2つ

必須の構成：

### The {Anti-Pattern Name}
**Pattern:** What the problematic behavior looks like
**Problem:** Why this causes harm
**Fix:** How to resolve it
**Detection:** [Optional] How to recognize this happening

よくあるアンチパターンのカテゴリ：

カテゴリ	名前の例
スコープの拡大	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

/**
 * Script Name
 *
 * Description of what it does.
 *
 * Usage:
 *   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 {
  // Generation logic
}

// === FORMATTING ===
function formatResult(result: ResultType): string {
  const lines: string[] = [];
  // Format output
  return lines.join("\n");
}

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

  // Help
  if (args.includes("--help") || args.includes("-h")) {
    console.log(`Script Name

Usage:
  deno run --allow-read script.ts [options]

Options:
  --flag     Description
  --json     Output as JSON
`);
    Deno.exit(0);
  }

  // Parse arguments
  const flagIndex = args.indexOf("--flag");
  const flagValue = flagIndex !== -1 ? args[flagIndex + 1] : null;
  const jsonOutput = args.includes("--json");

  // Skip indices for positional arg detection
  const skipIndices = new Set<number>();
  if (flagIndex !== -1) {
    skipIndices.add(flagIndex);
    skipIndices.add(flagIndex + 1);
  }

  // Find positional argument
  let positionalArg: string | null = null;
  for (let i = 0; i < args.length; i++) {
    if (!args[i].startsWith("--") && !skipIndices.has(i)) {
      positionalArg = args[i];
      break;
    }
  }

  // Generate
  const result = generate(/* params */);

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

main();

引数解析パターン

// 1. Help check first
if (args.includes("--help") || args.includes("-h")) { ... }

// 2. Parse --flag value pairs
const flagIndex = args.indexOf("--flag");
const flagValue = flagIndex !== -1 ? args[flagIndex + 1] : defaultValue;

// 3. Boolean flags
const boolFlag = args.includes("--bool");

// 4. Track consumed indices
const skipIndices = new Set<number>();
if (flagIndex !== -1) {
  skipIndices.add(flagIndex);
  skipIndices.add(flagIndex + 1);
}

// 5. Find positional args
for (let i = 0; i < args.length; i++) {
  if (!args[i].startsWith("--") && !skipIndices.has(i)) {
    positionalArg = args[i];
    break;
  }
}

データ読み込みパターン

// For external JSON files
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);
  }
}

// Relative path from script
const scriptDir = new URL(".", import.meta.url).pathname;
const dataPath = `${scriptDir}../data/file.json`;

出力パターン

// Always support multiple formats
if (jsonOutput) {
  console.log(JSON.stringify(result, null, 2));
} else if (briefOutput) {
  console.log(formatBrief(result));
} else {
  console.log(formatFull(result));
}

データファイルのパターン

単純なリスト（エントロピー／ランダム化用）

{
  "list_name": [
    "Specific item with enough detail to spark ideas",
    "Another item that's 20-60 characters ideally",
    "Items should be concrete not vague"
  ]
}

品質のしきい値：

• スターター：10～30項目（デモのみ）
• 実用レベル：30～75項目（使用可能）
• 本番レベル：75～150項目（すぐに利用可能）
• 包括的：150項目以上（リファレンス品質）

構造化データ（複雑な生成用）

{
  "_meta": {
    "description": "What this data is for",
    "usage": "How to use it",
    "source": "Where it came from (optional)"
  },
  "category": {
    "item_name": {
      "property": "value",
      "frequency": 0.85,
      "tags": ["tag1", "tag2"]
    }
  }
}

頻度で重み付けしたデータ

{
  "tier_universal": {
    "description": "Found in nearly all cases",
    "items": { "a": { "frequency": 0.95 }, "b": { "frequency": 0.90 } }
  },
  "tier_common": {
    "description": "Found in most cases",
    "items": { "c": { "frequency": 0.70 } }
  },
  "tier_rare": {
    "description": "Unusual but attested",
    "items": { "d": { "frequency": 0.15 } }
  }
}

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

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

1. 問題領域を特定する

• このスキルでどのような問題を診断しますか？
• ユーザーが気づく症状は何ですか？
• 既存のスキルとどのようにつながりますか？

2. 状態を定義する

• 互いに異なる状態を3～7個作成します
• 各状態に必要なもの：症状、重要な質問、介入方法
• 状態は相互に排他的でありながら、問題領域全体を網羅する必要があります

3. ツールを設計する

• LLM の判断よりもスクリプトのほうが得意なことは何ですか？
• ランダム化？構造の生成？検証？
• スクリプトに必要なデータは何ですか？

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

• どのほかのスキルとつながりますか？
• ほかのスキルのどの状態からこのスキルにつながりますか？
• このスキルのどの状態から別のスキルにつながりますか？

5. 完全性を検証する

validate-skill.ts を実行して、次の項目を確認します：

• 必須のフロントマター項目
• すべての要素がそろった状態の定義
• スクリプトのドキュメント
• 統合に関する参照

利用可能なツール

scaffold.ts

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

# Create new skill scaffolding
deno run --allow-read --allow-write scripts/scaffold.ts skill-name

# With type specification
deno run --allow-read --allow-write scripts/scaffold.ts skill-name --type diagnostic

# Preview without writing
deno run --allow-read scripts/scaffold.ts skill-name --dry-run

validate-skill.ts

スキルの完全性とパターンへの準拠を確認します。

# Validate a skill
deno run --allow-read scripts/validate-skill.ts ../worldbuilding

# Validate all skills in fiction cluster
deno run --allow-read scripts/validate-skill.ts --all

# JSON output for CI
deno run --allow-read scripts/validate-skill.ts ../conlang --json

アンチパターン

機能一覧スキル

問題： スキルが、診断フレームワークではなく、実行できることの一覧になっています。 解決策： 問題の状態を中心に再構成します。ユーザーは何につまずいていますか？

あれもこれも詰め込む

問題： スキルが多くのことをしようとし、複数の問題領域を扱っています。 解決策： 焦点を絞ったスキルに分割します。1つのスキルで扱う診断領域は1つです。

スキルのないスクリプト

問題： スクリプトは存在するものの、いつ使うべきかを説明する SKILL.md がありません。 解決策： すべてのスクリプトを、目的を明記したスキルに含めます。

孤立したスキル

問題： スキルがほかのスキルを参照せず、ほかのスキルからも参照されていません。 解決策： 統合セクションを追加します。ほかのスキルとの間の状態遷移をマッピングします。

複製スキル

問題： スキルが、異なる名前を付けて別のスキルの状態を重複させています。 解決策： 統合するか、問題領域を明確に差別化します。

検証（オラクル）

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

このスキルで検証できること

• 構造上の完全性 - validate-skill.ts は必須セクションが存在することを確認します（高い確信度）
• 状態の命名規則 - {ABBREV}{N}: Name パターンを検証します（高い確信度）
• フロントマターの有無 - 必須の type/mode フィールドが存在することを確認します（高い確信度）
• セクションの有無 - Anti-patterns、Integration Graph、Output Persistence が存在することを確認します（高い確信度）
• 状態コンポーネントの構造 - 各状態に Symptoms/Questions/Interventions が存在することを確認します（中程度の確信度）

人による判断が必要なこと

• 状態の品質 - 状態は相互に排他的で、網羅的ですか？（意味的な判断）
• 統合の正確さ - 状態遷移はスキル間で筋が通っていますか？（文脈的な判断）
• アンチパターンの有用性 - 実際の失敗例を捉えていますか？（経験に基づく判断）
• 例の関連性 - 例は実際のユースケースに合っていますか？（ドメイン知識）
• 境界の適切さ - 1つのスキルとして適切なスコープですか？（設計上の判断）

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

スクリプト	検証内容	確信度
validate-skill.ts	完全性／品質／使いやすさにわたる20項目の成熟度スコアリング	構造については高く、意味については低い
scaffold.ts	生成されたファイルが想定される構造に一致するか	高い

オラクルの制限事項

validate-skill.ts スクリプトでは、次のことはできません。

• 検出できません スキルの適用範囲の重複（The Clone Skill アンチパターン）
• 検出できません スコープクリープ（The Kitchen Sink アンチパターン）
• 検証できません 統合の双方向性（両方のスキルを手動で確認する必要があります）
• 有無を報告するだけで、品質は報告しません - セクションが存在しても、内容が優れているとは限りません

フィードバックループ

このセクションでは、出力をどのように保持し、今後のセッションに活用するかを説明します。 フィードバックループの背景については、organization/architecture/context-packet-architecture.md を参照してください。

セッション間の保持

• 出力先： skills/{cluster}/{skill-name}/（ディレクトリ構造）
• 保存するもの： SKILL.md、scripts/、data/、templates/
• 命名パターン： スキル名がディレクトリ名になります

セッションをまたいだ学習

• 開始前： この問題領域に対応するスキルがすでに存在するか確認します
• 既存のスキルがある場合： 重複させずに拡張し、統合グラフを確認します
• このスキルの改善に役立つフィードバック：
  • スキルの作成中に見つかった新しいアンチパターン
  • 見つかった状態名の衝突
  • 効果的な統合パターン

改善のきっかけ

• validate-skill.ts でよくある失敗が明らかになった場合 → 成熟度の基準を更新します
• スキルの作成に苦労した場合 → アンチパターンに追加します
• 統合のマッピングが不明瞭な場合 → Integration Graph セクションを改善します

設計上の制約

このセクションでは、前提条件と境界について説明します。 制約の背景については、organization/architecture/context-packet-architecture.md を参照してください。

このスキルの前提

• ユーザーが対処する問題領域を明確に定めている（「スキルを作って」のように曖昧ではない）
• 問題領域に特定可能な状態がある（ユーザーが気づく症状がある）
• ある程度の自動化が可能である（スクリプトと LLM に分けるのが妥当）

このスキルでは扱わないこと

• フレームワークの開発（より高い抽象度）- ルーティング先：framework-development methodology
• 単発スクリプト（診断モデルがない）- ルーティング先：simple script writing
• 状態を持たないスキル（純粋なジェネレーター）- ルーティング先：generator template（よりシンプルな構造）

劣化の兆候

このスキルが誤って適用されている兆候：

• 問題領域に対して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/
• 状態の定義 - 診断モデル
• スクリプトテンプレート - 生成されたユーティリティスクリプト
• 連携マップ - 他のスキルとのつながり

会話とファイルの使い分け

ファイルに保存	会話に残す
生成された SKILL.md	問題領域についての議論
スクリプトテンプレート	状態定義の反復
データファイルのひな型	連携の計画
検証結果	リアルタイムのフィードバック

ファイル名

パターン：skills/{cluster}/{skill-name}/（ディレクトリ構造） 例：skills/fiction/dialogue/

行わないこと

• 明確な問題状態がないままスキルを構築しません
• SKILL.md のドキュメントなしにスクリプトを作成しません
• 既存のスキルの対応範囲と重複させません
• 連携マッピングを省略しません
• フレームワークを構築しますが、作成するスキルはユーザーが決定します

他のスキルとの連携

list-builder との連携（fiction クラスター）

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

• スキルを本番利用可能とする前に、リストの成熟度を検証します
• リストの多様性には、次元フレームワークに従います

クラスターをまたぐスキル

スキルは、ほかのクラスターにあるスキルを参照できます：

• 両方のスキルに連携を記載します
• クラスターをまたぐ場合は、完全なパスで参照します

クラスターの規約

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

• frontmatter の cluster に親スキルを設定します
• スキル間の状態を対応づける連携テーブルを追加します
• スクリプトとデータには、クラスターで確立されたパターンに従います