agentsclimarketplace

Astro orchestrator

Skill Sheshiyer/skill-clusters/skills/astro-orchestrator

Hub-and-spoke agent-skill clusters, one per stack (Astro·GSAP·Remotion, Tauri, …). Installable via skills.sh.

Install
npx -y skills add Sheshiyer/skill-clusters --skill astro-orchestrator

Assembled 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-core for the mode/content decision).
  • Choose how it renders (SSG vs on-demand SSR vs hybrid; should this piece be a server island?) → astro-core, then astro-framework.
  • Publish a docs / wiki / press-kitastro-wiki-publisher.
  • Add scroll effects / animation / embedded videocreative-frontend cluster (astro-gsap-scrolltrigger, creative-frontend-orchestrator).

Standard Operating Flow

  1. Establish the rendering mode and content source from astro-core (it shapes everything else).
  2. Delegate build work to astro-framework; publishing/QA to astro-wiki-publisher.
  3. For motion on the page, redirect to the creative-frontend cluster.
  4. 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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.