EC

echokit-config-generator

An interactive utility to generate config.toml files for EchoKit server deployments.

Install

mkdir -p .claude/skills/echokit-config-generator && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/3137" && unzip -o skill.zip -d .claude/skills/echokit-config-generator && rm skill.zip

Installs to .claude/skills/echokit-config-generator

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Generate config.toml for EchoKit servers with interactive setup for ASR, TTS, LLM services, MCP servers, API key entry, and server launch
137 charsno explicit “when” trigger
Beginner

Key capabilities

  • Constructs structured config.toml files
  • Integrates ASR and TTS service settings
  • Embeds MCP server configuration strings
  • Standardizes API key storage methods
  • Automates five-phase interactive setup

How it works

Processes user inputs through a five-phase sequential questionnaire, applying defaults if triggered by specific keywords, to populate a configuration template.

Inputs & outputs

You give it
Assistant purpose, tone, and service capabilities via interactive prompts
You get back
Formatted config.toml file for server launch

When to use echokit-config-generator

  • Generate EchoKit server config
  • Configure ASR and TTS services
  • Add MCP server settings
  • Input API keys for LLM integration

About this skill

EchoKit Config Generator

Overview

This SKILL generates config.toml files for EchoKit servers through an interactive five-phase process that includes configuration generation, API key entry, and server launch.

Announce at start: "I'm using the EchoKit Config Generator to create your config.toml."

Handling User Input

Throughout this SKILL, when asking questions with default values:

Always phrase it as: "Question? (default: {VALUE})"

Handle responses:

  • Empty response or Enter → Use the default value
  • User provides value → Use user's value
  • User enters "default" → Use the default value explicitly

Example:

AI: How many messages should it remember? (default: 5)
User: [Enter]
AI: [Uses 5]

AI: How many messages should it remember? (default: 5)
User: 10
AI: [Uses 10]

This applies to ALL questions with defaults throughout the SKILL.

Phase 1: Assistant Definition

Ask these questions one at a time:

  1. "What is your AI assistant's primary purpose? (Describe in 1-2 sentences)"
  2. "What tone should it have? (professional, casual, friendly, expert, or describe your own)"
  3. "What specific capabilities should it have?"
    • Prompt with examples if needed: "code generation", "data analysis", "creative writing", "problem-solving", "teaching", etc.
  4. "Any response format requirements?"
    • Examples: "short answers", "detailed explanations", "step-by-step", "conversational", "formal reports"
  5. "Any domain-specific knowledge areas?" (Optional)
    • Examples: "programming", "medicine", "law", "finance", etc.
  6. "Any constraints or guidelines?" (Optional)
    • Examples: "no bullet points", "always cite sources", "avoid jargon", "max 3 sentences"
  7. "Any additional instructions or preferences?" (Optional)

Generate sophisticated system prompt using this structure:

[[llm.sys_prompts]]
role = "system"
content = """
You are a {TONE} AI assistant specialized in {PURPOSE}.

## Core Purpose
{PURPOSE_EXPANDED - elaborate based on user input}

## Your Capabilities
- List the capabilities provided by user
- Each capability on its own line
- Be specific about what you can do

## Response Style
{FORMAT_REQUIREMENTS}

## Domain Knowledge
{DOMAIN_KNOWLEDGE if provided, otherwise omit this section}

## Behavioral Guidelines
{BEHAVIORS_FROM_USER}
- Add any relevant default behaviors based on tone

## Constraints
{CONSTRAINTS_FROM_USER}
- Always maintain {TONE} tone
- {RESPONSE_FORMAT_RULES}

## Additional Instructions
{ADDITIONAL_NOTES if provided}

---
Remember: Stay in character as a {TONE} {DOMAIN} assistant. Always prioritize helpfulness and accuracy.
"""

Enhanced defaults based on tone:

If user doesn't provide specific behaviors, use these expanded defaults:

  • professional:

    • Provide accurate, well-researched information
    • Maintain formal, business-appropriate language
    • Acknowledge limitations and uncertainty
    • Structure responses logically
  • casual:

    • Be conversational and engaging
    • Use natural, relaxed language
    • Show personality when appropriate
    • Keep interactions friendly and approachable
  • friendly:

    • Be warm and welcoming
    • Use simple, clear language
    • Show empathy and understanding
    • Make users feel comfortable
  • expert:

    • Provide comprehensive technical details
    • Cite sources and references when relevant
    • Explain trade-offs and alternatives
    • Use appropriate terminology correctly
    • Acknowledge edge cases and limitations

Phase 2: Platform Selection

For each service category (ASR, TTS, LLM):

  1. Read platform data from platforms/{category}.yml using the Read tool
  2. Display available options with this format:
