adding monkeytype

.claude/skills/commit.md

@@ -0,0 +1,30 @@
+# Commit Changes
+
+Trigger: user asks to commit, or uses /commit
+
+## Steps
+
+1. Determine what to commit:
+   - Run `git diff --cached --name-only` to check for staged changes.
+   - If there are staged changes, commit only those. Tell the user: "Committing staged changes."
+   - If no staged changes, run `git diff --name-only` to check for unstaged changes.
+   - If there are unstaged changes, stage all of them (`git add` each file by name) and commit. Tell the user: "Staging and committing all changes."
+   - If no changes at all, tell the user "Nothing to commit." and stop.
+2. Run `git diff --cached` to see the full diff of what will be committed.
+3. Write a conventional commit message:
+   - Format: `<type>: <description>`
+   - Types: `feat`, `fix`, `refactor`, `style`, `chore`, `docs`, `test`, `perf`
+   - Description: lowercase, imperative mood, no period, concise
+   - Pick the type that best fits the change. Use `feat` for new features, `fix` for bug fixes, `refactor` for code restructuring, `style` for visual/CSS-only changes, `chore` for maintenance/tooling.
+   - Add a body (separated by blank line) only if the description alone is insufficient to understand the change.
+4. Show the user the proposed commit message and ask for confirmation before committing.
+5. On confirmation, create the commit. Use a HEREDOC for the message:
+   ```
+   git commit -m "$(cat <<'EOF'
+   <type>: <description>
+
+   Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
+   EOF
+   )"
+   ```
+6. Run `git status` after to verify success.

.claude/skills/review.md

@@ -0,0 +1,21 @@
+# Review Changed Files
+
+Trigger: user asks to review changes, review code, or uses /review
+
+## Steps
+
+1. Determine what to review, in priority order:
+   - If the user has selected specific lines/code, review that selection. Tell the user: "Reviewing selection."
+   - Otherwise, run `git diff --cached --name-only`. If there are staged changes, review only staged changes (`git diff --cached`). Tell the user: "Reviewing staged changes."
+   - Otherwise, run `git diff --name-only`. If there are unstaged changes, review only unstaged changes (`git diff`). Tell the user: "Reviewing unstaged changes."
+   - Otherwise, review the last commit (`git diff HEAD~1`). Tell the user: "Reviewing last commit."
+2. Read the full file for each changed file (not just the diff) to understand context.
+3. Review for:
+   - **Bugs**: null/undefined access, race conditions, off-by-one errors, missing error handling at system boundaries
+   - **Dead code**: unused imports, variables, functions, or parameters introduced or left behind by the changes
+   - **Redundancy**: code that duplicates existing logic or can be simplified
+   - **Consistency**: does the change follow patterns established in surrounding code and project conventions (see CLAUDE.md)
+   - **Tailwind**: non-canonical classes, inline styles that should be Tailwind, missing responsive variants if siblings have them
+   - **Solid-specific**: broken reactivity, missing cleanup, doing things not the "Solid way"
+   - **Improvements**: any other changes that would make the code more robust, readable, maintainable, better
+4. Output a concise list of findings. Highlight which issues should be absolutely fixed before merging/committing. If nothing found, say "No issues found."