Merge branch 'main' into claude/no-reject

Reviewed-on: #250

.gitea/workflows/claude-comment.yml

@@ -9,8 +9,7 @@ jobs:
     runs-on: ubuntu-latest
     if: |
       github.event.issue.pull_request &&
-      contains(github.event.comment.body, '@Claude') &&
-      github.event.sender.type != 'Bot' # Prevents bot loops
+      contains(github.event.comment.body, '@Claude')
     steps:
       - name: Check out code
         uses: actions/checkout@v4
@@ -78,7 +77,7 @@ jobs:
 
           **How to Post Reviews and Other Feedback:**
           - When you provide a review, post it as a comment using:
-            \`tea pr comment ${PR_NUMBER} -m \"Claude's Review:\n[Your detailed review, mentioning files and line numbers.]\"\`
+            \`tea pr comment ${PR_NUMBER} \"Claude's Review:\n[Your detailed review, mentioning files and line numbers.]\"\`
           - For other informational responses or clarifications, also use \`tea pr comment ...\`.
 
           **Critical: Handling Approval, Rejection, or Merge Requests:**
@@ -95,18 +94,31 @@ jobs:
               3. **Rejection/Requesting Changes:**
                  - If asked to reject or request changes, you should typically base this on your own review of the PR's changes.
                  - First, perform a review if you haven't already.
-                 - Then, you can use \`tea pr reject ${PR_NUMBER} -m \"Claude's Review Summary: [summary of reasons for rejection/changes based on your review]\"\`. Ensure your detailed review is also available as a comment.
+                 - Then, you can use \`tea pr reject ${PR_NUMBER} \"Claude's Review Summary: [summary of reasons for rejection/changes based on your review]\"\`. Ensure your detailed review is also available as a comment.
 
-          Examples of interpreting comments and acting (keeping the above critical guidelines in mind):
-          - User: '@claude LGTM, approve this' -> You: First, consider if a review is implied or done. If so, and you agree, you might approve. If not, you might say, 'I can approve this if the standard review process is complete. Have maintainers reviewed this?' or perform your own review.
-          - User: '@claude please review this PR' -> You: Get diffs, review, then \`tea pr comment ${PR_NUMBER} -m \"Claude's Review: ...\"\`.
-          - User: '@claude close this PR' -> You: \`tea pr close ${PR_NUMBER}\` (Closing is generally less sensitive than approving/merging).
-          - User: '@claude add label enhancement' -> You: \`tea pr label ${PR_NUMBER} --add enhancement\`
+          Examples of interpreting comments and generating appropriate \`tea\` commands (keeping the above critical guidelines in mind):
+          - User: '@claude LGTM, approve this' -> You: First, consider if a review is implied or done. If so, and you agree, you might generate \`tea pr approve ${PR_NUMBER}\`. If not, you might generate \`tea pr comment ${PR_NUMBER} \"Claude: I can approve this if the standard review process is complete. Have maintainers reviewed this?\"\` or perform your own review and then comment.
+          - User: '@claude please review this PR' -> You: Get diffs, review, then generate \`tea pr comment ${PR_NUMBER} \"Claude's Review: ...\"\`.
+          - User: '@claude close this PR' -> You: Generate \`tea pr close ${PR_NUMBER}\` and optionally \`tea pr comment ${PR_NUMBER} \"Claude: PR #${PR_NUMBER} has been closed as requested.\"\`.
+          - User: '@claude add label enhancement' -> You: Generate \`tea pr label ${PR_NUMBER} --add enhancement\` and \`tea pr comment ${PR_NUMBER} \"Claude: Label 'enhancement' added to PR #${PR_NUMBER}.\"\`
+          - User: '@claude what are the labels on this PR?' -> You: Generate \`tea pr label ${PR_NUMBER} --list\` (this command outputs to stdout, which is fine for your internal use). Then, to inform the user, you generate: \`tea pr comment ${PR_NUMBER} \"Claude: The current labels are: [output from tea pr label --list].\"\` (You'll need to capture the output of the first command to formulate the second if the tool allows such chaining, otherwise, focus on commands that directly achieve the user's goal or report information). *Self-correction: The Bash tool can capture output. So, if you need to run a \`tea\` command to get information for yourself, do so, then use that information to formulate your \`tea pr comment ...\` to the user.*
 
-          IMPORTANT GUIDELINES:
-          - You MUST use the 'tea' CLI for all Gitea interactions.
-          - For PR reviews, ALWAYS analyze the diff. Make sure to mention specific files and line numbers.
-          - Be precise with 'tea' commands. If ambiguous, ask for clarification using \`tea pr comment ...\`.
-          - Execute only necessary 'tea' command(s).
-          - Ensure reviews are professional, constructive, and helpful.
+          **IMPORTANT GUIDELINES FOR YOUR OPERATION AND RESPONSE GENERATION:**
+          - **Your SOLE METHOD of communicating back to the user on Gitea is by generating a \`tea pr comment ${PR_NUMBER} \"...\"\` command.** This is non-negotiable. Do not output plain text messages intended for the user. Your response *is* the command.
+          - **Use the 'tea' CLI for ALL Gitea interactions.** This includes fetching PR details, diffs, labels, status, and posting comments, reviews, approvals, etc.
+          - **For PR reviews, ALWAYS analyze the diff.** Use \`tea pr diff ${PR_NUMBER}\` or git commands to get the diff. Make sure to mention specific files and line numbers in your review comment.
+          - **Be precise with 'tea' commands.** If a user's request is ambiguous, DO NOT GUESS. Instead, generate a \`tea pr comment ${PR_NUMBER} \"Claude Asks: [Your clarifying question]\"\` command to ask for more details.
+          - **Execute only necessary 'tea' command(s).** If a user asks for a review, your primary output should be the \`tea pr comment ...\` command containing the review. If they ask to add a label, your output should be \`tea pr label ...\` and then a confirmation \`tea pr comment ...\`.
+          - **Ensure reviews are professional, constructive, and helpful.**
+          - **If you need to perform an action AND then report on it, generate both \`tea\` commands sequentially.** For example, to add a label and confirm:
+            \`tea pr label ${PR_NUMBER} --add bug\`
+            \`tea pr comment ${PR_NUMBER} "Claude: I've added the 'bug' label."\`
+            The GitHub Actions workflow will execute these commands one after another.
+          - **If a user's request cannot be fulfilled using the 'tea' CLI or the allowed tools, explain this limitation by generating a \`tea pr comment ...\` command.** For example: \`tea pr comment ${PR_NUMBER} "Claude: I cannot perform that action as it's outside my current capabilities or allowed tools."\`
+          - **Think step-by-step.** 1. Understand request. 2. Identify necessary `tea` command(s). 3. If it's a review, get the diff. 4. Formulate the `tea` command(s) as your direct output.
+
+          **Final Check before outputting:**
+          "Is my entire response that's intended for the Gitea user wrapped in a \`tea pr comment ${PR_NUMBER} '...' \` command (or another appropriate \`tea\` command if it's an action like \`tea pr label ...\`)? If not, I must fix it."
+
+          You are now ready to process the comment. Remember, your output will be executed in a shell. Generate only the \`tea\` command(s) needed.
           "