@robot-inventor/agent-skills 0.0.0 → 0.7.1

package/skills/review-loop/SKILL.md

@@ -1,45 +1,45 @@
----
-name: review-loop
-description: Thoroughly improve code quality by requesting a review from a sub-agent after completing tasks requiring code editing, before returning the conversation turn to the user. Use for any task that edits code or configuration. Read this skill before starting edits, and after completing the requested changes run an isolated sub-agent review loop before returning the final response.
-license: MIT
-metadata:
-  author: Robot-Inventor
----
-
-# Review Loop Skill
-
-This skill involves thoroughly improving code quality by repeatedly requesting a review from a sub-agent after editing and improving the code based on the results. Humans typically improve code quality by creating a pull request after editing code and having it reviewed by a reviewer. Such reviews are important because they can identify problems that might be missed through self-review alone.
-
-## When to apply
-
-Apply this skill in the following situations:
-
-- When you have performed a task that requires code editing, and
-- After completing the task instructed by the user, and
-- Before returning the conversation to the user
-
-## Steps
-
-The following is the core of this skill; please follow the specified steps.
-
-### 1. Request a code review
-
-Request a code review from the subagent.
-
-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. Forking the context would be equivalent to a self-review, so you need to launch a subagent in an isolated context to review it from a different perspective.
-
-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.
-
-### 2. Receive reviews and improve your code
-
-Once you receive the review results from the sub-agent, consider whether each point is valid. You may ignore clearly unreasonable points, but you must address valid points and correct the code accordingly.
-
-In particular, if you receive feedback on a part that doesn't strictly follow the user's instructions as a result of compromises, do not ignore it. Instead, correct it according to the review to align with the user's instructions as much as possible. If you absolutely cannot comply with the user's request, you may ignore the sub-agent's point about that part, but be sure to inform the user of the compromise you made when you return the conversation to them.
-
-### 3. Review loop
-
-After addressing valid feedback from the subagent, repeat steps 1 and 2 ("1. Request a code review" and "2. Receive reviews and improve your code") until there is no more valid feedback from the subagent, thoroughly improving your code quality. In this review loop, always have a new subagent review your code each time.
-
-### 4. Report the results to the user
-
-Once the review loop is complete, return the conversation to the user. Be sure to honestly report to the user any points where you had to compromise and did not strictly follow their instructions.
+---
+name: review-loop
+description: Thoroughly improve code quality by requesting a review from a sub-agent after completing tasks requiring code editing, before returning the conversation turn to the user. Use for any task that edits code or configuration. Read this skill before starting edits, and after completing the requested changes run an isolated sub-agent review loop before returning the final response.
+license: MIT
+metadata:
+  author: Robot-Inventor
+---
+
+# Review Loop Skill
+
+This skill involves thoroughly improving code quality by repeatedly requesting a review from a sub-agent after editing and improving the code based on the results. Humans typically improve code quality by creating a pull request after editing code and having it reviewed by a reviewer. Such reviews are important because they can identify problems that might be missed through self-review alone.
+
+## When to apply
+
+Apply this skill in the following situations:
+
+- When you have performed a task that requires code editing, and
+- After completing the task instructed by the user, and
+- Before returning the conversation to the user
+
+## Steps
+
+The following is the core of this skill; please follow the specified steps.
+
+### 1. Request a code review
+
+Request a code review from the subagent.
+
+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. Forking the context would be equivalent to a self-review, so you need to launch a subagent in an isolated context to review it from a different perspective.
+
+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.
+
+### 2. Receive reviews and improve your code
+
+Once you receive the review results from the sub-agent, consider whether each point is valid. You may ignore clearly unreasonable points, but you must address valid points and correct the code accordingly.
+
+In particular, if you receive feedback on a part that doesn't strictly follow the user's instructions as a result of compromises, do not ignore it. Instead, correct it according to the review to align with the user's instructions as much as possible. If you absolutely cannot comply with the user's request, you may ignore the sub-agent's point about that part, but be sure to inform the user of the compromise you made when you return the conversation to them.
+
+### 3. Review loop
+
+After addressing valid feedback from the subagent, repeat steps 1 and 2 ("1. Request a code review" and "2. Receive reviews and improve your code") until there is no more valid feedback from the subagent, thoroughly improving your code quality. In this review loop, always have a new subagent review your code each time.
+
+### 4. Report the results to the user
+
+Once the review loop is complete, return the conversation to the user. Be sure to honestly report to the user any points where you had to compromise and did not strictly follow their instructions.

