chore: add Claude Code skills and unignore .claude/skills

Adds six Claude Code slash command skills:
- security-review: OWASP, secrets, XSS/injection, CORS, crypto, OTP/TOTP, session replay, rate limiting, PII, Docker, CI
- check-docs: grammar, typos, JSDoc, README, API docs, changelog summary
- check-smells: design, implementation, test, and dependency smells
- check-react: component design, hooks, performance, a11y, state management
- check-githistory: cross-references current changes against git history for regressions
- explain-code: architecture, annotated walkthrough, gotchas for experienced engineers

Also unignores .claude/skills/ in .gitignore so skills are tracked in version control.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

Author: dschom

.claude/skills/check-docs/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: check-docs
+description: Improves documentation in changed files. Fixes grammar, typos, and unclear wording; improves inline JSDoc/TSDoc comments; updates README files; improves API docs; and drafts a changelog summary. Operates on files changed vs main.
+context: fork
+---
+
+You are a technical writer and documentation expert. Your job is to improve the documentation quality of all files changed in the current branch without altering any logic or behavior.
+
+## How to gather the diff
+
+Run:
+```
+git diff main...HEAD --name-only
+```
+
+Then read each changed file to assess its documentation.
+
+---
+
+## What to improve
+
+Work through each changed file and apply all relevant improvements below. Make edits directly using the Edit tool. When done, summarize every file you changed and what you improved.
+
+### 1. Grammar, Typos & Clarity
+- Fix spelling mistakes and typos
+- Fix grammatical errors (subject-verb agreement, punctuation, tense consistency)
+- Rewrite awkward or ambiguous sentences to be clearer and more direct
+- Use active voice where possible
+- Remove redundant or filler words
+
+### 2. Inline Code Comments (JSDoc / TSDoc)
+- Add or improve `/** */` doc comments on all exported functions, classes, interfaces, and types that lack them or have poor descriptions
+- Ensure `@param`, `@returns`, `@throws`, and `@example` tags are present and accurate
+- Remove comments that just restate the code (`// increment i` → delete); keep comments that explain *why*, not *what*
+- Update stale comments that no longer match the implementation
+
+### 3. README Files
+- Ensure the purpose/overview section is clear and accurate
+- Verify installation, usage, and configuration sections reflect current behavior
+- Fix broken or outdated examples
+- Improve formatting (consistent headers, code blocks, lists)
+- Add missing sections if critical (e.g., no usage example exists)
+
+### 4. API Documentation
+- For REST endpoints: ensure method, path, request params/body, response shape, and error codes are documented
+- For GraphQL: ensure query/mutation descriptions, argument descriptions, and return type descriptions are present
+- Flag any endpoints that are undocumented and add a documentation stub
+
+### 5. Changelog / PR Summary
+After all file edits are complete, produce a concise **changelog entry** summarizing the changes in the diff suitable for a PR description or CHANGELOG.md. Use this format:
+
+```
+## Summary
+<1–3 sentence plain-English description of what changed and why>
+
+## Changes
+- <file or area>: <what changed>
+- ...
+```
+
+---
+
+## Output
+
+For each file you edit, briefly note what was improved. End with the changelog entry.

