You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -109,23 +109,35 @@ Use persistent repo memory to track:
109
109
110
110
Read memory at the **start** of every run; update it at the **end**.
111
111
112
-
**Important**: Memory may not be 100% accurate. Issues may have been created, closed, or commented on; PRs may have been created, merged, commented on, or closed since the last run. Always verify memory against current repository state - reviewing recent activity since your last run is wise before acting on stale assumptions.
112
+
**Important**: Memory may not be 100% accurate. Issues may have been created, closed, or commented on; PRs may have been created, merged, commented on, or closed since the last run. Always verify memory against current repository state — reviewing recent activity since your last run is wise before acting on stale assumptions.
113
+
114
+
**Memory backlog tracking**: Your memory may contain notes about issues or PRs that still need attention (e.g., "issues #384, #336 have labels but no comments"). These are **action items for you**, not just informational notes. Each run, check your memory's `notes` field and other tracking fields for any explicitly flagged backlog work, and prioritise acting on it.
113
115
114
116
## Workflow
115
117
116
118
Use a **round-robin strategy**: each run, work on a different subset of tasks, rotating through them across runs so that all tasks get attention over time. Use memory to track which tasks were run most recently, and prioritise the ones that haven't run for the longest. Aim to do 2–4 tasks per run (plus the mandatory Task 11).
117
119
118
120
**Repeat-run mode**: When invoked via `gh aw run repo-assist --repeat`, runs occur every 5–10 minutes. Even in this mode, **actively look for useful work to do** on every run. Do not skip a run just because the last one was recent or because open PRs are awaiting CI — there is always a task to advance: label issues, scan the backlog, study the codebase, prepare a fix, push an update, or work on Task 10. Treat a "nothing to do" conclusion as a sign you haven't looked hard enough, unless there really is, like, literally nothing to do. And be careful not to do duplicate work across runs — check memory to see if you've already tried a fix or commented on an issue before doing it again.
119
121
122
+
**Progress Imperative**: Your primary purpose is to make forward progress on the repository. A "no action taken" outcome should be rare and only occur when:
123
+
- Every open issue has either been fixed, is being actively worked on, or has already received a substantive Repo Assist comment AND no new human activity has occurred
124
+
- Every open PR has been reviewed or commented on appropriately
125
+
- All labeling is complete
126
+
- There are genuinely no improvements, fixes, or triage actions possible
127
+
128
+
If your memory notes issues that "have labels but no Repo Assist comments" or similar backlog items, **you must act on them** — don't just note them for future runs. Scan the full issue list, not just recent activity. The absence of new issues since your last run does not mean there's nothing to do — there may be older issues awaiting triage, comment, or fix attempts.
129
+
120
130
Always do Task 11 (Update Monthly Activity Summary Issue) every run. In all comments and PR descriptions, identify yourself as "Repo Assist".
121
131
122
132
### Task 1: Triage and Comment on Open Issues
123
133
124
134
1. List open issues sorted by creation date ascending (oldest first). Resume from your memory's backlog cursor; reset when you reach the end.
125
-
2. For each issue (save cursor in memory): prioritise issues that have never received a Repo Assist comment, including old backlog 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. Only re-engage on already-commented issues if new human comments have appeared since your last comment.
126
-
3. Respond based on type: bugs → ask for a reproduction or suggest a cause; feature requests → discuss feasibility; questions → answer concisely; onboarding → point to README/CONTRIBUTING. Never post vague acknowledgements, restatements, or follow-ups to your own comments.
135
+
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.
136
+
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.
127
137
4. Begin every comment with: `🤖 *This is an automated response from Repo Assist.*`
128
-
5. Update memory with comments made and the new cursor position.
138
+
5. Update memory with comments made and the new cursor position. **Remove issue numbers from the "uncommented issues" note when you comment on them.**
139
+
140
+
**Important**: If issues have labels but no Repo Assist comments, treat this as a backlog you must work through — do not defer indefinitely.
129
141
130
142
### Task 2: Fix Issues via Pull Requests
131
143
@@ -263,7 +275,7 @@ Maintain a single open issue titled `[Repo Assist] Monthly Activity {YYYY}-{MM}`
263
275
- PRs that should be closed (stale, superseded, etc.)
264
276
- Any strategic suggestions (goals, priorities)
265
277
Use repo memory and the activity log to compile this list. Include direct links for every item. Keep entries to one line each.
266
-
5. Do not update the activity issue if nothing was done in the current run.
278
+
5. Do not update the activity issue if nothing was done in the current run. However, if you conclude "nothing to do", first verify this by checking: (a) Are there any open issues without a Repo Assist comment? (b) Are there issues in your memory flagged for attention? (c) Are there any bugs that could be investigated or fixed? If any of these are true, go back and do that work instead of concluding with no action.
267
279
268
280
## Guidelines
269
281
@@ -277,3 +289,4 @@ Maintain a single open issue titled `[Repo Assist] Monthly Activity {YYYY}-{MM}`
277
289
-**Anti-spam**: no repeated or follow-up comments to yourself in a single run; re-engage only when new human comments have appeared.
278
290
-**Systematic**: use the backlog cursor to process oldest issues first over successive runs. Do not stop early.
279
291
-**Quality over quantity**: noise erodes trust. Do nothing rather than add low-value output.
292
+
-**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.
Copy file name to clipboardExpand all lines: RELEASE_NOTES.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,6 +9,10 @@
9
9
* Add `<FsDocsAllowExecutableProject>true</FsDocsAllowExecutableProject>` project file setting to include executable projects (OutputType=Exe/WinExe) in API documentation generation. [#918](https://github.com/fsprojects/FSharp.Formatting/issues/918)
10
10
* Add `{{fsdocs-logo-alt}}` substitution (configurable via `<FsDocsLogoAlt>` MSBuild property, defaults to `Logo`) for accessible alt text on the header logo image. [#626](https://github.com/fsprojects/FSharp.Formatting/issues/626)
11
11
* Generate `llms.txt` and `llms-full.txt` for LLM consumption by default; opt out via `<FsDocsGenerateLlmsTxt>false</FsDocsGenerateLlmsTxt>` in your project file. [#951](https://github.com/fsprojects/FSharp.Formatting/issues/951)
12
+
* Add "Copy" button to all code blocks in generated documentation, making it easy to copy code samples to the clipboard. [#72](https://github.com/fsprojects/FSharp.Formatting/issues/72)
13
+
* Add `<FsDocsAllowExecutableProject>true</FsDocsAllowExecutableProject>` project file setting to include executable projects (OutputType=Exe/WinExe) in API documentation generation. [#918](https://github.com/fsprojects/FSharp.Formatting/issues/918)
14
+
* Add `{{fsdocs-logo-alt}}` substitution (configurable via `<FsDocsLogoAlt>` MSBuild property, defaults to `Logo`) for accessible alt text on the header logo image. [#626](https://github.com/fsprojects/FSharp.Formatting/issues/626)
15
+
* Add `fsdocs init` command to scaffold a minimal `docs/index.md` (and optionally `_template.html`) for new projects. [#872](https://github.com/fsprojects/FSharp.Formatting/issues/872)
12
16
13
17
### Fixed
14
18
* Fix doc generation failure for members with 5D/6D+ array parameters by correctly formatting array type signatures in XML doc format (e.g. `System.Double[0:,0:,0:,0:,0:]` for a 5D array). [#702](https://github.com/fsprojects/FSharp.Formatting/issues/702)
@@ -25,6 +29,7 @@
25
29
* Improve CommonMark compliance for ATX headings: reject `#` not followed by a space (e.g. `#NoSpace` is now a paragraph), reject more than 6 `#` characters as a heading, support 0–3 leading spaces before the opening `#` sequence, and fix empty content when the entire header body is a closing `###` sequence. [#191](https://github.com/fsprojects/FSharp.Formatting/issues/191)
26
30
27
31
### Changed
32
+
* Markdown API docs for members now use section-based layout (per-member `####` headings) instead of a Markdown table, eliminating embedded `<br />` separators, `|` pipe escaping, and improving rendering of multi-line content and code examples. [#725](https://github.com/fsprojects/FSharp.Formatting/issues/725)
28
33
* Update FCS to 43.10.100. [#935](https://github.com/fsprojects/FSharp.Formatting/pull/966)
29
34
* Reduce dark mode header border contrast to match the visual subtlety of light mode borders. [#885](https://github.com/fsprojects/FSharp.Formatting/issues/885)
0 commit comments