一键导入
astro-pr-writer
// Write and update Astro pull requests with reviewer-friendly titles and high-signal bodies. Trigger whenever the user asks to create a PR, open a PR, draft a PR, update PR title/body, or write PR notes/summary/description.
// Write and update Astro pull requests with reviewer-friendly titles and high-signal bodies. Trigger whenever the user asks to create a PR, open a PR, draft a PR, update PR title/body, or write PR notes/summary/description.
Triage a bug report. Reproduces the bug, diagnoses the root cause, verifies whether the behavior is intentional, and attempts a fix. Use when asked to "triage issue
Create a changeset for the Astro monorepo. Use this skill whenever you need to add a changeset file to a PR, write a changelog entry, or document a package version bump. Also trigger when the user says "add a changeset", "write a changeset", "create a changeset", or when another skill instructs you to create a changeset.
Comprehensive guide for developing in the Astro monorepo. Covers architecture, debugging, testing, and critical constraints. Use when working on features, fixes, tests, or understanding the codebase structure.
Analyze recent GitHub Actions workflow runs to identify patterns, mistakes, and improvements. Use when asked to "analyze workflow logs", "review action runs", or "analyze GitHub Actions".
| name | astro-pr-writer |
| description | Write and update Astro pull requests with reviewer-friendly titles and high-signal bodies. Trigger whenever the user asks to create a PR, open a PR, draft a PR, update PR title/body, or write PR notes/summary/description. |
Write Astro pull request descriptions that help reviewers quickly understand intent, behavior changes, and validation.
Use this skill whenever the user asks for any PR-writing task, including:
Describe the change, how it works, and why it matters.
Changes explains what the fix/feature does.Testing lists what test code was added or changed.Docs explains whether user-facing docs changes are needed.Do not use PR sections as a task log.
Use a human, reviewer-friendly title.
Do not use:
fix:, feat:, docs:, etc.)fix(cloudflare): ...)Use this structure:
## Changes
- <Behavior change and why it matters>
- <Implementation detail and impact>
## Testing
- <New or changed test and what it covers>
- <Why an existing assertion changed>
## Docs
- <No docs update needed, because ...>
Focus on behavior, implementation approach, and impact.
Include:
Do not include:
Testing)List what test code was added or changed, and why. Reviewers read this section to understand test coverage changes — not to hear that you ran a test suite.
Include:
Do not include:
Explain docs impact clearly.
Default to short. 1-2 bullets per section is normal — add more only when the change is genuinely complex. A reviewer scanning a PR queue should be able to read the whole body in under 30 seconds for a typical patch.
Too verbose:
- Moves
.optional().prefault({})outsidez.preprocess()for theserverconfig property in bothbase.tsandrelative.ts, matching theintegrationsfix from #16531. Zod 4.4.0 rejects missing properties wrapped inz.preprocess()before the preprocessor or inner defaults can execute — moving.optional().prefault({})outside the preprocess call resolves this. Fixes theserverproperty issue reported there by @rururux.- Adds
invalid_key,invalid_element, and discriminated unionoptionshandlers to both Astro and DB error maps for Zod 4.4.0 compatibility. Zod 4.4.0 surfaces record key refinement failures (e.g. env schema variable names) as structuredinvalid_keyissues with nested errors instead of a flat message. The handlers extract the actual refinement message for clear user-facing errors.- All changes are backward-compatible with Zod 4.3.x. New error map branches only activate on issue codes that 4.4.0 starts emitting.
Better:
- Moves
.optional().prefault({})outsidez.preprocess()for theserverconfig, matching theintegrationsfix from #16531. Fixes the issue reported there by @rururux.- Adds
invalid_key,invalid_element, and discriminated unionoptionshandlers to both error maps for Zod 4.4.0 compat.- Backward-compatible with Zod 4.3.x.
Every PR that modifies a package requires a changeset. Only examples/* changes are exempt.
Load the changeset skill to create the changeset file and write the message. It covers file creation, format, bump types, and message conventions.
When writing the PR body:
Changes section — it is process noise, not a behavior changeChanges bullets describe behavior/implementation/impactTesting lists test code added/changed, not test run resultsDocs decision is explicit.changeset/ for any package-modifying PR