elixir-generator

name	elixir-generator
description	This skill enables AI agents to generate new DHTI elixir project. Elixirs provide backend GenAI capabilities as HTTP endpoints hosted by LangServe. The skill guides the agent through environment setup, project scaffolding, studying reference implementations, and implementing the requested elixir functionality.

When to Use This Skill

Use this skill when you need to:

• Create a new DHTI elixir project from scratch
• Generate a LangServe-based backend service with FHIR integration
• Implement clinical decision support services using LangChain
• Build AI-powered EMR chatbot functionalities

Best Practices

• Each elixir should ideally focus ONLY on a single function. (e.g. file upload and glycemic recommender should be separate elixirs). If multiple functionalities are needed, create multiple elixirs and orchestrate them.
• Reuse existing elixirs where possible instead of creating new ones. You may refer to the list of existing elixirs in the DHTI monorepo: https://github.com/dermatologist/dhti-elixir#available-elixirs
• Always create a README.md file in the new package folder documenting the purpose, functionality, and usage of the elixir, including additional configuration steps if any as well as other elixirs or services it depends on and needs to be installed alongside.
• If a RAG pattern is needed, use redis vector stores. Use neo4j to represent complex graphs. Read src/resources/docker-compose.yml to understand how redis and neo4j containers will be spun up. Prefer using existing elixirs if any and mention the dependency in notes/README.md.

Instructions

Environment Setup and Project Scaffolding

• Read and internalize the original user feature request:

  • Understand the clinical functionality needed.

• Decide on a simple but unique name for your backend. It may be provided by the user (e.g., glycemic, heart_rate, skin_tone etc.). IN THE INSTRUCTIONS BELOW, REPLACE <<name>> WITH YOUR CHOSEN NAME.

• Scaffold a new microfrontend project :

copy packages/starter from the monorepo to packages/<>. YOU WILL USE THIS NEW PACKAGE AS THE BASE DIRECTORY FOR YOUR NEW ELIXIR PROJECT.

• Adapt the starter implementation
  • Rename packages/<>/dhti_elixir_starter to packages/<>/dhti_elixir_<>
  • You have to replace "starter" with your chosen name wherever applicable with dhti_elixir_<> in the generated project.

• Implementation:
  • chain.py:
    • The main class should be named "DhtiChain" inheriting from BaseChain ( from package dhti_elixir_base)
    • The main LLM and optionally a function calling LLM should be injected while bootstrapping as di["dhti_elixir_<>main_llm"] and di["dhti_elixir<>function_llm"] respectively. The default prompt should also be injected as di["dhti_elixir<>_prompt"]. Additional hyperparameters can be injected as needed. (Replace <> with your chosen name)
    • Plan how the problem can be solved using LangChain constructs (chains, agents, tools, callbacks, etc.) following the patterns in the reference chain.py.
• Bootstrap / configuration of the chain:
  • bootstrap.py:
    • This file is responsible for setting up dependency injection (DI) for the chain, including:
      • Configuring the main LLM and function calling LLM (if applicable).
      • Setting up prompts and any additional tools or services.
      • Configuring FHIR endpoints and any other external services.
    • Add default FakeChatLLM configuration for both main_llm and function_llm if not specified in the user request.
    • The cds_hook_discovery should be configured as follows:

di["dhti_elixir_<<name>>_cds_hook_discovery"] = {  # <- <<name>>
    "services": [
        {
            "id": "dhti-service",   # <- Keep as is
            "hook": "order-select",  # <- Keep as is
        }
    ]
}

Extract and internalize the following from other packages such as simple_chat in the monorepo:

• How the LangChain chain is constructed (inputs, outputs, prompts, tools, callbacks, etc.).
• How configuration, environment variables, and settings are wired in bootstrap.py.
• How FHIR or other external services are integrated, if present.
• Any conventions for logging, error handling, and dependency injection.

You must follow the same architectural and stylistic patterns in the <> project's chain.py and bootstrap.py.

Implement the new Elixir request

Your primary task is to update the newly created chain.py and bootstrap.py in the generated project to implement the following user specification:

The DhtiChain should implement the functionality described in the original user request for the elixir.

Interpret below as the high-level functional requirement for the chain. Your implementation should:

• Align with the reference pattern:
  • Mirror the structure, abstractions, and flow used in the reference chain.py and bootstrap.py.
  • Reuse naming conventions, configuration style, and initialization patterns where appropriate.
