Creating Custom Plugins

Overview

Custom plugins let you build your own AI-powered text transformation tools with full control over the prompt pipeline. If the 8 built-in plugins don't cover your needs, you can create a plugin that does exactly what you want.

Creating custom plugins requires a Writer+ plan or higher. Once created, your plugins appear in your plugin library alongside the built-in tools and work exactly the same way — select text, run the plugin, Keep or Discard.

The Creation Wizard

The plugin creation wizard walks you through a 5-step process:

1. Intent — describe what your plugin does, or skip to build manually.
2. Prompts — define the AI prompt pipeline (1–4 stages).
3. Test — run your plugin on sample text to verify quality.
4. Details — name, description, category, and output settings.
5. Publish — set visibility and save your plugin.

Access the wizard from the Plugins page by clicking Create Plugin, or from the Plugin Marketplace page.

Step 1: Intent

Start by describing what your plugin does in plain language. Write a description between 10 and 1,000 characters — the more specific you are, the better the AI-generated prompts will be.

For example: “Transform dialogue to sound more natural and conversational. Remove stiff phrasing, add contractions, and make characters sound like real people talking.”

You'll see a model selector with a cost estimate for the generation. The AI uses your description to generate system prompts for your pipeline stages.

Boilerplate Starters

Not sure how to describe your plugin? Click the Boilerplates button in the text area to choose from ready-made descriptions you can use as-is or customize. Each boilerplate includes a structured description with rules and input/output examples that produce high-quality generated prompts.

Here's what a strong plugin description looks like — the Show Don't Tell boilerplate:

Rewrites highlighted text to show through action, sensation, and
detail instead of telling. Keeps the same meaning but makes it
vivid and immersive.

Rules:
- Replace emotion labels with physical reactions and body language
- Replace state descriptions with concrete actions
- Preserve the original POV and tense
- Keep roughly the same word count

Example:
Selected: "She was very angry at him."
Output: "Her jaw clenched. She set the glass down hard enough to
crack the stem, then turned away without a word."

Notice the structure: a one-line summary of what it does, explicit rules for the AI to follow, and a concrete input/output example. This pattern consistently produces the best generated prompts. The available boilerplates cover common use cases like dialogue punch-ups, sensory layering, pacing diagnostics, cliché detection, and tone shifting.

Step 2: Prompts

This is the heart of your plugin. Here you define the prompt pipeline that transforms selected text. Each plugin can have between 1 and 3 stages, where each stage is an independent AI call.

Every stage has two fields:

• System prompt — instructions to the AI about its role and how to process the text. This sets the behavior for that stage.
• User prompt — the actual input sent to the AI, typically including the selected text and any user instructions. The default user prompt is: {user_instructions}\n\nText to work with:\n\n{selected_text}

Available Variables

Use these variables in your prompts. They're automatically replaced with real data at execution time. All variables are injected as plain text (no JSON, no markup) — just drop the placeholder into your prompt and the AI sees the substituted text.

Empty variables silently resolve to empty strings. If the writer has no linked characters, {characters} becomes blank. Design your prompts so they still make sense when context is missing — don't depend on a variable always having content.

{selected_text}

What it is: the text the writer highlighted when they ran the plugin. This is the primary input — almost every plugin uses it.

Example substitution:

"I don't know," Marcus said quietly. He looked away from her.

{preceding_text}

What it is: roughly the last 1,000–2,000 characters of prose immediately before the selection — what just happened in the scene. Useful when your plugin needs to match voice or continue momentum.

When to use it: tone-matching plugins, continuation plugins, or anything that needs to “know what just happened”. Skip it for plugins that transform a passage in isolation (grammar, formatting, translation).

{characters}

What it is: plain-text summaries of characters relevant to the selection, pulled from the Story Bible. Each character gets a short block with name, personality snapshot, speech patterns, and backstory highlights.

Example substitution:

Marcus Hale — 34, former field medic. Speaks in short clipped sentences when stressed; softens in private. Haunted by a patient he couldn't save.

Elena Vasquez — detective, relentlessly curious. Uses humor as armor; asks too many questions at the wrong moment.

When to use it: dialogue plugins, voice plugins, anything involving character interiority. The variable is capped at ~4 characters — use sparingly, and prefer it over {story_context} for character-focused transforms.

{project_context}

What it is: project metadata — title, genre, subgenre, tone, themes, and logline. Short, high-signal.

Example substitution:

Title: The Glasswright's Apprentice
Genre: Literary fantasy
Tone: Melancholy, contemplative
Themes: Grief, craft, inheritance
Logline: A glassblower's daughter must finish her mother's final commission to save the family workshop.

When to use it: plugins where genre or tone should shape output — a horror tone-shift behaves very differently in literary fantasy vs. cozy mystery. Lets one plugin adapt to many projects.

{scene_info}

What it is: the current draft node's chapter title and synopsis (if the writer has filled those in). Anchors the plugin to this scene, not the whole project.

Example substitution:

Chapter: "Night Shift"
Synopsis: Marcus works a double at the hospital and re-encounters a case file that mirrors his own trauma.

{story_context}

What it is: matched worldbuilding, locations, and lore entries that are relevant to the selected text. Genesis Writer runs a lightweight keyword match against Story Bible entries and injects the most relevant ones.

When to use it: worldbuilding-aware plugins (a spell-check that respects your invented magic system, a continuity checker that knows your world's rules). Expensive in tokens — skip for plugins that work on prose mechanics.

{user_instructions}

What it is: freeform text the writer enters when running the plugin, if you've enabled the “Ask user for input” option. Only substitutes when the writer actually provides input — otherwise empty.

Example substitution: make it more formal or 3 (for a numbered-scale plugin) or Spanish (for a translator).

See Accepting User Input below for how to design prompts that use this variable well.

{stage_output}

What it is: the full text output from the previous stage in a multi-stage plugin. Only valid in stage 2 and later.

When to use it: whenever you build a multi-stage plugin. See Multi-Stage Pipelines below.

Accepting User Input

Turn on “Ask user for input” when you want the writer to supply a parameter at runtime. The wizard will prompt you for an input prompt — the question the writer sees before the plugin runs.

Common patterns:

• Free text: “What should the new tone be?” →{user_instructions} becomes bitter and sardonic.
• Numbered scale: “Intensity level 1–5?” →{user_instructions} becomes 3. Decode the number in your system prompt (“1=subtle, 5=extreme”).
• Choice from a list: “Genre? (noir, cozy, thriller)” → {user_instructions} becomes the chosen word.

Multi-Stage Pipelines

Multi-stage pipelines are powerful. Each stage processes the text and passes its output to the next stage via the {stage_output} variable.

Here's an example of a 3-stage “Deep Polish” pipeline:

1. Stage 1: Identify prose issues (passive voice, weak verbs, wordiness).
2. Stage 2: Rewrite the text to fix the issues found in Stage 1.
3. Stage 3: Final polish pass — rhythm, flow, and word choice.

Step 3: Test

The Test step lets you run your plugin on sample text before publishing it. Paste or type a text sample, click Run Test, and see exactly what your prompt pipeline produces.

Testing is optional but strongly recommended. It's much easier to spot prompt issues in the wizard than after you've published the plugin. If the output isn't what you expected, go back to the Prompts step and adjust.

Step 4: Details

Give your plugin an identity:

• Name — up to 60 characters. This is what appears in plugin lists.
• Tagline — up to 120 characters. A short description that appears on the plugin card.
• Description — up to 1,000 characters. A full explanation of what the plugin does and when to use it.
• Category — choose from 9 categories: Narrative & Plot, Character Development, Editing & Revision, Scene Enhancement, Worldbuilding, Analysis & Feedback, Marketing, Genre-Specific, or Multi-Lingual.

Output Style Presets

Output Style controls the temperature of the AI generation, which affects how creative or predictable the output is:

Expected Output Length

This setting tells Genesis Writer how much text your plugin typically produces relative to the input. It prevents truncation for expansion plugins and stops a short input from requesting an oversized response.

You can also optionally lock the model for your plugin. When a model is locked, the plugin always uses that specific model regardless of the user's current model selection. This is useful when you've tuned your prompts to work best with a particular model.

Step 5: Publish

The final step sets how your plugin is shared:

• Visibility
  • Private — only you can see and use this plugin.
  • Public — published to the Plugin Marketplace for other writers to discover.
• Prompt visibility
  • Hidden — other users can use your plugin but can't see your prompts. Your prompt engineering stays private.
  • Visible — other users can see your prompts. Great for educational plugins or if you want to encourage remixing.

Tags are auto-generated based on your plugin's name, description, and category. These tags help other writers find your plugin in marketplace search.

How Plugin Execution Works

When a user runs your plugin, here's what happens under the hood:

1. The user selects text in the editor and chooses your plugin.
2. Genesis Writer resolves all prompt variables ({selected_text}, {characters}, etc.).
3. Stage 1 runs: the system prompt and user prompt are sent to the AI model.
4. If multi-stage, Stage 1's output becomes {stage_output} for Stage 2, and so on.
5. The final stage's output replaces the selected text in the editor.
6. The user sees the Keep/Discard toolbar and makes their choice.

All plugins are selection-based — they always operate on text the user has selected. There is no way to create a plugin that inserts text at the end of the document (that's what Write and Continue are for).

Anatomy of a Good Plugin Prompt

“Make it better” is not a plugin. Every prompt that produces consistent, useful output has four parts. Skip any of them and the AI fills in the gap unpredictably.

1. Role. Tell the AI who it is. “You are an expert dialogue editor” produces different output than “You are a copy editor.” The role sets the whole frame.
2. Task. State the transformation clearly. What takes in what? What changes? What stays the same?
3. Rules / constraints. List specific dos and don'ts. “Match length within ±20%” is a rule. “Never change what was said — only how” is a rule. Rules are how you prevent the AI from wandering.
4. Output format. Say exactly what should come back. “Output ONLY the rewritten passage — no commentary, no labels” prevents the AI from adding preambles like “Here's your rewritten text:”.

You don't have to worry about this last point as much as you might think — Genesis Writer automatically wraps every custom plugin's system prompt with a default output rule. But if your plugin needs a specific format (JSON, bullets, a specific header), state it in your prompt and it takes precedence.

Worked Example: Dialogue Sharpener

Here's a real working system prompt from one of the built-in boilerplates, with each section labeled:

// ROLE
You are an expert dialogue editor. Rewrite the selected dialogue to be
sharper, more natural, and more revealing of character.

// RULES
RULES:
- Cut filler words, hedges, and on-the-nose exposition.
- Replace "said + adverb" with action beats that reveal character.
- Let subtext carry emotional weight — what isn't said matters more.
- Keep each character's voice distinct and consistent with the Story Bible.
- Preserve the POV, tense, and plot information of the original.
  Never change what was said — only how.
- Match the length within ±20%.

// CONTEXT
{characters}

// OUTPUT FORMAT
Output ONLY the rewritten passage — no commentary, no labels, no explanation.

// INPUT
Selected:
{selected_text}

Why this works:

• The role is specific (“dialogue editor”, not just “editor”) — the model pattern-matches to a narrower persona.
• The rules include boundaries (“never change what was said”, “±20% length”). Without these, the AI tends to rewrite too aggressively.
• Character context is injected via {characters}, so the dialogue stays in-voice for this project's cast.
• The output format is explicit, which stops the model from prepending “Here is your sharpened dialogue:” or wrapping the result in quotes.
• The input is labeled and placed last, so the model processes all the instructions before reading the material.

You can find more working examples in the boilerplate starters (Step 1). Clone one, adapt the rules, and you'll produce a plugin that behaves consistently.

Additional Tips

• Test with real prose. Don't test with lorem ipsum. Use actual fiction passages similar to what your target users will select — edge cases reveal prompt weaknesses.
• Start with one stage. Get a single-stage plugin working well before adding complexity. Multi-stage pipelines are powerful but much harder to debug.
• Use context variables sparingly. Plugins that stuff every available variable into the prompt often perform worse than focused ones. Pick the 1–2 variables that actually matter for your task.
• Match Output Style to the task. Precise (low temperature) for mechanical transformations; Creative for tone shifts and artistic rewrites.
• Write a good description. If you publish your plugin, the description is what convinces other writers to try it. Explain what it does and when to use it, not just what it's called.