install
source · Clone the upstream repo
git clone https://github.com/Intense-Visions/harness-engineering
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/Intense-Visions/harness-engineering "$T" && mkdir -p ~/.claude/skills && cp -r "$T/agents/skills/codex/astro-integration-pattern" ~/.claude/skills/intense-visions-harness-engineering-astro-integration-pattern-c7ccad && rm -rf "$T"
manifest:
agents/skills/codex/astro-integration-pattern/SKILL.mdsource content
Astro Integration Pattern
Build or consume Astro integrations to extend the build pipeline — add renderers, inject routes, modify Vite config, and hook into build lifecycle events.
When to Use
- You are adding an official Astro integration (
,@astrojs/react
,@astrojs/tailwind
) to a project@astrojs/sitemap - You are writing a custom integration to encapsulate shared configuration across multiple Astro projects
- You need to inject a virtual route, a client-side script, or an additional Vite plugin
- You are authoring a third-party integration for the Astro ecosystem
- You want to understand what an integration's hooks are doing to debug build issues
Instructions
- Add official integrations in
using theastro.config.mjs
array. Call each integration as a function:integrations
// astro.config.mjs import { defineConfig } from 'astro/config'; import react from '@astrojs/react'; import tailwind from '@astrojs/tailwind'; import sitemap from '@astrojs/sitemap'; export default defineConfig({ site: 'https://example.com', integrations: [react(), tailwind({ applyBaseStyles: false }), sitemap()], });
- Create a custom integration as a plain function that returns an object with a
andname
:hooks
// my-integration.ts import type { AstroIntegration } from 'astro'; export function myIntegration(options: { debug?: boolean } = {}): AstroIntegration { return { name: 'my-integration', hooks: { 'astro:config:setup': ({ updateConfig, injectRoute, injectScript, addWatchFile, logger }) => { // Modify Vite config updateConfig({ vite: { plugins: [myVitePlugin()], define: { __DEBUG__: options.debug ?? false }, }, }); // Inject a virtual route injectRoute({ pattern: '/my-integration-page', entrypoint: './src/my-integration/page.astro', }); // Inject a script on every page injectScript('page', `console.log('Integration active');`); logger.info('My integration configured'); }, 'astro:build:done': ({ dir, routes, logger }) => { logger.info(`Build complete. ${routes.length} routes generated.`); }, }, }; }
- Use the correct hook for each type of work:
| Hook | When it runs | Common uses |
|---|---|---|
| Before build starts | , , , |
| After all integrations have modified config | Read the final resolved config |
| Dev server created | Add Vite dev server middleware |
| Dev server listening | Log the dev URL |
| Build starts | Initialize build-time resources |
| All pages/assets generated | Post-process output files, generate sitemaps |
- Add a custom renderer (for a new UI framework) with
insideaddRenderer()
:astro:config:setup
'astro:config:setup': ({ addRenderer }) => { addRenderer({ name: 'my-framework', serverEntrypoint: 'my-framework/server.js', clientEntrypoint: 'my-framework/client.js', jsxImportSource: 'my-framework', jsxTransformOptions: async () => ({ plugins: [['@babel/plugin-transform-react-jsx', { runtime: 'automatic' }]], }), }); }
- Use
to trigger HMR when config files outside the project root change:addWatchFile()
'astro:config:setup': ({ addWatchFile, config }) => { addWatchFile(new URL('./my-config.json', config.root)); }
- Read the user's final resolved Astro config in
— this is after all integrations have run and the config is finalized:astro:config:done
'astro:config:done': ({ config }) => { if (config.output === 'static') { // perform SSG-specific setup } }
- Export your integration alongside
indefineConfig
for colocation, or publish it as a separate npm package following theastro.config.mjs
naming convention.astro-*
Details
Astro integrations are the official extensibility mechanism. They are synchronous or async functions that hook into well-defined lifecycle points in the Astro build pipeline. Unlike Vite plugins (which are lower-level), Astro integrations have access to Astro-specific primitives like
injectRoute, addRenderer, and the Astro config object.
Integration execution order:
Integrations are executed in the order they appear in the
integrations array. Hook calls within each lifecycle event are also ordered. This matters when integrations modify shared config (e.g., Vite plugins) — later integrations see the changes made by earlier ones.
merging:updateConfig
updateConfig() does a deep merge with the existing config. Call it multiple times if needed — each call merges on top of the previous state. Be careful with arrays (like vite.plugins) — they are concatenated, not replaced.
and virtual modules:injectRoute
injectRoute adds a route to the Astro router backed by an actual file. For truly virtual content (generated at build time), pair it with a Vite virtual module plugin to serve the file from memory.
Integration API stability:
The
astro:config:setup and astro:build:done hooks are stable. Hooks prefixed with astro:server:* are available only in development. The full hooks API is documented in the Astro Integrations Reference.
Official integration patterns to study:
— minimal integration that generates files in@astrojs/sitemapastro:build:done
— adds a Vite plugin via@astrojs/tailwindupdateConfig
— uses@astrojs/react
plusaddRenderer
for JSX transformupdateConfig
Publishing guidelines:
Name your package
astro-<feature>. Add astro and astro-component to keywords in package.json. Export the integration as the default export. Add "astro" to peerDependencies.
Source
https://docs.astro.build/en/reference/integrations-reference
Process
- Read the instructions and examples in this document.
- Apply the patterns to your implementation, adapting to your specific context.
- Verify your implementation against the details and edge cases listed above.
Harness Integration
- Type: knowledge — this skill is a reference document, not a procedural workflow.
- No tools or state — consumed as context by other skills and agents.
Success Criteria
- The patterns described in this document are applied correctly in the implementation.
- Edge cases and anti-patterns listed in this document are avoided.