Teaches an agent to compose a workflow with the `workflow_create` tool that LibreFang ships as a builtin: when a workflow beats a one-off `agent_send`, the four agent-binding shapes and why `{"type": …}` find-or-spawn makes a workflow portable, how `required_skills` fails a step before it bills an LLM call, and the creation-time validations an author is most likely to trip.
Written against the tool's implementation rather than its issue description, and the copy pinned in librefang/librefang's registry snapshot is loaded by `crates/librefang-runtime/tests/workflow_creator_skill.rs`, which checks the ceilings quoted here against the live tool schema.
Refs librefang/librefang#6934
The `librefang` dashboard's federated catalog UI surfaces every
optional SKILL.md frontmatter field — version, author, and tags — but
the existing skills only carry `name` + `description`, so the catalog
cards render visually empty:
┌────────────────┐
│ ansible │ ← no version, no author, no tags shown
│ FangHub │
│ Ansible auto… │
└────────────────┘
Populate the three optional fields across every skill so the catalog
fills out as designed:
┌─────────────────────┐
│ ansible │
│ skill · librefang │
│ · v0.1.0 │
│ Ansible auto… │
│ [devops][automation]│
│ [infra] │
└─────────────────────┘
Choices
- author = `librefang`. Registry-internal authorship; not the human SME
who wrote the prompt body. Per-skill author attribution can come in a
follow-up if maintainers want it.
- version = `0.1.0` baseline. Future content updates bump per-skill.
- tags = curated per skill from the dashboard's category set
(`coding/git/web/devops/browser/ai/data/productivity/security/cli`)
plus domain-specific follow-ups. First tag is the primary category.
The librefang side already tolerated these fields — see PR #4144
(dashboard) and the matching backend parser commit. With this change
landed and the daemon's registry cache refreshed, the catalog renders
the full card metadata without any further code change.
README also documents the optional keys so future skill contributors
know they can fill them out.
* fix(providers): remove ~anthropic, skip ~ prefixes in sync script
OpenRouter uses ~ prefixes for internal auto-routing aliases (e.g. ~anthropic).
These are not real providers — they already route through openrouter.toml.
The generated ~anthropic.toml was confusing (looked like a stale backup)
and redundant with the existing openrouter provider.
- Delete providers/~anthropic.toml
- Skip provider IDs starting with ~ in sync-pricing.py --create-missing
* fix(providers): remove morph, aider, kwaipilot
- morph: specialized code-editing/patching tool, not a general LLM provider
- aider: CLI meta-tool wrapper (base_url empty), redundant with claude-code/codex-cli/gemini-cli/qwen-code
- kwaipilot: Kwai internal coding assistant routed via OpenRouter, niche
* fix(sync): add morph/aider/kwaipilot to SKIP_PROVIDERS to prevent re-creation
* feat(sync): merge OpenRouter-only providers into openrouter.toml
Instead of generating standalone .toml files that just wrap the OpenRouter
endpoint, merge their models directly into openrouter.toml with the
standard 'openrouter/{provider}/{model}' ID convention.
- Add _build_model_fields() and _model_lines() helpers to deduplicate
model rendering between standalone and merged paths
- Add merge_into_openrouter() that appends new models idempotently
- generate_provider_toml() now only runs for providers in PROVIDER_API
- --create-missing routes OpenRouter-only providers to merge_into_openrouter
* fix(providers): remove 14 OpenRouter-only standalone files
These providers have no direct public API and all route through
openrouter.ai/api/v1. Per the new sync-pricing.py policy, their models
will be merged into openrouter.toml on the next CI run instead of
living in separate files that just wrap the OpenRouter endpoint.
Removed: allenai, deepcogito, essentialai, inclusionai, inflection,
liquid, meituan, nex-agi, nousresearch, prime-intellect, relace,
switchpoint, tngtech, writer
* fix(providers): remove 7 niche providers with no driver support
No dedicated LLM driver code exists for these providers — they rely
purely on OpenAI-compatible passthrough with no special handling.
Removing them reduces registry noise; users can still reach them via
openrouter.toml if needed.
Removed: microsoft, ibm-granite, xiaomi, upstage, inception, aion-labs, arcee-ai
* fix(providers): remove ai21, chutes, venice
All three use ApiFormat::OpenAI with no special handling — pure passthrough.
No registry entry needed; users can reach them via openrouter.toml or by
adding a custom provider.
* docs(providers): rewrite README with full provider catalog and inclusion criteria
- List all 46 providers grouped by category with descriptions
- Document why each provider exists (direct API, unique endpoint, dedicated driver, local, CLI)
- Add inclusion criteria section explaining when to create standalone files vs merging into openrouter.toml
- Document sync script routing logic
- Update model counts: 49→46 providers, 339→232 models
* docs: add comprehensive READMEs for all registry sections + deepinfra provider
- agents/README.md: 32 agents across 7 categories with capability field reference
- channels/README.md: 44 channels across 5 categories with protocol reference table
- hands/README.md: 18 hands across 5 categories with HAND.toml format guide
- mcp/README.md: 33 MCP servers across 5 categories with transport/auth format
- plugins/README.md: 12 plugins with hook protocol documentation
- skills/README.md: 60 skills across 9 categories with SKILL.md format guide
- providers/deepinfra.toml: add DeepInfra serverless inference (5 models)
- Move example skills to examples/skills/
- Move scaffolding templates to examples/{agents,hands,channels,plugins,providers,integrations,skills}/
- Remove legacy skill.toml from example skills; SKILL.md is the canonical format
- Delete top-level templates/ directory
Standardize on Claude Code's SKILL.md format as every skill's source of
truth. skill.toml becomes an optional metadata layer for runtime, input
schema, and versioning — never for the prompt body.
- validate.py: require SKILL.md in every skill dir; when skill.toml also
exists, cross-check name/description consistency to prevent drift
- Add SKILL.md to the two custom-skill examples
- Move the meeting-agenda prompt body out of skill.toml into SKILL.md
- Rewrite skills/README.md to document the md-first, toml-as-metadata convention
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
33 agent READMEs, 14 hand READMEs, 2 plugin READMEs
(echo-memory + hooks), and 2 skill READMEs
(custom-skill-prompt + custom-skill-python).
Each README documents the component's purpose, configuration,
and usage based on its TOML definition.
Each directory (agents, hands, integrations, plugins, providers,
scripts, skills) now has a README documenting its TOML format,
current contents, and contribution steps.
Evan