We Built an Obsidian-Style Plugin Directory -- for Form Workflows

In my last post here, I shared how FORMLOVA found blue ocean in the form market by focusing on post-publish operations instead of form creation. The response was generous and the questions were sharp. One pattern kept coming up: "What workflows do you support?"

The honest answer was: whatever the LLM and the user figure out together. FORMLOVA provides 127 tools. The user tells the AI what to do with them. The workflows emerge from conversation.

That answer is accurate. It is also terrible for adoption.

A new user staring at 127 tools has no idea where to start. "You can do anything" sounds like "figure it out yourself." That is not a product experience. That is a homework assignment.

So we built what we call Workflow Place -- a public directory of reusable automation recipes. And the design decisions behind it are unusual enough that I think they are worth sharing.

Why Workflows Are the Right Thing to Share

When I thought about what FORMLOVA users could share with each other, I considered three options:

1. Form templates -- the form structure itself (fields, layout, design)
2. Design themes -- colors, fonts, spacing
3. Workflows -- the automation that runs after a form is published

I chose workflows only. Here is why.

Form templates and design themes are things an LLM generates well. You say "make me an event registration form with a modern dark theme" and you get a reasonable result in seconds. Sharing templates between users adds little value when the AI can generate a fresh one tailored to your exact needs every time.

Workflows are different. A workflow like "send auto-reply immediately, then a reminder 3 days before the event, then a follow-up survey the day after, and if NPS is below 6 escalate to the CS channel" is operational knowledge. It comes from running events and learning what works. The LLM cannot invent that from first principles. It needs to be taught by someone who has done it.

Form structure is generatable. Design is generatable. Operational workflows are not. That is the gap where sharing has real value.

The Obsidian Model

If you use Obsidian, you know the plugin community is the product's greatest asset. Thousands of plugins, no curation, no approval process. Quality emerges from usage signals. Bad plugins sink. Good plugins rise.

We are applying the same model to workflows. Here is how it works.

Anyone can save a workflow. When you set up an automation on your form -- auto-reply, reminders, conditional emails, webhook chains -- you can save it as a reusable recipe. It starts private. Only you can see it and apply it to your other forms.

Publishing requires proof of use. To make a workflow public, three conditions must be met:

1. The workflow has fired at least 10 times on real data
2. It has at least 2 steps (no single-action recipes)
3. It has a description

This is the quality gate. No review board. No approval queue. But also no untested theoretical workflows cluttering the directory. Everything listed has actually run in production.

The signal is Likes, not star ratings. We deliberately avoided star ratings, reviews, or complex scoring. A Like button is all there is. You can Like a recipe even without logging in -- we track it per device with localStorage. It is not strict, and that is fine. The point is a lightweight signal that accumulates passively, not a review system nobody uses.

The Cold Start Problem

Every directory has the same bootstrapping challenge: nobody comes to an empty shelf.

Our approach: seed the catalog with 20-25 official recipes before opening it to users. These are workflows we built and tested ourselves, covering the 9 categories we defined:

1. Events
2. Surveys
3. Customer support
4. Sales and lead capture
5. Recruiting
6. Education and training
7. Reservations and bookings
8. Customer follow-up
9. Other

Each category gets at least 2 official workflows. The "Other" category stays empty on purpose -- that is where users fill in use cases we did not anticipate.

The official workflows serve two purposes. For users who want to use them: they work immediately. For users who want to create their own: they show what a workflow looks like and what level of complexity is expected. If the official workflows are all 10-step masterpieces, nobody will feel comfortable publishing their simple 2-step recipe. So we deliberately include simple ones alongside complex ones.

Two Types of Workflows

This is where it gets architecturally interesting.

Type 1: FORMLOVA-native workflows. These run on our server automatically. A form response triggers a chain: auto-reply email, wait 3 days, send reminder, wait until event day, send follow-up survey. The server executes each step without any human involvement. Set it and forget it.

Type 2: MCP cross-service workflows. These involve services beyond FORMLOVA. A form response triggers: create a HubSpot contact, post to a Slack channel, sync to Google Sheets. The LLM orchestrates these by calling multiple MCP servers from the same chat session.

Currently, we support 8 MCP providers in the recipe system: FORMLOVA, HubSpot, Slack, Google Sheets, Gmail, Figma, Canva, and Notion. Each recipe step specifies which provider it uses, so users know upfront what they need connected.

Here is the critical difference between the two types: Type 1 is fully automatic. Type 2 requires the user to initiate from chat. The user says "process the new responses" and the LLM executes the cross-service chain.

Both types live in the same directory. The user does not need to know the implementation difference. They see a workflow, they copy the prompt, it works.

How Users Actually Use Recipes: Copy a Prompt

This is where we made a deliberate UX decision that goes against the standard "marketplace" playbook.

We built an apply modal first. It had form selection, slot mapping UI, confirmation steps. It looked like a proper integration wizard. Then we tested it. The feedback was immediate: "What is slot mapping?" "What if I do not have a form yet?"

So we deleted the modal. All of it.

