fabric

Fabric

このスキルは、既存のテキストやコンテンツに対して、Fabric の再利用可能な名前付き AI 変換を実行することが実際の目的である場合に使用します。

Fabric が最も力を発揮するのは、次の3つの条件がそろっている場合です。

1. 入力がすでに存在するか、事前に整理できます。
2. 変換を繰り返し実行するため、名前付きパターンにする価値があります。
3. CLI、シェルパイプライン、または軽量な HTTP インターフェースを通じて出力を提供します。

詳しく確認する前に、次の関連ドキュメントを読んでください。

• references/routing-and-mode-selection.md
• references/operator-packets-and-route-outs.md
• references/install-and-provider-setup.md
• references/pattern-workflow-recipes.md

このスキルを使用する場合

• ユーザーが明示的に Fabric を希望している。
• 毎回新しいプロンプトを即興で作るのではなく、名前付きパターンを求めている。
• 標準入力、ファイル、トランスクリプト、クリップボードのテキスト、メモ、ログ、または整理済みの記事テキストを対象とする、繰り返し実行可能な変換を行う。
• 繰り返し行う作業向けのカスタムパターンパックを求めている。
• Fabric をシェルパイプラインや小規模なローカルツールチェーンに組み込む。
• 別のツールが fabric --serve による Fabric サーバーモードを必要としている。
• Fabric、汎用 LLM CLI、コーディングアシスタントのどれを使うべきか判断できない。

このスキルを使用しない場合

• 現在のセッションで一度限りのチャットプロンプトを実行する → 現在のモデルを直接使用します。
• リポジトリを理解したうえでのコーディング、編集、Git の実装作業 → コーディングアシスタントのスキルを使用します。
• スクレイピング、OCR、トランスクリプトの復元、ファイル変換がまだ難所である → まず上流の入力レイヤーを改善します。
• 決定論的な複数ステップの自動化が本来の目的である → スクリプトまたはワークフロー自動化を使用し、必要に応じて Fabric を一工程として組み込みます。
• 質問がプロバイダーやプラットフォームの設定全般に関するもので、Fabric 固有ではない → まず、より適切なプラットフォームまたはプロバイダーのスキルを使用します。

基本的な使い分け

• Fabric ＝ 外部のテキストやコンテンツに対する、パターン駆動型の再利用可能な変換。
• 汎用 LLM CLI ＝ パターンライブラリの利用を重視しない、その場限りのプロンプト。
• コーディングアシスタント ＝ リポジトリを理解したうえでの編集、実装、Git ワークフロー。
• ワークフロー自動化／スクリプト ＝ Fabric を一工程として使う場合もある、決定論的なオーケストレーション。

手順

ステップ1：リクエストを1つの主要レーンに分類する

次のレーンから、必ず1つだけ選びます。

fabric_intake:
  primary_lane: quick-transform | pattern-selection | custom-pattern | shell-pipeline | serve-api | boundary-review
  input_shape: stdin-text | file | clipboard | transcript | url-derived-text | logs | code-snippet | mixed | unknown
  output_shape: summary | extraction | rewrite | explanation | classification | structured-markdown | custom
  repetition_level: one-off | recurring | team-shared | embedded-in-script
  provider_need: default | specific-provider | local-model | server-mode | unknown
  input_ready: yes | no | unclear

レーンの選び方：

• quick-transform → テキストがすでに利用可能で、Fabric を1回実行すれば十分です。
• pattern-selection → 適切な組み込みパターンまたはパターン群が必要です。
• custom-pattern → ワークフローを繰り返し実行するため、安定した出力形式が必要です。
• shell-pipeline → Fabric をより大きなターミナルワークフローの一工程として使用します。
• serve-api → 別のローカルツールまたはスクリプトから、HTTP 経由で Fabric を呼び出します。
• boundary-review → Fabric、汎用 LLM CLI、コーディングアシスタントのどれを使うか判断します。

ステップ2：パターンについて話す前に、入力レイヤーを確認する

まず、次の点を確認します。

1. テキストはどこから取得しますか？
2. テキストは Fabric で処理できる程度に整理されていますか？
3. これは一度限りの変換ですか、それとも再利用可能なワークフローですか？
4. プロバイダーとモデルの設定はすでに利用可能ですか？

テキストがまだ未整理の HTML、OCR のノイズ、品質の低いトランスクリプトである場合、またはテキスト自体が存在しない場合は、そのことを明示してください。上流の整理作業を Fabric が担えるかのように説明してはいけません。

ステップ3：適切なレーンを実行する

A. Quick-transform

次の内容を返します。

• 推奨パターンを1つ
• 正確なコマンドを1つ
• 想定される出力形式
• 実質的な効果がある場合に限り、任意の後続処理チェーンを1つ

例：

cat transcript.txt | fabric -p summarize
pbpaste | fabric -p extract_wisdom
git diff HEAD~1 | fabric -p explain_code

B. パターンの選択

有力なパターンを1～3 個挙げ、その理由を説明します。

目新しさではなく、タスクの形に基づいて選びます。

• summarize → ソースを読みやすい概要にまとめる
• extract / wisdom / questions / claims → 構造化されたアイデアを抽出する
• explain / analyze → コード、文章、ログ、インシデント、または判断を解釈する
• rewrite / improve / repurpose → 成果物を別のトーンや形式に変換する

