I noticed that a recent ColdBox CLI change consolidated all AI skills into a single .agents/skills/ folder. Previously, the generated structure separated skills into folders like core, custom, and overrides.
I understand the goal of simplifying the structure, and I agree that the separate overrides folder may not be necessary. That concept could probably be handled under custom. However, I think there is still a strong practical reason to keep a clear separation between framework-provided skills and project-authored skills.
The main issue is source control.
The core ColdBox skills feel more like generated framework dependencies. Since they can be regenerated or updated by the CLI, I would generally want to ignore those in .gitignore. But any custom skills I create for my specific application are part of my project and should be committed.
When all skills live directly in .agents/skills/, it becomes much harder to distinguish:
.agents/skills/
coldbox-core-skill
another-framework-skill
my-custom-project-skill
my-other-custom-skill
Previously, the folder structure made this much easier to manage:
.agents/skills/core/
.agents/skills/custom/
.agents/skills/overrides/
That allowed a .gitignore strategy like this:
# Ignore everything under .agents by default
.agents/**
# Keep the root folder and manifest
!.agents/
!.agents/manifest.json
# Keep project-authored guidelines
!.agents/guidelines/
!.agents/guidelines/custom/
!.agents/guidelines/custom/**
!.agents/guidelines/overrides/
!.agents/guidelines/overrides/**
# Keep project-authored skills
!.agents/skills/
!.agents/skills/custom/
!.agents/skills/custom/**
!.agents/skills/overrides/
!.agents/skills/overrides/**
My suggestion would be to restore a subfolder structure for skills, similar to how .agents/guidelines works. For example:
.agents/skills/core/
.agents/skills/custom/
I do not feel strongly about keeping overrides as a separate folder. I think custom is probably enough. The key point is that project-authored skills should have a predictable location that can be safely committed, while generated ColdBox/framework skills can be ignored.
Would you consider reverting the skills consolidation or updating the manifest structure to support separate skill folders again?
Thanks for all the work on this. I really like the direction of the Agentic ColdBox tooling. I just think this small folder distinction would make the generated structure easier to manage in real-world projects.
I noticed that a recent ColdBox CLI change consolidated all AI skills into a single .agents/skills/ folder. Previously, the generated structure separated skills into folders like
core,custom, andoverrides.I understand the goal of simplifying the structure, and I agree that the separate
overridesfolder may not be necessary. That concept could probably be handled undercustom. However, I think there is still a strong practical reason to keep a clear separation between framework-provided skills and project-authored skills.The main issue is source control.
The core ColdBox skills feel more like generated framework dependencies. Since they can be regenerated or updated by the CLI, I would generally want to ignore those in
.gitignore. But any custom skills I create for my specific application are part of my project and should be committed.When all skills live directly in
.agents/skills/, it becomes much harder to distinguish:Previously, the folder structure made this much easier to manage:
That allowed a .gitignore strategy like this:
My suggestion would be to restore a subfolder structure for skills, similar to how .agents/guidelines works. For example:
I do not feel strongly about keeping
overridesas a separate folder. I think custom is probably enough. The key point is that project-authored skills should have a predictable location that can be safely committed, while generated ColdBox/framework skills can be ignored.Would you consider reverting the skills consolidation or updating the manifest structure to support separate skill folders again?
Thanks for all the work on this. I really like the direction of the Agentic ColdBox tooling. I just think this small folder distinction would make the generated structure easier to manage in real-world projects.