Add more ai agent context, add PR review to architect agent

.opencode/agent/submit.md

@@ -1,5 +1,5 @@
 ---
-description: Check if branch is ready to submit, review pending changes, prepare for PR/code review, verify tests pass, assess submission readiness, and suggest reviewers for the changes
+description: Prepares changes for submission. Reviews pending changes, runs pre-submission checks, crafts commit messages, and suggests reviewers. Use when ready to submit a PR or to check if a branch is ready.
 mode: subagent
 temperature: 0.1
 permission:
@@ -11,6 +11,10 @@ permission:
     'git log*': allow
     'git show*': allow
     'git blame*': allow
+    'git fetch*': allow
+    'git branch*': allow
+    'git rev-parse*': allow
+    'git merge-base*': allow
     'git add*': ask
     'git commit*': ask
     'git stash*': ask
@@ -27,36 +31,27 @@ permission:
     'rg *': allow
     'grep *': allow
     'find *': allow
+    'ls': allow
     'ls *': allow
     'cat *': allow
     'head *': allow
     'tail *': allow
     'wc *': allow
-    'gh pr view --json comments': allow
-    'gh pr checks': allow
-    'gh pr status': allow
-    'gh pr diff': allow
-    'gh pr list': allow
+    'gh pr view*': allow
+    'gh pr checks*': allow
+    'gh pr status*': allow
+    'gh pr diff*': allow
+    'gh pr list*': allow
+    'gh pr create*': ask
     'gh pr checkout*': ask
     'gh pr comment*': ask
-    'gh pr close*': ask
-    'gh pr reopen*': ask
-    'gh pr merge*': ask
+    'gh pr review*': ask
+    'gh api *': ask
     'gh issue view*': allow
     'gh issue list*': allow
-    'gh issue comment*': ask
-    'gh issue close*': ask
-    'gh issue reopen*': ask
-    'gh issue create*': ask
-    'gh issue edit*': ask
     'gh issue status': allow
     'gh auth status': allow
-    'gh auth login*': ask
-    'gh auth logout*': ask
     'gh alias list': allow
-    'gh alias set*': ask
-    'gh alias delete*': ask
-    'gh alias rename*': ask
 ---
 
 You are a Code Submission agent specializing in helping to prepare changes for code review. Your role is to assist developers ensure their changes are well-organized, properly tested, documented, and ready for review.
@@ -183,19 +178,27 @@ Fixes: #1234
 If changes need restructuring:
 
 - Suggest logical commit boundaries
-- Help stage files incrementally with `git add -p` guidance
+- Help stage specific files with `git add <file>` commands
 - Recommend squashing or splitting commits as needed
 - Fixup commits are ok but need to be squashed before merging a PR
 
 ### 6. Check to see if GitHub comments are addressed
 
-If the current branch has an associated GitHub PR, check for any unresolved comments. If there are any, list them out and recommend addressing them before submission.
+If the current branch has an associated GitHub PR, fetch review comments via `gh api repos/{owner}/{repo}/pulls/{number}/comments` and review threads via `gh pr view --json comments`. Check whether resolved comments have actually been addressed in the current code. List any unresolved or incorrectly resolved comments and recommend addressing them before submission.
 
 If the current branch is not rebased on the latest main branch, recommend rebasing to pick up any new changes or fixes.
 
 ### 7. Try to identify conflicting changes
 
-If the current branch has an associated GitHub PR, check for any conflicting changes with the main branch. If there are any, list them out and recommend resolving them before submission. In general, the current branch should be rebased on the latest main branch to minimize the chance of conflicts but if that's not possible, examine the delta to identify potential conflicts and suggest resolutions.
+If the current branch has an associated GitHub PR, check for conflicting changes with the main branch:
+
+1. Run `git fetch origin main` to get the latest main.
+2. Run `git merge-base HEAD origin/main` to find the common ancestor.
+3. Run `git diff origin/main...HEAD --name-only` to see files changed on this branch.
+4. Run `git diff origin/main --name-only` to see files changed on main since divergence.
+5. If the same files appear in both, examine the specific changes to identify conflicts.
+
+In general, the current branch should be rebased on the latest main branch. If that's not possible, list the conflicting files and suggest resolutions.
 
 ### 8. Suggest reviewers
 
@@ -240,30 +243,6 @@ Do suggest reviewers who have made material comments or suggestions on the assoc
 
 ---
 
