fabric

Fabric

当真正要做的工作是使用 Fabric 对现有文本／内容运行可复用的命名 AI 转换时，请使用此技能。

Fabric 最适合以下三种情况：

1. 输入内容已经存在，或可以先清理，
2. 转换过程具有足够的重复性，值得设定一个命名模式，
3. 输出需要通过 CLI、Shell 管道或轻量级 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。
• 用户想要命名模式，而不是每次都临时编写新提示词。
• 任务是对 stdin、文件、转录文本、剪贴板文本、笔记、日志或清理后的文章文本进行可重复的转换。
• 用户想为重复性工作创建自定义模式包。
• Fabric 应集成到 Shell 管道或小型本地工具链中。
• 其他工具需要通过 fabric --serve 使用 Fabric 服务模式。
• Fabric、通用大模型 CLI 和编码助手之间的界限尚不明确。

何时不使用此技能

• 当前会话中的一次性聊天提示 → 直接使用当前模型。
• 了解代码仓库的编码、编辑或 Git 实现工作 → 使用编码助手技能。
• 抓取、OCR、转录文本恢复或文件转换仍是难点 → 先解决上游输入层问题。
• 确定性的多步骤自动化才是真正的工作 → 使用脚本或工作流自动化，并在需要时将 Fabric 作为其中一个步骤。
• 问题完全涉及提供商／平台设置，且与 Fabric 无关 → 优先使用更相关的平台／提供商技能。

核心界限

• Fabric = 对外部文本／内容进行由模式驱动的可复用转换。
• 通用大模型 CLI = 无需严格遵循模式库的临时提示。
• 编码助手 = 了解代码仓库的编辑、实现和 Git 工作流。
• 工作流自动化／脚本 = 确定性的编排，Fabric 可以作为其中一个阶段。

说明

步骤 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 处理就足够。
• pattern-selection → 用户需要选择合适的内置模式或模式系列。
• custom-pattern → 工作流会重复运行，需要稳定的输出格式。
• shell-pipeline → Fabric 是更大规模终端工作流中的一个步骤。
• serve-api → 其他本地工具或脚本需要通过 HTTP 调用 Fabric。
• boundary-review → 用户正在 Fabric、通用大模型 CLI 或编码助手之间做选择。

步骤 2：讨论模式之前，先确认输入层

先回答以下问题：

1. 文本来自哪里？
2. 文本是否已经清理到足以交给 Fabric 处理？
3. 这是一次性转换还是可复用的工作流？
4. 提供商／模型设置是否已经就绪？

如果文本仍是杂乱的 HTML、充满 OCR 噪声、转录质量很差，或文本尚不存在，请明确说明。不要假装上游清理问题归 Fabric 负责。

步骤 3：运行正确的类别

A. Quick-transform

返回：

• 一个推荐模式，
• 一条确切命令，
• 预期输出格式，
• 仅当确实有帮助时，提供一个可选的后续处理链。

示例：

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. Shell 流水线

将 Fabric 视为流水线中的一个环节：

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 用于转换层。

步骤 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

步骤 5：让建议便于复用

优先选择：

• 一个主要路径，
• 一个首选建议，而非一长串选项，
• 可复用的自定义模式框架，而非巧妙的一次性提示，
• 当 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