Available {SERVICE} Services:

1. {PLATFORM_1.name}
   URL: {PLATFORM_1.url}
   Model: {PLATFORM_1.model}
   Get API key: {PLATFORM_1.api_key_url}
   Notes: {PLATFORM_1.notes}

2. {PLATFORM_2.name}
   URL: {PLATFORM_2.url}
   Model: {PLATFORM_2.model}
   Get API key: {PLATFORM_2.api_key_url}
   Notes: {PLATFORM_2.notes}

C. Custom - Specify your own platform/model

Your choice (1-{N} or C):
  1. User selection:

    If user selects a number (1-{N}):

    • Store the selected platform data from the YAML file
    • Continue to next service

    If user selects 'C' (Custom):

    Step 1: Get platform name

    • Ask: "What's the platform name?" (e.g., "groq", "deepseek", "mistral", "together")

    Step 2: Auto-fetch API information

    • Use WebSearch to find API documentation
    • Search query: "{PLATFORM_NAME} API endpoint {SERVICE_TYPE} 2025"
      • For ASR: "speech to text API", "transcription API"
      • For TTS: "text to speech API"
      • For LLM: "chat completions API", "LLM API"
    • Extract from search results:
      • API endpoint URL
      • API documentation URL
      • Authentication method
      • Default model names

    Step 3: Confirm with user Display what was found:

    I found the following for {PLATFORM_NAME} {SERVICE}:
    
    API Endpoint: {FOUND_URL}
    Documentation: {FOUND_DOCS_URL}
    Authentication: {FOUND_AUTH_METHOD}
    Default Models: {FOUND_MODELS}
    
    Is this correct? (y/edit)
    

    Step 4: Gather additional details

    • Ask: "What model should I use? (suggested: {FOUND_MODELS} or enter custom)"
    • Ask for additional settings:
      • LLM: "How many messages should it remember? (default: 5)"
      • TTS: "What voice should it use? (default: default)"
      • ASR: "What language? (default: en)"

    Step 5: Store custom platform

    name: "{PLATFORM_NAME}"
    platform: "{INFERRED_TYPE from API docs or user}"
    url: "{CONFIRMED_URL}"
    model: "{USER_MODEL_CHOICE}"
    history/voice/lang: {USER_SETTINGS}
    api_key_url: "{FOUND_DOCS_URL}"
    notes: "Custom {PLATFORM_NAME} - auto-configured"
    
  2. Continue to next service

Load platforms in order:

  1. ASR from platforms/asr.yml
  2. TTS from platforms/tts.yml
  3. LLM from platforms/llm.yml

Note on WebSearch: Use WebSearch tool with year-specific queries (2025) to get current API information. For common platforms, you can also infer from patterns:

  • OpenAI-compatible: https://api.{platform}.com/v1/chat/completions
  • Anthropic-compatible: https://api.{platform}.com/v1/messages
  • Together/Groq: OpenAI-compatible format

Phase 3: MCP Server (Optional)

Ask: "Do you need an MCP server? (y/n)"

If yes, ask: "What's your MCP server URL?"

Default: http://localhost:8000/mcp

Add MCP configuration to LLM section:

The MCP server is configured within the LLM configuration as:

[[llm.mcp_server]]
server = "{USER_PROVIDED_URL or http://localhost:8000/mcp}"
type = "http_streamable"
call_mcp_message = "Please hold on a few seconds while I am searching for an answer!"

Explain to user:

  • The MCP server will be added to the LLM section
  • type can be: "http_streamable" or "http"
  • call_mcp_message is shown to users when MCP is being called

Phase 4: Generate Files

Step 1: Preview config.toml

IMPORTANT: EchoKit server requires a specific TOML structure:

  • Section order MUST be: [tts][asr][llm]
  • No comments allowed at the beginning of the file
  • Field names vary by platform (check platform-specific requirements)

Display complete configuration with this format:

addr = "0.0.0.0:8080"
hello_wav = "hello.wav"

[tts]
platform = "{SELECTED_TTS.platform}"
url = "{SELECTED_TTS.url}"
{TTS_API_KEY_FIELD} = "YOUR_API_KEY_HERE"
{TTS_MODEL_FIELD} = "{SELECTED_TTS.model}"
voice = "{SELECTED_TTS.voice}"

[asr]
platform = "{SELECTED_ASR.platform}"
url = "{SELECTED_ASR.url}"
{ASR_API_KEY_FIELD} = "YOUR_API_KEY_HERE"
model = "{SELECTED_ASR.model}"
lang = "{ASR_LANG}"
prompt = "Hello\\n你好\\n(noise)\\n(bgm)\\n(silence)\\n"
vad_url = "http://localhost:9093/v1/audio/vad"

