automation recipies
update
+183
-50
+113
AGENT.md
+113
AGENT.md
···
1
+
---
2
+
name: agent
3
+
description: Rules
4
+
compatibility: opencode
5
+
---
6
+
7
+
Only reply in English.
8
+
9
+
# General
10
+
- When encountering ambiguity, ask the user.
11
+
- Thoughts can be long, but code, documentation, and stdout to user must be succinct and concise.
12
+
13
+
# Tests
14
+
- Write tests to determine the outcome of an anticipated feature.
15
+
- Only write enough code to pass the test.
16
+
- Tests must not be modified once complete.
17
+
- Always complete task without providing build and lint output.
18
+
- Use build, lint and typecheck after every change.
19
+
20
+
# Naming
21
+
- Write descriptive variable names at all times.
22
+
- Keep labels consistent across the entire project.
23
+
- No abbreviated function names or variables.
24
+
25
+
# Code
26
+
- Scan the existing codebase and reuse existing functions, style and structure wherever possible.
27
+
- Never ouput a single file with over 250 lines.
28
+
- Generally code should stay under 100 lines in a single file. Code over 250 lines in a single file must be refactored.
29
+
- Try/except blocks must be written to catch specific, expected exception types.
30
+
- If an import is small, performative, and significantly reduces needs for new code, use the library.
31
+
- No global variables.
32
+
- No emoji.
33
+
- (Python only) Keep all imports within functions unless they must be mocked in a test.
34
+
- (Python only) variable names must be `snake_case` sequence of descriptive words <=5 letters long.
35
+
36
+
# Comments
37
+
- Write short Sphinx docstrings as a single line description, a single line for each parameter. On first line of docstrings use `\n`.
38
+
- No inline comments.
39
+
- No comments between docstring and next function.
40
+
- No empty lines or linebreaks in docstrings.
41
+
- Do not mark ignore on type errors.
42
+
43
+
# Git
44
+
- In commit messages use `+` for code adds, `-` for code subtractions, `~` for refactors/fixes.
45
+
- No semantic commit messages.
46
+
47
+
48
+
# 将军
49
+
- 遇到歧义时，询问用户。
50
+
- 想法可能很长，但代码、文档和用户标准文档必须简明扼要。
51
+
52
+
# 测试
53
+
- 编写测试，以确定预期功能的结果。
54
+
- 只写足够通过测试的代码。
55
+
- 测试完成后不得修改。
56
+
- 总是在不提供构建和林特输出的情况下完成任务。
57
+
- 每次更改后使用build、lint和typecheck。
58
+
59
+
# 命名
60
+
- 始终写描述性变量名称。
61
+
- 在整个项目中保持标签一致。
62
+
- 没有缩写的函数名称或变量。
63
+
64
+
# 代码
65
+
- 扫描现有的代码库，并尽可能重复使用现有的功能、样式和结构。
66
+
- 切勿输出超过250行的单个文件。
67
+
- 一般来说，代码应在单个文件中保持在100行以下。 单个文件中超过250行的代码必须重构。
68
+
- 必须写入尝试/排除块来捕捉特定的、预期的异常类型。
69
+
- 如果导入很小，具有性能，并且大大减少了对新代码的需求，请使用库。
70
+
- 没有全局变量。
71
+
- 没有表情符号。
72
+
- (仅限Python）将所有导入保留在函数中，除非它们必须在测试中模拟。
73
+
- (僅限Python）變數名必須是`snake_case`描述性單詞序列<=5個字母長。
74
+
75
+
# 评论
76
+
77
+
- 将简短的狮身人面像文档字符串写成一行描述，每个参数一行。 在文档字符串的第一行使用`\n`。
78
+
- 没有内联评论。
79
+
- 文档字符串和下一个函数之间没有注释。
80
+
- 文档字符串中没有空行或换行符。
81
+
- 不要在类型错误上标记为忽略。
82
+
83
+
# Git
84
+
85
+
- 在提交消息中，使用`+`用于代码添加，`-`用于代码减法，`~`用于重构/修复。
86
+
- 没有语义提交消息。
87
+
88
+
89
+
# Core Checklist
90
+
91
+
- [ ] Clear technical requirements
92
+
- [ ] Clear constraints and requirements
93
+
- [ ] Important context provided
94
+
- [ ] Specific, scoped feature
95
+
- [ ] Clear scope and focus areas
96
+
- [ ] Business implications explained
97
+
- [ ] Points to existing patterns to follow
98
+
- [ ] Measurable success criteria
99
+
- [ ] Defines what “done” looks like
100
+
101
+
# Refactor/Rewrite
102
+
- [ ] Specific problems identified
103
+
- [ ] Exact error message
104
+
- [ ] Specific file and line number
105
+
- [ ] Clear expected vs. actual behavior
106
+
- [ ] Suggested approach for the fix
107
+
108
+
# Case-specific
109
+
- [ ] Requested output format specified
110
+
111
+
# Process
112
+
113
+
Review instructions using the checklist one by one. When encountering ambiguity, ask the human.
+38
-29
skills/calibrate_en/SKILL.md
+38
-29
skills/calibrate_en/SKILL.md
···
1
1
---
2
-
name: calibrate
2
+
name: calibrate_en
3
3
description: Terms Of Service
4
4
compatibility: opencode
5
5
---
6
-
- Scan the existing codebase and reuse existing functions, style and structure wherever possible.
7
-
- Write descriptive variable names at all times.
8
-
- Keep labels consistent across the entire project.
9
-
- Python variable names must be `snake_case` sequence of descriptive words <=5 letters long.
10
-
- Write tests to determine the outcome of an anticipated feature.
11
-
- Only write enough code to pass the test.
12
-
- Write short Sphinx docstrings as a single line description, a single line for each parameter.
13
-
- On first line of docstrings use `\n`.
14
-
- Keep all imports within functions unless they must be mocked in a test.
15
-
- If an import is small, performative, and significantly reduces needs for new code, use the library.
16
-
- Try/except blocks must be written to catch specific, expected exception types.
17
-
- Generally code should stay under 100 lines in a single file. Code over 250 lines in a single file must be refactored.
18
-
- In commit messages use `+` for code adds, `-` for code subtractions, `~` for refactors/fixes.
19
-
- Use build, lint and typecheck after every change.
20
-
- No inline comments.
21
-
- No comments between docstring and next function.
22
-
- No empty lines or linebreaks in docstrings.
23
-
- No abbreviated function names or variables.
24
-
- No emoji.
25
-
- No global variables.
26
-
- No semantic commit messages.
27
-
- Never allow over 250 lines in a single file.
28
-
- Tests must not be modified once complete.
29
-
- No bare or generic exception catching.
30
-
- Do not mark ignore on type errors.
31
-
- Complete task without providing build and lint output.
32
-
- Thoughts can be long, but code, documentation, and stdout to user must be succinct and concise.
33
-
- When encountering ambiguity, ask the user.
6
+
# General
7
+
- When encountering ambiguity, ask the user.
8
+
- Thoughts can be long, but code, documentation, and stdout to user must be succinct and concise.
9
+
10
+
# Tests
11
+
- Write tests to determine the outcome of an anticipated feature.
12
+
- Only write enough code to pass the test.
13
+
- Tests must not be modified once complete.
14
+
- Always complete task without providing build and lint output.
15
+
- Use build, lint and typecheck after every change.
16
+
17
+
# Naming
18
+
- Write descriptive variable names at all times.
19
+
- Keep labels consistent across the entire project.
20
+
- No abbreviated function names or variables.
21
+
22
+
# Code
23
+
- Scan the existing codebase and reuse existing functions, style and structure wherever possible.
24
+
- Never ouput a single file with over 250 lines.
25
+
- Generally code should stay under 100 lines in a single file. Code over 250 lines in a single file must be refactored.
26
+
- Try/except blocks must be written to catch specific, expected exception types.
27
+
- If an import is small, performative, and significantly reduces needs for new code, use the library.
28
+
- No global variables.
29
+
- No emoji.
30
+
- (Python only) Keep all imports within functions unless they must be mocked in a test.
31
+
- (Python only) variable names must be `snake_case` sequence of descriptive words <=5 letters long.
32
+
33
+
# Comments
34
+
- Write short Sphinx docstrings as a single line description, a single line for each parameter. On first line of docstrings use `\n`.
35
+
- No inline comments.
36
+
- No comments between docstring and next function.
37
+
- No empty lines or linebreaks in docstrings.
38
+
- Do not mark ignore on type errors.
39
+
40
+
# Git
41
+
- In commit messages use `+` for code adds, `-` for code subtractions, `~` for refactors/fixes.
42
+
- No semantic commit messages.
+32
-21
skills/calibrate_zh/SKILL.md
+32
-21
skills/calibrate_zh/SKILL.md
···
3
3
description: Terms Of Service
4
4
compatibility: opencode
5
5
---
6
-
- 扫描现有的代码库，并尽可能重复使用现有的功能、样式和结构。
6
+
# 将军
7
+
- 遇到歧义时，询问用户。
8
+
- 想法可能很长，但代码、文档和用户标准文档必须简明扼要。
9
+
10
+
# 测试
11
+
- 编写测试，以确定预期功能的结果。
12
+
- 只写足够通过测试的代码。
13
+
- 测试完成后不得修改。
14
+
- 总是在不提供构建和林特输出的情况下完成任务。
15
+
- 每次更改后使用build、lint和typecheck。
16
+
17
+
# 命名
7
18
- 始终写描述性变量名称。
8
19
- 在整个项目中保持标签一致。
9
-
- Python變數名稱必須是<=5個字母的描述性單詞序列。
10
-
- 编写测试，以确定预期功能的结果。
11
-
- 只写足够通过测试的代码。
12
-
- 将简短的狮身人面像文档字符串写成一行描述，每个参数一行。
13
-
- 在文档字符串的第一行使用`\n`。
14
-
- 将所有导入保留在函数内，除非它们必须在测试中被模拟。
20
+
- 没有缩写的函数名称或变量。
21
+
22
+
# 代码
23
+
- 扫描现有的代码库，并尽可能重复使用现有的功能、样式和结构。
24
+
- 切勿输出超过250行的单个文件。
25
+
- 一般来说，代码应在单个文件中保持在100行以下。 单个文件中超过250行的代码必须重构。
26
+
- 必须写入尝试/排除块来捕捉特定的、预期的异常类型。
15
27
- 如果导入很小，具有性能，并且大大减少了对新代码的需求，请使用库。
16
-
- 必须写入尝试/排除块来捕捉特定的、预期的异常类型。
17
-
- 一般来说，代码应在单个文件中保持在100行以下。 单个文件中超过250行的代码必须重构。
18
-
- 在提交消息中，使用`+`用于代码添加，`-`用于代码减法，`~`用于重构/修复。
19
-
- 每次更改后使用build、lint和typecheck。
28
+
- 没有全局变量。
29
+
- 没有表情符号。
30
+
- (仅限Python）将所有导入保留在函数中，除非它们必须在测试中模拟。
31
+
- (僅限Python）變數名必須是`snake_case`描述性單詞序列<=5個字母長。
32
+
33
+
# 评论
34
+
35
+
- 将简短的狮身人面像文档字符串写成一行描述，每个参数一行。 在文档字符串的第一行使用`\n`。
20
36
- 没有内联评论。
21
37
- 文档字符串和下一个函数之间没有注释。
22
38
- 文档字符串中没有空行或换行符。
23
-
- 没有缩写的函数名称或变量。
24
-
- 没有表情符号。
25
-
- 没有全局变量。
26
-
- 没有语义提交消息。
27
-
- 一个文件中绝不允许超过250行。
28
-
- 测试完成后不得修改。
29
-
- 没有裸露的或通用的例外捕获。
30
39
- 不要在类型错误上标记为忽略。
31
-
- 在不提供构建和林特输出的情况下完成任务。
32
-
- 想法可能很长，但代码、文档和用户标准文档必须简明扼要。
33
-
- 遇到歧义时，询问用户。
40
+
41
+
# Git
42
+
43
+
- 在提交消息中，使用`+`用于代码添加，`-`用于代码减法，`~`用于重构/修复。
44
+
- 没有语义提交消息。