Skip to content
Open
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 73 additions & 0 deletions AGENTS.md
Original file line number Diff line number Diff line change
Expand Up @@ -56,3 +56,76 @@ Note: Edits to source files take effect after rebuilding the package via `pnpm b
- Example: `agent-browser click @e1` / `fill @e2 "text"` - Interact using refs
- Re-snapshot after page changes.
- Note: If you can't find `agent-browser`, your machine may not have it installed. If this happens, ask the user to run `npm install -g agent-browser && agent-browser install`. If you are running in headless mode with no human operator and need this tool to complete your job, it is best to fail the job vs. trying to work around not having the tool.

# Pull Request Guidelines

## Commit Messages

Use [conventional commits](https://www.conventionalcommits.org/):

```
feat: add View Transitions support for SVG
fix: resolve CSS scoping regression in nested components
docs: update integration guide for React 19
refactor: simplify middleware pipeline
chore: update dependencies
```

## Changesets

This repo uses changesets. If your change affects published packages (features, fixes — not docs/chore), create a changeset. It will not trigger a release unless there is a changeset:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, docs such as JsDocs should count as patches. That's what we've been doing


```bash
pnpm changeset add --empty
```

Then edit the generated file in `.changeset/` to add the package name, bump type, and summary. For example:

```markdown
---
'astro': patch
---

Fix CSS scoping regression in nested components
```

- `feat:` → minor bump
- `fix:` → patch bump
- `docs:`, `chore:`, `refactor:` → usually no changeset needed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps a section on major?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, saying "don't"!


## PR Description

Every PR **must** use the repo's PR template at [`.github/PULL_REQUEST_TEMPLATE.md`](.github/PULL_REQUEST_TEMPLATE.md). Fill in all sections:

1. **Changes** — Short, concise bullet points describing what changed and why.
2. **Testing** — How you verified the change works (tests added/updated, manual steps). Never delete this section — if no tests were added, explain why.
3. **Docs** — Whether this could affect user behavior and if docs updates are needed.

### AI Disclosure

If the PR was authored or co-authored using an AI tool (e.g. Claude, Copilot, Cursor, OpenCode), this **must** be disclosed in the PR description. Use one of the following labels:

- **`AI-generated`** — The contribution was primarily generated by an AI tool with human review.
- **`AI-assisted`** — A human wrote the contribution with help from AI tools (e.g. code completion, suggestions, debugging).

Include this as a line in the PR description, e.g.:

```
> AI-assisted: Co-authored using OpenCode (Claude)
```

or

```
> AI-generated: Generated by Claude with human review and testing
```

If a PR is `AI-generated`, it **must** be created as a draft (`gh pr create --draft`). The human controlling the agenty must manually review the changes and mark it as ready for review before it will be reviewed by the Astro team.
Comment on lines +105 to +124
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a heavy AI user, so maybe I'm wrong about the flow, but if I open an AI-TUI to ask a few questions or guide me through a PR, or do the same with ChatGPT in a tab of my browser, my PR is AI-assisted but I would never see this informations in this file I guess?

Shouldn't this be in the PR template or our CONTRIBUTING.md file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, maybe


## Workflow

1. Always create a branch from `main` — never push directly.
2. Make changes and commit using conventional commit messages.
3. Create a changeset if needed.
4. Run tests (`pnpm test`) and fix any failures.
5. Push the branch and create a PR via `gh pr create`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This assumes users have gh installed, however we don't require it in the project. Maybe we could fallback to the classic git command