[META] Create a reusable "Prompt Entity" and field

This forgets complex prompts which I use all the time. Somehow I need to prove they are very important :-)

I was searching for this issue while fixing ai_translate module :)
Hard-coding the prompts is definitely not the best idea, and doesn't give users much flexibility.
So, what is a prompt? Config entity with token support? In this case, initial prompts are placed in config/install and then configurable at some "prompt UI"?

I think in best of worlds, its actual Twig or something close to it. If we really want to make good prompting possible via GUI, conditionals are a must.

Take the example with AI Translate that I know from speaking German and Swedish, where the courtesy of personal pronouns differs, where it could be for instance:

{% if $source_lang == 'sv' && $dest_lang == 'en' %}
Take the following text and translate it from Swedish to German word by word. Make sure that you try to understand from context if the person be spoken to are in a position where they are allowed to say du, otherwise change this to sie:

{{ text }}
{% else %}
Take the following text and translate it from {{ source_lang }} to {{ dest_lang }} word by word.

{{ text }}
{% endif %}

It will be a lot more complex to do this, but I think having the possibility to do this opens up a lot better prompting. Maybe it could be that any prompt entity can be hooked/have event right before being used and the conditional happens there. But if we can get it into config, it would be easy to share complex prompts.

How much of this do you cover in https://www.drupal.org/project/aiprompt → @mindaugasd? I guess one option is keep it simple here, and have aiprompt be a supported integration with this (and perhaps vice versa making ai dependency of aiprompt to focus on just the prompting there... something to discuss)

Take the example with AI Translate that I know from speaking German and Swedish, where the courtesy of personal pronouns differs, where it could be for instance

@Marcus_Johansson I think GUI of aiprompt is better than twig for situation you described.

Recently I implemented arguments UI, which enables to define variables the prompt accepts in GUI ✨ Allow to pass variables to aiprompt programatically Active

In this situation you would define "translate_from" and "translate_to" variables.
And this feature ✨ Possibility to constrain available options for string and integer arguments Active would also allow to predefine possible options (provide "select" list of options to choose from)

The most obvious use for "arguments" would be to define a variable called "mode", and predefine list of prompt variants/modes.

Then, user would select which segment is (in)visible depending on the current prompt "mode".
✨ Implement conditions for prompt segments Active

aiprompt is scheduled to support inheritance ✨ Inheriting segments of parent prompt in user interface Active , allowing to define "default" prompt in configuration, and enable to override/extend/reset individual parts of it. It is for prompt re-use to enable not repeat the same segments across prompts and have central prompts with defaults.

I use "content" entity prompt day to day, but will do default definitions with "config" entity.
AIPrompt module already supports both content and config entities at the same time.

aiprompt dev version also already supports all tokens.
There is a so much more existing and coming to aiprompt: https://www.drupal.org/project/issues/aiprompt →

It also enables developers to create they own segment plugins, and the custom plugins I developed have quite huge UIs for convenience of doing complex tasks. Will release more of such plugins when ready.

But the big issue of integrating aiprompt within /ai module is that it have quite extensive UI and my prompt configurations are huuge not fitting for inline editing and requires a separate page, so I don't have personal need to edit prompts inline, but separate pages may be too much for most simple usecases users might have.

These improvements will make UI more integratable inline:
- https://www.drupal.org/project/aiprompt/issues/3461448 ✨ Implement horizontal tabs Active
- https://www.drupal.org/project/aiprompt/issues/3459142 ✨ Improve support for inline entity form Active
- https://www.drupal.org/project/aiprompt/issues/3446532 ✨ Implement aiprompt_field submodule Active
- Many issues have an additional bullet list to upgrade that particular functionality for ajax/modal at later point. It is probably main requirement in order to make prompt integratable inline. Right now every activity follows a 'url' page (example would be how "rules" module work).

Arguments UI exist in dev version, but there is no way to utilize those arguments yet (not completed).

Additional features will exist:

1. Utilize arguments as tokens
2. Utilize arguments as conditions
3. Pass arguments to parent as well (part of inheritance feature)

Argument can be any entity passed to the prompt, so 'arguments as tokens' feature is a bit stuck right now (while I am working on other features).
It is stuck to a level that I even proposed to modernize Drupal Core Tokens system:
✨ Modernize token system Active
Does anyone know what it takes to achieve the same with current Drupal token system (as described in that issue).

