adding monkeytype

.claude/hooks/format-and-lint.sh

@@ -0,0 +1,27 @@
+#!/bin/bash
+INPUT=$(cat)
+FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')
+
+if [[ -z "$FILE_PATH" ]]; then
+  exit 0
+fi
+
+# Only run on ts/tsx/js/jsx files
+if [[ "$FILE_PATH" != *.ts && "$FILE_PATH" != *.tsx && "$FILE_PATH" != *.js && "$FILE_PATH" != *.jsx ]]; then
+  exit 0
+fi
+
+npx oxfmt "$FILE_PATH" >&2 || true
+npx oxlint --type-aware --type-check "$FILE_PATH" >&2 || true
+
+# Run matching test file if it exists
+# Map frontend/src/ts/<path>/<file>.ts(x) -> frontend/__tests__/<path>/<file>.spec.ts(x)
+if [[ "$FILE_PATH" == frontend/src/ts/* ]]; then
+  REL="${FILE_PATH#frontend/src/ts/}"
+  BASE="${REL%.*}"
+  EXT="${REL##*.}"
+  TEST_FILE="frontend/__tests__/${BASE}.spec.${EXT}"
+  if [[ -f "$TEST_FILE" ]]; then
+    npx vitest run "$TEST_FILE" >&2 || true
+  fi
+fi

.claude/settings.json

@@ -0,0 +1,15 @@
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash .claude/hooks/format-and-lint.sh"
+          }
+        ]
+      }
+    ]
+  }
+}

.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."