diff --git a/.github/workflows/claude-doc-sync.yml b/.github/workflows/claude-doc-sync.yml
index bb6c88908..32f37a971 100644
--- a/.github/workflows/claude-doc-sync.yml
+++ b/.github/workflows/claude-doc-sync.yml
@@ -8,7 +8,6 @@ on:
 
 permissions:
   contents: write
-  pull-requests: write
 
 jobs:
   doc-sync:
@@ -60,6 +59,7 @@ jobs:
           PR_NUMBER: ${{ github.event.pull_request.number }}
           PR_TITLE: ${{ github.event.pull_request.title }}
           BASE_REF: ${{ github.event.pull_request.base.ref }}
+          REPO: ${{ github.repository }}
         run: |
           cat > "$RUNNER_TEMP/claude-prompt.txt" <<EOF
           Pull request #$PR_NUMBER ("$PR_TITLE") was just merged into $BASE_REF.
@@ -69,8 +69,8 @@ jobs:
           1. Run \`gh pr diff $PR_NUMBER\` to see exactly what changed.
           2. Search this repository's EXISTING documentation (root README.md, each package's README.md, and any existing /docs content) for anything describing the behavior, API, configuration, or usage that this PR changed. Do not treat CHANGELOG.md files as documentation - they're generated by release tooling, leave them alone.
           3. If you find existing documentation that's now inaccurate, incomplete, or missing details because of this change, update it in place to match. Only edit files that already exist - do not add new documentation files or new sections covering something that had no prior documentation at all.
-          4. If no existing documentation is relevant to this change, do not touch the repo: no branch, no commit, no pull request. Instead, write one or two sentences explaining that decision to doc-sync-decision.md in the repository root (e.g. "No existing docs reference the changed behavior in packages/core/src/foo.ts; nothing to update.") and stop.
-          5. If you did update existing documentation, create a new branch off $BASE_REF named \`docs/sync-pr-$PR_NUMBER\`, commit the changes, push it, and open a pull request against $BASE_REF with \`gh pr create\`. Title it "docs: sync with #$PR_NUMBER" and explain in the body which doc(s) you updated, why, and link back to #$PR_NUMBER.
+          4. If no existing documentation is relevant to this change, do not touch the repo: no branch, no commit. Write one or two sentences explaining that decision to doc-sync-result.md in the repository root (e.g. "No existing docs reference the changed behavior in packages/core/src/foo.ts; nothing to update.") and stop.
+          5. If you did update existing documentation, create a new branch off $BASE_REF named \`docs/sync-pr-$PR_NUMBER\`, commit, and push it. Do not run \`gh pr create\` or attempt to open a pull request - GitHub Actions is not permitted to create pull requests in this organization and it will fail. Instead, write to doc-sync-result.md: which doc(s) you updated, why, and this link so a maintainer can open the PR themselves: https://github.com/$REPO/compare/$BASE_REF...docs/sync-pr-$PR_NUMBER?expand=1
           EOF
 
       - name: Sync docs with Claude
@@ -82,11 +82,10 @@ jobs:
           claude -p "$(cat "$RUNNER_TEMP/claude-prompt.txt")" \
             --allowedTools "Edit,MultiEdit,Write,Read,Glob,Grep,Bash(git:*),Bash(gh:*)"
 
-      # Only exists if Claude decided nothing needed updating; ignored otherwise.
-      - name: Upload no-op decision artifact
+      - name: Upload doc-sync result
         if: always() && steps.gate.outputs.approved == 'true'
         uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4
         with:
-          name: doc-sync-decision-${{ github.event.pull_request.number }}
-          path: doc-sync-decision.md
-          if-no-files-found: ignore
+          name: doc-sync-result-${{ github.event.pull_request.number }}
+          path: doc-sync-result.md
+          if-no-files-found: warn
diff --git a/.github/workflows/claude-issue-investigate.yml b/.github/workflows/claude-issue-investigate.yml
index 0189701cf..6d57708df 100644
--- a/.github/workflows/claude-issue-investigate.yml
+++ b/.github/workflows/claude-issue-investigate.yml
@@ -7,7 +7,6 @@ on:
 
 permissions:
   contents: write
-  pull-requests: write
   issues: read
   id-token: write
 
@@ -45,17 +44,19 @@ jobs:
       - name: Write prompt
         env:
           ISSUE_NUMBER: ${{ github.event.issue.number }}
+          REPO: ${{ github.repository }}
         run: |
           cat > "$RUNNER_TEMP/claude-prompt.txt" <<EOF
           Investigate GitHub issue #$ISSUE_NUMBER in this repository.
 
           1. Run \`gh issue view $ISSUE_NUMBER\` to read the full issue (title, body, comments).
-          2. Based on the description, actually try to reproduce the reported problem using this repository's existing code and test tooling - write and run a small script or test case that exercises the described behavior, don't just reason about whether it would fail.
-          3. If you reproduce it, identify the root cause in the source code.
-          4. If you can reproduce it and you're confident the fix is small, narrow, and clearly correct, implement it, create a new branch off master named \`fix/issue-$ISSUE_NUMBER\`, commit, push it, and open a pull request against master with \`gh pr create\` that includes "Fixes #$ISSUE_NUMBER" in the body. If the right fix is unclear, would need broader changes, or you're not confident it's correct, do not open a PR - note that in the report instead.
-          5. If you cannot reproduce it, explain exactly what you tried, why it didn't reproduce, and what additional information (exact repro steps, versions, environment) would help.
-          6. Do not comment on the issue itself.
-          7. Always write your findings to investigation-report.md in the repository root: a summary, the exact reproduction steps you tried, whether it reproduced, your root-cause diagnosis if found, and whether you opened a fix PR (with its number) or why you decided not to.
+          2. Based on the description, actually try to reproduce the reported problem using this repository's existing code and test tooling - don't just reason about whether it would fail. If it's reproducible, write a real regression test in the appropriate existing test file, following this repo's existing test conventions, and confirm it fails on the current code for the same reason the issue describes.
+          3. If you reproduce it, identify the root cause in the source code using actual evidence from your reproduction - do not guess. If you cannot pin down the root cause with real evidence, say so plainly in the report instead of presenting a guess as a diagnosis, and state what information or access would let you confirm it.
+          4. If you found the root cause and you're confident the fix is small, narrow, and clearly correct, implement it. Include the regression test from step 2 in the same change, run it again to confirm it now passes, and report both results (failing before, passing after) as proof the fix addresses what you diagnosed. Then create a new branch off master named \`fix/issue-$ISSUE_NUMBER\`, commit, and push it. Do not run \`gh pr create\` or attempt to open a pull request - GitHub Actions is not permitted to create pull requests in this organization and it will fail. Instead, include the branch name and this link in the report so a maintainer can open the PR themselves: https://github.com/$REPO/compare/master...fix/issue-$ISSUE_NUMBER?expand=1
+          5. If the right fix is unclear, would need broader changes, or you're not confident it's correct, do not push anything and do not guess at a fix - state plainly in the report what's unclear and what you'd need (from the reporter, a maintainer, or elsewhere) to move forward.
+          6. If you cannot reproduce the issue at all, explain exactly what you tried, why it didn't reproduce, and what additional information (exact repro steps, versions, environment) would help - do not assume it isn't real just because you couldn't trigger it.
+          7. Do not comment on the issue itself.
+          8. Always write your findings to investigation-report.md in the repository root: a summary, the exact reproduction steps you tried, whether it reproduced, your root-cause diagnosis (or an explicit statement that you couldn't confirm one and what's missing), the regression test's before/after results if you wrote a fix, and whether you pushed a fix branch (with its name and compare link) or why you decided not to. Never present a guess as a finding anywhere in the report - be explicit about what you verified versus what remains uncertain.
           EOF
 
       - name: Investigate with Claude