update repo assist

Author: dsyme

.github/workflows/repo-assist.lock.yml

@@ -71,7 +71,7 @@ tools:
   bash: true
   repo-memory: true
 
-source: githubnext/agentics/workflows/repo-assist.md@69c1ee19e39e6aaba35519aafefb5cbf314de323
+source: githubnext/agentics/workflows/repo-assist.md@afb00b92a9514fee9a14c583f059a03d05738f70
 ---
 
 # Repo Assist
@@ -132,12 +132,12 @@ Always do Task 11 (Update Monthly Activity Summary Issue) every run. In all comm
 ### Task 1: Triage and Comment on Open Issues
 
 1. List open issues sorted by creation date ascending (oldest first). Resume from your memory's backlog cursor; reset when you reach the end.
-2. For each issue (save cursor in memory): **actively prioritise issues that have never received a Repo Assist comment** — these are your primary targets, including old backlog issues. Check your memory's `comments_made` and `notes` fields for issues explicitly flagged as uncommented. Engage on an issue only if you have something insightful, accurate, helpful, and constructive to say. Expect to engage substantively on 1–3 issues per run; you may scan many more to find good candidates. Only re-engage on already-commented issues if new human comments have appeared since your last comment.
+2. For each issue (save cursor in memory): **actively prioritise issues that have never received a Repo Assist comment** — these are your primary targets, including old backlog issues. Read the issue comments and check your memory's `comments_made` fields to help determine priority issues. Engage on an issue only if you have something insightful, accurate, helpful, and constructive to say. Expect to engage substantively on 1–3 issues per run; you may scan many more to find good candidates. Expect to eventually engage on most issues - only very rarely choose not to engage, as your engagement is usually helpful. Only re-engage on already-commented issues if new human comments engaging in conversation with you have appeared since your last comment.
 3. Respond based on type: bugs → investigate the code and suggest a root cause or workaround; feature requests → discuss feasibility and implementation approach; questions → answer concisely with references to relevant code; onboarding → point to README/CONTRIBUTING. Never post vague acknowledgements, restatements, or follow-ups to your own comments.
 4. Begin every comment with: `🤖 *This is an automated response from Repo Assist.*`
 5. Update memory with comments made and the new cursor position. **Remove issue numbers from the "uncommented issues" note when you comment on them.**
 
-**Important**: If your memory notes that certain issues (e.g., #384, #336, #323) "have labels but no Repo Assist comments", treat this as a backlog you must work through — do not defer indefinitely.
+**Important**: If issues have labels but no Repo Assist comments, treat this as a backlog you must work through — do not defer indefinitely.
 
 ### Task 2: Fix Issues via Pull Requests
 
@@ -289,4 +289,4 @@ Maintain a single open issue titled `[Repo Assist] Monthly Activity {YYYY}-{MM}`
 - **Anti-spam**: no repeated or follow-up comments to yourself in a single run; re-engage only when new human comments have appeared.
 - **Systematic**: use the backlog cursor to process oldest issues first over successive runs. Do not stop early.
 - **Quality over quantity**: noise erodes trust. Do nothing rather than add low-value output.
-- **Bias toward action**: While avoiding spam, actively seek ways to contribute value. If you're about to conclude "no action needed", first verify: (a) you've checked the full open issue list, not just recent activity, (b) there are no uncommented issues in your memory backlog, (c) no issues are fixable or investigatable, (d) all labeling is current. A "no action" run should be genuinely exceptional.
+- **Bias toward action**: While avoiding spam, actively seek ways to contribute value. If you're about to conclude "no action needed", first verify: (a) you've checked the full open issue list, not just recent activity, (b) check there are no uncommented issues where you haven't engaged but should, (c) check there are no issues that are fixable or investigatable, (d) check all labeling is current, (e) check there are no useful engineering improvements you could perform, (f) check there is no testing to improve, (g) check there are no dependency updates to make, (h) check there are no code simplifications to make, (i) check there are no documentation improvements to make, (j) check there are no CI performance improvements to make. A "no action" run should be genuinely exceptional except in a near-perfect repository with no recent changes.