astro-pr-writer

Source excerpt starting at line 1.

1---2name: astro-pr-writer3description: 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.4---5 6# Astro PR Writer7 8Write Astro pull request descriptions that help reviewers quickly understand intent, behavior changes, and validation.9 10Use this skill whenever the user asks for any PR-writing task, including:11 12- create/open a pull request13- create/open a draft pull request14- update a PR title15- update a PR body/description16- write PR notes/summary17 18## Core Principle19 20Describe the **change**, **how it works**, and **why it matters**.21 22- `Changes` explains what the fix/feature does.23- `Testing` lists what test code was added or changed.24- `Docs` explains whether user-facing docs changes are needed.25 26Do not use PR sections as a task log.27 28## PR Title Rules29 30Use a human, reviewer-friendly title.31 32- Describe the outcome in plain language.33- Keep it concise and specific.34- Prefer phrasing a person would naturally write in a review queue.35 36Do not use:37 38- conventional commit prefixes in PR titles (`fix:`, `feat:`, `docs:`, etc.)39- scoped commit-style titles (`fix(cloudflare): ...`)40 41## Body Rules42 43Use this structure:44 45```md46## Changes47 48- <Behavior change and why it matters>49- <Implementation detail and impact>50 51## Testing52 53- <New or changed test and what it covers>54- <Why an existing assertion changed>55 56## Docs57 58- <No docs update needed, because ...>59```60 61### Changes62 63Focus on behavior, implementation approach, and impact.64 65Include:66 67- what now works that did not work before68- how the fix/feature works (reviewer-useful level)69- user-facing reliability/compatibility/perf behavior changes70 71Do not include:72 73- "added test" or "updated fixture" (belongs in `Testing`)74- "added changeset"75- internal process notes with no behavior impact76 77### Testing78 79List 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.80 81Include:82 83- new test files or test cases added, with a short description of what they cover84- existing tests that were updated, and why the assertion changed85 86Do not include:87 88- that tests pass (CI shows this; it's noise)89- which commands you ran90- how many tests passed91 92### Docs93 94Explain docs impact clearly.95 96- If docs are not needed, say why in one sentence.97- If docs are needed, link the docs PR.98 99## Brevity Guidance100 101Default 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.102 103**Too verbose:**104 105> - Moves `.optional().prefault({})` outside `z.preprocess()` for the `server` config property in both `base.ts` and `relative.ts`, matching the `integrations` fix from #16531. Zod 4.4.0 rejects missing properties wrapped in `z.preprocess()` before the preprocessor or inner defaults can execute — moving `.optional().prefault({})` outside the preprocess call resolves this. Fixes the `server` property issue reported there by @rururux.106> - Adds `invalid_key`, `invalid_element`, and discriminated union `options` handlers 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 structured `invalid_key` issues with nested errors instead of a flat message. The handlers extract the actual refinement message for clear user-facing errors.107> - 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.108 109**Better:**110 111> - Moves `.optional().prefault({})` outside `z.preprocess()` for the `server` config, matching the `integrations` fix from #16531. Fixes the issue reported there by @rururux.112> - Adds `invalid_key`, `invalid_element`, and discriminated union `options` handlers to both error maps for Zod 4.4.0 compat.113> - Backward-compatible with Zod 4.3.x.114 115## Changesets116 117Every PR that modifies a package requires a changeset. Only `examples/*` changes are exempt.118 119Load the `changeset` skill to create the changeset file and write the message. It covers file creation, format, bump types, and message conventions.120 121When writing the PR body:122 123- Before posting, check whether a changeset exists. If the PR modifies a package and none exists, **create it now** using the `changeset` skill — do not post the PR without one.124- Do not mention "added changeset" in the `Changes` section — it is process noise, not a behavior change125 126## Self-Check Before Posting127 128- Title is reviewer-friendly (not commit-style)129- `Changes` bullets describe behavior/implementation/impact130- `Testing` lists test code added/changed, not test run results131- `Docs` decision is explicit132- Changeset file exists in `.changeset/` for any package-modifying PR — if missing, create it before posting133