connector-builder
Skill19 starsChanged 3 months agoMITView on GitHub
Scaffold new spell step commands and connectors. Use when building new step commands for spells or extending the spell engine with new capabilities. Connectors are for new I/O transport types OR platforms requiring complex multi-step interaction (e.g., browser-based automation).
In this repository30 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- src/CLAUDE.mdCLAUDE.md
- communeSkill
- distillSkill
- divineSkill
- eldarSkill
- flflSkill
- flo-simplifySkill
- floSkill
- floSkill
- guidanceSkill
- healerSkill
- luminariumSkill
- meditateSkill
- memory-optimizationSkill
- memory-patternsSkill
- memory-teamSkill
- memory-worktreeSkill
- optimize-learningsSkill
- perf-auditSkill
- publishSkill
- quickenSkill
- reasoningbank-intelligenceSkill
- reset-epicSkill
- spell-builderSkill
- spell-scheduleSkill
- test-gapsSkill
- vector-searchSkill
- verifySkill
- wardSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 1 is distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 45
Documentation requirement: When creating any new step command or connector, you MUST also create a README.md following …
- Very specific: line 77
Use the full scaffold in templates/connector.md.
- Very specific: line 90
Add to src/cli/spells/connectors/index.ts so the engine discovers it:
- Distinctive: line 147
After gathering capabilities, you MUST display the permission implications to the user — same rules as the connector path.
- Very specific: line 151
Use the full scaffold in templates/step-command.md.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Connector Builder
Purpose: scaffold production-ready step commands (StepCommand) and, when truly needed, generalized I/O connectors (SpellConnector) with proper types, tests, and registration.
Read First — Companion Files
| File | When to read |
| templates/connector.md | When generating a generalized connector — full source + test + registration scaffold |
| templates/step-command.md | When generating a step command — full source + test + registration scaffold |
| ../spell-builder/architecture.md | Always — three-layer model and connector-vs-step decision tree |
| ../spell-builder/permissions.md | When defining capabilities — required disclosure format |
| ../spell-builder/preflight.md | When authoring preflight checks — copywriting rules for user-visible reason strings |
Prerequisites
- MoFlo project with
cli/spellspackage - TypeScript 5+
- Vitest for testing
What This Skill Does
- Guides you through building a step command (spell step logic) or, rarely, a generalized connector (new I/O transport)
- Generates type-safe TypeScript implementing the correct interface
- Creates a test file with vitest mocks
- Shows how to register the component and use it in spell YAML
Quick Start
Ask the user:
What do you want to build?
- Step command — executes logic within a spell step (transform data, control flow, etc.)
- Generalized connector — wraps a new I/O transport type (e.g., WebSocket, gRPC, MQTT)
Important: Simple service integrations (Slack webhook, S3 upload, Jira comment) should compose existing connectors (http, github-cli, playwright) in spell YAML — no dedicated connector needed. However, platforms requiring complex multi-step browser interaction (like Outlook.com web UI) DO warrant a dedicated connector. See ../spell-builder/architecture.md for the decision tree.
Documentation requirement: When creating any new step command or connector, you MUST also create a README.md following .claude/guidance/moflo-guidance-rules.md. Use existing READMEs in .claude/skills/spell-builder/steps/ or connectors/ as templates. Apply automatically — the user should never need to ask.
Building a Generalized Connector (Rare — New I/O Transports Only)
You almost certainly want a step command, not a connector. The three built-in connectors (http, github-cli, playwright) cover web APIs, CLI tools, and browser automation. Only create a new connector for a fundamentally new I/O transport (WebSocket, gRPC, MQTT, etc.) that no existing connector supports.
Step 1: Gather Requirements
| Field | Required | Example |
| Name | Yes | websocket, grpc, mqtt |
| Description | Yes | WebSocket bidirectional messaging |
| Version | Yes (default 1.0.0) | 1.0.0 |
| Capabilities | Yes — pick from read, write, search, subscribe, authenticate | read, write |
| Actions | Yes (at least 1) | connect, send, receive, close |
For each action, ask:
- Action name (kebab-case)
- Description
- Input parameters (name, type, required?)
- Output fields (name, type)
Verify the connector is generalized: the name should describe an I/O transport, not a service. websocket is correct; slack is not.
Step 2: Disclose Permissions
Before generating any source, surface the connector's capability profile to the user. Capabilities like shell, fs:write, credentials, agent, net, and browser carry specific risk classifications and required warning text. See ../spell-builder/permissions.md for the levels (readonly/standard/elevated/autonomous), risk classes ([SAFE]/[SENSITIVE]/[DESTRUCTIVE]), and the warning text to display per capability.
Step 3: Generate Connector Source + Test
Use the full scaffold in templates/connector.md. It implements the SpellConnector interface with all required pieces:
name,description,version,capabilities- Lifecycle methods:
initializeanddispose execute(action, params)dispatcherlistActions()schema reporter- Per-action validation function
- Vitest test file with mocks
The generated test file lives at src/cli/__tests__/spells/<name>.test.ts.
Step 4: Register the Connector
Add to src/cli/spells/connectors/index.ts so the engine discovers it:
import { <name>Connector } from './<name>.js';
export { <name>Connector };
export const builtinConnectors: SpellConnector[] = [
httpConnector,
githubCliConnector,
playwrightConnector,
<name>Connector, // <-- add here
];Step 5: Example Spell YAML
name: example-with-<name>
version: "1.0"
description: Example spell using the <name> connector
connectors:
- <name>
steps:
- name: do-something
type: bash
config:
command: "echo 'preparing...'"
- name: use-<name>
type: <name> # the step command registered in Step 4
config:
action: <action-1>
# ...action paramsDo not reach a connector from an agent step. That step type has never been executable. A connector is reached from its own step command (Step 4 above), from a composite step's tool action, or from a custom step command.
Building a Step Command
Step 1: Gather Requirements
| Field | Required | Example |
| Type | Yes (kebab-case) | transform, notify, validate-schema |
| Description | Yes | Transform data using jq-like expressions |
| Config fields | Yes (at least 1) | expression: string, input: object |
| Capabilities | No | fs:read, fs:write, net, shell, memory, credentials, browser, agent |
| Permission Level | No | readonly, standard, elevated, autonomous — auto-derived from capabilities when omitted |
| MoFlo level | No (default none) | none, memory, hooks, full, recursive |
| Prerequisites | No | External CLI tools needed |
Step 2: Disclose Permissions
After gathering capabilities, you MUST display the permission implications to the user — same rules as the connector path. See ../spell-builder/permissions.md for the format and per-capability warnings. Steps using destructive capabilities will require user acceptance before first run via the spell-wide dry-run report.
Step 3: Generate Step Command Source + Test
Use the full scaffold in templates/step-command.md. It implements the StepCommand<TConfig> interface with all required pieces:
type,description,capabilities,defaultMofloLevelconfigSchema(JSONSchema for runtime validation)validate(config, context)andexecute(config, context)methodsdescribeOutputs()for downstream variable references- Optional
preflightblock — see ../spell-builder/preflight.md forreasoncopywriting rules - Optional
rollback(config, context)for failure cleanup - Vitest test file with
mockContext
For compile-time type safety on the config, prefer the createStepCommand() factory from src/cli/spells/commands/create-step-command.ts.
Step 4: Register the Step Command
Add to src/cli/spells/commands/index.ts:
import { <type>Command } from './<type>-command.js';
export { <type>Command };
export type { <Type>StepConfig } from './<type>-command.js';
export const builtinCommands: readonly StepCommand[] = [
agentCommand,
bashCommand,
// ... existing commands
<type>Command, // <-- add here
];Step 5: Example Spell YAML
name: example-with-<type>
version: "1.0"
description: Example spell using the <type> step
steps:
- name: my-step
type: <type>
config:
<field1>: "value"
<field2>: "optional-value"Reference
Type Definitions
- Connector interface:
src/cli/spells/types/spell-connector.types.ts—SpellConnector,ConnectorAction,ConnectorOutput,ConnectorCapability - Step command interface:
src/cli/spells/types/step-command.types.ts—StepCommand,StepConfig,StepOutput,CastingContext,JSONSchema - Step factory:
src/cli/spells/commands/create-step-command.ts—createStepCommand()
Existing Components
Shipped connectors (src/cli/spells/connectors/): http (http-tool.ts), github-cli (github-cli.ts), playwright (playwright.ts)
Built-in step commands (src/cli/spells/commands/): agent (agent-command.ts), bash (bash-command.ts), condition (condition-command.ts), prompt (prompt-command.ts), memory (memory-command.ts), wait (wait-command.ts), loop (loop-command.ts), browser (browser-command.ts), github (github-command.ts)
Related Skills
- /spell-builder — composes connectors and steps into spell definitions; references this skill when a needed connector doesn't exist
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