-## Project-Specific Context
-
-### workerd Conventions
-
-- Use KJ library idioms (`kj::Own`, `kj::Maybe`, `kj::Promise`, etc.)
-- Follow Cap'n Proto conventions for schemas
-- V8/JSG integration follows patterns in `src/workerd/jsg/`
-- Compatibility flags go in `compatibility-date.capnp`
-- Risky changes use autogates (`src/workerd/util/autogate.*`)
-
-### Test Commands
-
-- `just test` - Run all tests
-- `just node-test <name>` - Run Node.js compatibility tests
-- `just wpt-test <name>` - Run Web Platform Tests
-- `bazel test //path/to:target` - Run specific test target
-
-### Build Commands
-
-- `just build` or `bazel build //src/workerd/server:workerd`
-- `just build-asan` - Build with AddressSanitizer
-
----
-
 ## Output Format
 
 When reviewing changes, provide:
@@ -306,7 +285,7 @@ List of potential reviewers based on code changes.
 
 ## Notes
 
-- The CONTRIBUTING.md file for project-specific contribution guidelines and the README.md for general project overview.
+- See CONTRIBUTING.md for project-specific contribution guidelines and README.md for general project overview.
 - A PR may involve multiple commits; ensure each is well-scoped.
 - A PR is not ready to merge unless all required checks pass, all comments are resolved, there are no fixup commits, and the PR has been approved by at least one reviewer. However, your role is only to help prepare the changes for review, not to determine merge readiness.
 - When suggesting running tests or builds, always specify the exact command to run.

.opencode/commands/autogate.md

@@ -0,0 +1,48 @@
+---
+description: Look up an autogate, or list all autogates if no argument given
+subtask: true
+---
+
+Look up autogate: $ARGUMENTS
+
+**If no argument is provided (empty or blank), list all autogates:**
+
+1. Read the `AutogateKey` enum in `src/workerd/util/autogate.h`.
+2. For each entry (excluding `NumOfKeys`), read the comment above it for a description.
+3. Read the string mapping in `src/workerd/util/autogate.c++` to get the config string for each.
+4. Output a summary table:
+
+   | Autogate    | Config string  | Description                    |
+   | ----------- | -------------- | ------------------------------ |
+   | `ENUM_NAME` | `"string-key"` | Brief description from comment |
+
+   Include the total count of active autogates.
+
+**If an argument is provided, look up that specific autogate:**
+
+1. **Find the enum entry.** Search `src/workerd/util/autogate.h` for the autogate name. The argument may be the enum name (e.g., `SOME_FEATURE`), the string key, or a partial match.
+
+2. **Find the string mapping.** Search `src/workerd/util/autogate.c++` for the corresponding entry in the string-to-enum mapping. Verify the enum and string map are in sync — flag a warning if one exists without the other.
+
+3. **Find usage sites.** Search for where the autogate is checked:
+
+   ```
+   grep -rn 'AutogateKey::<name>\|isAutoGateEnabled.*<name>' src/ --include='*.h' --include='*.c++'
+   ```
+
+4. **Find tests.** Search for the autogate name in test files:
+
+   ```
+   grep -rn '<name>' src/ --include='*.wd-test' --include='*-test.js' --include='*-test.ts' --include='*-test.c++'
+   ```
+
+   Also check if any tests use the `@all-autogates` variant to exercise this gate.
+
+5. **Output:**
+   - **Enum**: `AutogateKey::<name>` (file:line)
+   - **String key**: the string used in configuration (file:line)
+   - **In sync**: yes/no — whether enum and string map match
+   - **Usage sites**: file:line list of where the autogate is checked
+   - **Tests**: file:line list of tests that reference this autogate
+   - **Notes**: Autogates are temporary and should be removed once the feature is fully rolled out. If the autogate appears to be stale (no recent commits touching it), note that.
+   - If the autogate is not found, suggest checking for typos and list all available autogates from the enum definition.

.opencode/commands/changelog.md

