Astro orchestrator
Hub-and-spoke agent-skill clusters, one per stack (Astro·GSAP·Remotion, Tauri, …). Installable via skills.sh.
npx -y skills add Sheshiyer/skill-clusters --skill astro-orchestratorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Route an Astro task to the right spoke — building the site (components, islands/hydration, content, SSR, actions, i18n) or publishing a docs/wiki/press-kit site. USE WHEN working on an Astro project but the specific concern isn't named, or when deciding the rendering mode (static vs on-demand vs hybrid). For scroll/animation/video on an Astro page, hand off to the creative-frontend cluster.
SKILL.md
3.1 KB, 629 tokens by cl100k_base, as published. Nobody here has run it
Astro Orchestrator
Entry skill for Astro site work (the framework itself — not the animation layer). It picks
the rendering strategy and routes to the right spoke. The rendering-mode decision, content
model, and hydration rules live in astro-core; read it before choosing static vs SSR or
wiring content collections.
Cluster map (routing targets)
astro-core— rendering mode (static / on-demand SSR / hybrid + server islands), hydration directives, Content Layer & collections,astro:env+ sessions + actions, SSR adapter selection, view transitions.astro-framework— (shared with creative-frontend) the deep implementation skill: components, islands, hydration, Content Layer (glob/file/live loaders),server:defer, actions, i18n, SSR adapters, view transitions, React/Vue/Svelte/Solid integration.astro-wiki-publisher— publishing/hardening a docs/wiki/press-kit site: Markdown/MDX content, generated routes, copy QA, browser verification, Vercel/Cloudflare deploy.
Routing Rules by Intent
- Build the site (components, layouts, islands, content, actions, i18n, SSR) →
astro-framework(+astro-corefor the mode/content decision). - Choose how it renders (SSG vs on-demand SSR vs hybrid; should this piece be a server island?) →
astro-core, thenastro-framework. - Publish a docs / wiki / press-kit →
astro-wiki-publisher. - Add scroll effects / animation / embedded video → creative-frontend cluster (
astro-gsap-scrolltrigger,creative-frontend-orchestrator).
Standard Operating Flow
- Establish the rendering mode and content source from
astro-core(it shapes everything else). - Delegate build work to
astro-framework; publishing/QA toastro-wiki-publisher. - For motion on the page, redirect to the creative-frontend cluster.
- Return: rendering mode chosen, adapter (if SSR), content strategy, next action.
Guardrails
See astro-core. In short: ship static by default, opt into on-demand SSR only where you
need it (and add server islands for dynamic fragments inside static pages); keep islands minimal
and hydrate at the latest directive that works (client:visible/idle over load); validate
secrets through astro:env rather than raw import.meta.env on the server.
Loading spokes on demand
To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:
~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.