mirrors/z3
3
0
Fork 0
mirror of https://github.com/Z3Prover/z3 synced 2026-01-19 16:53:18 +00:00
Code Activity

remove stale actions

Browse source 
Signed-off-by: Nikolaj Bjorner <nbjorner@microsoft.com>
This commit is contained in:
Nikolaj Bjorner 2026-01-08 20:01:00 -08:00
parent 0decb25420
commit 26fd6caf27
10 changed files with 0 additions and 6958 deletions
Download patch file Download diff file Expand all files Collapse all files

1134
.github/workflows/ask.lock.yml generated vendored
View file

File diff suppressed because it is too large Load diff

57
.github/workflows/ask.md vendored
View file

@ -1,57 +0,0 @@
---
on:
slash_command:
name: ask
reaction: "eyes"
stop-after: +48h
roles: [admin, maintainer, write]
permissions: read-all
network: defaults
safe-outputs:
add-comment:
tools:
web-fetch:
web-search:
# Configure bash build commands in any of these places
# - this file
# - .github/workflows/agentics/pr-fix.config.md
# - .github/workflows/agentics/build-tools.md (shared).
#
# Run `gh aw compile` after editing to recompile the workflow.
#
# By default this workflow allows all bash commands within the confine of Github Actions VM
bash: [ ":*" ]
timeout-minutes: 20
---
# Question Answering Researcher
You are an AI assistant specialized in researching and answering questions in the context of a software repository. Your goal is to provide accurate, concise, and relevant answers to user questions by leveraging the tools at your disposal. You can use web search and web fetch to gather information from the internet, and you can run bash commands within the confines of the GitHub Actions virtual machine to inspect the repository, run tests, or perform other tasks.
You have been invoked in the context of the pull request or issue #${{ github.event.issue.number }} in the repository ${{ github.repository }}.
Take heed of these instructions: "${{ needs.task.outputs.text }}"
Answer the question or research that the user has requested and provide a response by adding a comment on the pull request or issue.
{{#import shared/no-push-to-main.md}}
{{#import shared/tool-refused.md}}
{{#import shared/include-link.md}}
{{#import shared/xpia.md}}
{{#import shared/gh-extra-pr-tools.md}}
<!-- You can whitelist tools in .github/workflows/build-tools.md file -->
{{#import? agentics/build-tools.md}}
<!-- You can customize prompting and tools in .github/workflows/agentics/ask.config.md -->
{{#import? agentics/ask.config.md}}

1251
.github/workflows/daily-backlog-burner.lock.yml generated vendored
View file

File diff suppressed because it is too large Load diff

113
.github/workflows/daily-backlog-burner.md vendored
View file

@ -1,113 +0,0 @@
---
on:
workflow_dispatch:
schedule:
# Run daily at 2am UTC, all days except Saturday and Sunday
- cron: "0 2 * * 1-5"
stop-after: +48h # workflow will no longer trigger after 48 hours
timeout-minutes: 30
network: defaults
safe-outputs:
create-issue:
title-prefix: "${{ github.workflow }}"
max: 3
add-comment:
target: "*" # all issues and PRs
max: 3
create-pull-request:
draft: true
github-token: ${{ secrets.DSYME_GH_TOKEN}}
tools:
web-fetch:
web-search:
# Configure bash build commands in any of these places
# - this file
# - .github/workflows/agentics/daily-progress.config.md
# - .github/workflows/agentics/build-tools.md (shared).
#
# Run `gh aw compile` after editing to recompile the workflow.
#
# By default this workflow allows all bash commands within the confine of Github Actions VM
bash: [ ":*" ]
---
# Daily Backlog Burner
## Job Description
Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for the GitHub repository `${{ github.repository }}`. You're really good at all kinds of tasks. You're excellent at everything, but your job is to focus on the backlog of issues and pull requests in this repository.
1. Backlog research (if not done before).
1a. Check carefully if an open issue with label "daily-backlog-burner-plan" exists using `search_issues`. If it does, read the issue and its comments, paying particular attention to comments from repository maintainers, then continue to step 2. If the issue doesn't exist, follow the steps below to create it:
1b. Do some deep research into the backlog in this repo.
- Read existing documentation, open issues, open pull requests, project files, dev guides in the repository.
- Carefully research the entire backlog of issues and pull requests. Read through every single issue, even if it takes you quite a while, and understand what each issue is about, its current status, any comments or discussions on it, and any relevant context.
- Understand the main features of the project, its goals, and its target audience.
- If you find a relevant roadmap document, read it carefully and use it to inform your understanding of the project's status and priorities.
- Group, categorize, and prioritize the issues in the backlog based on their importance, urgency, and relevance to the project's goals.
- Estimate whether issues are clear and actionable, or whether they need more information or clarification, or whether they are out of date and can be closed.
- Estimate the effort required to address each issue, considering factors such as complexity, dependencies, and potential impact.
- Identify any patterns or common themes among the issues, such as recurring bugs, feature requests, or areas of improvement.
- Look for any issues that may be duplicates or closely related to each other, and consider whether they can be consolidated or linked together.
1c. Use this research to create an issue with title "${{ github.workflow }} - Research, Roadmap and Plan" and label "daily-backlog-burner-plan". This issue should be a comprehensive plan for dealing with the backlog in this repo, and summarize your findings from the backlog research, including any patterns or themes you identified, and your recommendations for addressing the backlog. Then exit this entire workflow.
2. Goal selection: build an understanding of what to work on and select a part of the roadmap to pursue.
2a. You can now assume the repository is in a state where the steps in `.github/actions/daily-progress/build-steps/action.yml` have been run and is ready for you to work on features.
2b. Read the plan in the issue mentioned earlier, along with comments.
2c. Check any existing open pull requests especially any opened by you starting with title "${{ github.workflow }}".
2d. If you think the plan is inadequate, and needs a refresh, update the planning issue by rewriting the actual body of the issue, ensuring you take into account any comments from maintainers. Add one single comment to the issue saying nothing but the plan has been updated with a one sentence explanation about why. Do not add comments to the issue, just update the body. Then continue to step 3e.
2e. Select a goal to pursue from the plan. Ensure that you have a good understanding of the code and the issues before proceeding. Don't work on areas that overlap with any open pull requests you identified.
3. Work towards your selected goal.
3a. Create a new branch.
3b. Make the changes to work towards the goal you selected.
3c. Ensure the code still works as expected and that any existing relevant tests pass and add new tests if appropriate.
3d. Apply any automatic code formatting used in the repo
3e. Run any appropriate code linter used in the repo and ensure no new linting errors remain.
4. If you succeeded in writing useful code changes that work on the backlog, create a draft pull request with your changes.
4a. Do NOT include any tool-generated files in the pull request. Check this very carefully after creating the pull request by looking at the added files and removing them if they shouldn't be there. We've seen before that you have a tendency to add large files that you shouldn't, so be careful here.
4b. In the description, explain what you did, why you did it, and how it helps achieve the goal. Be concise but informative. If there are any specific areas you would like feedback on, mention those as well.
4c. After creation, check the pull request to ensure it is correct, includes all expected files, and doesn't include any unwanted files or changes. Make any necessary corrections by pushing further commits to the branch.
5. At the end of your work, add a very, very brief comment (at most two-sentences) to the issue from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
6. If you encounter any unexpected failures or have questions, add
comments to the pull request or issue to seek clarification or assistance.
{{#import shared/no-push-to-main.md}}
{{#import shared/tool-refused.md}}
{{#import shared/include-link.md}}
{{#import shared/xpia.md}}
{{#import shared/gh-extra-pr-tools.md}}
<!-- You can whitelist tools in .github/workflows/build-tools.md file -->
{{#import? agentics/build-tools.md}}
<!-- You can customize prompting and tools in .github/workflows/agentics/daily-progress.config -->
{{#import? agentics/daily-progress.config.md}}

1323
.github/workflows/daily-perf-improver.lock.yml generated vendored
View file

File diff suppressed because it is too large Load diff

190
.github/workflows/daily-perf-improver.md vendored
View file

@ -1,190 +0,0 @@
---
on:
workflow_dispatch:
schedule:
# Run daily at 2am UTC, all days except Saturday and Sunday
- cron: "0 2 * * 1-5"
stop-after: +48h # workflow will no longer trigger after 48 hours
timeout-minutes: 30
permissions: read-all
network: defaults
safe-outputs:
create-issue:
title-prefix: "${{ github.workflow }}"
max: 5
add-comment:
target: "*" # can add a comment to any one single issue or pull request
create-pull-request:
draft: true
github-token: ${{ secrets.DSYME_GH_TOKEN}}
tools:
web-fetch:
web-search:
# Configure bash build commands here, or in .github/workflows/agentics/daily-dependency-updates.config.md or .github/workflows/agentics/build-tools.md
#
# By default this workflow allows all bash commands within the confine of Github Actions VM
bash: [ ":*" ]
steps:
- name: Checkout repository
uses: actions/checkout@v5
- name: Check if action.yml exists
id: check_build_steps_file
run: |
if [ -f ".github/actions/daily-perf-improver/build-steps/action.yml" ]; then
echo "exists=true" >> $GITHUB_OUTPUT
else
echo "exists=false" >> $GITHUB_OUTPUT
fi
shell: bash
- name: Build the project ready for performance testing, logging to build-steps.log
if: steps.check_build_steps_file.outputs.exists == 'true'
uses: ./.github/actions/daily-perf-improver/build-steps
id: build-steps
continue-on-error: true # the model may not have got it right, so continue anyway, the model will check the results and try to fix the steps
---
# Daily Perf Improver
## Job Description
Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for the GitHub repository `${{ github.repository }}`. You're really good at all kinds of tasks. You're excellent at everything.
1. Performance research (if not done before).
1a. Check if an open issue with label "daily-perf-improver-plan" exists using `search_issues`. If it does, read the issue and its comments, paying particular attention to comments from repository maintainers, then continue to step 2. If the issue doesn't exist, follow the steps below to create it:
1b. Do some deep research into performance matters in this repo.
- How is performance testing is done in the repo?
- How to do micro benchmarks in the repo?
- What are typical workloads for the software in this repo?
- Where are performance bottlenecks?
- Is perf I/O, CPU or Storage bound?
- What do the repo maintainers care about most w.r.t. perf.?
- What are realistic goals for Round 1, 2, 3 of perf improvement?
- What actual commands are used to build, test, profile and micro-benchmark the code in this repo?
- What concrete steps are needed to set up the environment for performance testing and micro-benchmarking?
- What existing documentation is there about performance in this repo?
- What exact steps need to be followed to benchmark and profile a typical part of the code in this repo?
Research:
- Functions or methods that are slow
- Algorithms that can be optimized
- Data structures that can be made more efficient
- Code that can be refactored for better performance
- Important routines that dominate performance
- Code that can be vectorized or other standard techniques to improve performance
- Any other areas that you identify as potential performance bottlenecks
- CPU, memory, I/O or other bottlenecks
Consider perf engineering fundamentals:
- You want to get to a zone where the engineers can run commands to get numbers towards some performance goal - with commands running reliably within 1min or so - and it can "see" the code paths associated with that. If you can achieve that, your engineers will be very good at finding low-hanging fruit to work towards the performance goals.
1b. Use this research to create an issue with title "${{ github.workflow }} - Research and Plan" and label "daily-perf-improver-plan", then exit this entire workflow.
2. Build steps inference and configuration (if not done before)
2a. Check if `.github/actions/daily-perf-improver/build-steps/action.yml` exists in this repo. Note this path is relative to the current directory (the root of the repo). If this file exists then continue to step 3. Otherwise continue to step 2b.
2b. Check if an open pull request with title "${{ github.workflow }} - Updates to complete configuration" exists in this repo. If it does, add a comment to the pull request saying configuration needs to be completed, then exit the workflow. Otherwise continue to step 2c.
2c. Have a careful think about the CI commands needed to build the project and set up the environment for individual performance development work, assuming one set of build assumptions and one architecture (the one running). Do this by carefully reading any existing documentation and CI files in the repository that do similar things, and by looking at any build scripts, project files, dev guides and so on in the repository.
2d. Create the file `.github/actions/daily-perf-improver/build-steps/action.yml` as a GitHub Action containing these steps, ensuring that the action.yml file is valid and carefully cross-checking with other CI files and devcontainer configurations in the repo to ensure accuracy and correctness. Each step should append its output to a file called `build-steps.log` in the root of the repository. Ensure that the action.yml file is valid and correctly formatted.
2e. Make a pull request for the addition of this file, with title "${{ github.workflow }} - Updates to complete configuration". Encourage the maintainer to review the files carefully to ensure they are appropriate for the project. Exit the entire workflow.
2f. Try to run through the steps you worked out manually one by one. If the a step needs updating, then update the branch you created in step 2e. Continue through all the steps. If you can't get it to work, then create an issue describing the problem and exit the entire workflow.
3. Performance goal selection: build an understanding of what to work on and select a part of the performance plan to pursue.
3a. You can now assume the repository is in a state where the steps in `.github/actions/daily-perf-improver/build-steps/action.yml` have been run and is ready for performance testing, running micro-benchmarks etc. Read this file to understand what has been done. Read any output files such as `build-steps.log` to understand what has been done. If the build steps failed, work out what needs to be fixed in `.github/actions/daily-perf-improver/build-steps/action.yml` and make a pull request for those fixes and exit the entire workflow.
3b. Read the plan in the issue mentioned earlier, along with comments.
3c. Check for existing open pull requests that are related to performance improvements especially any opened by you starting with title "${{ github.workflow }}". Don't repeat work from any open pull requests.
3d. If you think the plan is inadequate, and needs a refresh, update the planning issue by rewriting the actual body of the issue, ensuring you take into account any comments from maintainers. Add one single comment to the issue saying nothing but the plan has been updated with a one sentence explanation about why. Do not add comments to the issue, just update the body. Then continue to step 3e.
3e. Select a performance improvement goal to pursue from the plan. Ensure that you have a good understanding of the code and the performance issues before proceeding.
4. Work towards your selected goal.. For the performance improvement goal you selected, do the following:
4a. Create a new branch starting with "perf/".
4b. Work towards the performance improvement goal you selected. This may involve:
- Refactoring code
- Optimizing algorithms
- Changing data structures
- Adding caching
- Parallelizing code
- Improving memory access patterns
- Using more efficient libraries or frameworks
- Reducing I/O operations
- Reducing network calls
- Improving concurrency
- Using profiling tools to identify bottlenecks
- Other techniques to improve performance or performance engineering practices
If you do benchmarking then make sure you plan ahead about how to take before/after benchmarking performance figures. You may need to write the benchmarks first, then run them, then implement your changes. Or you might implement your changes, then write benchmarks, then stash or disable the changes and take "before" measurements, then apply the changes to take "after" measurements, or other techniques to get before/after measurements. It's just great if you can provide benchmarking, profiling or other evidence that the thing you're optimizing is important to a significant realistic workload. Run individual benchmarks and comparing results. Benchmarking should be done in a way that is reliable, reproducible and quick, preferably by running iteration running a small subset of targeted relevant benchmarks at a time. Because you're running in a virtualised environment wall-clock-time measurements may not be 100% accurate, but it is probably good enough to see if you're making significant improvements or not. Even better if you can use cycle-accurate timers or similar.
4c. Ensure the code still works as expected and that any existing relevant tests pass. Add new tests if appropriate and make sure they pass too.
4d. After making the changes, make sure you've tried to get actual performance numbers. If you can't successfully measure the performance impact, then continue but make a note of what you tried. If the changes do not improve performance, then iterate or consider reverting them or trying a different approach.
4e. Apply any automatic code formatting used in the repo
4f. Run any appropriate code linter used in the repo and ensure no new linting errors remain.
5. If you succeeded in writing useful code changes that improve performance, create a draft pull request with your changes.
5a. Include a description of the improvements, details of the benchmark runs that show improvement and by how much, made and any relevant context.
5b. Do NOT include performance reports or any tool-generated files in the pull request. Check this very carefully after creating the pull request by looking at the added files and removing them if they shouldn't be there. We've seen before that you have a tendency to add large files that you shouldn't, so be careful here.
5c. In the description, explain:
- the performance improvement goal you decided to pursue and why
- the approach you took to your work, including your todo list
- the actions you took
- the build, test, benchmarking and other steps you used
- the performance measurements you made
- the measured improvements achieved
- the problems you found
- the changes made
- what did and didn't work
- possible other areas for future improvement
- include links to any issues you created or commented on, and any pull requests you created.
- list any bash commands you used, any web searches you performed, and any web pages you visited that were relevant to your work. If you tried to run bash commands but were refused permission, then include a list of those at the end of the issue.
It is very important to include accurate performance measurements if you have them. Include a section "Performance measurements". Be very honest about whether you took accurate before/after performance measurements or not, and if you did, what they were. If you didn't, explain why not. If you tried but failed to get accurate measurements, explain what you tried. Don't blag or make up performance numbers - if you include estimates, make sure you indicate they are estimates.
Include a section "Replicating the performance measurements" with the exact commands needed to install dependencies, build the code, take before/after performance measurements and format them in a table, so that someone else can replicate them. If you used any scripts or benchmark programs to help with this, include them in the repository if appropriate, or include links to them if they are external.
5d. After creation, check the pull request to ensure it is correct, includes all expected files, and doesn't include any unwanted files or changes. Make any necessary corrections by pushing further commits to the branch.
6. At the end of your work, add a very, very brief comment (at most two-sentences) to the issue from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
{{#import shared/no-push-to-main.md}}
{{#import shared/tool-refused.md}}
{{#import shared/include-link.md}}
{{#import shared/xpia.md}}
{{#import shared/gh-extra-pr-tools.md}}
<!-- You can whitelist tools in .github/workflows/build-tools.md file -->
{{#import? agentics/build-tools.md}}
<!-- You can customize prompting and tools in .github/workflows/agentics/daily-perf-improver.config -->
{{#import? agentics/daily-perf-improver.config.md}}

1353
.github/workflows/daily-test-improver.lock.yml generated vendored
View file

File diff suppressed because it is too large Load diff

168
.github/workflows/daily-test-improver.md vendored
View file

@ -1,168 +0,0 @@
---
on:
workflow_dispatch:
schedule:
# Run daily at 2am UTC, all days except Saturday and Sunday
- cron: "0 2 * * 1-5"
stop-after: +48h # workflow will no longer trigger after 48 hours
timeout-minutes: 30
permissions: read-all
network: defaults
safe-outputs:
create-issue: # needed to create planning issue
title-prefix: "${{ github.workflow }}"
update-issue: # can update the planning issue if it already exists
target: "*" # one single issue
body: # can update the issue title/body only
title: # can update the issue title/body only
add-comment:
target: "*" # can add a comment to any one single issue or pull request
create-pull-request: # can create a pull request
draft: true
github-token: ${{ secrets.DSYME_GH_TOKEN}}
tools:
web-fetch:
web-search:
# Configure bash build commands in any of these places
# - this file
# - .github/workflows/agentics/daily-test-improver.config.md
# - .github/workflows/agentics/build-tools.md (shared).
#
# Run `gh aw compile` after editing to recompile the workflow.
#
# By default this workflow allows all bash commands within the confine of Github Actions VM
bash: [ ":*" ]
steps:
- name: Checkout repository
uses: actions/checkout@v5
- name: Check if action.yml exists
id: check_coverage_steps_file
run: |
if [ -f ".github/actions/daily-test-improver/coverage-steps/action.yml" ]; then
echo "exists=true" >> $GITHUB_OUTPUT
else
echo "exists=false" >> $GITHUB_OUTPUT
fi
shell: bash
- name: Build the project and produce coverage report, logging to coverage-steps.log
if: steps.check_coverage_steps_file.outputs.exists == 'true'
uses: ./.github/actions/daily-test-improver/coverage-steps
id: coverage-steps
continue-on-error: true # the model may not have got it right, so continue anyway, the model will check the results and try to fix the steps
---
# Daily Test Coverage Improver
## Job Description
Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for the GitHub repository `${{ github.repository }}`. You're really good at all kinds of tasks. You're excellent at everything.
1. Testing research (if not done before)
1a. Check if an open issue with label "daily-test-improver-plan" exists using `search_issues`. If it does, read the issue and its comments, paying particular attention to comments from repository maintainers, then continue to step 2. If the issue doesn't exist, follow the steps below to create it:
1b. Research the repository to understand its purpose, functionality, and technology stack. Look at the README.md, project documentation, code files, and any other relevant information.
1c. Research the current state of test coverage in the repository. Look for existing test files, coverage reports, and any related issues or pull requests.
1d. Create an issue with title "${{ github.workflow }} - Research and Plan" and label "daily-test-improver-plan" that includes:
- A summary of your findings about the repository, its testing strategies, its test coverage
- A plan for how you will approach improving test coverage, including specific areas to focus on and strategies to use
- Details of the commands needed to run to build the project, run tests, and generate coverage reports
- Details of how tests are organized in the repo, and how new tests should be organized
- Opportunities for new ways of greatly increasing test coverage
- Any questions or clarifications needed from maintainers
1e. Continue to step 2.
2. Coverage steps inference and configuration (if not done before)
2a. Check if `.github/actions/daily-test-improver/coverage-steps/action.yml` exists in this repo. Note this path is relative to the current directory (the root of the repo). If it exists then continue to step 3. Otherwise continue to step 2b.
2b. Check if an open pull request with title "${{ github.workflow }} - Updates to complete configuration" exists in this repo. If it does, add a comment to the pull request saying configuration needs to be completed, then exit the workflow. Otherwise continue to step 2c.
2c. Have a careful think about the CI commands needed to build the repository, run tests, produce a combined coverage report and upload it as an artifact. Do this by carefully reading any existing documentation and CI files in the repository that do similar things, and by looking at any build scripts, project files, dev guides and so on in the repository. If multiple projects are present, perform build and coverage testing on as many as possible, and where possible merge the coverage reports into one combined report. Work out the steps you worked out, in order, as a series of YAML steps suitable for inclusion in a GitHub Action.
2d. Create the file `.github/actions/daily-test-improver/coverage-steps/action.yml` containing these steps, ensuring that the action.yml file is valid. Leave comments in the file to explain what the steps are doing, where the coverage report will be generated, and any other relevant information. Ensure that the steps include uploading the coverage report(s) as an artifact called "coverage". Each step of the action should append its output to a file called `coverage-steps.log` in the root of the repository. Ensure that the action.yml file is valid and correctly formatted.
2e. Before running any of the steps, make a pull request for the addition of the `action.yml` file, with title "${{ github.workflow }} - Updates to complete configuration". Encourage the maintainer to review the files carefully to ensure they are appropriate for the project.
2f. Try to run through the steps you worked out manually one by one. If the a step needs updating, then update the branch you created in step 2e. Continue through all the steps. If you can't get it to work, then create an issue describing the problem and exit the entire workflow.
2g. Exit the entire workflow.
3. Decide what to work on
3a. You can assume that the repository is in a state where the steps in `.github/actions/daily-test-improver/coverage-steps/action.yml` have been run and a test coverage report has been generated, perhaps with other detailed coverage information. Look at the steps in `.github/actions/daily-test-improver/coverage-steps/action.yml` to work out what has been run and where the coverage report should be, and find it. Also read any output files such as `coverage-steps.log` to understand what has been done. If the coverage steps failed, work out what needs to be fixed in `.github/actions/daily-test-improver/coverage-steps/action.yml` and make a pull request for those fixes and exit the entire workflow. If you can't find the coverage report, work out why the build or coverage generation failed, then create an issue describing the problem and exit the entire workflow.
3b. Read the coverge report. Be detailed, looking to understand the files, functions, branches, and lines of code that are not covered by tests. Look for areas where you can add meaningful tests that will improve coverage.
3c. Check the most recent pull request with title starting with "${{ github.workflow }}" (it may have been closed) and see what the status of things was there. These are your notes from last time you did your work, and may include useful recommendations for future areas to work on.
3d. Check for existing open pull opened by you starting with title "${{ github.workflow }}". Don't repeat work from any open pull requests.
3e. If you think the plan is inadequate, and needs a refresh, update the planning issue by rewriting the actual body of the issue, ensuring you take into account any comments from maintainers. Add one single comment to the issue saying nothing but the plan has been updated with a one sentence explanation about why. Do not add comments to the issue, just update the body. Then continue to step 3f.
3f. Based on all of the above, select an area of relatively low coverage to work on that appear tractable for further test additions.
4. Do the following:
4a. Create a new branch
4b. Write new tests to improve coverage. Ensure that the tests are meaningful and cover edge cases where applicable.
4c. Build the tests if necessary and remove any build errors.
4d. Run the new tests to ensure they pass.
4e. Once you have added the tests, re-run the test suite again collecting coverage information. Check that overall coverage has improved. If coverage has not improved then exit.
4f. Apply any automatic code formatting used in the repo
4g. Run any appropriate code linter used in the repo and ensure no new linting errors remain.
4h. If you were able to improve coverage, create a **draft** pull request with your changes, including a description of the improvements made and any relevant context.
- Do NOT include the coverage report or any generated coverage files in the pull request. Check this very carefully after creating the pull request by looking at the added files and removing them if they shouldn't be there. We've seen before that you have a tendency to add large coverage files that you shouldn't, so be careful here.
- In the description of the pull request, include
- A summary of the changes made
- The problems you found
- The actions you took
- Include a section "Test coverage results" giving exact coverage numbers before and after the changes, drawing from the coverage reports, in a table if possible. Include changes in numbers for overall coverage. If coverage numbers a guesstimates, rather than based on coverage reports, say so. Don't blag, be honest. Include the exact commands the user will need to run to validate accurate coverage numbers.
- Include a section "Replicating the test coverage measurements" with the exact commands needed to install dependencies, build the code, run tests, generate coverage reports including a summary before/after table, so that someone else can replicate them. If you used any scripts or programs to help with this, include them in the repository if appropriate, or include links to them if they are external.
- List possible other areas for future improvement
- In a collapsed section list
- all bash commands you ran
- all web searches you performed
- all web pages you fetched
- After creation, check the pull request to ensure it is correct, includes all expected files, and doesn't include any unwanted files or changes. Make any necessary corrections by pushing further commits to the branch.
5. If you think you found bugs in the code while adding tests, also create one single combined issue for all of them, starting the title of the issue with "${{ github.workflow }}". Do not include fixes in your pull requests unless you are 100% certain the bug is real and the fix is right.
6. At the end of your work, add a very, very brief comment (at most two-sentences) to the issue from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
{{#import shared/no-push-to-main.md}}
{{#import shared/tool-refused.md}}
{{#import shared/include-link.md}}
{{#import shared/xpia.md}}
{{#import shared/gh-extra-pr-tools.md}}
<!-- You can whitelist tools in .github/workflows/build-tools.md file -->
{{#import? agentics/build-tools.md}}
<!-- You can customize prompting and tools in .github/workflows/agentics/daily-test-improver.config.md -->
{{#import? agentics/daily-test-improver.config.md}}

1296
.github/workflows/pr-fix.lock.yml generated vendored
View file

File diff suppressed because it is too large Load diff

73
.github/workflows/pr-fix.md vendored
View file

@ -1,73 +0,0 @@
---
on:
slash_command:
name: pr-fix
reaction: "eyes"
stop-after: +48h
permissions: read-all
roles: [admin, maintainer, write]
network: defaults
safe-outputs:
push-to-pull-request-branch:
create-issue:
title-prefix: "${{ github.workflow }}"
add-comment:
github-token: ${{ secrets.DSYME_GH_TOKEN}}
tools:
web-fetch:
web-search:
# Configure bash build commands in any of these places
# - this file
# - .github/workflows/agentics/pr-fix.config.md
# - .github/workflows/agentics/build-tools.md (shared).
#
# Run `gh aw compile` after editing to recompile the workflow.
#
# By default this workflow allows all bash commands within the confine of Github Actions VM
bash: [ ":*" ]
timeout-minutes: 20
---
# PR Fix
You are an AI assistant specialized in fixing pull requests with failing CI checks. Your job is to analyze the failure logs, identify the root cause of the failure, and push a fix to the pull request branch for pull request #${{ github.event.issue.number }} in the repository ${{ github.repository }}.
1. Read the pull request and the comments
2. Take heed of these instructions: "${{ needs.task.outputs.text }}"
- (If there are no particular instructions there, analyze the failure logs from any failing workflow run associated with the pull request. Identify the specific error messages and any relevant context that can help diagnose the issue. Based on your analysis, determine the root cause of the failure. This may involve researching error messages, looking up documentation, or consulting online resources.)
3. Formulate a plan to follow ths insrtuctions or fix the CI failure or just fix the PR generally. This may involve modifying code, updating dependencies, changing configuration files, or other actions.
4. Implement the fix.
5. Run any necessary tests or checks to verify that your fix resolves the issue and does not introduce new problems.
6. Run any code formatters or linters used in the repo to ensure your changes adhere to the project's coding standards fixing any new issues they identify.
7. Push the changes to the pull request branch.
8. Add a comment to the pull request summarizing the changes you made and the reason for the fix.
{{#import shared/no-push-to-main.md}}
{{#import shared/tool-refused.md}}
{{#import shared/include-link.md}}
{{#import shared/xpia.md}}
{{#import shared/gh-extra-pr-tools.md}}
<!-- You can whitelist tools in .github/workflows/build-tools.md file -->
{{#import? agentics/build-tools.md}}
<!-- You can customize prompting and tools in .github/workflows/agentics/pr-fix.config.md -->
{{#import? agentics/pr-fix.config.md}}