package/skills/simple-engineering/SKILL.md

@@ -1,27 +1,27 @@
----
-name: simple-engineering
-description: A skill outlining the fundamental principles to keep in mind when writing or editing code. Read this skill before developing an implementation plan or writing or reviewing code, and apply it to your work.
-license: MIT
-metadata:
-  author: Robot-Inventor
----
-
-# Simple Engineering
-
-## Keep it simple and elegant
-
-Overengineering is a shameful and foolish act, and it is important to always pursue simple and elegant solutions.
-
-Before implementing a feature or fixing a bug, consider all options. Instead of just listing similar choices or being bound by preconceptions and previous thinking, consider all options, including completely different approaches. Among the available options, choose the one that is the clearest, simplest, requires the fewest lines of code, and meets the user's requirements. There is no need to use iron plates and nails to repair torn clothes. Choose a right-sized, simple approach rather than an overly large and complex one.
-
-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.
-
-## Avoid reinventing the wheel
-
-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.
-
-## Keep only necessary changes
-
-Keep the YAGNI (You aren't gonna need it) principle in mind. You should not introduce complexity just because you might need it in the future. Also, there is no need to maintain backward compatibility for unreleased features.
-
-The code ultimately delivered to the user should be such that every line of change is necessary and no unnecessary code remains. Carefully review the diff line by line, rather than file by file, to ensure that all changes are truly necessary.
+---
+name: simple-engineering
+description: A skill outlining the fundamental principles to keep in mind when writing or editing code. Read this skill before developing an implementation plan or writing or reviewing code, and apply it to your work.
+license: MIT
+metadata:
+  author: Robot-Inventor
+---
+
+# Simple Engineering
+
+## Keep it simple and elegant
+
+Overengineering is a shameful and foolish act, and it is important to always pursue simple and elegant solutions.
+
+Before implementing a feature or fixing a bug, consider all options. Instead of just listing similar choices or being bound by preconceptions and previous thinking, consider all options, including completely different approaches. Among the available options, choose the one that is the clearest, simplest, requires the fewest lines of code, and meets the user's requirements. There is no need to use iron plates and nails to repair torn clothes. Choose a right-sized, simple approach rather than an overly large and complex one.
+
+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.
+
+## Avoid reinventing the wheel
+
+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.
+
+## Keep only necessary changes
+
+Keep the YAGNI (You aren't gonna need it) principle in mind. You should not introduce complexity just because you might need it in the future. Also, there is no need to maintain backward compatibility for unreleased features.
+
+The code ultimately delivered to the user should be such that every line of change is necessary and no unnecessary code remains. Carefully review the diff line by line, rather than file by file, to ensure that all changes are truly necessary.

package/skills/web-master/SKILL.md

@@ -1,109 +1,109 @@
----
-name: web-master
-description: A skill outlining the fundamental principles to keep in mind when writing or editing web-related code. Read this skill before developing an implementation plan or writing or reviewing code for web-related tasks, and apply it to your work.
-license: MIT
-metadata:
-  author: Robot-Inventor
----
-
-# Web Master
-
-Follow these instructions when writing web-related code.
-
-## TypeScript
-
-### Do not use type assertions
-
-Do not reach for type assertions unless you need one. Never add a type assertion up front because you think you might need it later. You may use a type assertion only when all of these conditions apply:
-
-- You first write the code without a type assertion and encounter a type error.
-- You cannot resolve that type error by improving type definitions elsewhere.
-- Adding the type assertion does not compromise type safety.
-
-### Do not use `ReturnType`
-
-Do not use `ReturnType` unless you need it. Use the following approaches instead.
-
-If you need to use the return type of a specific function defined in the project somewhere other than that function:
-
-- For a simple primitive type such as `boolean` or `string`, write the type directly.
-- For a complex type, define a named type, specify it as the function's return type (`(): T => {}`), and reuse `T`.
-
-If you need the return type of a library function:
-
-- Check the function's type definitions first.
-- If the library exports that type, use the exported type.
-  - If you need to pass the return type of another library function as a type argument and the library does not export that function's return type, you may use `ReturnType` inside the type argument.
-- If the library does not export the type:
-  - Write the type directly if it is a simple primitive type.
-  - Otherwise, you may use `ReturnType`.
-
-```ts
-// Incorrect
-import foo from "foo";
-
-const myFunc = (): string => {...};
-
-const myFunc2 = (arg: ReturnType<typeof foo>, arg2: ReturnType<typeof myFunc>): number => {...};
-
-// Correct
-import type { FooResult } from "foo";
-
-const myFunc = (): string => {...};
-
-const myFunc2 = (arg: FooResult, arg2: string): number => {...};
-```
-
-### Prefer `as const satisfies` over type annotations
-
-Do not add type annotations unless you need them. Start by writing the code without a type annotation. If that causes a type error, first try to resolve it by improving type definitions elsewhere. Use a type annotation only as a last resort when those changes cannot solve the problem.
-
-When you write an object and need to guarantee that it conforms to a specific type, use `satisfies`. If the object will not change, also use `as const`.
-
-```ts
-// Incorrect
-const foo: Record<string, string> = {
-  bar: "bar",
-};
-
-// Correct
-const foo = {
-  bar: "bar",
-} as const satisfies T;
-```
-
-### Do not disable ESLint rules
-
-Do not disable ESLint rules as an easy workaround. ESLint errors usually identify low-quality code rather than create pointless obstacles. Disabling a rule to silence an error leaves the underlying problem in place.
-
-Disable an ESLint rule only as a last resort when no better option exists. Handle ESLint errors as follows:
-
-1. Understand what ESLint is reporting. Identify the affected code and the purpose behind the rule.
-2. Improve the code in a way that addresses that purpose.
-3. Disable the rule only when complying with it would make the code **excessively** complex, the warning is a clear false positive, you have another legitimate reason to disable it, or a possible fix would conflict with the rule's underlying intent.
-
-#### Examples
-
-The ESLint `sort-imports` rule defines a consistent import order. In properly modularized code, behavior should not depend on import order, so you should follow the rule.
-
-```ts
-// Incorrect
-/* eslint-disable sort-imports */
-import foo from "foo";
-import bar from "bar";
-
-// Correct
-import bar from "bar";
-import foo from "foo";
-```
-
-The `no-magic-numbers` rule exists to give numeric values meaningful names when their purpose would otherwise be unclear. You do not need to force an obvious value, such as `60` when it represents the number of seconds in a minute, into a constant just to satisfy the rule. In that case, disabling the rule is acceptable. Replacing `1` with a constant named `ONE` also defeats the purpose of `no-magic-numbers`. Give the value a meaningful name instead, or disable the rule if its meaning is already obvious. Also consider whether the number needs to be hard-coded in the first place.
-
-```ts
-// Incorrect
-// eslint-disable-next-line no-magic-numbers
-if (myArray.length !== 0) {...}
-
-// Correct
-if (myArray.length) {...}
-```
+---
+name: web-master
+description: A skill outlining the fundamental principles to keep in mind when writing or editing web-related code. Read this skill before developing an implementation plan or writing or reviewing code for web-related tasks, and apply it to your work.
+license: MIT
+metadata:
+  author: Robot-Inventor
+---
+
+# Web Master
+
+Follow these instructions when writing web-related code.
+
+## TypeScript
+
+### Do not use type assertions
+
+Do not reach for type assertions unless you need one. Never add a type assertion up front because you think you might need it later. You may use a type assertion only when all of these conditions apply:
+
+- You first write the code without a type assertion and encounter a type error.
+- You cannot resolve that type error by improving type definitions elsewhere.
+- Adding the type assertion does not compromise type safety.
+
+### Do not use `ReturnType`
+
+Do not use `ReturnType` unless you need it. Use the following approaches instead.
+
+If you need to use the return type of a specific function defined in the project somewhere other than that function:
+
+- For a simple primitive type such as `boolean` or `string`, write the type directly.
+- For a complex type, define a named type, specify it as the function's return type (`(): T => {}`), and reuse `T`.
+
+If you need the return type of a library function:
+
+- Check the function's type definitions first.
+- If the library exports that type, use the exported type.
+  - If you need to pass the return type of another library function as a type argument and the library does not export that function's return type, you may use `ReturnType` inside the type argument.
+- If the library does not export the type:
+  - Write the type directly if it is a simple primitive type.
+  - Otherwise, you may use `ReturnType`.
+
+```ts
+// Incorrect
+import foo from "foo";
+
+const myFunc = (): string => {...};
+
+const myFunc2 = (arg: ReturnType<typeof foo>, arg2: ReturnType<typeof myFunc>): number => {...};
+
+// Correct
+import type { FooResult } from "foo";
+
+const myFunc = (): string => {...};
+
+const myFunc2 = (arg: FooResult, arg2: string): number => {...};
+```
+
+### Prefer `as const satisfies` over type annotations
+
+Do not add type annotations unless you need them. Start by writing the code without a type annotation. If that causes a type error, first try to resolve it by improving type definitions elsewhere. Use a type annotation only as a last resort when those changes cannot solve the problem.
+
+When you write an object and need to guarantee that it conforms to a specific type, use `satisfies`. If the object will not change, also use `as const`.
+
+```ts
+// Incorrect
+const foo: Record<string, string> = {
+  bar: "bar",
+};
+
+// Correct
+const foo = {
+  bar: "bar",
+} as const satisfies T;
+```
+
+### Do not disable ESLint rules
+
+Do not disable ESLint rules as an easy workaround. ESLint errors usually identify low-quality code rather than create pointless obstacles. Disabling a rule to silence an error leaves the underlying problem in place.
+
+Disable an ESLint rule only as a last resort when no better option exists. Handle ESLint errors as follows:
+
+1. Understand what ESLint is reporting. Identify the affected code and the purpose behind the rule.
+2. Improve the code in a way that addresses that purpose.
+3. Disable the rule only when complying with it would make the code **excessively** complex, the warning is a clear false positive, you have another legitimate reason to disable it, or a possible fix would conflict with the rule's underlying intent.
+
+#### Examples
+
+The ESLint `sort-imports` rule defines a consistent import order. In properly modularized code, behavior should not depend on import order, so you should follow the rule.
+
+```ts
+// Incorrect
+/* eslint-disable sort-imports */
+import foo from "foo";
+import bar from "bar";
+
+// Correct
+import bar from "bar";
+import foo from "foo";
+```
+
+The `no-magic-numbers` rule exists to give numeric values meaningful names when their purpose would otherwise be unclear. You do not need to force an obvious value, such as `60` when it represents the number of seconds in a minute, into a constant just to satisfy the rule. In that case, disabling the rule is acceptable. Replacing `1` with a constant named `ONE` also defeats the purpose of `no-magic-numbers`. Give the value a meaningful name instead, or disable the rule if its meaning is already obvious. Also consider whether the number needs to be hard-coded in the first place.
+
+```ts
+// Incorrect
+// eslint-disable-next-line no-magic-numbers
+if (myArray.length !== 0) {...}
+
+// Correct
+if (myArray.length) {...}
+```