Add axon-pr-reviewer TaskSpawner to replace cubic-dev-ai

self-development/README.md

@@ -160,6 +160,29 @@ This spawner uses a cron schedule (`0 */12 * * *`) and will create a task every
 - **Integration Opportunities** — identify tools/platforms Axon could integrate with (CI systems, monitoring, chat ops, etc.)
 - **New CRDs & API Extensions** — propose new Custom Resource Definitions or extensions to existing CRDs that would expand Axon's capabilities
 
+### axon-pr-reviewer.yaml
+
+This TaskSpawner watches for open pull requests labeled `ok-to-test` and performs automated code reviews, replacing the need for external code review bots.
+
+**Deploy:**
+```bash
+kubectl apply -f self-development/axon-pr-reviewer.yaml
+```
+
+This spawner polls for PRs labeled `ok-to-test` and creates a task for each one to:
+- Read the full PR diff for context and the incremental diff since the last review
+- Review for correctness, test coverage, style, security, and simplicity
+- Post a structured comment on the PR
+
+On follow-up reviews it focuses on the incremental diff (changes since the
+last reviewed commit) while using the full PR diff for overall context.
+The Task persists for one hour after completion (TTL 3600s), preventing
+repeated spawns. To re-trigger a review after pushing new commits, use
+the `/reset-worker` comment pattern to delete the existing Task so the
+spawner can recreate it on the next poll cycle.
+
+The reviewer is read-only — it does not push code or modify files.
+
 ## Customizing for Your Repository
 
 To adapt these examples for your own repository:

self-development/axon-pr-reviewer.yaml

@@ -0,0 +1,142 @@
+apiVersion: axon.io/v1alpha1
+kind: TaskSpawner
+metadata:
+  name: axon-pr-reviewer
+spec:
+  when:
+    githubIssues:
+      types:
+        - pulls
+      labels:
+        - ok-to-test
+  maxConcurrency: 3
+  taskTemplate:
+    workspaceRef:
+      name: axon-agent
+    model: opus
+    type: claude-code
+    ttlSecondsAfterFinished: 3600
+    credentials:
+      type: oauth
+      secretRef:
+        name: axon-credentials
+    podOverrides:
+      resources:
+        requests:
+          cpu: "250m"
+          memory: "512Mi"
+          ephemeral-storage: "4Gi"
+        limits:
+          cpu: "1"
+          memory: "2Gi"
+          ephemeral-storage: "4Gi"
+    agentConfigRef:
+      name: axon-dev-agent
+    promptTemplate: |
+      You are a code reviewer for the Axon project (github.com/axon-core/axon).
+      Your job is to review pull request #{{.Number}} and provide constructive feedback.
+
+      ## Context
+
+      PR #{{.Number}}: {{.Title}}
+      {{.Body}}
+
+      ## Your tasks
+
+      ### 1. Gather context
+      Fetch the current HEAD SHA and check whether a previous axon review exists:
+        ```
+        HEAD_SHA=$(gh pr view {{.Number}} --json headRefOid -q .headRefOid)
+        LAST_REVIEWED=$(gh pr view {{.Number}} --json comments \
+          --jq '[.comments[] | select(.body | test("Axon PR Reviewer")) | .body | capture("Reviewed commit:.* (?<sha>[0-9a-f]{7,40})")? | .sha] | last // empty')
+        echo "HEAD: $HEAD_SHA, last reviewed: ${LAST_REVIEWED:-none}"
+        ```
+
+      ### 2. Read the diff
+      Fetch the PR diff and understand the changes:
+        ```
+        git fetch --unshallow || true
+        git fetch origin main
+        gh pr diff {{.Number}}
+        ```
+
+      If `LAST_REVIEWED` is set (i.e., a previous review exists), also fetch
+      the incremental diff covering only the commits added since the last review:
+        ```
+        git diff "$LAST_REVIEWED"..."$HEAD_SHA"
+        ```
+      Focus your review on the incremental diff, but use the full PR diff for
+      overall context.
+
+      If `LAST_REVIEWED` is empty (first review), review the full PR diff.
+
+      ### 3. Read the project conventions
+      Read `CLAUDE.md` (or `AGENTS.md`) in the repository root so your review
+      aligns with the project's coding standards.
+
+      ### 4. Review the changes
+      Evaluate the PR for:
+        - **Correctness**: Does the code do what it claims? Are there logic errors or edge cases?
+        - **Tests**: Are there adequate tests for the changes? Are existing tests updated if needed?
+        - **Style & conventions**: Does the code follow the project's conventions (see CLAUDE.md)?
+        - **Security**: Are there any security concerns (injection, hardcoded secrets, etc.)?
+        - **Simplicity**: Is the change minimal and focused, or does it include unnecessary refactoring?
+
+      ### 5. Post your review
+      Post a single comment on the PR using `gh`:
+        ```
+        gh pr comment {{.Number}} --body "..."
+        ```
+
+      Format the comment as:
+
+      For a **first review** (no previous review):
+      ```
+      🤖 **Axon PR Reviewer**
+
+      **Reviewed commit:** <full HEAD_SHA>
+
+      ## Summary
+      <1-3 sentence summary of what the PR does>
+
+      ## Review
+
+      <Your review findings, organized by file or topic. Use code references
+      (file:line) where applicable. Be specific and actionable.>
+
+      ## Verdict
+      **LGTM** / **Changes requested**
+
+      <If changes are requested, list them as a concise checklist.>
+      ```
+
+      For a **follow-up review** (previous review exists):
+      ```
+      🤖 **Axon PR Reviewer**
+
+      **Reviewed commit:** <full HEAD_SHA>
+      **Changes since:** <LAST_REVIEWED>
+
+      ## Summary
+      <1-3 sentence summary of what changed since the last review>
+
+      ## Review
+
+      <Your review findings on the incremental changes. Use code references
+      (file:line) where applicable. Note whether previous review feedback
+      has been addressed.>
+
+      ## Verdict
+      **LGTM** / **Changes requested**
+
+      <If changes are requested, list them as a concise checklist.>
+      ```
+
+      ## Constraints
+      - Do NOT push code, create commits, or modify any files. This is a read-only review.
+      - Do NOT approve or request changes via GitHub's formal review mechanism.
+        Post comments only via `gh pr comment`.
+      - Be constructive and specific. Avoid vague feedback.
+      - Focus on substantive issues, not style nitpicks that a linter would catch.
+      - Always include the full reviewed commit SHA in the review comment header.
+  pollInterval: 1m