カタログ全体を列挙しないでください。

C. カスタムパターン

ワークフローを繰り返し実行する場合に使います。

最低限のひな形：

IDENTITY AND PURPOSE
STEPS
OUTPUT INSTRUCTIONS
INPUT

優れたカスタムパターンの出力には、以下を含めます。

• パターン名
• 具体的なユースケース
• system.md のひな形
• 使用例
• 既存パターンを再利用する場合とフォークする場合の判断基準

D. シェルパイプライン

Fabric をパイプラインの 1 つのステージとして扱います。

fetch or prepare input → optional cleanup → fabric pattern → save / chain / post-edit

以下を示します。

• 入力を作成するもの
• パイプライン内での Fabric の位置
• 出力先
• 人による確認や別のツールが引き続き必要な箇所

E. API サーバー

別のアプリやスクリプトから HTTP アクセスが必要な場合に使います。

基本コマンド：

fabric --serve
curl http://localhost:8080/patterns/names

また、以下も明記します。

• --api-key が必要かどうか
• ローカル専用か、共有マシンでの利用を想定するか
• 呼び出し元にパターンの CRUD、一覧表示、適用エンドポイント、または通常のチャット補完のどれが必要か

F. 境界の確認

ワークフローの形に基づいて比較します。

• Fabric → 外部のテキストやコンテンツに対する、繰り返し実行できる名前付き変換
• 汎用 LLM CLI → 柔軟なアドホックプロンプト
• コーディングアシスタント → リポジトリを把握したコード作業
• ワークフロー自動化 → 決定論的な複数ステップのロジック

ユーザーが複数のユースケースを混在させている場合は、Fabric を変換レイヤーにのみ使います。

Step 4：短い運用ガイドを返す

デフォルトの出力には、以下を含めます。

• 選択したレーン
• 入力元と前処理の前提
• 推奨パターン（複数可）またはカスタムパターンの作成手順
• 正確なコマンドまたは成果物の構成
• 現実的な注意点
• Fabric だけでは解決できない場合の代替手段

次の形式を使います。

# Fabric Workflow Packet

## Lane
- quick-transform | pattern-selection | custom-pattern | shell-pipeline | serve-api | boundary-review

## Input
- source: ...
- cleanup needed: ...
- assumptions: ...

## Recommended Fabric move
- pattern / custom pattern / server mode: ...
- why this fits: ...

## Command or artifact
- exact command(s) or `system.md` scaffold

## Output shape
- summary / extraction / rewrite / explanation / structured markdown / custom

## Friction
- provider setup / token limits / noisy input / post-editing / custom-pattern drift

## Route-outs
- next tool or workflow layer if Fabric is not the whole answer

Step 5：アドバイスを再利用できるようにする

次を優先します。

• 主となるレーンは 1 つ
• 選択肢の羅列ではなく、有力な推奨案を 1 つ
• 気の利いた使い捨てプロンプトではなく、再利用できるカスタムパターンのひな形
• Fabric だけでは解決できない場合は、適切な代替手段を率直に提示する

例

例 1：文字起こしの要約

入力

すでに transcript.txt があります。Fabric で要約する方法と、ワークフローを再利用可能にする方法を教えてください。

出力例

• レーン：quick-transform
• コマンド：cat transcript.txt | fabric -p summarize
• 出力：Markdown の要約
• 代替手段：アクションアイテムが必要な場合に限り、抽出の処理を追加する

例 2：毎週使うカスタムパターン

入力

毎週、競合他社の記事を要約しています。再利用可能な Fabric のパターンパックを作るのを手伝ってください。

出力例

• レーン：custom-pattern
• system.md のひな形と使用例を提示する
• 使い捨てのプロンプトを繰り返すよりカスタムパターンが適している理由を説明する

例 3：Fabric とほかのツールのどちらを使うべきか

入力

このワークフローには Fabric、汎用 LLM CLI、コーディングアシスタントのどれを使うべきですか？

出力例

• レーン：boundary-review
• 繰り返し実行するテキスト変換には Fabric を使う
• リポジトリを把握した編集作業はコーディングアシスタントに任せる

ベストプラクティス

1. Fabric は汎用のターミナルチャットボットではなく、パターンを中心とした変換レイヤーとして扱います。
2. パターンのせいにする前に、扱いにくい入力を取得する問題を解決します。
3. カタログ全体ではなく、有力なパターンを 1～3 個提示します。
4. ワークフローを繰り返す場合や、出力形式を一定に保つ必要がある場合は、カスタムパターンをフォークします。
5. 別のツールから HTTP アクセスが本当に必要な場合に限り、fabric --serve を推奨します。
6. プロバイダーやセットアップに伴う手間を、パターンの説明に隠さず明示します。
7. タスクが本質的にコーディングアシスタントの作業や決定論的な自動化である場合は、早めに代替手段を提示します。

参考資料

• Fabric の上流 README
• Fabric REST API ドキュメント
• references/routing-and-mode-selection.md
• references/operator-packets-and-route-outs.md
• references/install-and-provider-setup.md
• references/pattern-workflow-recipes.md