Instead, every recipe in the directory includes a prompt example -- a natural language sentence that the user copies and pastes into their MCP client (Claude, ChatGPT, Cursor, etc.). Something like:

"Set up an event registration workflow: send a confirmation email immediately after signup, remind attendees 3 days before the event, and send a feedback survey the day after."

The user copies this, pastes it into their AI chat, and the LLM handles the rest -- creating the form if needed, mapping fields, configuring the automation. If something is ambiguous, the LLM asks in conversation.

This is the chat-first philosophy taken to its logical conclusion. We do not need to build a configuration UI for what is essentially a conversation. The prompt IS the configuration.

The Slot System: How Recipes Stay Portable

Under the hood, recipes still need a way to be portable across different forms. My form has a field called "event_date" and your form has "when_is_the_event." If a recipe referenced specific field names, it would break instantly.

The solution: recipes reference slots, not field names.

{
  "slots": {
    "event_date": { "type": "datetime", "label": "Event date" },
    "attendee_email": { "type": "email", "label": "Attendee email" }
  },
  "actions": [
    { "type": "auto_reply", "to": "$attendee_email" },
    { "type": "reminder", "timing": "-3d", "relative_to": "$event_date" }
  ]
}

<!-- IMAGE: Supporting image 1 -- Slot shapes on left mapped through LLM diamond to field shapes on right -->

But here is the thing: the user never sees this. When they paste the prompt example into their AI chat, the LLM reads the recipe definition (via MCP tools like get_recipe_details), looks at the user's form fields, and maps them automatically. If there is a datetime field, it matches to the "event_date" slot. If it is ambiguous, the LLM asks: "Which field is the event date?"

This is invisible infrastructure. The slot system exists so recipes are portable. The user experience is: copy a prompt, paste it, answer a question or two, done.

What the Directory Looks Like

Each recipe card shows:

• Name and one-line summary (bilingual -- Japanese and English)
• Category tag
• Required plan -- Free, Standard+, or Premium
• Recipe type -- FORMLOVA-native or MCP cross-service
• Step count with provider labels (e.g., "[formlova] Send reminder", "[slack] Post notification")
• Like count -- the lightweight quality signal
• Author name -- just the FORMLOVA account name

Filters: by plan, by category, by recipe type (FORMLOVA-only or cross-service). Sort: by likes, by newest.

The directory is a public page. No login required to browse. This matters for SEO -- people searching for "event registration automation" or "NPS follow-up workflow" can find the directory, see what is possible, and that becomes a registration funnel.

Users can also save recipes to their favorites for later. It is a small feature, but it lets people bookmark interesting workflows without committing to anything.

<!-- IMAGE: Supporting image 2 -- Funnel from private workspace (bottom) through quality gate (middle) to public shelf (top) -->

What I Am Betting On

The bet is this: operational knowledge is the one thing an LLM cannot generate from scratch and users genuinely want to share.

If I am right, the directory becomes self-sustaining after the initial seeding. Users who discover a great workflow want to share their own. The Like count gives them a lightweight reason to publish -- it is a small dopamine hit to see your recipe getting likes.

If I am wrong, we have 20-25 official workflows that still provide value as a discovery mechanism for new users. The downside is limited.

The Modal We Deleted

I want to be transparent about this because I think it is a useful cautionary tale for other founders.

We spent real engineering time building an apply-and-configure modal for the directory. Form selection dropdown, visual slot mapping, step-by-step confirmation. It was technically correct. It handled edge cases. And it was completely wrong for the product.

FORMLOVA is chat-first. The moment we built a GUI workflow for applying a recipe, we were contradicting our own product thesis. The right answer was always: let the user describe what they want in natural language, and let the AI handle the configuration.

Deleting working code is painful. But the simpler version -- copy a prompt, paste it, chat with the AI -- is a better experience AND less code to maintain. Sometimes the right engineering decision is subtraction.

Numbers Update

Since the last post, a few things have changed:

• 127 MCP tools across 25 categories (up from 118/24)
• 98 database migrations (up from 86)
• Product Hunt launch: April 15, 2026 -- still on track
• Share campaign still running through end of May: share FORMLOVA anywhere with a link, get 3 months Premium free

The Workflow Place launches alongside the Product Hunt debut. It starts with official recipes only. User publishing opens within the first month, once we confirm the quality gate handles real-world variety well.

The Question I Am Sitting With

For those of you who have built community-driven directories or plugin ecosystems:

How important was the initial seed content versus the submission experience? I keep going back and forth on whether 20 official workflows is enough to make the directory feel alive, or whether I need 50 to cross some psychological threshold. The Obsidian plugin directory had hundreds before most people discovered it, but it also had years of head start.

If you launched a directory from zero, what made the first contributors show up?

---

• Free to start: formlova.com
• Setup guide: formlova.com/en/setup
• Product Hunt launch: April 15, 2026
• Previous post: I Found Blue Ocean in the Most Crowded Market on the Internet
• Technical deep-dive: 127 MCP Tools, 4 Safety Levels