Repository navigation
Split reference build guides - #34
Conversation
| the table below. | ||
| - If more than one matches (e.g. a CMake project with a `package.json` for | ||
| tooling), ask the user which build is the reference. | ||
| - If none match, stop and tell the user the build system isn't supported. |
There was a problem hiding this comment.
I wonder whether a one-shot agent will obey this rule. Armando, have you tried this version of the skill with your msbuild experiments? When I run gradle experiments, if the agents don't blow past this rule, I might soften it.
There was a problem hiding this comment.
Just tested, it does stop things pretty quickly from my first few tests. I agree that this isn't the best user (agent?) experience. I've tweaked it to ask the user if we should first add a new frontend using the current project as a case study. Some languages (like JS/TS) conceptually conflict with the main approach, but other build systems like gn and anything that spits out ninja build files should map nicely.
If we let things migrate without explicitly standing up a frontend, this is basically just a collection of text prompts for the agent. Mildly useful, but not the most compelling.
Instead of putting all reference builds into the main skill, add a dedicated initial phase for determining the reference build flavor so additional supporting context can get pulled in as needed (rather than all at once). This is particularly helpful for less powerful agents that can get confused with the entirely unrelated context.
cd0d28d to
bf62b38
Compare
2 participants
Instead of putting all reference builds into the main skill, add a dedicated initial phase for determining the reference build flavor so additional supporting context can get pulled in as needed (rather than all at once).
This is particularly helpful for less powerful agents that can get confused with the entirely unrelated context.