Initial commit

skills/cli/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: cli
+description: CLI guidelines. Use whenever using the Bash tool, which is almost always. Also use when you see "command not found: __zoxide_z" errors.
+---
+
+# CLI Guidelines
+
+## Directory Navigation
+
+- I replaced `cd` with `zoxide`. Use `command cd` to change directories
+  - This is the only command that needs to be prefixed with `command`
+  - Don't prefix `git` with `command git`
+- Try not to use `cd` or `zoxide` at all. It's usually not necessary with CLI commands
+  - Don't run `cd <dir> && git <subcommand>`
+  - Prefer `git -C <dir> <subcommand>`
+
+## Flag Names
+
+Prefer long flag names when available:
+
+- Don't run `git commit -m`
+- Run `git commit --message` instead

skills/code-quality/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: code-quality
+description: Code quality guidelines. ALWAYS use skill for ANY code changes.
+---
+
+# Code Quality Guidelines
+
+## Don't write forgiving code
+
+- Don't permit multiple input formats
+  - In TypeScript, this means avoiding Union Type (the `|` in types)
+- Use preconditions
+  - Use schema libraries
+  - Assert that inputs match expected formats
+  - When expectations are violated, throw, don't log
+- Don't add defensive try/catch blocks
+  - Usually we let exceptions propagate out
+- Don't keep legacy code paths as fallbacks
+  - Remove old code instead of keeping it around for compatibility
+
+## Naming Conventions
+
+- Don't use abbreviations or acronyms
+  - Choose `number` instead of `num` and `greaterThan` instead of `gt`
+
+## File Management
+
+- Prefer editing an existing file to creating a new one
+- Confirm with the user before creating any new markdown files
+
+## Style
+
+- Emoji and unicode characters are welcome
+  - Use them at the beginning of comments, commit messages, and in headers in docs

skills/comment-cleanup/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: comment-cleanup
+description: Guidelines for comments in code. Use when adding, editing, or removing comments.
+---
+
+# Comment Guidelines
+
+- Use comments sparingly
+- Don't comment out code
+  - Remove it instead
+- Don't add comments that describe the process of changing code
+  - Comments should not include past tense verbs like added, removed, or changed
+  - Example: `this.timeout(10_000); // Increase timeout for API calls`
+  - This is bad because a reader doesn't know what the timeout was increased from, and doesn't care about the old behavior
+- Don't add comments that emphasize different versions of the code, like "this code now handles"
+- Do not use end-of-line comments
+  - Place comments above the code they describe

skills/testing/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: testing
+description: Testing guidelines. Use when Writing, Editing, or reviewing tests.
+---
+
+# Testing Guidelines
+
+## Test Naming
+
+- Test names should not include the word "test"
+
+## Assertions
+
+- Test assertions should be strict
+  - Bad: `expect(content).to.include('valid-content')`
+  - Better: `expect(content).to.equal({ key: 'valid-content' })`
+  - Best: `expect(content).to.deep.equal({ key: 'valid-content' })`
+
+## Mocking
+
+- Use mocking as a last resort
+  - Don't mock a database, if it's possible to use an in-memory fake implementation instead
+  - Don't mock a larger API if we can mock a smaller API that it delegates to
+  - Prefer frameworks that record/replay network traffic over mocking
+  - Don't mock our own code
+- Don't overuse the word "mock"
+  - Mocking means replacing behavior, by replacing method or function bodies, using a mocking framework
+  - In other cases use the words "fake" or "example"