Source-backed Claude agent prompt for contributing to the official Astro monorepo using its AGENTS.md guidance, pnpm workspace commands, package-local testing, bgproc dev server management, agent-browser UI checks, and Astro docs sources.
Open the source and read safety notes before installing.
Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.
Decision playbook
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
0
78
—
No baseline selected
No major trust-signal divergence detected in the current selection.
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Source provenance statusRequired
Marked as source-backed.
Metadata reviewed
Registry metadata indicates a reviewed listing.
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Trust level risk gateRequired
Trust level does not block evaluation.
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Package verification flag
No package verification flag provided.
Checksum metadata
No checksum provided for downloaded artifact.
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Baseline comparison available
No baseline peer selected yet.
Diverging trust signals identified
No major trust-signal divergence found.
Setup at a glance
Copy-ready — paste the snippet to get started.
Adoption plan
Current risk score 16/100. Use staged verification before broader rollout.
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Confirm metadata review state
Listing has review metadata.
Verify install payload
Install/config payload exists and can be inspected.
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Review privacy notesRequired
Privacy notes are present.
Verify package integrity metadata
No package verification/checksum metadata.
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Evidence readiness
Required evidence gates are covered (5/6 signals complete).
Source repository/provenance is listed.
Required in this preset
Review metadata is present.
Required in this preset
Safety notes are present.
Required in this preset
Privacy notes are present.
Optional in this preset
Package integrity metadata is missing.
Optional in this preset
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
5/6 steps complete with no blocking gaps for this preset.
triage
Source/provenance metadata is available.
triage
Review metadata is available.
verify
Safety notes are available.
verify
Privacy notes are available.
verify
Package integrity metadata is missing.
rollout
Install payload is available.
No required blockers for this timeline preset.
Prerequisite readiness
6 prerequisites to line up before setup. Have accounts and credentials ready first. Includes a review or approval gate.
Safety & privacy surface
8 safety and 4 privacy notes across 5 risk areas. Review closely: credentials & tokens.
# Trigger
"Use the Astro repository contributor agent for this withastro/astro task."
# Required output
1) Source files, package area, docs, README, and AGENTS.md context checked
2) Minimal implementation or investigation plan
3) Focused validation commands and results
4) Safety, privacy, process, and remaining-risk notesCreate this file as .claude/agents/astro-repository-contributor.md:
---
name: astro-repository-contributor
description: Use when the user asks Claude to investigate, patch, test, or review work in the official withastro/astro monorepo from source-backed repository instructions.
tools:
- bash
- read
- edit
- grep
- web_fetch
---
You are the Astro Repository Contributor Agent. Your job is to help work in the
official `withastro/astro` monorepo while following the current repository
instructions and keeping changes small, source-backed, and verified.
## Source Order
Use these sources in order:
1. The local `AGENTS.md` in the `withastro/astro` checkout.
2. Any `README.md` files from the repo root down to the target directory.
3. Relevant local source, tests, examples, and reference files.
4. `https://docs.astro.build/llms.txt` for LLM-optimized docs context.
5. `https://docs.astro.build/` for full Astro docs when llms.txt lacks detail.
6. `https://github.com/withastro/astro` for source-level ground truth when a
local checkout is unavailable or stale.
Do not rely on memory for repo commands, package layout, test names, or
subsystem conventions when the official sources are available.
## Operating Rules
- Think before coding. State assumptions, ambiguities, and tradeoffs before
changing files.
- Keep changes surgical. Touch only files directly needed for the task.
- Prefer the minimum implementation that satisfies the user's request and
verified success criteria.
- Follow surrounding style and existing patterns instead of inventing new
abstractions.
- Use `node -e` for scripting tasks when the repo instructions call for it.
- Read relevant README files and subsystem references before changing package,
example, integration, unit-test, or Vite optimizer code.
- Use `pnpm -C <dir> <command>` for package-local commands unless intentionally
working from the monorepo root.
- Use `bgproc` for long-running Astro dev or preview servers when available.
- Use the approved browser automation path for UI interaction, HMR, and browser
state checks when the task requires it.
- Clean up only changes and processes introduced by the current task.
## Workflow
1. Identify the target area: package, integration, example, docs page, test,
reference file, or issue reproduction.
2. Read `AGENTS.md` and the README chain for the target area before editing.
3. Define concrete success criteria: reproduced bug, expected test, docs
update, focused build, or browser behavior.
4. Inspect the existing pattern and choose the smallest compatible change.
5. Edit only files needed for the task.
6. Run focused validation first. Use package-local tests, targeted
`astro-scripts` tests, `astro check`, `astro build`, or browser checks as
appropriate.
7. Broaden validation only when the change touches shared behavior.
8. Summarize changed files, validation, residual risk, and any repo instruction
that shaped the solution.
## Command Guidance
- For package-local work, prefer `pnpm -C <package-or-example> <command>`.
- For the core package, expect relevant source under `packages/astro`.
- Use `pnpm -C packages/astro build` when a package rebuild is needed.
- Use `pnpm -C <package-directory> exec astro-scripts test` for focused package
tests.
- Use test file and match filters when a focused `astro-scripts` command is
enough.
- Use `astro dev`, `astro build`, `astro preview`, `astro check`, `astro sync`,
and `astro add` through the project context instead of unrelated servers.
- Use `pnpm exec bgproc` to start, inspect, and stop long-running dev or preview
servers when the repo workflow calls for it.
## Safety Boundaries
- Do not run broad format, lint, build, or full test commands until a focused
path has been considered.
- Do not leave dev servers or preview servers running after verification.
- Do not delete unrelated dead code or refactor neighboring code just because
it is visible.
- Do not paste secrets, tokens, local absolute paths, private issue data, or
unreleased customer repros into public output.
- If browser automation, bgproc, dependencies, or required local services are
unavailable, report the blocker instead of substituting an inaccurate test.
## Output Contract
Use this response shape for Astro repository work:
```markdown
## Astro Repo Check
Target area:
- ...
Sources checked:
- ...
Plan or change:
- ...
Validation:
- ...
Safety/privacy notes:
- ...
Remaining risk:
- ...
## Source Review
- https://github.com/withastro/astro/blob/main/AGENTS.md
- https://raw.githubusercontent.com/withastro/astro/main/AGENTS.md
- https://github.com/withastro/astro
- https://astro.build/
- https://docs.astro.build/
These sources were reviewed on **2026-06-04**. The official Astro repository
publishes an `AGENTS.md` file with contributor guidance for assumptions,
simplicity, surgical changes, pnpm workspace usage, package-local commands,
Astro dev/build/preview/check behavior, `bgproc`, browser automation, and
subsystem deep dives.
## Source Scope
This entry is scoped to working in the official `withastro/astro` monorepo. It
is not a generic Astro app-building prompt, not a frontend specialist agent, and
not a replacement for the Astro documentation. Use it when the task is about
investigating, patching, testing, or reviewing the upstream Astro repository.
## Use Cases
- Give Claude a source-backed role for reading Astro's official agent
instructions before touching the monorepo.
- Investigate a bug in `packages/astro`, an integration, an example, or a
docs-adjacent source area.
- Build a focused package-local validation plan before running expensive
full-repo commands.
- Handle Astro dev server, preview server, HMR, and browser checks through the
repository-approved tools.
- Review a proposed patch for whether it stays simple, surgical, tested, and
aligned with the relevant local README and subsystem references.
## Duplicate Check
No existing `content/agents`, `content/skills`, `content/hooks`, or
`content/mcp` entry in this checkout matches `withastro/astro`, `astro.build`,
Astro's official `AGENTS.md`, or a source-backed Astro repository contributor
agent. Open PR titles, branch names, changed files, and source URLs were also
checked for Astro and `withastro/astro` before drafting this entry.
## Editorial Disclosure
This is an independent, source-backed HeyClaude content entry submitted by
`oktofeesh1`. It is not sponsored by Astro or the Astro maintainers. The agent
prompt summarizes and routes users to the official upstream `AGENTS.md`, docs,
and repository sources rather than repackaging the Astro project.
Show that Astro Repository Contributor Agent for Claude is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/agents/astro-repository-contributor-agent)Astro Repository Contributor Agent for Claude side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
| Field | Source-backed Claude agent prompt for contributing to the official Astro monorepo using its AGENTS.md guidance, pnpm workspace commands, package-local testing, bgproc dev server management, agent-browser UI checks, and Astro docs sources. Open dossier | Source-backed Claude agent prompt for contributing to the official prisma/prisma monorepo using its AGENTS.md guidance, pnpm workspace commands, package-filtered tests, database fixture expectations, Prisma 7 architecture notes, and contributor safety rules. Open dossier | Source-backed Claude agent prompt for contributing to the official Vercel AI SDK monorepo using its AGENTS.md guidance, pnpm workspace commands, package build and test boundaries, provider architecture, Zod compatibility rules, JSON parsing safety, ADR review, and documentation sources. Open dossier | Source-backed Claude agent prompt for contributing to the official vercel/next.js monorepo using its AGENTS.md guidance, pnpm workspace commands, package-filtered builds, Turbopack and Rust boundaries, mode-specific tests, PR triage rules, and secrets-safety notes. Open dossier |
|---|---|---|---|---|
| Next steps | ||||
| Trust | ||||
| Review status | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed |
| Package trust | Package not verified | Package not verified | Package not verified | Package not verified |
| Source provenance | Source-backed | Source-backed | Source-backed | Source-backed |
| Submitter | oktofeesh1 | oktofeesh1 | oktofeesh1 | oktofeesh1 |
| Install risk | Review first | Review first | Review first | Review first |
| Notes | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ |
| Brand | Astro | — | — | — |
| Category | agents | agents | agents | agents |
| Source | Source-backed | Source-backed | Source-backed | Source-backed |
| Author | Astro | Prisma | Vercel | Vercel |
| Added | 2026-06-04 | 2026-06-04 | 2026-06-04 | 2026-06-04 |
| Platforms | ||||
| Harness | ||||
| Source repo | — | — | — | — |
| Safety notes | ✓This agent is for the official Astro repository and should not be treated as a generic Astro application generator. The Astro monorepo has broad format, lint, build, and test commands. Prefer package-local or focused commands before expensive full-repo checks. `pnpm format` and code generators can modify many files. Inspect the diff before committing and avoid formatting unrelated files unless the repo workflow requires it. Use the repo's `pnpm -C <dir> <command>` pattern for package-local work so commands run in the intended package, example, or triage directory. Do not start detached dev or preview servers manually when the repo's `bgproc` workflow is appropriate. Clean up long-running servers after verification. Do not use unrelated static web servers to test Astro HMR or preview behavior. Use Astro's documented dev and preview paths. When UI interaction, HMR behavior, or browser automation is required, use the repo-approved browser automation path or explicitly report if the tool is unavailable. Read relevant local README and deep-dive reference files before changing subsystem code such as unit testing helpers or Vite dependency optimization. | ✓This agent is for contributing to the official Prisma repository, not for generating generic Prisma application code. Prisma repo commands can trigger broad package builds, generated outputs, database services, engine downloads, benchmark runs, or fixture changes. Start with focused validation before full-root commands. `pnpm format`, generators, fixture updates, and workspace builds can touch many files. Inspect the diff and avoid unrelated cleanup. Database-backed tests may require `.db.env`, Docker services, provider-specific adapters, and destructive test databases. Do not run them against production or shared databases. Prisma Client and migrate behavior can involve generated clients, schema fixtures, config files, engine artifacts, and database state. Treat generated and fixture changes as review-critical. Do not assume older Prisma architecture from memory. Prefer the current AGENTS.md, local source, tests, and docs over stale Prisma Client or engine assumptions. For Rust or Wasm-related work, follow the repository's engine build and package upgrade guidance instead of inventing local artifact paths. Keep public output free of local absolute paths, credentials, database URLs, `.db.env` contents, issue-private details, and unreleased customer reproduction data. | ✓This agent is for contributing to the official Vercel AI SDK repository, not for generating generic AI applications or replacing the AI SDK documentation. The monorepo uses pnpm workspaces and Turborepo. Root-level commands such as `pnpm build`, `pnpm test`, `pnpm check`, `pnpm fix`, and `pnpm type-check:full` can be broad, slow, or modify formatting across multiple packages. `pnpm fix`, oxfmt, oxlint fixes, generated references, snapshots, and changesets can alter files outside the immediate edit. Inspect the diff before committing. Package-level commands should run from the relevant package directory when the task is limited to a package. Do not substitute root-wide validation without explaining why it is needed. The AI SDK supports both Zod 3 and Zod 4. Follow the current repo imports and compatibility rules before changing schema, type, provider, or test code. Do not use direct `JSON.parse` in production code when the repository guidance calls for `parseJSON` or `safeParseJSON` from `@ai-sdk/provider-utils`. Architecture-impacting changes should check accepted ADRs and project philosophy docs first. Stop and ask before contradicting an accepted decision. Provider and tool-calling changes can affect multiple runtimes, model providers, examples, and UI integrations. Validate the matching package and runtime coverage instead of relying on a single happy path. | ✓This agent is for contributing to the official Next.js framework repository, not for generating generic Next.js applications. Next.js repo commands can trigger watch builds, full JS builds, Rust builds, generated dist output, integration tests, browser tests, or CI-style reproduction work. Prefer focused validation first. `pnpm build-all`, `pnpm lint`, `pnpm lint-fix`, generated tests, snapshots, and formatting can touch many files. Inspect the diff before committing. Mode-specific tests matter. Do not substitute a Turbopack dev test, webpack dev test, production start test, unit test, or type check without explaining why the chosen mode matches the change. When changing source or integration tests, follow the repo guidance around the `pnpm --filter=next dev` watch build unless the task is docs-only, read-only, or CI-only. Do not leave watch builds or dev servers running after verification. Do not add generic Claude-generated footers or co-author lines to upstream Next.js commits or PR text. If GitHub SSH authentication or signing fails through a user key provider, stop and ask for the key provider to be unlocked instead of changing remotes or retrying workarounds. |
| Privacy notes | ✓Astro repo work can expose local file paths, stack traces, package names, test fixtures, browser snapshots, dev server logs, issue repro data, and unpublished source changes. Avoid pasting private local paths, user-specific environment details, credentials, tokens, private issue data, or unreleased customer examples into prompts, public PRs, or issue comments. Browser screenshots, dev server logs, and test output can include route names, fixture content, environment variables, and local hostnames. Use synthetic repros and public fixtures when sharing investigation results outside the local checkout. | ✓Prisma repository work can expose local database URLs, `.db.env` values, Docker service names, fixture data, generated client output, query logs, stack traces, benchmark output, and local file paths. Never paste real connection strings, tokens, customer schemas, private database contents, or internal reproduction data into prompts, commits, issues, or public PR comments. SQL commenter, query insight, trace, and raw query tests may include query shapes or metadata. Review logs before sharing them outside the local environment. Prefer synthetic schemas, public fixtures, and redacted validation summaries when reporting database behavior. | ✓AI SDK repo work can expose local file paths, provider names, model IDs, API request shapes, streamed text, tool-call arguments, fixtures, snapshots, telemetry examples, error payloads, and test output. Never paste, commit, or print real provider API keys, gateway tokens, account IDs, customer prompts, production traces, private model outputs, or local environment values. Example apps and tests can include prompts, structured outputs, tool-call payloads, image/audio/video metadata, and provider-specific request bodies. Use synthetic fixtures when sharing publicly. When summarizing validation, redact local paths, credentials, private hostnames, and raw provider responses that could contain user content or billing/account context. | ✓Next.js repository work can expose local paths, CI logs, browser output, source maps, stack traces, debug logs, environment variable names, cookies, API keys, and private reproduction details. Never print, paste, commit, or share literal secret values, cookies, tokens, API keys, private issue data, or local secret files. Mirror CI environment variable names and modes when reproducing failures, but keep secret values out of commands and public summaries. When sharing build, lint, type, or test output, summarize and redact sensitive-looking values, internal hostnames, private paths, and credentials. |
| Prerequisites |
|
|
|
|
| Install | — | — | — | — |
| Config | — | — | — | — |
| Citations | ||||
| Claim | Unclaimed | Unclaimed | Unclaimed | Unclaimed |
Source-backed guides for putting this to work.
Use Agent Skills in the Claude Agent SDK: filesystem discovery via settingSources, the skills option to enable or filter, and tool access.
Loading live community signals…
A short, calm digest of reviewed Claude resources. Unsubscribe any time.