Fabric

Fabric

Use this skill when the real job is running a reusable named AI transform over existing text/content with Fabric.

Fabric is strongest when three things are true: 1. the input already exists or can be cleaned first, 2. the transform is repeatable enough to deserve a named pattern, 3. the output should be delivered through a CLI, shell pipeline, or lightweight HTTP surface.

Read these support docs before going deeper:

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

When to use this skill

• The user explicitly wants Fabric.
• The user wants a named pattern instead of improvising a fresh prompt every time.
• The job is a repeatable transform over stdin, files, transcripts, clipboard text, notes, logs, or cleaned article text.
• The user wants a custom pattern pack for recurring work.
• Fabric should sit inside a shell pipeline or a small local toolchain.
• Another tool needs Fabric server mode via fabric --serve.
• The boundary between Fabric vs general LLM CLI vs coding assistant is unclear.

When not to use this skill

• One-off chat prompting in the current session → use the current model directly.
• Repo-aware coding, editing, or git implementation → use a coding-assistant skill.
• Scraping, OCR, transcript recovery, or file conversion is still the hard part → fix the upstream input layer first.
• Deterministic multi-step automation is the real job → use scripts or workflow automation, with Fabric only as one step if needed.
• Provider/platform setup is the whole question and not Fabric-specific → use the more relevant platform/provider skill first.

Core boundary

• Fabric = reusable pattern-driven transforms on external text/content.
• General LLM CLI = ad hoc prompting without strong pattern-library expectations.
• Coding assistant = repo-aware editing, implementation, and git workflows.
• Workflow automation / scripts = deterministic orchestration where Fabric may be one stage.

Instructions

Step 1: Classify the request into one primary lane

Choose exactly one lane:

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

Lane chooser:

• quick-transform → the text is already available and one strong Fabric pass is enough.
• pattern-selection → the user needs the right built-in pattern or family.
• custom-pattern → the workflow repeats and needs a stable output shape.
• shell-pipeline → Fabric is one step inside a larger terminal workflow.
• serve-api → another local tool or script should call Fabric over HTTP.
• boundary-review → the user is deciding among Fabric, a general LLM CLI, or a coding assistant.

Step 2: Verify the input layer before talking about patterns

Answer these first: 1. Where does the text come from? 2. Is the text already clean enough for Fabric? 3. Is this a one-shot transform or a reusable workflow? 4. Is provider/model setup already available?

If the text is still messy HTML, OCR noise, bad transcripts, or missing entirely, say so explicitly. Do not pretend Fabric owns the upstream cleanup problem.

Step 3: Run the correct lane

A. Quick-transform

Return:

• one recommended pattern,
• one exact command,
• expected output shape,
• one optional follow-up chain only if it materially helps.

Examples:

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

B. Pattern-selection

Return the top 1-3 plausible patterns and why.

Use job shape, not novelty:

• summarize → compress source into a readable brief
• extract / wisdom / questions / claims → pull structured ideas out
• explain / analyze → interpret code, prose, logs, incidents, or decisions
• rewrite / improve / repurpose → convert one artifact into another tone or shape

Do not dump the whole catalog.

C. Custom-pattern

Use when the workflow will recur.

Minimum scaffold:

IDENTITY AND PURPOSE
STEPS
OUTPUT INSTRUCTIONS
INPUT

Good custom-pattern output includes:

• pattern name,
• exact use case,
• system.md skeleton,
• example invocation,
• note on when to fork vs reuse a stock pattern.

D. Shell-pipeline

Treat Fabric as one stage in a pipeline:

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

Return:

• what creates the input,
• where Fabric sits,
• where output goes,
• what still needs human review or another tool.

E. Serve-api

Use when another app/script needs HTTP access.

Baseline commands:

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

Also call out:

• whether --api-key is needed,
• local-only vs shared-machine assumptions,
• whether the caller needs pattern CRUD, listing, apply endpoints, or plain chat completion.

F. Boundary-review

Compare by workflow shape:

• Fabric → repeatable named transforms over external text/content
• general LLM CLI → flexible ad hoc prompting
• coding assistant → repo-aware code work
• workflow automation → deterministic multi-step logic

If the user is mixing use cases, keep Fabric only for the transform layer.

Step 4: Return a short operator packet

Default output should contain:

• chosen lane,
• input source and cleanup assumptions,
• recommended pattern(s) or custom-pattern path,
• exact command(s) or artifact layout,
• realistic friction note,
• route-out if Fabric is not the whole answer.

Use this structure:

# 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: Keep the advice reusable

Prefer:

• one primary lane,
• one top recommendation over a laundry list,
• a reusable custom-pattern scaffold over a clever one-off prompt,
• honest route-outs when Fabric is not the whole answer.

Examples

Example 1: Transcript summary

Input

I already have transcript.txt. Show me how to use Fabric to summarize it and keep the workflow reusable.

Output sketch

• Lane: quick-transform
• Command: cat transcript.txt | fabric -p summarize
• Output: markdown summary
• Route-out: only add another extraction pass if action items matter

Example 2: Weekly custom pattern

Input

We summarize competitor articles every week. Help me make a reusable Fabric pattern pack.

Output sketch

• Lane: custom-pattern
• Deliver system.md scaffold plus invocation
• Explain why a custom pattern beats repeating a one-off prompt

Example 3: Fabric or something else?

Input

Should I use Fabric, a general LLM CLI, or a coding assistant for this workflow?

Output sketch

