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: .cursor/rules/general.mdc
+13-10Lines changed: 13 additions & 10 deletions
Original file line number
Diff line number
Diff line change
@@ -8,23 +8,26 @@ alwaysApply: true
8
8
9
9
- Name: @exercode/problem-utils
10
10
- Description: :100: A set of utilities for judging programs on Exercode (https://exercode.willbooster.com/).
11
-
- Package Manager: yarn
11
+
- Package Manager: yarn on zsh
12
12
13
13
## General Instructions
14
14
15
+
- Create a new branch if the current branch is `main`.
15
16
- Do not write tests unless explicitly requested.
16
17
- When fixing tests, gather debug information through logging and screenshots before modifying the code.
17
-
- After making code changes, run `yarn check-all-for-ai` to execute all tests (note: this may take up to 30 minutes), or run `yarn check-for-ai` for type checking and linting only.
18
+
- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or run `yarn check-for-ai` for type checking and linting only (takes up to 10 minutes).
18
19
- If you are confident your changes will not break any tests, you may use `check-for-ai`.
19
-
- Once you have verified your changes, commit them to the non-main branch using the `--no-verify` option and push to the current branch.
20
-
- Follow conventional commits, i.e., your commit message should start with `feat:`, `fix:`, etc.
21
-
- Make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Cursor) <agent@willbooster.com>`.
20
+
- Once you have verified your changes, commit them to a non-main branch using the `--no-verify` option and push to the current branch.
21
+
- Follow conventional commits; your commit message should start with `feat:`, `fix:`, etc.
22
+
- If not specified, make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Cursor) <agent@willbooster.com>`.
22
23
- Always create new commits. Avoid using `--amend`.
23
24
24
25
## Coding Style
25
26
26
-
- Write comments that explain "why" rather than "what". Avoid explanations that can be understood from the code itself.
27
-
- Use stderr for logging debug messages temporarily since stdout output is sometimes omitted.
28
-
- When adding new functions or classes, define them below any functions or classes that call them to maintain clear call order.
29
-
- Prefer `undefined` over `null` unless explicitly dealing with APIs or libraries that require `null`.
30
-
- Always perform existence checks on array due to `noUncheckedIndexedAccess: true`.
27
+
- Simplify code as much as possible to eliminate redundancy.
28
+
- Design each module with high cohesion, grouping related functionality together.
29
+
- Refactor existing large modules into smaller, focused modules when necessary.
30
+
- Create well-organized directory structures with low coupling and high cohesion.
31
+
- When adding new functions or classes, define them below any functions or classes that call them to maintain a clear top-down call order.
32
+
- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
33
+
- Prefer `undefined` over `null` unless explicitly required by APIs or libraries.
Copy file name to clipboardExpand all lines: AGENTS.md
+13-10Lines changed: 13 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,23 +2,26 @@
2
2
3
3
- Name: @exercode/problem-utils
4
4
- Description: :100: A set of utilities for judging programs on Exercode (https://exercode.willbooster.com/).
5
-
- Package Manager: yarn
5
+
- Package Manager: yarn on zsh
6
6
7
7
## General Instructions
8
8
9
+
- Create a new branch if the current branch is `main`.
9
10
- Do not write tests unless explicitly requested.
10
11
- When fixing tests, gather debug information through logging and screenshots before modifying the code.
11
-
- After making code changes, run `yarn check-all-for-ai` to execute all tests (note: this may take up to 30 minutes), or run `yarn check-for-ai` for type checking and linting only.
12
+
- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or run `yarn check-for-ai` for type checking and linting only (takes up to 10 minutes).
12
13
- If you are confident your changes will not break any tests, you may use `check-for-ai`.
13
-
- Once you have verified your changes, commit them to the non-main branch using the `--no-verify` option and push to the current branch.
14
-
- Follow conventional commits, i.e., your commit message should start with `feat:`, `fix:`, etc.
15
-
-Make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Codex CLI) <agent@willbooster.com>`.
14
+
- Once you have verified your changes, commit them to a non-main branch using the `--no-verify` option and push to the current branch.
15
+
- Follow conventional commits; your commit message should start with `feat:`, `fix:`, etc.
16
+
-If not specified, make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Codex CLI) <agent@willbooster.com>`.
16
17
- Always create new commits. Avoid using `--amend`.
17
18
18
19
## Coding Style
19
20
20
-
- Write comments that explain "why" rather than "what". Avoid explanations that can be understood from the code itself.
21
-
- Use stderr for logging debug messages temporarily since stdout output is sometimes omitted.
22
-
- When adding new functions or classes, define them below any functions or classes that call them to maintain clear call order.
23
-
- Prefer `undefined` over `null` unless explicitly dealing with APIs or libraries that require `null`.
24
-
- Always perform existence checks on array due to `noUncheckedIndexedAccess: true`.
21
+
- Simplify code as much as possible to eliminate redundancy.
22
+
- Design each module with high cohesion, grouping related functionality together.
23
+
- Refactor existing large modules into smaller, focused modules when necessary.
24
+
- Create well-organized directory structures with low coupling and high cohesion.
25
+
- When adding new functions or classes, define them below any functions or classes that call them to maintain a clear top-down call order.
26
+
- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
27
+
- Prefer `undefined` over `null` unless explicitly required by APIs or libraries.
Copy file name to clipboardExpand all lines: CLAUDE.md
+13-10Lines changed: 13 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,23 +2,26 @@
2
2
3
3
- Name: @exercode/problem-utils
4
4
- Description: :100: A set of utilities for judging programs on Exercode (https://exercode.willbooster.com/).
5
-
- Package Manager: yarn
5
+
- Package Manager: yarn on zsh
6
6
7
7
## General Instructions
8
8
9
+
- Create a new branch if the current branch is `main`.
9
10
- Do not write tests unless explicitly requested.
10
11
- When fixing tests, gather debug information through logging and screenshots before modifying the code.
11
-
- After making code changes, run `yarn check-all-for-ai` to execute all tests (note: this may take up to 30 minutes), or run `yarn check-for-ai` for type checking and linting only.
12
+
- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or run `yarn check-for-ai` for type checking and linting only (takes up to 10 minutes).
12
13
- If you are confident your changes will not break any tests, you may use `check-for-ai`.
13
-
- Once you have verified your changes, commit them to the non-main branch using the `--no-verify` option and push to the current branch.
14
-
- Follow conventional commits, i.e., your commit message should start with `feat:`, `fix:`, etc.
15
-
-Make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Claude Code) <agent@willbooster.com>`.
14
+
- Once you have verified your changes, commit them to a non-main branch using the `--no-verify` option and push to the current branch.
15
+
- Follow conventional commits; your commit message should start with `feat:`, `fix:`, etc.
16
+
-If not specified, make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Claude Code) <agent@willbooster.com>`.
16
17
- Always create new commits. Avoid using `--amend`.
17
18
18
19
## Coding Style
19
20
20
-
- Write comments that explain "why" rather than "what". Avoid explanations that can be understood from the code itself.
21
-
- Use stderr for logging debug messages temporarily since stdout output is sometimes omitted.
22
-
- When adding new functions or classes, define them below any functions or classes that call them to maintain clear call order.
23
-
- Prefer `undefined` over `null` unless explicitly dealing with APIs or libraries that require `null`.
24
-
- Always perform existence checks on array due to `noUncheckedIndexedAccess: true`.
21
+
- Simplify code as much as possible to eliminate redundancy.
22
+
- Design each module with high cohesion, grouping related functionality together.
23
+
- Refactor existing large modules into smaller, focused modules when necessary.
24
+
- Create well-organized directory structures with low coupling and high cohesion.
25
+
- When adding new functions or classes, define them below any functions or classes that call them to maintain a clear top-down call order.
26
+
- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
27
+
- Prefer `undefined` over `null` unless explicitly required by APIs or libraries.
Copy file name to clipboardExpand all lines: GEMINI.md
+13-10Lines changed: 13 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,23 +2,26 @@
2
2
3
3
- Name: @exercode/problem-utils
4
4
- Description: :100: A set of utilities for judging programs on Exercode (https://exercode.willbooster.com/).
5
-
- Package Manager: yarn
5
+
- Package Manager: yarn on zsh
6
6
7
7
## General Instructions
8
8
9
+
- Create a new branch if the current branch is `main`.
9
10
- Do not write tests unless explicitly requested.
10
11
- When fixing tests, gather debug information through logging and screenshots before modifying the code.
11
-
- After making code changes, run `yarn check-all-for-ai` to execute all tests (note: this may take up to 30 minutes), or run `yarn check-for-ai` for type checking and linting only.
12
+
- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or run `yarn check-for-ai` for type checking and linting only (takes up to 10 minutes).
12
13
- If you are confident your changes will not break any tests, you may use `check-for-ai`.
13
-
- Once you have verified your changes, commit them to the non-main branch using the `--no-verify` option and push to the current branch.
14
-
- Follow conventional commits, i.e., your commit message should start with `feat:`, `fix:`, etc.
15
-
-Make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Gemini CLI) <agent@willbooster.com>`.
14
+
- Once you have verified your changes, commit them to a non-main branch using the `--no-verify` option and push to the current branch.
15
+
- Follow conventional commits; your commit message should start with `feat:`, `fix:`, etc.
16
+
-If not specified, make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Gemini CLI) <agent@willbooster.com>`.
16
17
- Always create new commits. Avoid using `--amend`.
17
18
18
19
## Coding Style
19
20
20
-
- Write comments that explain "why" rather than "what". Avoid explanations that can be understood from the code itself.
21
-
- Use stderr for logging debug messages temporarily since stdout output is sometimes omitted.
22
-
- When adding new functions or classes, define them below any functions or classes that call them to maintain clear call order.
23
-
- Prefer `undefined` over `null` unless explicitly dealing with APIs or libraries that require `null`.
24
-
- Always perform existence checks on array due to `noUncheckedIndexedAccess: true`.
21
+
- Simplify code as much as possible to eliminate redundancy.
22
+
- Design each module with high cohesion, grouping related functionality together.
23
+
- Refactor existing large modules into smaller, focused modules when necessary.
24
+
- Create well-organized directory structures with low coupling and high cohesion.
25
+
- When adding new functions or classes, define them below any functions or classes that call them to maintain a clear top-down call order.
26
+
- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
27
+
- Prefer `undefined` over `null` unless explicitly required by APIs or libraries.
0 commit comments