Skip to content

Document Agent Sandbox autonomous-run guidance in AGENTS.md #3815

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
gavande1 wants to merge 1 commit into
base: trunk
Choose a base branch
from
Draft

Document Agent Sandbox autonomous-run guidance in AGENTS.md #3815

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
9 changes: 9 additions & 0 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,6 +85,15 @@ WordPress Studio - Electron desktop app for managing local WordPress sites. Buil
**PRs**: Create PR against `trunk` branch. Use the template from `.github/PULL_REQUEST_TEMPLATE.md` (include Related issues, How AI was used in this PR, Proposed Changes, Testing Instructions, Pre-merge Checklist). In **Proposed Changes**, focus on the intent of the change and the user impact (the "why" and how the user experiences it) — do not list modified files or describe implementation mechanics; the diff already shows that. MUST pass all CI checks before merge.
**IMPORTANT**: Prefer merging `trunk` into your branch over rebasing. Avoid force pushes to trunk/main branches. Avoid force pushes to already-pushed branches - add new commits instead.

## Autonomous Agent (Agent Sandbox) Runs

Studio issues on the **Studio App & CLI** Linear team (`STU-*`) can be picked up by the Agent Sandbox: the issue is triaged and a PR is opened autonomously, headless, in a sandbox. If you are that agent:

- **Stay in scope.** Touch only the files the issue requires. Prefer the smallest change that resolves it; do not opportunistically refactor.
- **Verify before claiming done.** Run `npx eslint --fix` on modified files, `npm run typecheck`, and `npm test -- <path>` for affected tests. If the toolchain or a dependency install is unavailable in the sandbox, say so explicitly — never assert a change is verified when it isn't.
- **You cannot see the UI.** Visual and dark-mode correctness can't be confirmed headless. For UI/CSS changes, use the `--color-frame-*` tokens (never `--wpds-color-*`) and flag the PR for human visual review rather than asserting it renders correctly.
- **Big or speculative work → draft PoC.** If the change grows large or crosses architectural boundaries, follow the Proof of Concept guidance below instead of opening it as merge-ready.

## Large & Exploratory Contributions (Vibe-Coded Features)

If you've built a substantial new feature — especially one generated with AI assistance or built rapidly without prior team alignment — treat your PR as a **Proof of Concept** rather than a merge-ready change:
Expand Down