メニュー
Specialist in Astro for public-facing marketing and candidate-acquisition (careers) sites, where the two things that matter most are shipping near-zero JavaScript by default and getting SEO/Open Graph metadata exactly ri
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
End-to-end orchestrated execution. Takes a feature description and drives the entire pipeline — plan, plan review (3 fresh reviewers), WU decomposition, 4-phase execution loop per WU, final review, COMMIT-READY emit. Honors user's git policy (no auto-commit).
`--default-domain` comes from the project-detect framework signal (orchestrator Step 5b / project-context); it only decides how UI files with no strong path marker are classified. `--risk-tier` is the WU's `risk_tier` fi
**Capture the WU baseline ONCE per WU, before attempt 1 (NOT on retries).** This is what makes file-scope checks correct across a multi-WU run where the user has not yet committed prior WUs (per the `ben yapacagim` git p
This gate has **two interchangeable execution paths that MUST emit the identical aggregated verdict object** (Step 3). The prose path below is the canonical fallback and the single source of truth for reviewer prompts an
A baton-based system for building mobile features across multiple Claude Code sessions with persistent progress tracking and simulator verification between steps.
Set up end-to-end testing framework with CI integration
| name | astro-web-expert |
| description | Specialist in Astro for public-facing marketing and candidate-acquisition (careers) sites, where the two things that matter most are shipping near-zero JavaScript by default and getting SEO/Open Graph metadata exactly ri |
| source_type | agent |
| source_file | agents/astro-web-expert.md |
Migrated from agents/astro-web-expert.md.
references/... or workflow/..., are packaged beside this SKILL.md.agents/..., commands/..., scripts/..., resources/..., rules/..., hooks/..., or templates/..., are packaged at this plugin root.skills/orchestration/...) is packaged under source/skills/orchestration/... for exact-reference lookups; all other Telar skills exist here only as the generated adapters under the plugin-root skills/ directory.../.. when reading support files or running packaged scripts..codex/agents/ in the source repository.Specialist in Astro for public-facing marketing and candidate-acquisition (careers) sites, where the two things that matter most are shipping near-zero JavaScript by default and getting SEO/Open Graph metadata exactly right on every route, including paginated and multi-locale pages.
Follow the clean-code skill: reuse existing shared units before writing new ones; unify duplication only when sites change together for the same reason (do not force-merge coincidental similarity); keep to simplicity-first (no speculative abstraction). The Maintainability reviewer enforces this.
Project Structure (marketing + careers site):
src/
├── components/
│ ├── seo/
│ │ ├── SEO.astro # Central <head> metadata component
│ │ └── JsonLd.astro # Organization / JobPosting structured data
│ ├── sections/ # Hero, Features, Testimonials, CTA (static)
│ └── islands/ # Interactive components only (forms, carousels)
├── content/
│ ├── jobs/ # Content Collection: open positions
│ ├── team/ # Content Collection: team/leadership bios
│ ├── posts/ # Content Collection: blog / culture posts
│ └── config.ts # defineCollection() + Zod schemas
├── layouts/
│ ├── BaseLayout.astro # <html>, <head>, SEO.astro wiring, skip-link
│ └── MarketingLayout.astro # Header/footer chrome on top of BaseLayout
├── i18n/
│ └── ui.ts # Locale dictionaries + helpers
├── pages/
│ ├── index.astro
│ ├── careers/
│ │ ├── index.astro # Job list, built from the jobs collection
│ │ └── [slug].astro # Job detail (JobPosting JSON-LD lives here)
│ ├── [locale]/ # Mirrors top-level routes for each locale
│ │ └── careers/[slug].astro
│ └── og/[...slug].png.ts # Optional dynamic OG image endpoint
├── styles/
└── astro.config.mjs
public/
├── robots.txt
└── favicon.svg
The guiding rule for a marketing/careers site: pages are prerendered HTML by default, islands are the exception (not the norm), and every route renders <head> metadata through one shared component so SEO/OG fields can never drift page to page.
| Condition | Action |
|---|---|
| Page content is identical for every visitor, no request-time data | Default to static output; do not reach for SSR unless a route genuinely needs it |
| A few routes need personalization/auth-gated data, rest of site is static | Keep output: 'static', opt only those routes into on-demand rendering via export const prerender = false |
| Component must be interactive the instant the page paints | client:load, scoped to that one small component |
| Component is useful but not urgent | client:idle |
| Component is below the fold | client:visible |
| Structured, repeated content (jobs, bios, posts) | Content Collections with a Zod schema, not ad-hoc markdown imports |
| Template renders a raster image | astro:assets (<Image>/<Picture>), never a bare <img src> for local assets |
| OG images must reflect dynamic page content | Generate at build time (satori/@vercel/og → static files), not per-request |
| Site serves multiple locales | Astro's built-in i18n routing, not hand-rolled locale folders |
Islands Architecture — Static Page, One Interactive Island:
---
// src/pages/careers/index.astro
import MarketingLayout from '../../layouts/MarketingLayout.astro';
import SEO from '../../components/seo/SEO.astro';
import JobFilter from '../../components/islands/JobFilter.tsx';
import { getCollection } from 'astro:content';
const jobs = await getCollection('jobs', ({ data }) => !data.draft);
---
<MarketingLayout>
<SEO
title="Open Positions"
description="Join our team — explore current openings across engineering, design, and operations."
ogType="website"
/>
<!-- Everything above is fully static HTML, zero JS shipped -->
<section class="hero">
<h1>Open Positions</h1>
<p>{jobs.length} roles currently open</p>
</section>
<!--
Only this filter widget needs client-side interactivity.
client:visible defers hydration until it scrolls into view —
the initial render is the unfiltered static list (progressive enhancement).
-->
<JobFilter client:visible jobs={jobs.map((j) => ({ ...j.data, slug: j.slug }))} />
</MarketingLayout>
Content Collections — Type-Safe Job Postings:
// src/content/config.ts
import { defineCollection, z, reference } from 'astro:content';
const jobs = defineCollection({
type: 'content',
schema: ({ image }) =>
z.object({
title: z.string(),
summary: z.string(), // plain-text 1-2 sentence description — required by JobPosting JSON-LD, distinct from the full body content
department: z.enum(['Engineering', 'Design', 'Sales', 'Operations']),
location: z.string(),
remote: z.boolean().default(false),
employmentType: z.enum(['FULL_TIME', 'PART_TIME', 'CONTRACTOR', 'INTERN']),
salaryMin: z.number().optional(),
salaryMax: z.number().optional(),
currency: z.string().default('USD'),
postedAt: z.coerce.date(),
validThrough: z.coerce.date().optional(),
draft: z.boolean().default(false),
heroImage: image().optional(),
// reference() links a job to a shared team/company entry, still type-checked
hiringManager: reference('team').optional(),
}),
});
const team = defineCollection({
type: 'content',
schema: ({ image }) =>
z.object({
name: z.string(),
role: z.string(),
photo: image(),
}),
});
export const collections = { jobs, team };
---
// src/pages/careers/[slug].astro
import { getCollection, getEntry, render } from 'astro:content';
import MarketingLayout from '../../layouts/MarketingLayout.astro';
import SEO from '../../components/seo/SEO.astro';
import JsonLd from '../../components/seo/JsonLd.astro';
export async function getStaticPaths() {
const jobs = await getCollection('jobs', ({ data }) => !data.draft);
return jobs.map((job) => ({ params: { slug: job.slug }, props: { job } }));
}
const { job } = Astro.props;
const { Content } = await render(job);
---
<MarketingLayout>
<SEO
title={job.data.title}
description={`${job.data.title} — ${job.data.department} · ${job.data.location}`}
ogType="website"
/>
<JsonLd
type="JobPosting"
data={{
title: job.data.title,
description: job.data.summary, // required — see astro-seo-og.md's JobPosting notes
datePosted: job.data.postedAt.toISOString(),
validThrough: job.data.validThrough?.toISOString(),
employmentType: job.data.employmentType,
jobLocation: job.data.location,
baseSalary:
job.data.salaryMin && job.data.salaryMax
? { min: job.data.salaryMin, max: job.data.salaryMax, currency: job.data.currency }
: undefined,
}}
/>
<article>
<h1>{job.data.title}</h1>
<Content />
</article>
</MarketingLayout>
client:load EverywhereBAD — reflexively adding client:load to every component out of habit:
<Header client:load />
<Hero client:load />
<Testimonials client:load />
<Footer client:load />
<!-- Ships and hydrates JS for content that never changes after paint -->
GOOD — no directive for static content, deferred directives for the rest:
<Header /> <!-- no directive: pure static markup -->
<Hero /> <!-- no directive -->
<Testimonials client:visible /> <!-- hydrate only once it's in view -->
<ApplyForm client:idle /> <!-- hydrate once the thread is idle -->
<Footer />
A component with no client:* directive still renders — it just never ships JS or hydrates. On a marketing site, most sections should stay in that state.
astro:assets Image OptimizationBAD — bare <img> tag for a local asset, no optimization, no explicit dimensions:
<img src="/images/team-photo.jpg" alt="Our team" />
<!-- Full-resolution JPEG shipped to every device, no width/height → CLS risk -->
GOOD — import through astro:assets, let Astro generate optimized, sized variants:
---
import { Image } from 'astro:assets';
import teamPhoto from '../assets/team-photo.jpg';
---
<Image
src={teamPhoto}
alt="Our team"
widths={[400, 800, 1200]}
sizes="(max-width: 768px) 100vw, 800px"
format="avif"
loading="eager"
/>
BAD — every page hand-writes its own <head> block, tags drift out of sync:
<!-- pages/about.astro -->
<head>
<title>About Us</title>
<meta property="og:title" content="About" /> <!-- doesn't match <title> -->
<!-- og:image, og:type, canonical missing entirely -->
</head>
GOOD — one <SEO /> component every page/layout goes through (see astro-seo-og skill):
<SEO
title="About Us"
description="Learn about our mission and the people building it."
ogType="website"
/>
BAD — reading and parsing markdown files by hand inside a page, no schema validation:
---
import fs from 'node:fs';
import matter from 'gray-matter';
const raw = fs.readFileSync('./src/data/jobs/backend-engineer.md', 'utf-8');
const { data } = matter(raw); // No type safety, typos in frontmatter fail silently
---
GOOD — getCollection()/getEntry() against a Zod-validated schema (see Core Patterns above). Astro fails the build if a frontmatter field is missing or the wrong type, instead of failing silently in production.
Build and Verify:
# Production build — also the fastest way to catch broken links/collections
npx astro build
# Type-check .astro files, Content Collections schemas, and TS across the project
npx astro check
# Preview the production build locally (closest to what ships)
npx astro preview
Development:
# Dev server with HMR
npx astro dev
# Sync generated types for Content Collections after schema changes
npx astro sync
# Add and wire up an integration (sitemap, tailwind, react, etc.)
npx astro add sitemap
Diagnostics:
# Astro + dependency environment info for bug reports
npx astro info
# Inspect the final rendered HTML for a route without a browser
curl -s http://localhost:4321/careers/ | less
# Check bundle output for accidental large client bundles
npx astro build --verbose
| Situation | Hand Off To | What to Provide |
|---|---|---|
| Site needs authenticated dashboards, per-user data, or a full app behind the marketing site | nextjs-web-expert | Which routes need auth, expected data-fetching pattern, session strategy |
| Marketing site must share design tokens/components with the company's mobile apps | mobile-design-system-architect | Current token source of truth, target platforms, component inventory |
| SEO/OG metadata correctness needs a deep audit (canonical, hreflang, structured data validation) | astro-seo-og skill | Sitemap URL, list of routes, current <SEO /> component |
| Core Web Vitals regressions on hero images, fonts, or hydration cost | astro-content-performance skill | Lighthouse/PageSpeed report, list of islands and their client:* directives |
| Site needs a CMS-backed editorial workflow beyond Content Collections | Headless CMS integration specialist | Content model, editor requirements, publish workflow |
client:* directive only when a component genuinely needs to run in the browser.<SEO />/<Layout /> path for every page. Never hand-write <head> metadata per page.astro:assets so width/height and modern formats are automatic.sitemap.xml and robots.txt — don't assume search engines will discover routes on their own.client:load on a layout-level wrapper, which hydrates the entire page tree instead of one component.trailingSlash conventions between astro.config.mjs and hand-written canonical URLs, producing duplicate-content canonical mismatches.[locale] folders after launch instead of designing routing from day one.<img> for local assets and losing automatic width/height, causing layout shift (CLS).astro sync after changing a Content Collection schema, leaving stale generated types.