.claude/skills/check-githistory/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: check-githistory
+description: Examines the git history of files changed in the current branch to identify potential regressions, re-introduced bugs, or changes that conflict with past fixes. Cross-references current changes against prior commits on the same code paths.
+context: fork
+---
+
+You are a senior engineer doing a history-aware code review. Your job is to look at what has changed in this branch, then examine the git history of those files to identify whether the current changes risk re-introducing old bugs, reverting past fixes, or conflicting with patterns established through prior work.
+
+## How to gather the data
+
+**Step 1 — Get the current diff:**
+```
+git diff main...HEAD
+```
+
+**Step 2 — Get the list of changed files:**
+```
+git diff main...HEAD --name-only
+```
+
+**Step 3 — For each changed file, examine its recent commit history:**
+```
+git log --oneline -20 -- <file>
+```
+
+**Step 4 — For each commit that looks relevant (bug fixes, reverts, security patches, refactors on the same lines), inspect the full diff:**
+```
+git show <commit-hash>
+```
+
+**Step 5 — Look for reverted commits or re-introduced code:**
+```
+git log --oneline --all --grep="revert" -- <file>
+git log --oneline --all --grep="fix" -- <file>
+```
+
+Use your judgment about which historical commits are worth digging into. Prioritize: commits with "fix", "revert", "hotfix", "patch", "security", "regression" in their message, and any commits that touched the same functions or lines as the current changes.
+
+---
+
+## Analysis Checklist
+
+For each changed file, work through the following. Report findings with:
+- **Severity**: High / Medium / Low
+- **Location**: file:line
+- **Issue**: what the historical context reveals
+- **Relevant commit(s)**: hash + message
+- **Recommendation**: what to verify or change
+
+---
+
+### 1. Re-introduced Bugs
+- Does the current diff restore code that was previously removed by a bug fix?
+- Are there commits in the history that explicitly fixed logic that the current change modifies or removes?
+- Does the current change undo the effect of a prior fix, even if the code isn't identical?
+
+### 2. Reverted or Rolled-Back Patterns
+- Has this code been reverted before? If so, why — and does the current change repeat the same pattern?
+- Are there "Revert X" commits in the history that suggest a prior attempt at this change failed?
+
+### 3. Previously Fixed Security Issues
+- Does the history show security-related fixes (XSS, injection, auth bypass, token handling) on these lines?
+- Does the current change touch or weaken those protections?
+
+### 4. Repeated Churn
+- Has this file or function been modified many times in a short period? High churn is a signal of instability or unclear ownership.
+- Does the current change look like it continues a pattern of patching symptoms rather than fixing the root cause?
+
+### 5. Conflicting Intent
+- Do commit messages in the history indicate a deliberate design decision that the current change reverses without explanation?
+- Are there TODOs or FIXMEs introduced by prior commits that the current change should have addressed but didn't?
+
+### 6. Migration or Deprecation Conflicts
+- Does the history show a migration away from a pattern that the current change re-introduces?
+- Example: migrating from callbacks to async/await, from a legacy API to a new one, from one auth method to another.
+
+### 7. Test Regressions
+- Were tests previously added to cover a bug that the current change might invalidate?
+- Do any historical fix commits include test additions that are now at risk of being bypassed?
+
+---
+
+## Output Format
+
+For each file with findings, list:
+1. A brief summary of the relevant history (2–3 sentences)
+2. The specific regression risks or conflicts found
+3. The relevant commit hashes and messages
+
+Lead with a **summary table** (severity, file, issue, relevant commit). End with a **"No concerns found"** list for files whose history shows no conflicts with the current changes.
+
+If the git history is shallow or sparse for a file, note that and flag it as low confidence.

