Skip to content

Feature Request: Support additional placeholder variables in the system prompt #598

Description

@LexioJ

Describe the feature you'd like to request

Summary

Currently, the admin-configurable "Chat User Instructions" (system prompt) for both chat completions and title generation only supports a single placeholder: {user}, which resolves to the current user's display name (see lib/Controller/ChattyLLMController.php, str_replace('{user}', $user->getDisplayName(), $userInstructions)).

It would be useful to support a small set of additional placeholders so admins can write more context-aware and personalized system prompts without needing code changes for every use case.

Motivation

Right now the system prompt is fairly static aside from the display name. Being able to inject a few more pieces of contextual information (date, language, login name, etc.) would let admins:

  • Localize/adjust behavior based on the user's preferred language
  • Reference the current date/time for time-sensitive tasks (e.g. "today is {date}")
  • Distinguish between a user's display name and their login/username

Describe the solution you'd like

Proposed variables

Placeholder Resolves to
{user} (existing) User's display name
{username} User's login name / UID (IUser::getUID())
{email} User's email address (IUser::getEMailAddress())
{language} User's preferred language (e.g. from IUser/IL10N)
{date} Current date (server or user timezone)
{time} Current time (server or user timezone)

Additional context

  • Substitution currently happens via simple str_replace() calls in lib/Controller/ChattyLLMController.php (used in newSession(), generateTitle(), and checkTitleGenerationTask()), so adding more placeholders would follow the same pattern.
  • The available placeholders are documented inline in the admin settings UI (src/components/AdminSettings.vue) via NcNoteCard hint text below each prompt field — this documentation should be updated to list any newly added variables.
  • Open question: should placeholder resolution be strict (only replace exact known tokens) or should unknown {...} tokens be left untouched/escaped to avoid breaking existing prompts that happen to contain literal curly braces?

Describe alternatives you've considered

None

Assisted-by: ClaudeCode:claude-fable-5

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions