Add 260+ Claude Code skills from skills.sh

Complete collection of AI agent skills including:
- Frontend Development (Vue, React, Next.js, Three.js)
- Backend Development (NestJS, FastAPI, Node.js)
- Mobile Development (React Native, Expo)
- Testing (E2E, frontend, webapp)
- DevOps (GitHub Actions, CI/CD)
- Marketing (SEO, copywriting, analytics)
- Security (binary analysis, vulnerability scanning)
- And many more...

Synchronized from: https://skills.sh/

Co-Authored-By: Claude <noreply@anthropic.com>

commit-work/skill.md

@@ -0,0 +1,55 @@
+---
+name: commit-work
+description: "Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits."
+---
+
+# Commit work
+
+## Goal
+Make commits that are easy to review and safe to ship:
+- only intended changes are included
+- commits are logically scoped (split when needed)
+- commit messages describe what changed and why
+
+## Inputs to ask for (if missing)
+- Single commit or multiple commits? (If unsure: default to multiple small commits when there are unrelated changes.)
+- Commit style: Conventional Commits are required.
+- Any rules: max subject length, required scopes.
+
+## Workflow (checklist)
+1) Inspect the working tree before staging
+   - `git status`
+   - `git diff` (unstaged)
+   - If many changes: `git diff --stat`
+2) Decide commit boundaries (split if needed)
+   - Split by: feature vs refactor, backend vs frontend, formatting vs logic, tests vs prod code, dependency bumps vs behavior changes.
+   - If changes are mixed in one file, plan to use patch staging.
+3) Stage only what belongs in the next commit
+   - Prefer patch staging for mixed changes: `git add -p`
+   - To unstage a hunk/file: `git restore --staged -p` or `git restore --staged <path>`
+4) Review what will actually be committed
+   - `git diff --cached`
+   - Sanity checks:
+     - no secrets or tokens
+     - no accidental debug logging
+     - no unrelated formatting churn
+5) Describe the staged change in 1-2 sentences (before writing the message)
+   - "What changed?" + "Why?"
+   - If you cannot describe it cleanly, the commit is probably too big or mixed; go back to step 2.
+6) Write the commit message
+   - Use Conventional Commits (required):
+     - `type(scope): short summary`
+     - blank line
+     - body (what/why, not implementation diary)
+     - footer (BREAKING CHANGE) if needed
+   - Prefer an editor for multi-line messages: `git commit -v`
+   - Use `references/commit-message-template.md` if helpful.
+7) Run the smallest relevant verification
+   - Run the repo's fastest meaningful check (unit tests, lint, or build) before moving on.
+8) Repeat for the next commit until the working tree is clean
+
+## Deliverable
+Provide:
+- the final commit message(s)
+- a short summary per commit (what/why)
+- the commands used to stage/review (at minimum: `git diff --cached`, plus any tests run)