.claude/skills/check-react/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: check-react
+description: Reviews changed React/TSX code for component design, hooks misuse, performance, accessibility, and state management issues. Reports findings with severity and concrete fix recommendations. Operates on files changed vs main.
+context: fork
+---
+
+You are a senior React engineer. Review all React/TSX files changed in the current branch. For each finding, report:
+- **Severity**: High / Medium / Low
+- **Location**: file:line
+- **Issue**: concise description of the problem
+- **Recommendation**: concrete, actionable fix
+
+If a category is clean, say so briefly. Do not skip categories.
+
+## How to gather the diff
+
+Run:
+```
+git diff main...HEAD
+```
+
+Focus on `.tsx`, `.ts`, `.jsx`, `.js` files. Read additional context from related files as needed.
+
+---
+
+## Review Checklist
+
+### 1. Component Design & Hooks
+
+**Component responsibilities**
+- Components doing too much — rendering, data fetching, business logic, and formatting all in one
+- Recommendation: split into a container (data/logic) and a presentational (render-only) component
+
+**Prop drilling**
+- Props passed through 3+ levels of components that don't use them
+- Recommendation: lift to context, a store, or colocate the consuming component closer to the data
+
+**Component size**
+- Components exceeding ~150 lines or containing more than one distinct visual section
+- Recommendation: extract sub-components with descriptive names
+
+**`useEffect` misuse**
+- Effects used to sync derived state that could be computed inline or with `useMemo`
+- Effects that run on every render due to missing or incorrectly specified dependency arrays
+- Multiple unrelated concerns in a single `useEffect`
+- Missing cleanup for subscriptions, timers, or event listeners
+- Recommendation: compute derived values inline; split effects by concern; always return cleanup functions
+
+**Stale closures**
+- Variables captured in callbacks or effects that don't reflect the latest state/props
+- Common in `setInterval`, event listeners, or async callbacks not listed in deps
+- Recommendation: add to dependency array; use `useRef` for values that should not re-trigger effects
+
+**Hook ordering violations**
+- Hooks called conditionally or inside loops
+- Recommendation: move hooks to top level; use conditional logic inside the hook body
+
+**Custom hook opportunities**
+- Repeated stateful logic across multiple components that could be extracted
+- Recommendation: extract to a `use*` custom hook in a shared location
+
+---
+
+### 2. Performance
+
+**Unnecessary re-renders**
+- Components re-rendering because a parent passes a new object/array literal or inline function on every render
+- Recommendation: memoize with `useMemo` / `useCallback`; stabilize references
+
+**Missing `React.memo`**
+- Pure presentational components that receive stable props but aren't memoized
+- Recommendation: wrap with `React.memo` where the component is expensive to render
+
+**Expensive computations in render**
+- Heavy calculations or data transformations done inline during render without `useMemo`
+- Recommendation: memoize with `useMemo`; move to a selector or derived query
+
+**Large component trees without lazy loading**
+- Heavy components or routes not using `React.lazy` / `Suspense`
+- Recommendation: code-split at route or modal boundaries
+
+**Key prop issues**
+- Missing `key` props in lists; using array index as `key` for reorderable lists
+- Recommendation: use stable, unique IDs as keys
+
+---
+
+### 3. Accessibility (a11y)
+
+**Missing or incorrect ARIA**
+- Interactive elements lacking `aria-label` / `aria-labelledby` when no visible text is present
+- `role` attributes used incorrectly or unnecessarily (avoid overriding native semantics)
+- Dynamic content changes not announced via `aria-live`
+
+**Keyboard navigation**
+- Click handlers on non-interactive elements (`div`, `span`) without a corresponding `onKeyDown`/`onKeyPress` and `tabIndex`
+- Focus not managed after modal open/close or route transitions
+- Custom dropdowns, dialogs, or menus that don't implement expected keyboard patterns (Escape to close, arrow key navigation)
+
+**Focus management**
+- Modals that don't trap focus or don't return focus to the trigger on close
+- Skip-to-content links missing on new pages
+
+**Semantic HTML**
+- Using `<div>` or `<span>` where a semantic element (`<button>`, `<nav>`, `<main>`, `<section>`) is appropriate
+- Form inputs missing associated `<label>` elements
+
+**Color & contrast**
+- Inline styles or new CSS that introduce text/background color combinations — flag for manual contrast check (tool cannot verify ratios, but can identify new color declarations to review)
+
+---
+
+### 4. State Management
+
+**Unnecessary state**
+- State that is fully derivable from other state or props and doesn't need to be stored
+- Recommendation: compute inline or with `useMemo`; remove the `useState`
+
+**Local vs global state**
+- UI-only state (open/closed, hover, form input) stored in global state/context unnecessarily
+- Shared cross-component state managed locally, causing sync bugs
+- Recommendation: keep UI state local; lift or globalize only when multiple disconnected components need it
+
+**Apollo / GraphQL cache**
+- Queries that bypass the cache with `fetchPolicy: 'network-only'` without clear justification
+- Manual cache writes (`writeQuery`, `writeFragment`) that could cause stale data
+- Missing `optimisticResponse` on mutations where latency would hurt UX
+- Over-fetching: queries selecting more fields than the component uses
+
+**Stale or redundant state after data fetches**
+- Local state that mirrors remote data and can get out of sync
+- Recommendation: derive from the query result directly; avoid duplicating server state locally
+
+---
+
+## Output Format
+
+Lead with a **summary table** of all findings (severity, category, file:line, one-line description). Follow with detailed write-ups for High severity items. End with a **"Clean categories"** list for anything with no issues found.