This makes Drupal a PMS or Prompt Management System :D
I like the hookability a lot.
(I was already thinking of adding those hooks to the places were it's hardcoded now).
That would not be needed anymore.

I was thinking Content managers often would use this to save all the tone of voice instructions (for multiple languages?) in one place.
They could then be injected into all relevant prompts (as a token or variable or reference?) so that all prompts that require it return consistent good content.

This makes Drupal a PMS or Prompt Management System :D

:D

Just posted another idea to enable most custom level of integrations:

✨ Make prompt available as a custom form element Active

prompt available as form element

This idea would be quite challenging, because routes are tied to entities:

/admin/config/aiprompt/{aiprompt_config}/segment/add/{plugin_id}
/admin/config/aiprompt/{aiprompt_config}/segment/{segment_id}/edit
/admin/config/aiprompt/{aiprompt_config}/segment/{segment_id}/delete

/admin/config/aiprompt/{aiprompt_config}/argument/add/{plugin_id}
/admin/config/aiprompt/{aiprompt_config}/argument/{argument_name}/edit
/admin/config/aiprompt/{aiprompt_config}/argument/{argument_name}/delete

/aiprompt/{aiprompt}/edit/segment/add/{plugin_id}
/aiprompt/{aiprompt}/edit/segment/{segment_id}/edit
/aiprompt/{aiprompt}/edit/segment/{segment_id}/delete

/aiprompt/{aiprompt}/edit/argument/add/{plugin_id}
/aiprompt/{aiprompt}/edit/argument/{argument_name}/edit
/aiprompt/{aiprompt}/edit/argument/{argument_name}/delete

Never seen this before, but maybe is possible to tie the route to ID of $form_state, so ensuring all this is saved under particular $form_state.

Created issue to gather all the requirements ✨ [meta] Where prompts will be used Active for different situations/places where prompt will be used.

This makes Drupal a PMS or Prompt Management System :D

Created issue to limit features to most essential for inline editing within AI automator forms:
📌 Introduce "simple" mode Active

Am I the only one to suddenly think of webform and its structure/UI?
Component chaining, parameters, plugins, conditionals etc... webform has it all, with stable UI to configure.
Can we borrow some of webform approaches?

Webform module is the best, but for a different use-case.

I mentioned some of webform components in AI modules which will be used:

• ✨ Implement horizontal tabs Active
• 📌 Chat in the sidebar (drupal off-canvas support) Active

But these two are cases when Drupal core does not provide something, while webform has it.
Otherwise you just build with components which Drupal core provides.

Another inspiration of mine is Views module which one could also say could be used for prompt engineering by itself.

Issue description does not talk how prompt can be integrated within all the different places (#3462784]. This is the hardest part which aiprompt have not solved yet.

aiprompt does not use much of ajax (postponed for later upgrade), but also ajax is not necessarily better:

• 'Views' module completely relied on ajax in Drupal 6 days, but later opted for modals.
• Or webform uses the off-canvas instead of ajax.

And both 'sidebar' and 'modals' can be overkill too if someone just want to edit the prompt inline, so that is why this solution: [#346278]

For actual integration, out of all options considered so far, ✨ Improve support for inline entity form Active seems best if API of this module is sufficient for all the requirements of aiprompt. If not, we may need to create a custom widget (or extend features of inline_entity_form).

I seen videos how new features of AI module module work (will be released on Monday),
I think it would be useful to select a prompt within various contexts from the prompt library: ✨ Prompt library in the popup modal Active

I'm afraid we're over-engineering the starting point.
Visual editing, inheritance and so on of prompts is great, but just for the purposes of being able to change default prompt, even simple configuration entity would suffice.
If aiprompt is not finding its way into "core" ai (or ai's composer.json as dependency) real soon, ai and its submodules cannot rely on the very existence of prompt entity.
As an immediate solution, I would suggest having prompt as a config entity (I am going to try this approach as a PoC for ai_translate and specifically 💬 Can't modify prompt for translating Needs review )
aiprompt can add visual editing, separate ConfigEntity class etc., but "core" ai should have something to start with

There are many paths:

1. If someone needs it, as suggested here #3466061-8: Can't modify prompt for translating → , it won't be difficult to do edit it with little custom code.
2. If there is even more need in specific areas, then AI module can simply expose a text-area to edit the prompt.
3. If there is super urgent need and can't wait, then yes, AI module could have config entity now.

I'm afraid we're over-engineering the starting point.

I am developing assistants in custom code for 1.5 years. It does not feel like over-engineering to me, but as next iteration and putting things together for open source as flexible module I would like to use. I often talk how I love 'views' module for 'ambitious site builders', so I want Drupal to have more modules like it allowing to build a lot with little coding. So this prompt engineering tool is like a views module with quite many possibilities. I think its good that open release have flexible architecture from the start.

Ajax on the entity form is hard, battling it for days lately: ✨ Add segment row enable/disable actions for segments table Active
Final solution - will do this without ajax and call it a day (or multiple:) to proceed building inheritance feature.

I'm late to see this but I have a totally different suggestion (which is probably not really usefull).
We could also make it much simpler.

Add a settings page with two things
- example prompts for people to use
- simple settings fields for prompts used everywhere.
This way you can override the prompts used everywhere.
Its super simple
(maybe too simple?)

We could alos have pieces of prompt as Tokens (actual Drupal tokens).
For example:

• Tone of voice prompt goes into [ai_prompt:tone]
• Translation prompt goes into [ai_prompt:translate]

This way you can mix and match different prompts (and reuse the tone of voice everywhere).

Just some ideas.

Would be the same as in 💬 Can't modify prompt for translating Needs review
Having a settings page is good optimal solution, unless there is some drawbacks? What are benefits of having a separate entity?

- example prompts for people to use

Below each prompt setting, documentation could expand with various examples relating to that particular context.
Again a bit similar like #3466061-15: Can't modify prompt for translating →

Just my two cents, I put my thoughts based on the latest AI translation implementation I just completed in a comment here - https://www.drupal.org/project/ai/issues/3466061#comment-15725346 💬 Can't modify prompt for translating Needs review

Adding to issue summary that prompts should accept arguments or wouldn't really be very usable e.g. for RAG type things where multiple variables can get replaced. See also earlier comment in #6:

Recently I implemented arguments UI, which enables to define variables the prompt accepts in GUI ✨ Allow to pass variables to aiprompt programatically Active