SillyTavern Extension Builder

Overview

Workflow

1. Define the extension contract.

• Confirm extension slug, display name, minimum supported SillyTavern version, required modules, and whether the feature is UI-only, slash-command-only, or background worker based.
• If the user does not provide a slug, generate a lowercase kebab-case slug.

1. Scaffold baseline files.

• Prefer

  scripts/scaffold_extension.sh

  to generate

  manifest.json

  ,

  index.js

  ,

  style.css

  , and

  settings.html

  .
• Choose template mode:

  • default

    for UI/event-focused extensions.

  • slash

    for slash-command-first extensions.
• If the user already has files, perform minimal edits instead of full rewrites.

1. Wire extension lifecycle and settings.

• Keep extension settings under

  extension_settings[EXTENSION_NAME]

  .
• Call

  loadExtensionSettings(EXTENSION_NAME)

  before reading setting values.
• Use

  saveSettingsDebounced()

  after setting changes.
• Register startup/event handlers inside

  jQuery(async () => { ... })

  .

1. Implement user-facing behavior.

• For DOM/UI integration, use documented APIs (context helpers, templates, settings rendering).
• For command behavior, add slash commands and argument parsing with the slash-command APIs when needed.
• For background logic, use a module worker class and gate execution by current chat context.

1. Validate compatibility and packaging.

• Ensure manifest keys are correct and file names match actual files.
• Ensure import paths are valid from the extension directory.
• Keep third-party dependency usage explicit and minimal.
• Package as a repo or zip with only required runtime files.

1. Return deliverables.

• Provide final file set and a concise integration note.
• Include install path expectations and any required module prerequisites.

Output Rules

• Prefer minimal-diff changes when editing an existing extension.
• Keep settings schema stable; migrate old keys instead of silently breaking them.
• Use deterministic IDs/command names (derive from extension slug).
• If introducing a slash command, include help text and argument validation.
• If introducing a module worker, include clear stop conditions for idle/no-chat states.

Resources

• references/writing-extensions-reference.md

  • Condensed upstream authoring guidance, required file anatomy, APIs, and release rules.

• references/st-extension-example-walkthrough.md

  • Practical breakdown of the

    city-unit/st-extension-example

    template and reuse patterns.

• references/extension-quality-guidelines.md

  • Research-backed recommendations for quality, maintainability, security, and release readiness.

• references/template-selection-guide.md

  • Decision guide for choosing

    default

    vs

    slash

    scaffold mode and migrating between them.

• assets/templates/extension/manifest.json

  • Starter manifest with placeholders.

• assets/templates/extension/index.js

  • Starter extension entrypoint with settings and event wiring.

• assets/templates/extension/style.css

  • Starter CSS file referenced by manifest.

• assets/templates/extension/settings.html

  • Starter settings template for

    renderExtensionTemplateAsync

    .

• assets/templates/extension-slash/manifest.json

  • Slash-command-first starter manifest.

• assets/templates/extension-slash/index.js

  • Slash-command-first starter entrypoint with parser registration and validation.

• assets/templates/extension-slash/style.css

  • Minimal stylesheet for command help/settings rows.

• assets/templates/extension-slash/settings.html

  • Starter settings block for enabling/disabling command behavior.

• scripts/scaffold_extension.sh

  • Generator script for new extension skeletons.

Notes

• The docs and extension APIs evolve. If behavior is uncertain, prefer upstream docs over assumptions and keep code conservative.
• Keep code style aligned with existing SillyTavern extension conventions (imports, settings handling, and event registration).