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
Copy file name to clipboardExpand all lines: docs/daily-perf-improver.md
+73-11Lines changed: 73 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,9 +2,7 @@
2
2
3
3
> For an overview of all available workflows, see the [main README](../README.md).
4
4
5
-
**Analyze code performance, identify bottlenecks, and implement optimizations through benchmarking**
6
-
7
-
The [Daily Performance Improver workflow](../workflows/daily-perf-improver.md?plain=1) analyzes your codebase for performance issues, runs benchmarks, and creates draft pull requests with optimizations.
5
+
The [Daily Performance Improver workflow](../workflows/daily-perf-improver.md?plain=1) is a performance-focused repository assistant that runs daily to identify and implement performance improvements. It can also be triggered on-demand via `/perf-assist <instructions>` to perform specific tasks. It discovers build/benchmark commands, identifies optimization opportunities, implements improvements with measured impact, maintains its own PRs, comments on performance issues, invests in measurement infrastructure, and maintains a monthly activity summary for maintainer visibility.
8
6
9
7
## Installation
10
8
@@ -22,21 +20,70 @@ This walks you through adding the workflow to your repository.
22
20
23
21
```mermaid
24
22
graph LR
25
-
A[Analyze Codebase] --> B[Identify Bottlenecks]
26
-
B --> C[Run Benchmarks]
27
-
C --> D{Improvements Found?}
28
-
D -->|Yes| E[Implement Optimizations]
29
-
E --> F[Create Draft PR]
30
-
D -->|No| G[Report: Performance OK]
23
+
A[Read Memory] --> B[Discover Commands]
24
+
A --> C[Identify Opportunities]
25
+
A --> D[Implement Improvements]
26
+
A --> E[Maintain PRs]
27
+
A --> F[Comment on Issues]
28
+
A --> G[Invest in Infrastructure]
29
+
A --> H[Update Activity Summary]
30
+
B --> H
31
+
C --> H
32
+
D --> H
33
+
E --> H
34
+
F --> H
35
+
G --> H
36
+
H --> I[Save Memory]
31
37
```
32
38
33
-
The workflow searches for performance optimization techniques and best practices online to inform its analysis.
39
+
The workflow operates through seven coordinated tasks each run:
40
+
41
+
### Task 1: Discover and Validate Build/Test/Perf Commands
42
+
43
+
Analyzes the repository to discover build commands, test commands, benchmark commands, lint/format tools, and profiling tools. Cross-references against CI files and validates by running them. Stores validated commands in memory for future runs.
44
+
45
+
### Task 2: Identify Performance Opportunities
46
+
47
+
Researches the performance landscape: current tooling, user-facing concerns, system bottlenecks, and development workflow issues. Prioritizes opportunities by impact (user-facing > internal), feasibility (low-risk > high-risk), and measurability.
48
+
49
+
### Task 3: Implement Performance Improvements
50
+
51
+
Selects optimization goals from the backlog, establishes baseline measurements, implements optimizations, and measures impact. Creates draft PRs with evidence of performance gains, trade-offs documented, and reproducibility instructions.
52
+
53
+
### Task 4: Maintain Perf Improver Pull Requests
54
+
55
+
Keeps its own PRs healthy by fixing CI failures and resolving merge conflicts. Uses `push_to_pull_request_branch` to update PR branches directly.
56
+
57
+
### Task 5: Comment on Performance Issues
58
+
59
+
Reviews open issues with `performance` label or mentioning performance. Suggests profiling approaches, measurement strategies, and offers to investigate. Maximum 3 comments per run.
60
+
61
+
### Task 6: Invest in Performance Measurement Infrastructure
62
+
63
+
Assesses existing benchmark suites, profiling tools, and CI performance regression detection. Discovers real-world performance priorities from user issues. Proposes or implements infrastructure improvements like new benchmarks or measurement harnesses.
64
+
65
+
### Task 7: Update Monthly Activity Summary
66
+
67
+
Every run, updates a rolling monthly activity issue that gives maintainers a single place to see all performance work and suggested actions.
68
+
69
+
### Guidelines Perf Improver Follows
70
+
71
+
-**Measure everything**: No performance claim without data
72
+
-**No breaking changes**: Never changes public APIs without explicit approval
73
+
-**No new dependencies**: Discusses in an issue first
74
+
-**Small, focused PRs**: One optimization per PR for easy measurement and revert
75
+
-**Read AGENTS.md first**: Before starting work, reads project-specific conventions
76
+
-**AI transparency**: Every output includes robot emoji disclosure
77
+
-**Build, format, lint, and test verification**: Runs all checks before creating PRs
78
+
-**Exclude generated files**: Performance reports go in PR description, not commits
34
79
35
80
## Usage
36
81
82
+
The main way to use Daily Perf Improver is to let it run daily and perform its tasks autonomously. You will see its activity summarized in the monthly activity issue it maintains, and you can review its PRs and comments as they come in.
83
+
37
84
### Configuration
38
85
39
-
The first run creates a pull request with inferred action pre-steps requiring approval and an issue with a performance improvement plan. Subsequent runs implement optimizations based on the plan.
86
+
This workflow requires no configuration and works out of the box. It uses repo-memory to track work across runs and avoid duplicate actions.
40
87
41
88
After editing run `gh aw compile` to update the workflow and commit all changes to the default branch.
42
89
@@ -54,6 +101,20 @@ To run repeatedly:
54
101
gh aw run daily-perf-improver --repeat 30
55
102
```
56
103
104
+
### Usage as a General-Purpose Performance Assistant
105
+
106
+
You can also trigger Perf Improver on-demand by commenting on any issue or PR:
107
+
108
+
```text
109
+
/perf-assist <instructions>
110
+
```
111
+
112
+
When triggered this way, Perf Improver focuses exclusively on your instructions instead of running its normal scheduled tasks. For example:
113
+
114
+
-`/perf-assist profile this function and suggest optimizations`
115
+
-`/perf-assist add benchmarks for the new API endpoints`
116
+
-`/perf-assist investigate why CI is slower after this PR`
117
+
57
118
### Triggering CI on Pull Requests
58
119
59
120
To automatically trigger CI checks on PRs created by this workflow, configure an additional repository secret `GH_AW_CI_TRIGGER_TOKEN`. See the [triggering CI documentation](https://github.github.com/gh-aw/reference/triggering-ci/) for setup instructions.
@@ -63,3 +124,4 @@ To automatically trigger CI checks on PRs created by this workflow, configure an
63
124
- Review performance improvement PRs and benchmark results
64
125
- Validate performance gains through independent testing
65
126
- Assess code quality and maintainability of optimizations
127
+
- Provide feedback via comments on the monthly activity issue
> For an overview of all available workflows, see the [main README](../README.md).
4
4
5
-
**Analyze test coverage and add tests to improve coverage in under-tested areas**
6
-
7
-
The [Daily Test Coverage Improver workflow](../workflows/daily-test-improver.md?plain=1) analyzes your test coverage, writes new tests, and submits draft PRs with coverage improvements.
5
+
The [Daily Test Improver workflow](../workflows/daily-test-improver.md?plain=1) is a testing-focused repository assistant that runs daily to improve test quality and coverage. It can also be triggered on-demand via `/test-assist <instructions>` to perform specific tasks. It discovers build/test/coverage commands, identifies high-value testing opportunities, implements test improvements with measured impact, maintains its own PRs, comments on testing issues, invests in test infrastructure, and maintains a monthly activity summary for maintainer visibility.
8
6
9
7
## Installation
10
8
@@ -22,26 +20,70 @@ This walks you through adding the workflow to your repository.
22
20
23
21
```mermaid
24
22
graph LR
25
-
A[Research Testing Setup] --> B[Analyze Coverage]
26
-
B --> C[Select Target Area]
27
-
C --> D[Write New Tests]
28
-
D --> E[Validate Tests]
29
-
E --> F{Tests Pass?}
30
-
F -->|Yes| G[Create Draft PR]
31
-
F -->|No| H[Create Bug Issue]
23
+
A[Read Memory] --> B[Discover Commands]
24
+
A --> C[Identify Opportunities]
25
+
A --> D[Implement Tests]
26
+
A --> E[Maintain PRs]
27
+
A --> F[Comment on Issues]
28
+
A --> G[Invest in Infrastructure]
29
+
A --> H[Update Activity Summary]
30
+
B --> H
31
+
C --> H
32
+
D --> H
33
+
E --> H
34
+
F --> H
35
+
G --> H
36
+
H --> I[Save Memory]
32
37
```
33
38
34
-
The workflow operates in two phases:
39
+
The workflow operates through seven coordinated tasks each run:
40
+
41
+
### Task 1: Discover and Validate Build/Test/Coverage Commands
42
+
43
+
Analyzes the repository to discover build commands, test commands, coverage generation commands, lint/format tools, and testing frameworks. Cross-references against CI files and validates by running them. Stores validated commands in memory for future runs.
Researches the testing landscape: current organization, frameworks, coverage reports, and open issues. Focuses on value, not just coverage numbers - prioritizes bug-prone areas, critical paths, untested edge cases, and integration points. Records maintainer priorities from comments.
48
+
49
+
### Task 3: Implement Test Improvements
50
+
51
+
Selects testing goals from the backlog aligned with maintainer priorities. Implements new tests, edge case coverage, regression tests, or test refactoring. Creates draft PRs with coverage impact documented.
52
+
53
+
### Task 4: Maintain Test Improver Pull Requests
54
+
55
+
Keeps its own PRs healthy by fixing CI failures and resolving merge conflicts. Uses `push_to_pull_request_branch` to update PR branches directly.
56
+
57
+
### Task 5: Comment on Testing Issues
58
+
59
+
Reviews open issues mentioning tests or coverage. Suggests testing approaches, points to related patterns, and offers to implement. Maximum 3 comments per run.
60
+
61
+
### Task 6: Invest in Test Infrastructure
62
+
63
+
Assesses existing test utilities, fixtures, and CI configuration. Identifies infrastructure gaps like missing helpers or slow test suites. Proposes or implements improvements like shared fixtures or coverage reporting.
35
64
36
-
**Phase 1 - Testing Research:** On the first run, researches the testing landscape, identifies build and coverage commands, and creates a discussion with the plan. Memory notes are stored in a `memory/daily-test-improver` branch.
65
+
### Task 7: Update Monthly Activity Summary
37
66
38
-
**Phase 2 - Test Development:** On subsequent runs, consults memory notes, selects a coverage area to improve, writes new tests, and submits draft PRs.
67
+
Every run, updates a rolling monthly activity issue that gives maintainers a single place to see all testing work, maintainer priorities noted, and suggested actions.
68
+
69
+
### Guidelines Test Improver Follows
70
+
71
+
-**Value over coverage**: A test that catches real bugs beats tests that just increase coverage numbers
72
+
-**No breaking changes**: Never changes public APIs without explicit approval
73
+
-**No new dependencies**: Discusses in an issue first
74
+
-**Small, focused PRs**: One testing goal per PR for easy review
75
+
-**Read AGENTS.md first**: Before starting work, reads project-specific conventions
76
+
-**AI transparency**: Every output includes robot emoji disclosure
77
+
-**Build, format, lint, and test verification**: Runs all checks before creating PRs
78
+
-**Exclude generated files**: Coverage reports go in PR description, not commits
39
79
40
80
## Usage
41
81
82
+
The main way to use Daily Test Improver is to let it run daily and perform its tasks autonomously. You will see its activity summarized in the monthly activity issue it maintains, and you can review its PRs and comments as they come in.
83
+
42
84
### Configuration
43
85
44
-
The first run creates a discussion with a research summary and plan. Review the plan and provide feedback via comments.
86
+
This workflow requires no configuration and works out of the box. It uses repo-memory to track work across runs and avoid duplicate actions.
45
87
46
88
After editing run `gh aw compile` to update the workflow and commit all changes to the default branch.
47
89
@@ -53,12 +95,33 @@ You can start a run immediately:
53
95
gh aw run daily-test-improver
54
96
```
55
97
98
+
To run repeatedly:
99
+
100
+
```bash
101
+
gh aw run daily-test-improver --repeat 30
102
+
```
103
+
104
+
### Usage as a General-Purpose Testing Assistant
105
+
106
+
You can also trigger Test Improver on-demand by commenting on any issue or PR:
107
+
108
+
```text
109
+
/test-assist <instructions>
110
+
```
111
+
112
+
When triggered this way, Test Improver focuses exclusively on your instructions instead of running its normal scheduled tasks. For example:
113
+
114
+
-`/test-assist add tests for this new feature`
115
+
-`/test-assist investigate why this test is flaky`
116
+
-`/test-assist add edge case tests for error handling`
117
+
56
118
### Triggering CI on Pull Requests
57
119
58
120
To automatically trigger CI checks on PRs created by this workflow, configure an additional repository secret `GH_AW_CI_TRIGGER_TOKEN`. See the [triggering CI documentation](https://github.github.com/gh-aw/reference/triggering-ci/) for setup instructions.
59
121
60
122
### Human in the Loop
61
123
62
-
- Review the initial research discussion and provide feedback
124
+
- Review test improvement PRs and coverage results
63
125
- Validate that new tests properly cover edge cases
64
-
- Ensure tests are meaningful and not just coverage-padding
126
+
- Ensure tests are meaningful and maintainable
127
+
- Provide feedback via comments on the monthly activity issue
0 commit comments