@@ -0,0 +1,67 @@
+---
+description: Summarize current branch changes for a PR description or release note
+subtask: true
+---
+
+Generate a changelog for the current branch. $ARGUMENTS
+
+Steps:
+
+1. **Determine the branch and base.** Run:
+
+   ```
+   git log --oneline origin/main..HEAD
+   ```
+
+   If there are no commits, try `main..HEAD`. If the user specified a different base in the arguments, use that.
+
+2. **Read the full diff** to understand the actual changes:
+
+   ```
+   git diff origin/main...HEAD --stat
+   ```
+
+3. **Read commit messages** for context:
+
+   ```
+   git log origin/main..HEAD --format='%h %s%n%n%b'
+   ```
+
+4. **Categorize changes** by area. Use these categories based on the files changed:
+   - **API** — `src/workerd/api/` changes
+   - **Node.js compat** — `src/workerd/api/node/` or `src/node/` changes
+   - **I/O** — `src/workerd/io/` changes
+   - **JSG** — `src/workerd/jsg/` changes
+   - **Server** — `src/workerd/server/` changes
+   - **Build** — `build/`, `MODULE.bazel`, `BUILD.bazel` changes
+   - **Types** — `types/` changes
+   - **Tests** — test-only changes
+   - **Docs** — documentation-only changes
+   - **Other** — anything that doesn't fit above
+
+5. **Draft the summary.** For each category with changes:
+   - One bullet per logical change (not per commit — squash related commits into one bullet)
+   - Start each bullet with a verb: Add, Fix, Update, Remove, Refactor
+   - Include the most important file references
+   - Note any breaking changes, new compat flags, or new autogates prominently
+
+6. **Output format:**
+
+   ```
+   ## Summary
+
+   <1-2 sentence overview of the branch's purpose>
+
+   ## Changes
+
+   ### <Category>
+   - <change description>
+
+   ## Breaking Changes
+   <if any, otherwise omit section>
+
+   ## Testing
+   <brief note on what tests were added or modified>
+   ```
+
+   If the user's arguments request a specific format (e.g., "for release notes", "for PR"), adjust the tone accordingly. PR descriptions should be more detailed; release notes should be user-facing and concise.

.opencode/commands/compat-flag.md

@@ -0,0 +1,51 @@
+---
+description: Look up a compatibility flag, or list all flags if no argument given
+subtask: true
+---
+
+Look up compatibility flag: $ARGUMENTS
+
+**If no argument is provided (empty or blank), list all compatibility flags:**
+
+1. Read `src/workerd/io/compatibility-date.capnp` and find all fields with `$compatEnableFlag`.
+2. For each flag, extract: field name, field number, enable flag string, enable date (or "experimental" / "no date"), and a one-line summary from the comment.
+3. Output a summary table grouped by category (streams, nodejs, containers, general, etc.):
+
+   | Flag        | Enable date | Description       |
+   | ----------- | ----------- | ----------------- |
+   | `flag_name` | 2025-01-15  | Brief description |
+
+   Include the total count of compatibility flags.
+
+**If an argument is provided, look up that specific flag:**
+
+1. **Find the flag definition.** Search `src/workerd/io/compatibility-date.capnp` for the flag name. The argument may be the snake_case flag name (e.g., `text_decoder_replace_surrogates`) or the camelCase field name (e.g., `textDecoderReplaceSurrogates`). Try both forms.
+
+2. **Extract flag metadata** from the capnp definition:
+   - Field name and number
+   - `$compatEnableFlag` name
+   - `$compatDisableFlag` name (if present)
+   - `$compatEnableDate` (if set)
+   - Whether it has `$experimental` annotation
+   - The comment block describing the flag
+
+3. **Find C++ usage sites.** Search for the getter (e.g., `getTextDecoderReplaceSurrogates()`) across the codebase:
+
+   ```
+   grep -rn "getTextDecoderReplaceSurrogates\|text_decoder_replace_surrogates" src/
+   ```
+
+4. **Find tests.** Search for the snake_case flag name in `.wd-test` and test `.js` files:
+
+   ```
+   grep -rn "text_decoder_replace_surrogates" src/ --include='*.wd-test' --include='*-test.js' --include='*-test.ts'
+   ```
+
+5. **Output:**
+   - **Flag**: enable name / disable name
+   - **Enable date**: date or "not set (must be explicitly enabled)"
+   - **Description**: from the capnp comment
+   - **Usage sites**: file:line list of where the flag is checked in C++
+   - **Tests**: file:line list of tests that exercise this flag
+   - **Annotations**: experimental, neededByFl, impliedByAfterDate, etc.
+   - If the flag is not found, suggest checking for typos and list flags with similar names