@robot-inventor/agent-skills 0.10.0 → 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@robot-inventor/agent-skills",
3
- "version": "0.10.0",
3
+ "version": "1.0.0",
4
4
  "description": "Roboin's personal collection of Agent Skills.",
5
5
  "homepage": "https://github.com/Robot-Inventor/agent-skills#readme",
6
6
  "bugs": {
@@ -26,9 +26,18 @@ The following is the core of this skill; please follow the specified steps.
26
26
 
27
27
  Request a code review from the subagent.
28
28
 
29
- If you have the option to choose whether to fork the context or launch the subagent in an isolated context when starting it, **always** launch it in an isolated context. When requesting a review from a sub-agent, be sure to provide them with an overview of the task requested by the user, and instruct them to thoroughly review the changes made to the current workspace.
29
+ If you have the option to choose whether to fork the context or launch the subagent in an isolated context when starting it, **always** launch it in an isolated context. Refer to the following for the prompt to send to the review agent.
30
30
 
31
- Code reviews by sub-agents can take time. Please note that if you re-spawn a sub-agent currently undergoing a review simply because it has not yet responded, the review process will start over from scratch, resulting in even longer wait times. If the workspace contains a mix of changes made by you and by the user, please specify the files to be reviewed when submitting your review request.
31
+ ```md
32
+ You are a code review agent. Thoroughly review the code for design issues, bugs, vulnerabilities, and oversights, and report the findings categorized as critical, high, medium, low, or informational. In addition to reviews that increase the amount of code, also check for over-engineering, such as excessive implementation or unnecessary conditional branching, in accordance with simple-engineering skill. In addition to the small details of the code, you should also consider whether there are simpler designs or alternative approaches to the overall logic of the changed parts, following the principles of simple-engineering. If you find any, you should report them, even if it requires rewriting the code being reviewed from scratch.
33
+
34
+ Flag excessive validation, overly defensive implementation, and unnecessary complexity that does not serve the code's intended purpose. For example, a function that opens product links for a specific website may only need to verify the hostname. Checking the pathname may add complexity without improving security. You might remove validation by defining the function argument as a type such as `https://example.com/product/{string}`, or by accepting only a product ID and constructing the link inside the function. These are examples, but you should look for simpler implementations of the same kind. Ask what purpose the code serves and whether the implementation contains only what that purpose requires. In addition to the aforementioned review output, also use the ponytail-review skill if available.
35
+
36
+ - Target: {uncomitted changes / filepath etc.}
37
+ - User's instructions: {user's request / instructions}
38
+ ```
39
+
40
+ Code reviews by sub-agents can take time. Please note that if you re-spawn a sub-agent currently undergoing a review simply because it has not yet responded, the review process will start over from scratch, resulting in even longer wait times. It is also prohibited to send additional prompts to urge a review when a review agent is taking a long time to respond.
32
41
 
33
42
  ### 2. Receive reviews and improve your code
34
43
 
@@ -16,6 +16,8 @@ Before implementing a feature or fixing a bug, consider all options. Instead of
16
16
 
17
17
  Also avoid bringing unnecessary complexity into your code. Carefully examine related processing to ensure there are no impossible conditional branches or unnecessary try-catch blocks. Check the type definitions and actual processing, and remove any impossible conditional branches. There is no need to wrap code in a new try-catch block if an exception is unlikely to occur normally or if a try-catch already exists inside the called function.
18
18
 
19
+ Flag excessive validation, overly defensive implementation, and unnecessary complexity that does not serve the code's intended purpose. For example, a function that opens product links for a specific website may only need to verify the hostname. Checking the pathname may add complexity without improving security. You might remove validation by defining the function argument as a type such as `https://example.com/product/{string}`, or by accepting only a product ID and constructing the link inside the function. These are examples, but you should look for simpler implementations of the same kind. Ask what purpose the code serves and whether the implementation contains only what that purpose requires.
20
+
19
21
  ## Avoid reinventing the wheel
20
22
 
21
23
  Reinventing the wheel should be avoided. Before adding code, check whether existing code in the project or the project's dependencies already provide functionality that covers part or all of that processing. When implementing complex processing, investigate whether a popular and well-maintained library that achieves equivalent functionality exists, and if so, propose using it to the user.