@robot-inventor/agent-skills 0.0.0 → 0.7.0

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) {...}
+```