[JS] Load input/output schemas from .prompt files

[Tyg-g]

Is your feature request related to a problem? Please describe.

When defining a flow containing a prompt loaded from a .prompt file, the input and output schemas have to be defined twice in the .prompt file and in the code.

Describe the solution you'd like

A much cleaner and dev-friendly solution would be if ai.prompt('...') would also return the schemas from the file as zod schemas.

Additional context

I think it's clear from this, if not, let me know. Perhaps I didn't miss anything from the docs regarding .prompt files.

Example -- Could work like this: (JS)

const ai = genkit({...});
const myPrompt = ai.prompt('my-prompt-file');

export const myFlow = ai.defineFlow(
  {
    name: 'myFlow',
    inputSchema: myPrompt.inputSchema,
    outputSchema: myPrompt.outputSchema,
  },
  async (input) => {
    const { output } = await myPrompt(input);
    return output;
  }
);

[Tyg-g]

This is a feature request, not sure why it isn't marked as such.

[MichaelDoyle]

Hey @Tyg-g have you seen defineSchema? https://js.api.genkit.dev/classes/genkit._.Genkit.html#defineschema

Does that meet your needs?

[Tyg-g]

Hi, thanks for the answer.

Not really. Using defineSchema I'd have the schema defined in a different file than the prompt.

I know it's possible to have schemas defined and used with prompts and flows in the code -- BUT the issue here is that there is no solution that would allow the codebase to stay well-organized.

[MichaelDoyle]

Thanks for the feedback - will relay this to the broader team. Seems like something that could be useful. Can you give some more details on what you are looking for in terms of a "well organized" code base?

The advantage of defineSchema is that it can be shared across many prompt files, as well as flows, etc. This is really common when you have "variants" of the same prompt with the same inputs/outputs but perhaps different implementation, etc. This does come at a cost of reducing the "portability" of the prompt file somewhat (because its no longer completely self describing). But still, nothing is in the way of organizing the schemas into a known place.

I think I could make a coherent argument (it's fine to disagree) that in the case you've described, the flow "owns" the schema definitions, since its the outermost user facing "thing", and those schemas should be passed down into to the prompts.

[Tyg-g]

Well organized in this case mainly means things that belong together be in one place (file). This mitigates errors when somebody edits one part of a "thing" (like a prompt) and either 1) forgets to edit another part in a different file or 2) it's difficult to locate the right file.

In my view - and in your words - a prompt owns its schema.

Perhaps a possible solution would be to organize all the schemas in a project into a single 'global' file.

Note on prompt variants: Prompt variants can't share a schema (only when predefined), but they can't share other properties either (like 'temperature' or 'model') what's also a similar issue.