// Generate a commit message and commit staged changes using git commit -s -S.
| name | commit |
| description | Generate a commit message and commit staged changes using git commit -s -S. |
| allowed-tools | Bash, AskUserQuestion |
Commit the current staged changes.
git diff --staged. If empty, tell the user there is nothing staged and stop.git log --oneline -5 to understand this repo's commit message style and conventions.git branch --show-current to get the branch name. If it contains an IN-XXX ticket number, include it inline at the end of the subject (e.g. feat: add token refresh IN-123).type: description. Subject max 72 characters. No scope required. No body, no extra trailers, no Co-Authored-By. (The Signed-off-by trailer is added automatically by -s.)git commit -s -S -m "<message>" using exactly the generated message.Record an architecture decision as an ADR in docs/adr/. Use when choosing between frameworks, libraries, databases, or architectural patterns; stating a decision with reasoning ("we decided X instead of Y because..."); or querying past decisions ("why did we choose X?").
Pre-PR validation — license headers, format, lint, TypeScript check, build, and protected file check. Use before submitting any PR, to check if code is ready, validate changes, or verify a branch before review.
Review a pull request against Insights architecture standards — fetches PR diff, verifies previous comments are addressed, validates PR metadata (title, branch, JIRA, size), runs a code-standards check against every file in `.claude/rules/` and `.claude/hooks/guard-protected-files.sh`, and drafts inline review comments with suggested fixes. NEVER auto-posts comments or submits reviews — always presents a draft in the terminal for user approval before any comment lands on the PR. Use when reviewing PRs, checking PR quality, validating code changes, or when the user says "review", "check this PR", or "audit code".
Run the docs site, blog, or Storybook locally. Use when contributing to documentation, previewing blog posts, or developing UI components in isolation. Not needed for regular frontend development.
Full development environment setup from scratch — prerequisites, dependencies, .env file, optional local PostgreSQL database (for auth/collections/chat work), and dev server. Use for first-time setup, broken environments, missing env vars, or when the app won't start.