[Q&A] How to use bundles correctly?

[Roebou1989]

What kind of help do you need?

Choosing the right skills

Your question

I have seen mentions of bundles, but is it not perhaps possible to use a specific bundle - i.e. "Essentials" or "Web Wizard" so that it uses all of the skills within those bundles (or whichever of them might be needed) instead of calling each skill one by one and having a discussion only with that skill? I can see that I have access to /brainstorming for example, but not access to /essentials-bundle or something to this extend.

Interested to hear your thoughts on this.

Environment and context

No response

What have you already tried?

• Read the docs

Before posting

• I checked the README, FAQ, and relevant docs first.

[sickn33]

Good question. The short answer is: bundles are not first-class “mega-skills” by default.

So today:

• Essentials, Web Wizard, etc. are curated lists of recommended skills
• they help you choose a good starting set
• they are not normally invoked as /essentials-bundle or @web-wizard

That is why you can access @brainstorming, but not something like /essentials-bundle.

The intended usage is:

1. install the repo once
2. pick a bundle from docs/users/bundles.md
3. use the individual skills from that bundle in your prompts

Example:

• Use @brainstorming to scope this feature
• Then apply @react-best-practices to the component structure
• Then run @lint-and-validate

That said, there is one practical way to use bundles more like an active subset: the activation scripts.
They can materialize only the skills from a chosen bundle into the live Antigravity directory, which is especially useful if you want a smaller focused set active at once.

Examples:

• macOS/Linux: ./scripts/activate-skills.sh --clear Essentials
• macOS/Linux: ./scripts/activate-skills.sh --clear "Web Wizard"
• Windows: .\scripts\activate-skills.bat --clear Essentials

So the distinction is:

• bundle as documentation/editorial guidance: pick skills from it manually
• bundle as active subset: use the activation scripts to expose only that bundle’s skills

What bundles do not currently do is act like an automatic router that silently calls any skill inside the bundle on your behalf. If we ever add that, it would be a separate orchestration layer rather than the current bundle system.

If helpful, I can also add a short note to the docs clarifying “bundles vs invokable skills vs activation scripts,” because you’re definitely not the first person to read it this way.

[Roebou1989]

Thanks for the detailed write-up. I think a note would be very beneficial.

It would also be very interesting to see how a separate orchestration component could go about and handle the skills for that specific bundle. I think a lot of users at this stage are new to tech as well, so they might not fully know when to use which item or they might think they do not really need it, but actually it was essential for them to have the skill review their work.

Keen to see where this journey goes, thanks for all your efforts, I find the repo extremely useful and comparing what this outputs versus a vanilla GenAI is worlds apart. Keep up the good work!

[sickn33]

@thepeanutgalleryandco thanks, I really appreciate that.

I agree with your read: for many newer users, the biggest gap is not the individual skill quality, but knowing when a skill should be pulled in and when a review/check skill is still worth using even if the user did not think to ask for it explicitly.

That is exactly why I think we should make the docs clearer in three layers:

1. bundles = curated discovery / active subset
2. skills = the actual invokable units
3. orchestration = a separate routing layer, not the same thing as bundles

And yes, a lightweight orchestration layer on top of a manifest/index is the direction that makes the most sense to explore, especially for beginner-friendly flows. The important constraint is that it should route and lazy-load, not preload the whole library and recreate the same overload problems.

I will likely add a short clarifying note in the docs around this distinction, because this confusion keeps coming up and it is a very reasonable interpretation from a user point of view.

Thanks again for the thoughtful feedback and for the kind words.