fix: cleanup (#15)

Author: varin-nair-factory

action.yml

@@ -30,7 +30,7 @@ runs:
         echo "$HOME/.local/bin" >> $GITHUB_PATH
         "$HOME/.local/bin/droid" --version
 
-    - name: Check and fill PR description if needed
+    - name: Auto-generate PR description on '@droid fill'
       shell: bash
       env:
         FACTORY_API_KEY: ${{ inputs.factory-api-key }}
@@ -64,10 +64,17 @@ runs:
         cat > pr_description_prompt.txt << EOF
         Generate a comprehensive pull request description for PR #${{ inputs.pr-number }}.
 
-        First, use the Web Fetch tool to get the full PR context from:
-        https://github.com/${{ github.repository }}/pull/${{ inputs.pr-number }}
+        Procedure:
+        - Get PR metadata (title & description): gh pr view ${{ inputs.pr-number }} --repo ${{ github.repository }} --json title,body
+        - Get existing comments: gh pr view --json comments
+        - Get diff: gh pr diff
+        - Get changed files with patches to compute inline positions: gh api repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files --paginate --jq '.[] | {filename,patch}'
 
-        This will provide you with the PR title, diff, changed files, and commit messages.
+        Use the PR metadata (title/body) as additional context:
+        - If the existing description includes notes/context, use it to inform your writeup
+        - Do not copy any placeholder tokens (e.g., "@droid fill") into the final output
+
+        This will help you understand the code changes in detail.
 
         $(if [ -n "$PR_TEMPLATE" ]; then
           echo "YOUR TASK: Fill out the following PR template based on the code changes."
@@ -131,90 +138,71 @@ runs:
         set -euo pipefail
 
         cat > prompt.txt << 'EOF'
-        You are an automated code review system for PR #${{ inputs.pr-number }}.
-
-        ## STEP 1: FETCH PR DATA
-        Use Web Fetch: https://github.com/${{ github.repository }}/pull/${{ inputs.pr-number }}
-
-        ## STEP 2: IDENTIFY ALL BUGS IN ONE PASS
-
-        Scan the ENTIRE diff and identify ALL issues now - don't save any for future runs.
-        
-        **Focus on:**
-        - Logic errors: unreachable code, missing break/return, off-by-one errors
-        - Async issues: missing await, unhandled promises
-        - Safety: null dereferences, resource leaks, injections
-        - Type errors: wrong operators (===/==, &&/||), type coercion issues
-        
-        **Skip:** style, naming, architecture, performance, test coverage
-
-        ## STEP 3: LINE SELECTION
+        You are running automated code review in a GitHub Actions runner. The gh CLI is available and authenticated via GH_TOKEN.
 
-        **Critical:** Use GitHub's diff line numbers instead of manual position math.
-        - For added/changed code, take the number shown on the RIGHT side of the diff (`side: "RIGHT"`).
-        - For removed code, use the LEFT column (`side: "LEFT"`).
-        - Never include a `position` field when using line-based payloads.
-
-        For multi-line feedback you must capture the first and last HEAD line numbers in the span. These become `start_line` and `line` with matching sides (usually `"RIGHT"` for new code).
-        
-        **Before submitting:** Verify the text at your calculated position matches the line to replace
-
-        ## STEP 4: FORMAT COMMENTS
-
-        Structure: Issue → Impact → (optional) Context.
-        Do NOT include commit suggestions or use fenced suggestion blocks.
-        No emojis or decorative formatting - be direct and professional.
-        
-        Example: "Missing await on async call. This returns a Promise instead of the data, causing undefined behavior downstream."
-
-        ## STEP 5: SUBMIT REVIEW
-        
-        **⚠️ CRITICAL: Use ONLY inline comments on specific lines. NO summaries, general comments, or commit suggestions.**
+        Context:
+          - Repo: ${{ github.repository }}
+          - PR Number: ${{ github.event.pull_request.number }}
+          - PR Head SHA: ${{ github.event.pull_request.head.sha }}
+          - PR Base SHA: ${{ github.event.pull_request.base.sha }}
         
-        Submit inline comments via API:
-        ```bash
-        curl -X POST \
-          -H "Authorization: Bearer $GH_TOKEN" \
-          -H "Accept: application/vnd.github.v3+json" \
-          https://api.github.com/repos/${{ github.repository }}/pulls/${{ inputs.pr-number }}/reviews \
-          -d '{
-            "event": "COMMENT",
-            "comments": [{
-              "path": "file.js",
-              "line": 42,              // HEAD line number from the RIGHT column of the diff
-              "side": "RIGHT",
-              "body": "Describe the issue and its impact. Provide guidance in prose only."
-            }]
-          }'
-        ```
-
-        Multi-line requires line ranges:
-        ```json
-        {
-          "path": "file.js",
-          "start_line": 40,
-          "line": 43,
-          "start_side": "RIGHT",
-          "side": "RIGHT",
-          "body": "Issue spans multiple lines. Explain the problem and recommend changes without suggestion blocks."
-        }
-        ```
-        (Do not mix `position` with line-based fields. Use `"LEFT"` sides when commenting on removed lines.)
-        Note: Keep feedback in plain text; do not embed suggestion blocks or code fences.
-
-        ## CONSTRAINTS
+        Objectives:
+          1) Re-check existing review comments and reply resolved when addressed.
+          2) Review the current PR diff and flag only clear, high-severity issues.
+          3) Leave very short inline comments (1-2 sentences) on changed lines only and a brief summary at the end.
         