• FHIR-based data retrieval:
  • Retrieve any required data using FHIR search.
  • Read and carefully study FHIR search here: https://r.jina.ai/https://www.hl7.org/fhir/search.html
  • Read how fhir search is implemented in dhti-elixir-base here: https://github.com/dermatologist/dhti-elixir-base/tree/develop/src/dhti_elixir_base/fhir. This is available as a dependency in the generated project. Hence you can use fhir search functionality from dhti-elixir-base in your implementation and avoid code duplication.
  • Use appropriate FHIR resource types and query parameters based on the needs implied by the original user specification.
  • Implement FHIR interactions in a way that is:
    • Configurable (e.g., via environment variables or settings),
    • Robust (handles typical error conditions),
• Dependencies and package usage:
  • Prefer existing dependencies and standard library where possible.
  • Only introduce additional Python packages when clearly necessary.
  • If you add any new package:
    • Add it to pyproject.toml as a dependency in the appropriate section.
    • Ensure compatibility with the existing project structure (e.g., version constraints if needed).
• Chain behavior:
  • Define the chain's inputs, outputs, and key steps clearly.
  • Ensure the chain logic fulfills all aspects of user request, including:
    • Any domain logic surrounding Elixir code analysis, generation, or orchestration.
    • Any interactions with external services (e.g., FHIR, LLMs, tools) as appropriate.
• Tools (if applicable):
  • Internalize how the agent uses tools if available from the package agent_chat in the monorepo.
  • The original user specification will indicate any available tools to use. If none are indicated, you do not have access to any tools.

Implementation details

• Update chain.py:
  • Implement the chain logic following the patterns from the reference chain.py.
  • Integrate FHIR search where needed.
  • Ensure the chain is testable, modular, and readable.
  • Include inline comments where non-trivial logic is implemented.
• Update bootstrap.py:
  • Configure the chain, environment variables, and external services following the patterns of the reference bootstrap.py.
  • Ensure:
    • FHIR endpoint configuration is clearly defined (and overridable),
    • Logging and error handling are consistent with the reference style,
    • Any secrets or sensitive settings are expected via environment variables or configuration files, not hard-coded.
• Dependency management:
  • If you added new packages:
    • Confirm they are correctly listed in pyproject.toml.
    • Ensure any import paths are correct and code runs without import errors.

Testing

• Write unit tests for the new behavior:
  • Place tests in the appropriate test directory or module, consistent with the generated project's testing structure.
  • Cover:
    • Core chain behavior (including expected inputs/outputs),
    • FHIR search integration (using mocks where appropriate),
    • Configuration behavior in bootstrap.py (e.g., how environment variables/config affect the chain).
• Ensure tests:
  • Are deterministic,
  • Avoid real external network calls when possible (use mocking or fixtures),
  • Use clear, descriptive test names.
• Run the test suite via uv and ensure all tests pass.

Documentation

• Update README.md to reflect the new functionality:
  • Add or update sections describing:
    • The purpose and scope of the project.
    • The behavior of the chain and what it means in practice.
    • How to configure FHIR endpoints and any relevant environment variables.
    • How to run the chain, including command examples.
    • How to run tests.
• Ensure the README is clear and suitable for:
  • Developers integrating or extending the chain,
  • Clinicians or researchers trying to understand the high-level purpose (if relevant).

Final quality pass

Perform a final pass over the project to ensure:

• Code quality:
  • Code is idiomatic, consistent with the reference style, and well-structured.
  • No obvious dead code, unused variables, or leftover debug prints.
  • Type hints are used where appropriate (if consistent with the template).
• Functionality:
  • The chain runs end-to-end for the scenario implied by the original user specification.
  • FHIR calls behave as expected (or are mockable in tests).
  • Configuration is documented and works as described.
• Project integrity:
  • All imports resolve.
  • Tests pass.
  • README is up to date.
  • The TODO list accurately reflects what has been completed (you may optionally mark completed tasks).

Expected Output

A fully functional DHTI elixir project that:

• Follows the architectural patterns of the reference template
• Implements the requested elixir functionality
• Includes proper FHIR integration
• Has comprehensive tests
• Is well-documented
• Can be installed into DHTI using the dhti-cli

Best Practices

• Each elixir should ideally focus ONLY on a single function. (e.g. file upload and glycemic recommender should be separate elixirs). If multiple functionalities are needed, create multiple elixirs and orchestrate them.
• Reuse existing elixirs where possible instead of creating new ones. You may refer to the list of existing elixirs in the DHTI monorepo: https://github.com/dermatologist/dhti-elixir#available-elixirs
• Always create a README.md file in the new package folder documenting the purpose, functionality, and usage of the elixir, including additional configuration steps if any as well as other elixirs or services it depends on and needs to be installed alongside.
• If a RAG pattern is needed, use redis vector stores. Use neo4j to represent complex graphs. Read src/resources/docker-compose.yml to understand how redis and neo4j containers will be spun up. Prefer using existing elixirs if any and mention the dependency in notes/README.md.