Plugin philosophy

[yaroslavyaroslav]

Who is target audience of such plugin

1. Researchers
2. Developers
3. Analysts

What is its kay value

1. Convenience way to get an AI assistance during they work [development|research|analysis].

What're ways to provide that value

1. Well designed and defined UX (not how it looks, but how it goes).
2. Tighter integration between a users code base (the context) and assistant model (the intelligence core).
3. Flexibility — it shouldn't ends as a single golden path tool for whatever target audience, thus it shouldn't limit an AI assistant capabilities on its side.

What's this exactly means

Well designed UX

It's not an option to expand a feature list without a deep understanding of the problem that it solves beforehand. This tool are so easy to fall into Nero CD burn one.

Tighter integration between user code base and assistant

If a ST provides a way to follow a model with an additional context one should be provided implicitly.

E.g.: user should be relieved from an obligation to specify in assistant setup its programming language, the frameworks the one uses within a project and inherited code definition to pass separately — there's the plugin for that.

Flexibility

AI assistant is a universal tool, like an iPhone or a PC, so it's capable to provide such assistance in really broad fields of knowledge, and the plugin should be so. There's shouldn't be made any decisions that are approaching one single use AI assistance use case, i.e. for a python development or for a specific area of knowledge support.

So the languages should be supported in their widest range, plugin shouldn't limit the intelligence power a given AI assistant in a way that provides a tool to gain a result for a very specific task, let's say for just a python, in contrast it should pass that limitations through to either ST or third-parties utilities or standards boundaries. In short the plugin should be invisible in terms of introducing new restrictions or limitations to a AI assistant.

Features list

The outcome from all of the above as the concrete features:

1. To get language from a ST implicitly from the scope name. This would allows to release such specification from an assistant settings.
2. To get imports list from an active file (pass the beginning of a file until 2 sequential line breakes)
3. To get function definition/documentation by lsp on a selected text, to release user from an obligation to provide copy paste all of that to Assistant manually for sake of additional context.
4. To provide an ability to bind custom user defined commands to a hotkeys or to add then as a separate commands in command palette. (i.e. text corrector, json formatter etc.)