feat: add example types to manifest

[shiv810]

Resolves #242

• Adds Example type to the manifest type

[0x4007]

Any QA we can demo with?

[whilefoo]

spelling mistake commandInvocation

is commandInvocation supposed to be the comment? example: @UbiquityOS can you change my address to 0x00
Parameters are the expected way to infer parameters from the comment, right?

[shiv810]

{
  "examples": [
    {
      "commandInvocation": "@UbiquityOS what is my wallet address?",
      "parameters": {
        "repositoryOwner": "repoOwnerUsername",
        "repositoryName": "example-repo",
        "issueNumber": 42,
        "author": "user1"
      },
      "expectedOutput": "{function: 'command-query', parameters: {\"username\": \"user1\"}}"
    }
  ]
}

Yes,commandInvocation is supposed to be a commend, the parameters, are values that are given to the LLM, and the expectedOutput is what the LLM should output, in this case it would be a tool call.

[whilefoo]

Oh, I thought the expectedOutput was supposed to be the output from the plugin, and parameters are the tool call generated by the LLM.
Maybe we could change the name from parameters to issueContext, githubContext or just context, and expectedOutput to expectedToolCall, what do you think?

Is it important for expectedOutput to be a string instead of an object? Because it's easier to write an object than to deal with escape characters and it's more readable.

[shiv810]

Oh, I thought the expectedOutput was supposed to be the output from the plugin, and parameters are the tool call generated by the LLM. Maybe we could change the name from parameters to issueContext, githubContext or just context, and expectedOutput to expectedToolCall, what do you think?

That sounds good. These terms would function more as guiding examples, which could be included in the prompt to assist with generating the tool calls.

Is it important for expectedOutput to be a string instead of an object? Because it's easier to write an object than to deal with escape characters and it's more readable.

No, it can definitely be an object instead

[0x4007]

We follow the manifest standard so any property name that does not conform should be prefixed with ubiquity:

[shiv810]

Any QA we can demo with?

I am not sure how to QA this? Should I make some sample manifests?

[0x4007]

It would be ideal if you set up a kernel and we could interact with it with this upgraded behavior. Have you done this before?

[whilefoo]

We follow the manifest standard so any property name that does not conform should be prefixed with ubiquity:

We had a discussion with @gentlementlegen where we both agreed that following the standard so strictly is unnecessary for our use case as these are not browser extensions or PWAs. We are already breaking the standard because skipBotEvents, configuration and commands don't have the prefix.

[0x4007]

We follow the manifest standard so any property name that does not conform should be prefixed with ubiquity:

We had a discussion with @gentlementlegen where we both agreed that following the standard so strictly is unnecessary for our use case as these are not browser extensions or PWAs. We are already breaking the standard because skipBotEvents, configuration and commands don't have the prefix.

Its not hard to make the prefix. I don't see why not conforming to standards was the conclusion you guys came to, its not right.

[gentlementlegen]

Because we can but I do not really see the point as we can conform to our own standards, we are not making a manifest for a web app, it just makes names in the manifest longer for no reason so far.

[0x4007]

Following this logic there's little reason to follow any standards. It doesn't make sense why you decide this to be an exception especially if the trade off is fixable with a find and replace.