@robot-inventor/agent-skills 0.9.1 → 0.10.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@robot-inventor/agent-skills",
-  "version": "0.9.1",
+  "version": "0.10.0",
   "description": "Roboin's personal collection of Agent Skills.",
   "homepage": "https://github.com/Robot-Inventor/agent-skills#readme",
   "bugs": {

package/skills/simple-engineering/SKILL.md

@@ -3,7 +3,7 @@ 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
+  author: Robot-Inventor
 ---
 
 # Simple Engineering
@@ -26,6 +26,16 @@ Keep the YAGNI (You aren't gonna need it) principle in mind. You should not intr
 
 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.
 
+## Keep the codebase clean
+
+Writing code is not synonymous with simply adding to existing code. Remove code that is no longer needed. Avoid forcibly adding to existing code that is semantically different; maintain clean code by splitting code as needed and refactoring, including redesigning the code.
+
+Refactoring should not be done only at special times; if there are poorly designed areas within the scope of the current changes that can be resolved with small-scale refactoring during normal work, refactoring should be proactively performed. However, explicit permission from the user should be sought before performing large-scale refactoring.
+
+## DRY principle and modifiability
+
+Keep the DRY principle and modifiability in mind. Avoid defining the same thing repeatedly; instead, aim for code that is easy to modify, where changing a single location automatically updates all related processes. For instance, regarding i18n, the ideal approach is to manage available languages and their labels in one place, such that adding or removing a language requires only updating that single location and adding or removing the corresponding translation file.
+
 ## Establish a shared understanding
 
-If `request_user_input` tool is available, actively use it when asking the user questions, especially while running the grilling session. Do not use it for a single yes/no question; instead, use it when asking multiple questions at once or when presenting multiple options. The tool description specifies limiting the number of questions to between one and three, but this is merely a recommendation rather than a functional constraint. Use the `request_user_input` tool even if there are four or more questions.
+If `request_user_input` tool is available, actively use it when asking the user questions, especially while running the grilling session. Do not use it for a single yes/no question; instead, use it when asking multiple questions at once or when presenting multiple options. The tool description specifies limiting the number of questions to between one and three, but this is not a functional constraint. If you have more than four questions, enter all of them in `request_user_input`, without limiting yourself to three or fewer.

package/skills/web-master/SKILL.md

@@ -58,17 +58,21 @@ const myFunc2 = (arg: FooResult, arg2: string): number => {...};
 
 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`.
+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`. You don't need to use `as const` on temporary arrays used inline, or `satisfies` on values whose type is obvious, such as arrays of strings. Also, you don't need to specify `ReadOnly` for the type of an `as const satisfies` value.
 
 ```ts
 // Incorrect
-const foo: Record<string, string> = {
-  bar: "bar",
+const foo: T = {
+    bar: "bar"
 };
 
+const foo = {
+    bar: "bar"
+} as const satisfies ReadOnly<T>;
+
 // Correct
 const foo = {
-  bar: "bar",
+    bar: "bar"
 } as const satisfies T;
 ```
 
@@ -107,3 +111,45 @@ if (myArray.length !== 0) {...}
 // Correct
 if (myArray.length) {...}
 ```
+
+The `max-lines` and `max-lines-per-function` rules exist as indicators of code readability and maintainability. Warnings for these rules suggest that your code design may be poor. Simply removing line breaks to meet the rules is a superficial solution and actually makes the code harder to read, thus violating the essence of the rules. Instead, you should fix the problem by removing redundant code or properly restructuring and modularizing it. If you've only slightly exceeded the limit and your code is already well-designed, you should disable the rules rather than removing line breaks or forcing splits.
+
+### Design code with types at its core
+
+TypeScript types are not just an afterthought to JavaScript. Designing with types in mind keeps your code clean and efficient. With proper type design, validation is rarely needed except at project boundaries such as user input or web API responses. When code is properly designed based on types, function inputs and outputs are reliable, eliminating the need to validate values repeatedly.
+
+## CSS
+
+### Define only the necessary styles
+
+When writing CSS, first check if a reset CSS is loaded into your project and if that reset CSS is applied to the page or layout file you are currently working on. If a reset CSS is in place, you do not need to define styles that overlap with it, such as `margin: 0` (this is an example, but not limited to this).
+
+In CSS, you should only specify properties that need to be changed from the parent element, and you should not specify properties that do not need to be changed again. Remember that CSS has inheritance, and style accordingly.
+
+### Intentional typography design
+
+Do not specify `font-family` outside the document root unless absolutely necessary, such as in code blocks. Also, as a general rule, do not change the font size unless there is a clear reason, such as making unimportant notices smaller or headings larger. Since the base font size may be overridden by browser settings, use `em` or `rem` instead of `px` for font size or areas that depend on font size.
+
+## HTML and JSX
+
+### Avoid redundant definitions
+
+If a UI component library is available, actively use its components and reduce custom implementations unless absolutely necessary.
+
+Also, avoid adding unnecessary attributes. For example, icon component libraries may have `aria-hidden` set by default; in such cases, there's no need to set this attribute again when using the component.
+
+## Testing
+
+### Design tests properly
+
+Do not mock application-owned modules. Prefer real implementations and test observable behavior rather than implementation wiring. Use mocks only at slow, nondeterministic, destructive, or external boundaries. Avoid tests whose assertions only verify mock calls or values configured on mocks.
+
+Test the behavior from an external perspective, not the internal implementation. In other words, tests that require changes when refactoring are bad tests. Test the project's code, not the browser or external libraries. For example, it's obvious that a button element will be displayed in the browser when you write it; this tests the browser's behavior, not the project's code.
+
+### Do not export for testing purposes
+
+You should not export functions, values, or other data solely for testing purposes. When testing things that are not used outside of the file except for testing, use [in-source testing](https://vitest.dev/guide/in-source) instead of exporting them and creating a separate test file.
+
+### Do not mock the external environment
+
+For tests that require access to databases or external servers, use Testcontainers instead of mocking them. If a timer is needed, use the fake timer from the test library.