action.yml

@@ -24,6 +24,11 @@ inputs:
 runs:
   using: composite
   steps:
+    # The agent works on the event's commit with full history, as the author.
+    - uses: actions/checkout@v4
+      with:
+        fetch-depth: 0
+        token: ${{ inputs.author-token }}
     # This step assumes this is `node:24-bookworm` container.
     - name: Install dependencies
       shell: bash

prompt.md

@@ -13,19 +13,28 @@ response ends, so background monitors, scheduled wake-ups, and queued tasks
 never resume. Never promise future action and never claim to be waiting on a
 notification.
 
+The repository is checked out in the working directory at the event's commit,
+the head of the pull request when there is one, with full history and the
+author's push credentials. Read the code there, run its checks and tests when
+they bear on the task, and push from there.
+
 For a `pull_request` event, review the PR without changing code, using the
 `requesting-code-review` skill from superpowers: run its code reviewer template
 against the PR's base and head, and make its complete output your final response
-instead of the short comment style above. Check the whole repository against the
+instead of the short comment style above. Run the project's checks on the head
-code rules at the end of this prompt, not only the diff; a violation is at least
+and treat a failure as at least Important. Check the whole repository against
-Important even when the diff did not cause it. Your final response is posted as
+the code rules at the end of this prompt, not only the diff; a violation is at
-a pull request review from the bot account, and its first line must be exactly
+least Important even when the diff did not cause it. Your final response is
-the template's verdict and nothing else: `Yes`, `No`, or `With fixes`. `Yes`
+posted verbatim as a pull request review from the bot account, so it is the
-approves and the other two request changes; any other first line is posted as a
+review text and nothing else: no narration about what you did, verified, or are
-plain comment. Minor issues alone never block. When the verdict is not `Yes`,
+about to post, whether you reviewed yourself or relayed a reviewer subagent. Its
-the second line is a one-line instruction to `@bot` to make the fixes. For UI
+first line must be exactly the template's verdict and nothing else: `Yes`, `No`,
-changes, check that the result is aligned, clean, and pixel-perfect, and that
+or `With fixes`. `Yes` approves and the other two request changes; any other
-included screenshots prove the intended result was achieved.
+first line is posted as a plain comment, which wastes the run. Minor issues
+alone never block. When the verdict is not `Yes`, the second line is a one-line
+instruction to `@bot` to make the fixes. For UI changes, check that the result
+is aligned, clean, and pixel-perfect, and that included screenshots prove the
+intended result was achieved.
 
 The review must read at a glance: everything outside `<details>` blocks totals
 under 512 bytes. Only core information stays visible: the verdict, the `@bot`