Hello, Grist community. I wanted to ask you if you have any Kills documents written for Grist. I found out that there is a very common use case for this because many of us use AI-assisted coding and there are ways to approach the tools that are specific to the tool itself.
In the case of Grist, in order to develop widgets, for example, you need to be mindful of the architecture, the lifecycle of a widget, the reactivity of it, and other stuff that might be relevant. And it would be good to have this synthesized in a skill that can be loaded in an agent, so these agents are better suited to support the coders in developing widgets.
So I wonder if any one of you have worked on this or there’s any use case for this. In particular, my inspiration is Marimo Notebooks. They have developed a skills GitHub repository that I link here below.
Yes we have been thinking about it and we are doing some experiments around this topic, but this is still too early to share with wider audience.
The hard part is actually validating those skill against different coding agents, different models, and having some skills that will assist as with reviewing the code that it produces.
If you have some experience with it we are open to any suggestions or PR’s in grist-core or grist-widget repository.
Personally I’m using those skills that I generated for myself to do those experiments and validate them against grist code base, feel free to check them out and give any feedback. I use it with claude code agent. They are not widget specific, but I’m planning to add those too.
It is nice to see that this is a path that you are exploring, and that you are doing the steps required to get a solid tool before you disseminate this with a wider audience.
I notice that the skills you wrote are mainly focused on backend grist development (both ui and grainjs). This will certainly serve Grist-core contributors on their journey to maintain and improve Grist.
What I was thinking was whether anyone was working on developing plugin skills. The skill should describe the plugin lifecycle, what are the best practices, what to avoid, some examples of what’s possible, how to interact with other parts of the system, the underlying schemas so the AI can draw from its training data the needed elements, etc.
I hope you get to do this, as it would lower the barrier for contributions, and would improve the quality of those that are done.
Also only slightly related to what you’re asking: I’ve had some success with using opencode + the grist API + a “suggesting” fork of my main grist doc (my API token was from a user that only has read+fork access to my main doc, so there was no danger of it going haywire and deleting all of my stuff). This allowed me to review its changes before merging into my main doc (there are still some rough edges there, but I think the approach shows promise). If this approach becomes popular, it would be interesting to see if a “suggesting only” API token could be made, that can only fork documents and make changes to forks. This would avoid the need for creating a pair of users like I have in my setup.
I did the whole thing within the grist repo, so I didn’t need to tell it what the grist API looked like. If someone writes a skill for grist API usage, it should probably point at the API schema, so that it can be used from anywhere.
I also reviewed every curl request that was made, because I didn’t want to abuse the grist free tier offering. I’ve now seen that the free tier has 5k API calls per doc per day, and pro has 40k, so maybe I should have just let it go nuts and upgraded to paid if I hit the limit.
