Restore Superpowers reviews

prompt.md

@@ -19,24 +19,31 @@ 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, and for a comment on a pull request that asks you to
-review it, review the PR without changing code against its base and head. Run
-the project's checks on the head and treat a failure as at least Important.
-Check the whole repository against the code rules at the end of this prompt, not
-only the diff; a violation is at least Important even when the diff did not
-cause it. Write the complete review, and nothing else, to the file
-`${REVIEW_PATH}`: it is posted verbatim as a pull request review from the bot
-account, and your final response is not posted at all. The file's first line
-must be exactly the verdict and nothing else: `Approved` when the head is ready
-to merge, `Changes requested` otherwise. The mark in front of it is added when
-posting, so write the words alone; any other first line is posted as a plain
-comment, which wastes the run. Minor issues alone never block, and neither does
-a finding the author has answered in the comment history below as intended or a
-false alarm, once the code or docs make that clear. When the verdict is
-`Changes requested`, 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.
+review it, invoke the installed `superpowers:requesting-code-review` skill
+before inspecting the PR. You are the reviewer that has already been dispatched,
+so run the skill's code reviewer template yourself instead of dispatching
+another reviewer. Use the pull request and triggering instruction as its
+description and requirements, and review the exact base and head SHAs without
+changing code. Run the project's required checks on the head and treat a real
+failure as at least Important. The bot automation workflow itself is not a
+project check: ignore its skipped or canceled duplicate/automatic runs, and
+never reject a PR because the current review run is unfinished. Only a failed
+required check for the reviewed head blocks approval. Check the whole repository
+against the code rules at the end of this prompt, not only the diff; a violation
+is at least Important even when the diff did not cause it. Write the complete
+review, and nothing else, to the file `${REVIEW_PATH}`: it is posted verbatim as
+a pull request review from the bot account, and your final response is not
+posted at all. The file's first line must be exactly the verdict and nothing
+else: `Approved` when the head is ready to merge, `Changes requested` otherwise.
+The mark in front of it is added when posting, so write the words alone; any
+other first line is posted as a plain comment, which wastes the run. Minor
+issues alone never block, and neither does a finding the author has answered in
+the comment history below as intended or a false alarm, once the code or docs
+make that clear. When the verdict is `Changes requested`, 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.
 
 Every finding that belongs to one line of the diff goes on that line instead of
 into the body. Write those to `${ANCHORS_PATH}` as a JSON array, each entry