[llm]
platform = "{SELECTED_LLM.platform}"
url = "{SELECTED_LLM.url}"
{LLM_API_KEY_FIELD} = "YOUR_API_KEY_HERE"
model = "{SELECTED_LLM.model}"
history = {SELECTED_LLM.history}

{GENERATED_SYSTEM_PROMPT}

{MCP_CONFIGURATION if enabled}

Platform-specific field mappings:

TTS platforms:

  • openai: uses api_key and model
  • elevenlabs: uses token and model_id
  • groq: uses api_key and model

ASR platforms:

  • openai/whisper: uses api_key and model

LLM platforms:

  • openai_chat: uses api_key (optional, can be empty string)

When generating the config, replace {TTS_API_KEY_FIELD}, {ASR_API_KEY_FIELD}, and {LLM_API_KEY_FIELD} with the appropriate field name for the selected platform:

  • For ElevenLabs TTS: use token
  • For OpenAI/Groq TTS: use api_key
  • For Whisper ASR: use api_key
  • For OpenAI Chat LLM: use api_key

Step 2: Ask for confirmation

"Does this configuration look correct? (y/edit/regenerate)"

  • y - Proceed to write files
  • e - Ask which section to edit (asr/tts/llm/system_prompt)
  • r - Restart from Phase 1

Step 3: Determine output location

Ask: "Where should I save the config files? (press Enter for default: echokit_server/)"

Handle user input:

  • Empty/Enter → Use default: echokit_server/
  • Custom path → Use user-provided path
  • Relative path → Use as-is (e.g., my_configs/)
  • Absolute path → Use as-is (e.g., /Users/username/echokit/)

After path is determined:

  1. Check if directory exists
  2. If not, ask: "Directory '{OUTPUT_DIR}' doesn't exist. Create it? (y/n)"
    • If y: Create with mkdir -p {OUTPUT_DIR}
    • If n: Ask for different path
  3. Verify write permissions
    • Test by attempting to create a temporary file
    • If fails, ask for different location

Step 4: Write files

Use the Write tool to create:

  1. {OUTPUT_DIR}/config.toml - Main configuration (includes MCP server if enabled)
  2. {OUTPUT_DIR}/SETUP_GUIDE.md - Setup instructions (use template from templates/SETUP_GUIDE.md)

Step 5: Display success message

✓ Configuration generated su

---

*Content truncated.*

When not to use it

  • Modifying existing server binary code
  • Performing runtime server debugging
  • Generating non-TOML configuration formats

Prerequisites

Access to EchoKit server source

Limitations

  • Requires manual keyboard input for each phase
  • Cannot validate if API keys are actually active
  • Strict adherence to TOML format constraints

How it compares

Ensures consistency in TOML formatting and API key structures through enforced, stage-gated interactive dialog rather than manual editing.

Compared to similar skills

echokit-config-generator side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
echokit-config-generator (this skill)16moReviewBeginner
telegram-bot-builder1066moReviewIntermediate
playwright-browser-automation297moReviewIntermediate
workflow-orchestration-patterns102moNo flagsAdvanced

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

telegram-bot-builder

davila7

Expert in building Telegram bots that solve real problems - from simple automation to complex AI-powered bots. Covers bot architecture, the Telegram Bot API, user experience, monetization strategies, and scaling bots to thousands of users. Use when: telegram bot, bot api, telegram automation, chat bot telegram, tg bot.

106130

playwright-browser-automation

lackeyjb

Complete browser automation with Playwright. Auto-detects dev servers, writes clean test scripts to /tmp. Test pages, fill forms, take screenshots, check responsive design, validate UX, test login flows, check links, automate any browser task. Use when user wants to test websites, automate browser interactions, validate web functionality, or perform any browser-based testing.

29146

workflow-orchestration-patterns

wshobson

Design durable workflows with Temporal for distributed systems. Covers workflow vs activity separation, saga patterns, state management, and determinism constraints. Use when building long-running processes, distributed transactions, or microservice orchestration.

10117

codex-skill

feiskyer

Use when user asks to leverage codex, gpt-5, or gpt-5.1 to implement something (usually implement a plan or feature designed by Claude). Provides non-interactive automation mode for hands-off task execution without approval prompts.

12110

bullmq-specialist

davila7

BullMQ expert for Redis-backed job queues, background processing, and reliable async execution in Node.js/TypeScript applications. Use when: bullmq, bull queue, redis queue, background job, job queue.

2595

n8n-expression-syntax

czlonkowski

Validate n8n expression syntax and fix common errors. Use when writing n8n expressions, using {{}} syntax, accessing $json/$node variables, troubleshooting expression errors, or working with webhook data in workflows.

6111

Search skills

Search the agent skills registry