automation recipies
update
+398
-21
+25
skills/analyze/SKILL.md
+25
skills/analyze/SKILL.md
···
1
+
---
2
+
name: analyze
3
+
description: Confirm understanding of prompt
4
+
compatibility: opencode
5
+
---
6
+
# Core Checklist
7
+
- [ ] Clear technical requirements
8
+
- [ ] Clear constraints and requirements
9
+
- [ ] Important context provided
10
+
- [ ] Specific, scoped feature
11
+
- [ ] Clear scope and focus areas
12
+
- [ ] Business implications explained
13
+
- [ ] Points to existing patterns to follow
14
+
- [ ] Measurable success criteria
15
+
- [ ] Defines what “done” looks like
16
+
17
+
# Refactor/Rewrite
18
+
- [ ] Specific problems identified
19
+
- [ ] Exact error message
20
+
- [ ] Specific file and line number
21
+
- [ ] Clear expected vs. actual behavior
22
+
- [ ] Suggested approach for the fix
23
+
24
+
# Case-specific
25
+
- [ ] Requested output format specified
+9
-21
skills/calibrate/SKILL.md
skills/calibrate_zh/SKILL.md
+9
-21
skills/calibrate/SKILL.md
skills/calibrate_zh/SKILL.md
···
1
1
---
2
-
name: calibrate
2
+
name: calibrate_zh
3
3
description: Terms Of Service
4
4
compatibility: opencode
5
5
---
6
-
7
-
# 服务条款
8
-
9
-
## 可接受的使用
10
-
11
-
-扫描现有的代码库，并尽可能重复使用现有的功能、样式和结构。
12
-
6
+
- 扫描现有的代码库，并尽可能重复使用现有的功能、样式和结构。
13
7
- 始终写描述性变量名称。
14
8
- 在整个项目中保持标签一致。
15
-
- 变量名称必须是描述性单词<=5个字母长的“snake_case”序列。
9
+
- Python變數名稱必須是<=5個字母的描述性單詞序列。
16
10
- 编写测试，以确定预期功能的结果。
17
11
- 只写足够通过测试的代码。
18
12
- 将简短的狮身人面像文档字符串写成一行描述，每个参数一行。
···
21
15
- 如果导入很小，具有性能，并且大大减少了对新代码的需求，请使用库。
22
16
- 必须写入尝试/排除块来捕捉特定的、预期的异常类型。
23
17
- 一般来说，代码应在单个文件中保持在100行以下。 单个文件中超过250行的代码必须重构。
24
-
- 在提交消息中：使用`+`进行代码添加，`-`进行代码减法，`~`进行重构/修复。
25
-
- Always reply in English.
26
-
27
-
## 禁止的行为
28
-
18
+
- 在提交消息中，使用`+`用于代码添加，`-`用于代码减法，`~`用于重构/修复。
19
+
- 每次更改后使用build、lint和typecheck。
29
20
- 没有内联评论。
30
21
- 文档字符串和下一个函数之间没有注释。
31
22
- 文档字符串中没有空行或换行符。
···
33
24
- 没有表情符号。
34
25
- 没有全局变量。
35
26
- 没有语义提交消息。
36
-
37
27
- 一个文件中绝不允许超过250行。
38
28
- 测试完成后不得修改。
39
29
- 没有裸露的或通用的例外捕获。
40
-
- 不要在类型错误上标记#ignore。
41
-
42
-
## 行为
43
-
44
-
“想法”可能很长，但代码、文档和用户标准文档必须简洁明了。
45
-
遇到歧义时，询问用户。
30
+
- 不要在类型错误上标记为忽略。
31
+
- 在不提供构建和林特输出的情况下完成任务。
32
+
- 想法可能很长，但代码、文档和用户标准文档必须简明扼要。
33
+
- 遇到歧义时，询问用户。
+33
skills/calibrate_en/SKILL.md
+33
skills/calibrate_en/SKILL.md
···
1
+
---
2
+
name: calibrate
3
+
description: Terms Of Service
4
+
compatibility: opencode
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.
+331
skills/gdsl/SKILL.md
+331
skills/gdsl/SKILL.md
···
1
+
---
2
+
name: gdsl
3
+
description: Gherkin Domain Specific Language.
4
+
compatibility: opencode
5
+
metadata:
6
+
type: language
7
+
---
8
+
9
+
**File extension** : `.feature.md`
10
+
11
+
# Gherkin Syntax
12
+
13
+
Like YAML or Python, Gherkin is a line-oriented language that uses indentation to define structure. Line endings terminate statements (called steps) and either spaces or tabs may be used for indentation. (We suggest you use spaces for portability.) Finally, most lines in Gherkin start with a special keyword:
14
+
15
+
Feature: Some terse yet descriptive text of what is desired
16
+
In order to realize a named business value
17
+
As an explicit system actor
18
+
I want to gain some beneficial outcome which furthers the goal
19
+
20
+
Scenario: Some determinable business situation
21
+
Given some precondition
22
+
And some other precondition
23
+
When some action by the actor
24
+
And some other action
25
+
And yet another action
26
+
Then some testable outcome is achieved
27
+
And something else we can check happens too
28
+
29
+
Scenario: A different situation
30
+
...
31
+
32
+
The parser divides the input into features, scenarios and steps. Let’s walk through the above example:
33
+
34
+
Feature: Some terse yet descriptive text of what is desired starts the feature and gives it a title. Learn more about features in the “Features” section.
35
+
Behat does not parse the next 3 lines of text. (In order to... As an... I want to...). These lines simply provide context to the people reading your feature, and describe the business value derived from the inclusion of the feature in your software.
36
+
Scenario: Some determinable business situation starts the scenario, and contains a description of the scenario. Learn more about scenarios in the “Scenarios” section.
37
+
The next 7 lines are the scenario steps, each of which is matched to a regular expression defined elsewhere. Learn more about steps in the “Steps” section.
38
+
Scenario: A different situation starts the next scenario, and so on.
39
+
40
+
Every *.feature file conventionally consists of a single feature. Lines starting with the keyword Feature: (or its localized equivalent) followed by three indented lines starts a feature. A feature usually contains a list of scenarios. You can write whatever you want up until the first scenario, which starts with Scenario: (or localized equivalent) on a new line. You can use tags to group features and scenarios together, independent of your file and directory structure.
41
+
42
+
Every scenario consists of a list of steps, which must start with one of the keywords Given, When, Then, But or And (or localized one). Here is an example:
43
+
44
+
Feature: Serve coffee
45
+
In order to earn money
46
+
Customers should be able to
47
+
buy coffee at all times
48
+
49
+
Scenario: Buy last coffee
50
+
Given there are 1 coffees left in the machine
51
+
And I have deposited 1 dollar
52
+
When I press the coffee button
53
+
Then I should be served a coffee
54
+
55
+
In addition to basic scenarios, feature may contain scenario outlines and backgrounds.
56
+
57
+
## Scenarios
58
+
59
+
Scenario is one of the core Gherkin structures. Every scenario starts with the Scenario: keyword (or localized one), followed by an optional scenario title. Each feature can have one or more scenarios, and every scenario consists of one or more steps.
60
+
61
+
The following scenarios each have 3 steps:
62
+
63
+
Scenario: Wilson posts to his own blog
64
+
Given I am logged in as Wilson
65
+
When I try to post to "Expensive Therapy"
66
+
Then I should see "Your article was published."
67
+
68
+
Scenario: Wilson fails to post to somebody else's blog
69
+
Given I am logged in as Wilson
70
+
When I try to post to "Greg's anti-tax rants"
71
+
Then I should see "Hey! That's not your blog!"
72
+
73
+
Scenario: Greg posts to a client's blog
74
+
Given I am logged in as Greg
75
+
When I try to post to "Expensive Therapy"
76
+
Then I should see "Your article was published."
77
+
78
+
## Scenario Outlines
79
+
80
+
Copying and pasting scenarios to use different values can quickly become tedious and repetitive:
81
+
82
+
Scenario: Eat 5 out of 12
83
+
Given there are 12 cucumbers
84
+
When I eat 5 cucumbers
85
+
Then I should have 7 cucumbers
86
+
87
+
Scenario: Eat 5 out of 20
88
+
Given there are 20 cucumbers
89
+
When I eat 5 cucumbers
90
+
Then I should have 15 cucumbers
91
+
92
+
Scenario Outlines allow us to more concisely express these examples through the use of a template with placeholders:
93
+
94
+
Scenario Outline: Eating
95
+
Given there are <start> cucumbers
96
+
When I eat <eat> cucumbers
97
+
Then I should have <left> cucumbers
98
+
99
+
Examples:
100
+
| start | eat | left |
101
+
| 12 | 5 | 7 |
102
+
| 20 | 5 | 15 |
103
+
104
+
The Scenario outline steps provide a template which is never directly run. A Scenario Outline is run once for each row in the Examples section beneath it (not counting the first row of column headers).
105
+
106
+
The Scenario Outline uses placeholders, which are contained within < > in the Scenario Outline’s steps. For example:
107
+
108
+
Given <I'm a placeholder and I'm ok>
109
+
110
+
Think of a placeholder like a variable. It is replaced with a real value from the Examples: table row, where the text between the placeholder angle brackets matches that of the table column header. The value substituted for the placeholder changes with each subsequent run of the Scenario Outline, until the end of the Examples table is reached.
111
+
112
+
You can also use placeholders in Multiline Arguments.
113
+
114
+
Your step definitions will never have to match the placeholder text itself, but rather the values replacing the placeholder.
115
+
116
+
So when running the first row of our example:
117
+
118
+
Scenario Outline: controlling order
119
+
Given there are <start> cucumbers
120
+
When I eat <eat> cucumbers
121
+
Then I should have <left> cucumbers
122
+
123
+
Examples:
124
+
| start | eat | left |
125
+
| 12 | 5 | 7 |
126
+
127
+
The scenario that is actually run is:
128
+
129
+
Scenario Outline: controlling order
130
+
- <start> replaced with 12:
131
+
Given there are 12 cucumbers
132
+
- <eat> replaced with 5:
133
+
When I eat 5 cucumbers
134
+
- <left> replaced with 7:
135
+
Then I should have 7 cucumbers
136
+
137
+
## Backgrounds
138
+
139
+
Backgrounds allows you to add some context to all scenarios in a single feature. A Background is like an untitled scenario, containing a number of steps. The difference is when it is run: the background is run before each of your scenarios, but after your BeforeScenario hooks (Hooking into the Test Process - Hooks).
140
+
141
+
Feature: Multiple site support
142
+
143
+
Background:
144
+
Given a global administrator named "Greg"
145
+
And a blog named "Greg's anti-tax rants"
146
+
And a customer named "Wilson"
147
+
And a blog named "Expensive Therapy" owned by "Wilson"
148
+
149
+
Scenario: Wilson posts to his own blog
150
+
Given I am logged in as Wilson
151
+
When I try to post to "Expensive Therapy"
152
+
Then I should see "Your article was published."
153
+
154
+
Scenario: Greg posts to a client's blog
155
+
Given I am logged in as Greg
156
+
When I try to post to "Expensive Therapy"
157
+
Then I should see "Your article was published."
158
+
159
+
## Steps
160
+
161
+
Features consist of steps, also known as Givens, Whens and Thens. These words have been carefully selected for their purpose, and you should know what the purpose is to get into the BDD mindset.
162
+
163
+
Robert C. Martin has written a great post about BDD’s Given-When-Then concept where he thinks of them as a finite state machine.
164
+
165
+
### Givens
166
+
167
+
The purpose of Given steps is to put the system in a known state before the user (or external system) starts interacting with the system (in the When steps). Avoid talking about user interaction in givens. If you have worked with use cases, givens are your preconditions.
168
+
169
+
Two good examples of using Givens are:
170
+
171
+
To create records (model instances) or set up the database:
172
+
173
+
Given there are no users on site
174
+
Given the database is clean
175
+
176
+
Authenticate a user (An exception to the no-interaction recommendation. Things that “happened earlier” are ok):
177
+
178
+
Given I am logged in as "Everzet"
179
+
180
+
It’s ok to call into the layer “inside” the UI layer here (in symfony: talk to the models).
181
+
182
+
And for all the symfony users out there, we recommend using a Given step with a tables arguments to set up records instead of fixtures. This way you can read the scenario all in one place and make sense out of it without having to jump between files:
183
+
184
+
Given there are users:
185
+
| username | password | email |
186
+
| everzet | 123456 | everzet@knplabs.com |
187
+
| fabpot | 22@222 | fabpot@symfony.com |
188
+
189
+
### Whens
190
+
191
+
The purpose of When steps is to describe the key action the user performs (or, using Robert C. Martin’s metaphor, the state transition).
192
+
193
+
Two good examples of Whens use are:
194
+
195
+
Interact with a web page (the Mink library gives you many web-friendly When steps out of the box):
196
+
197
+
When I am on "/some/page"
198
+
When I fill "username" with "everzet"
199
+
When I fill "password" with "123456"
200
+
When I press "login"
201
+
202
+
Interact with some CLI library (call commands and record output):
203
+
204
+
When I call "ls -la"
205
+
206
+
### Thens
207
+
208
+
The purpose of Then steps is to observe outcomes. The observations should be related to the business value/benefit in your feature description. The observations should inspect the output of the system (a report, user interface, message, command output) and not something deeply buried inside it (that has no business value and is instead part of the implementation).
209
+
210
+
Verify that something related to the Given+When is (or is not) in the output
211
+
Check that some external system has received the expected message (was an email with specific content successfully sent?)
212
+
213
+
When I call "echo hello"
214
+
Then the output should be "hello"
215
+
216
+
While it might be tempting to implement Then steps to just look in the database – resist the temptation. You should only verify output that is observable by the user (or external system). Database data itself is only visible internally to your application, but is then finally exposed by the output of your system in a web browser, on the command-line or an email message.
217
+
218
+
### And, But
219
+
220
+
If you have several Given, When or Then steps you can write:
221
+
222
+
Scenario: Multiple Givens
223
+
Given one thing
224
+
Given an other thing
225
+
Given yet an other thing
226
+
When I open my eyes
227
+
Then I see something
228
+
Then I don't see something else
229
+
230
+
Or you can use And or But steps, allowing your Scenario to read more fluently:
231
+
232
+
Scenario: Multiple Givens
233
+
Given one thing
234
+
And an other thing
235
+
And yet an other thing
236
+
When I open my eyes
237
+
Then I see something
238
+
But I don't see something else
239
+
240
+
If you prefer, you can indent scenario steps in a more programmatic way, much in the same way your actual code is indented to provide visual context:
241
+
242
+
Scenario: Multiple Givens
243
+
Given one thing
244
+
And an other thing
245
+
And yet an other thing
246
+
When I open my eyes
247
+
Then I see something
248
+
But I don't see something else
249
+
250
+
### Multiline Arguments
251
+
252
+
The regular expression matching in steps lets you capture small strings from your steps and receive them in your step definitions. However, there are times when you want to pass a richer data structure from a step to a step definition.
253
+
254
+
This is what multiline step arguments are for. They are written on lines immediately following a step, and are passed to the step definition method as the last argument.
255
+
256
+
Multiline step arguments come in two flavours: tables or pystrings.
257
+
258
+
### Tables
259
+
260
+
Tables as arguments to steps are handy for specifying a larger data set - usually as input to a Given or as expected output from a Then.
261
+
262
+
Scenario:
263
+
Given the following people exist:
264
+
| name | email | phone |
265
+
| Aslak | aslak@email.com | 123 |
266
+
| Joe | joe@email.com | 234 |
267
+
| Bryan | bryan@email.org | 456 |
268
+
269
+
Don’t be confused with tables from scenario outlines - syntactically they are identical, but have a different purpose.
270
+
271
+
A matching definition for this step looks like this:
272
+
273
+
/**
274
+
* @Given /the following people exist:/
275
+
*/
276
+
public function thePeopleExist(TableNode $table)
277
+
{
278
+
$hash = $table->getHash();
279
+
foreach ($hash as $row) {
280
+
// $row['name'], $row['email'], $row['phone']
281
+
}
282
+
}
283
+
284
+
A table is injected into a definition as a TableNode object, from which you can get hash by columns (TableNode::getHash() method) or by rows (TableNode::getRowsHash()).
285
+
286
+
### PyStrings
287
+
288
+
Multiline Strings (also known as PyStrings) are handy for specifying a larger piece of text. This is done using the so-called PyString syntax. The text should be offset by delimiters consisting of three double-quote marks (""") on lines by themselves:
289
+
290
+
Scenario:
291
+
Given a blog post named "Random" with:
292
+
"""
293
+
Some Title, Eh?
294
+
===============
295
+
Here is the first paragraph of my blog post.
296
+
Lorem ipsum dolor sit amet, consectetur adipiscing
297
+
elit.
298
+
"""
299
+
300
+
The inspiration for PyString comes from Python where """ is used to delineate docstrings, much in the way /* ... */ is used for multiline docblocks in PHP.
301
+
302
+
In your step definition, there’s no need to find this text and match it in your regular expression. The text will automatically be passed as the last argument into the step definition method. For example:
303
+
304
+
/**
305
+
* @Given /a blog post named "([^"]+)" with:/
306
+
*/
307
+
public function blogPost($title, PyStringNode $markdown)
308
+
{
309
+
$this->createPost($title, $markdown->getRaw());
310
+
}
311
+
312
+
PyStrings are stored in a PyStringNode instance, which you can simply convert to a string with (string) $pystring or $pystring->getRaw() as in the example above.
313
+
314
+
Indentation of the opening """ is not important, although common practice is two spaces in from the enclosing step. The indentation inside the triple quotes, however, is significant. Each line of the string passed to the step definition’s callback will be de-indented according to the opening """. Indentation beyond the column of the opening """ will therefore be preserved.
315
+
316
+
## Tags
317
+
318
+
Tags are a great way to organize your features and scenarios. Consider this example:
319
+
320
+
@billing
321
+
Feature: Verify billing
322
+
323
+
@important
324
+
Scenario: Missing product description
325
+
326
+
Scenario: Several products
327
+
328
+
A Scenario or Feature can have as many tags as you like, just separate them with spaces:
329
+
330
+
@billing @bicker @annoy
331
+
Feature: Verify billing