Checked-out head (#4)

Checked-out head (#4)

Co-authored-by: Danny Kim <temeddix@gmail.com>
Co-committed-by: Danny Kim <temeddix@gmail.com>

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,22 +13,32 @@ 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 names what
+must change in one line, addressed to the author; the author's own agent picks
+the fixes up, so never ask `@bot` to make them. 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`
+under 512 bytes. Only core information stays visible: the verdict, the summary
 line, and the section headings. Anything verbose goes into a `<details>` block
 whose `<summary>` is a few words, such as the `file:line` and title of an issue
 with the what, why, and how inside; the same for each strength, each