• Lane: boundary-review
• Keep repeatable text transforms in Fabric
• Route repo-aware editing to a coding assistant

Best practices

1. Treat Fabric as a pattern-first transform layer, not a generic terminal chatbot. 2. Solve messy input acquisition before blaming the pattern. 3. Return the top 1-3 pattern choices instead of the full catalog. 4. Fork a custom pattern when the workflow repeats or the output shape must stay stable. 5. Only recommend fabric --serve when another tool genuinely needs HTTP access. 6. Keep provider/setup friction explicit instead of hiding it behind pattern talk. 7. If the task is really coding-assistant work or deterministic automation, route out early.

References

• Fabric upstream README
• Fabric REST API docs
• 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 install and provider setup

This guide keeps install/setup advice practical instead of turning the main skill into a command dump.

Install patterns

macOS / Linux

curl -fsSL https://raw.githubusercontent.com/danielmiessler/fabric/main/scripts/installer/install.sh | bash

Homebrew

brew install fabric-ai

Windows

winget install danielmiessler.Fabric

First-time setup

fabric --setup

Upstream README positioning to remember:

• Fabric supports many providers and local-model setups.
• Install success does not mean provider config is correct.
• Server mode exists, but it should not be the default recommendation unless another tool needs HTTP access.

Provider / model questions to answer

1. Which provider or local model is already available? 2. Does the user need one default model or pattern-by-pattern routing? 3. Is the workflow local-only, remote API based, or mixed? 4. Is server mode necessary, or is CLI use enough?

Common friction points from upstream issues

• Vendor/model configuration drift or mis-parsing can break otherwise valid setups (for example remote Ollama vendor resolution issues).
• Custom pattern directories can behave differently between listing and retrieval in some server-mode paths.
• As Fabric keeps growing, the CLI surface can feel crowded; prefer a small recommended subset of commands.

Safe default operator advice

• Start with one working provider/model before discussing multi-provider routing.
• Verify pattern listing before deeper workflow work:

fabric -l
fabric -L

• Only recommend fabric --serve when the workflow genuinely needs HTTP access.
• If provider setup is the dominant blocker, say so explicitly instead of pretending the pattern choice is the real problem.

Fabric operator packets and route-outs

Use this guide when the main SKILL.md has already selected Fabric but the response still needs a clean operator packet.

Default packet skeleton

# 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

Route-out matrix

Lane-specific reminders

• quick-transform: one pattern, one command, one expected output shape.
• pattern-selection: top 1-3 patterns only; explain why each fits.
• custom-pattern: include system.md scaffold and when to fork vs reuse.
• shell-pipeline: state upstream input producer and downstream save/post-edit step.
• serve-api: mention address, auth, and whether the caller needs list/apply/CRUD endpoints.
• boundary-review: compare Fabric against adjacent tools by workflow shape, not by hype.

Fabric pattern workflow recipes

These recipes show the intended operator posture: clean input + one clear transform + realistic next step.

1. Transcript summary

cat transcript.txt | fabric -p summarize

Use when the text already exists and the first pass is a readable summary.

Add a second step only if needed:

cat transcript.txt | fabric -p summarize > summary.md
cat summary.md | fabric -p extract_wisdom

2. Clipboard to extraction workflow

pbpaste | fabric -p extract_wisdom

Good for articles, notes, or copied snippets already in the clipboard.

3. Code or diff explanation

git diff HEAD~1 | fabric -p explain_code

Useful when the job is understanding or summarizing code/text, not editing the repo.

4. Logs to first-pass analysis

tail -200 app.log | fabric -p analyze_logs

This is a first-pass triage step. Route deeper root-cause work to debugging/log-analysis workflows if needed.

5. Custom pattern skeleton

Directory layout:

~/.config/fabric/patterns/my-pattern/
└── system.md

Minimal scaffold:

# IDENTITY AND PURPOSE
You are an expert at ...

# STEPS
1. ...
2. ...

# OUTPUT INSTRUCTIONS
- Output Markdown only.
- Use these sections: ...

# INPUT
INPUT:

6. REST/server mode

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

Use when another local tool or script needs HTTP access to patterns or chat endpoints.

Pattern-choice reminders

• choose summary patterns when compression is the job,
• choose extract patterns when ideas/claims/actions are the job,
• choose explain/analyze patterns when interpretation is the job,
• fork a custom pattern when the workflow repeats and output shape matters.

Fabric routing and mode selection

Use this guide to keep fabric narrow and useful.

Choose Fabric when

• the job is a repeatable named prompt transform over text the user already has,
• stdin/files/clipboard/transcripts/logs/articles are the main input shape,
• the user wants a reusable pattern or custom pattern pack,
• shell composition is part of the workflow.

Do not choose Fabric when

• the user just wants a one-off answer from the current model,
• the job is repo-aware coding or implementation,
• the hard part is still scraping, OCR, transcript recovery, or file conversion,
• the workflow needs deterministic batching/app logic more than prompt transforms.

Mode chooser

Nearby tool boundaries

• Fabric = reusable prompt/pattern operations over external text/content.
• General LLM CLI = ad hoc prompting with lighter pattern expectations.
• Coding assistant = repo-aware implementation, code edits, and git workflows.
• Workflow automation / scripts = deterministic multi-step logic that may call Fabric as one step.

Friction checklist

Call these out early when they apply:

• provider/vendor config is not ready,
• input text is still noisy or unavailable,
• the chosen pattern is too broad or too specialized,
• the output still needs human review or post-editing,
• a custom pattern is more appropriate than another stock-pattern search.