-        **Comment Rules:**
-        - ONLY inline comments attached to specific line numbers
-        - NO general PR comments like "I've completed the review" or "Here's what I found"
-        - NO commit suggestions or fenced suggestion blocks
+        Procedure:
+          - Get existing comments: gh pr view --json comments
+          - Get diff: gh pr diff
+          - Get changed files with patches to compute inline positions: gh api repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files --paginate --jq '.[] | {filename,patch}'
+          - Compute exact inline anchors for each issue (file path + diff position). Comments MUST be placed inline on the changed line in the diff, not as top-level comments.
+          - Detect prior top-level "no issues" style comments authored by this bot (match bodies like: "no issues", "No issues found", "LGTM"; include earlier emoji-prefixed variants if present).
+          - If CURRENT run finds issues and any prior "no issues" comments exist:
+            - Prefer to remove them to avoid confusion:
+              - Try deleting top-level issue comments via: gh api -X DELETE repos/${{ github.repository }}/issues/comments/<comment_id>
+              - If deletion isn't possible, minimize them via GraphQL (minimizeComment) or edit to prefix "[Superseded by new findings]".
+            - If neither delete nor minimize is possible, reply to that comment: "Superseded: issues were found in newer commits".
+          - If a previously reported issue appears fixed by nearby changes, reply: This issue appears to be resolved by the recent changes
         
-        **Review Rules:**
-        - NEVER repeat comments from previous review runs
-        - Review ALL issues in a SINGLE run
-        - Use event: "COMMENT" only (never APPROVE/REQUEST_CHANGES)
-        - Only comment on modified lines in the diff
-        - Only suggest fixes when 100% confident, expressed in prose rather than suggestion blocks
+        - Analysis scope (broad but precise):
+            - Correctness: boundary/off-by-one error.
+            - Robustness & validation: missing input validation.
+            - API/contract misuse: wrong parameter order.
+            - Concurrency & async: race condition due to shared mutable state.
+            - Performance (evidence-based): N+1 queries.
+            - Resource management: unclosed file handle.
+            - Dead/unreachable code that affects behavior.
+            - Regression risks: breaking existing behavior or tests.
+        - Accuracy gates:
+            - Base findings on the current diff and minimal repo context available via gh; avoid speculation.
+            - Prioritize high-severity/high-confidence; cap at 10 comments.
+            - If confidence is low, ask a clarifying question rather than asserting an issue.
+            - Do not flag purely stylistic or preference-only concerns.
+        - Deduplication policy:
+            - Never repeat or re-raise an issue previously highlighted by this bot on this PR, regardless of whether the thread is marked resolved or unresolved.
+            - Do not create a new comment for a previously reported issue; if needed, reply in the existing thread with a brief status update (e.g., "Resolved ...") or skip.
+
+        Commenting rules:
+          - Max 10 inline comments total; prioritize the most critical issues
+          - One issue per comment; place on the exact changed line
+          - All issue comments MUST be inline (anchored to a file and line/position in the PR diff)
+          - Natural tone, specific and actionable; do not mention automated or high-confidence
+          - Tone: write like a junior developer who defers to the PR author; be polite and tentative, avoid authoritative language, and prefer concise, respectful phrasing.
+          - Confidence: for each potential issue, internally assess confidence as High/Medium/Low.
+              - Low confidence: phrase the comment as a question (e.g., "I noticed the code does X — did you mean to Y?") and keep it brief.
+              - Medium/High confidence: state the issue directly and concretely.
+          - False positives are very undesirable: only surface an issue when you are fairly confident it is valid; when uncertain, prefer a single clarifying question over a definitive claim.
+          - Only propose an exact code change (e.g., a concrete patch/suggestion) when you are absolutely certain the change is correct and safe; otherwise do not suggest a code change—only describe the issue succinctly.
+          - No speculative or stylistic suggestions; focus strictly on definitive fixes to high-severity issues.
+
+        Submission:
+          - If there are NO issues to report and an existing top-level comment indicating "no issues" already exists (e.g., "no issues", "No issues found", "LGTM"), do NOT submit another comment. Skip submission to avoid redundancy.
+          - If there are NO issues to report and NO prior "no issues" comment exists, submit one brief summary comment noting no issues.
+          - If there ARE issues to report and a prior "no issues" comment exists, ensure that prior comment is deleted/minimized/marked as superseded before submitting the new review.
+          - If there ARE issues to report, submit ONE review containing ONLY inline comments plus an optional concise summary body. Use the GitHub Reviews API to ensure comments are inline:
+            - Build a JSON array of comments like: [{ "path": "<file>", "position": <diff_position>, "body": "..." }]
+            - Submit via: gh api repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/reviews -f event=COMMENT -f body="$SUMMARY" -f comments='[$COMMENTS_JSON]'
+          - Do NOT use: gh pr review --approve or --request-changes
         EOF
 
         echo "Running code review analysis..."