Name: commit
Author: Wizardworks-AB

Prompt file imported from Wizardworks-AB/wizardworks-client-agent-template (.claude/commands/commit.md). Copyright stays with the author.

Commit Command

This command validates your changes against the project's Patterns & Practices before committing.

What This Command Does

Review changes — Run /code-review on staged/unstaged changes
Generate documentation — Create brief feature documentation for significant changes
Decide — If review passes → commit + push. If issues found → present options.
Commit — Create commit with descriptive message

Workflow

/commit
     ↓
┌─ 1. Show diff summary (files changed, lines added/removed)
├─ 2. Run code review agent against Patterns & Practices
├─ 3. Generate brief change documentation (if feature-level change)
│
├─ Review PASSED?
│   ├─ YES → Generate commit message, commit, push
│   └─ NO  → Show issues, ask:
│            a) Fix issues first (recommended)
│            b) Commit anyway (with review notes in commit message)
│            c) Cancel
└─ Done

Steps

Step 1: Analyze Changes

Run git diff and git diff --staged to understand what changed.

Summarize:

Files changed
Nature of changes (new feature, bug fix, refactor, etc.)
Scope (single file vs multi-file)

Step 2: Code Review

Spawn the code-reviewer agent to review changes against the project's standards:

Patterns & Practices compliance
Security issues
Architecture adherence
Tests for the change

Focus on the diff only — don't review the entire codebase.

Step 3: Documentation (if applicable)

For feature-level changes (not typos, not small fixes):

Generate a brief documentation entry:

# [Feature/Change Name]

## Vad
[1-2 sentences: what does this change do?]

## Hur
[Brief technical description]

## Filer
[List of key files changed]

Save to docs/features/ or update existing documentation.

Skip documentation for:

Typo fixes
Dependency updates
Config changes
Small bug fixes (< 10 lines changed)

Step 4: Commit

If review passed (or user chose to commit anyway):

Generate descriptive commit message based on changes
Stage all relevant files (including generated docs)
Commit with the message
Push to current branch

Usage

/commit                           # Review and commit all changes
/commit fix login timeout         # Commit with specific message context

Example Output

## Commit Summary

### Changes
- 3 files changed: the user service, its API endpoint, and their tests
- Type: New feature (user registration endpoint)

### P&P Review: ✅ PASSED
- CSR pattern: ✅
- Public IDs: ✅
- DTOs: ✅
- Tests: ✅
- Security: ✅

### Documentation
Generated: docs/features/user-registration.md

### Commit
Message: "Add user registration with email verification"
Branch: feature/user-registration
Pushed: ✅

---

(If review fails)

### P&P Review: ❌ 2 ISSUES FOUND

1. [HIGH] Missing input validation on email field
   File: <the endpoint handling registration>:42

2. [MEDIUM] Magic number for token expiry
   File: <the user service>:78

Options:
a) Fix issues first (recommended)
b) Commit anyway (issues noted in commit message)
c) Cancel

/code-review — Full code review (this command runs a focused version)
/security-review — Dedicated security audit
/update-docs — Full documentation update
See rules/git-workflow.md for commit message standards

Remember: Quality commits build quality software.

Install commit and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# Commit Command This command validates your changes against the project's Patterns & Practices before committing. ## What This Command Does 1. **Review changes** — Run `/code-review` on staged/unstaged changes 2. **Generate documentation** — Create brief feature documentation for significant changes 3. **Decide** — If review passes → commit + push. If issues found → present options. 4. **Commit** — Create commit with descriptive message ## Workflow ``` /commit ↓ ┌─ 1. Show diff summary (files changed, lines added/removed) ├─ 2. Run code review agent against Patterns & Practices ├─ 3. Generate brief change documentation (if feature-level change) │ ├─ Review PASSED? │ ├─ YES → Generate commit message, commit, push │ └─ NO → Show issues, ask: │ a) Fix issues first (recommended) │ b) Commit anyway (with review notes in commit message) │ c) Cancel └─ Done ``` ## Steps ### Step 1: Analyze Changes Run `git diff` and `git diff --staged` to understand what changed. Summarize: - Files changed - Nature of changes (new feature, bug fix, refactor, etc.) - Scope (single file vs multi-file) ### Step 2: Code Review Spawn the code-reviewer agent to review changes against the project's standards: - Patterns & Practices compliance - Security issues - Architecture adherence - Tests for the change Focus on the **diff only** — don't review the entire codebase. ### Step 3: Documentation (if applicable) For feature-level changes (not typos, not small fixes): Generate a brief documentation entry: ```markdown # [Feature/Change Name] ## Vad [1-2 sentences: what does this change do?] ## Hur [Brief technical description] ## Filer [List of key files changed] ``` Save to `docs/features/` or update existing documentation. Skip documentation for: - Typo fixes - Dependency updates - Config changes - Small bug fixes (< 10 lines changed) ### Step 4: Commit If review passed (or user chose to commit anyway): 1. Generate descriptive commit message based on changes 2. Stage all relevant files (including generated docs) 3. Commit with the message 4. Push to current branch ## Usage ```bash /commit # Review and commit all changes /commit fix login timeout # Commit with specific message context ``` ## Example Output ``` ## Commit Summary ### Changes - 3 files changed: the user service, its API endpoint, and their tests - Type: New feature (user registration endpoint) ### P&P Review: ✅ PASSED - CSR pattern: ✅ - Public IDs: ✅ - DTOs: ✅ - Tests: ✅ - Security: ✅ ### Documentation Generated: docs/features/user-registration.md ### Commit Message: "Add user registration with email verification" Branch: feature/user-registration Pushed: ✅ --- (If review fails) ### P&P Review: ❌ 2 ISSUES FOUND 1. [HIGH] Missing input validation on email field File: <the endpoint handling registration>:42 2. [MEDIUM] Magic number for token expiry File: <the user service>:78 Options: a) Fix issues first (recommended) b) Commit anyway (issues noted in commit message) c) Cancel ``` ## Related - `/code-review` — Full code review (this command runs a focused version) - `/security-review` — Dedicated security audit - `/update-docs` — Full documentation update - See `rules/git-workflow.md` for commit message standards **Remember**: Quality commits build quality software.

{ "prompt": "# Commit Command\n\nThis command validates your changes against the project's Patterns & Practices before committing.\n\n## What This Command Does\n\n1. **Review changes** — Run `/code-review` on staged/unstaged changes\n2. **Generate documentation** — Create brief feature documentation for significant changes\n3. **Decide** — If review passes → commit + push. If issues found → present options.\n4. **Commit** — Create commit with descriptive message\n\n## Workflow\n\n```\n/commit\n ↓\n┌─ 1. Show diff summary (files changed, lines added/removed)\n├─ 2. Run code review agent against Patterns & Practices\n├─ 3. Generate brief change documentation (if feature-level change)\n│\n├─ Review PASSED?\n│ ├─ YES → Generate commit message, commit, push\n│ └─ NO → Show issues, ask:\n│ a) Fix issues first (recommended)\n│ b) Commit anyway (with review notes in commit message)\n│ c) Cancel\n└─ Done\n```\n\n## Steps\n\n### Step 1: Analyze Changes\n\nRun `git diff` and `git diff --staged` to understand what changed.\n\nSummarize:\n- Files changed\n- Nature of changes (new feature, bug fix, refactor, etc.)\n- Scope (single file vs multi-file)\n\n### Step 2: Code Review\n\nSpawn the code-reviewer agent to review changes against the project's standards:\n\n- Patterns & Practices compliance\n- Security issues\n- Architecture adherence\n- Tests for the change\n\nFocus on the **diff only** — don't review the entire codebase.\n\n### Step 3: Documentation (if applicable)\n\nFor feature-level changes (not typos, not small fixes):\n\nGenerate a brief documentation entry:\n\n```markdown\n# [Feature/Change Name]\n\n## Vad\n[1-2 sentences: what does this change do?]\n\n## Hur\n[Brief technical description]\n\n## Filer\n[List of key files changed]\n```\n\nSave to `docs/features/` or update existing documentation.\n\nSkip documentation for:\n- Typo fixes\n- Dependency updates\n- Config changes\n- Small bug fixes (< 10 lines changed)\n\n### Step 4: Commit\n\nIf review passed (or user chose to commit anyway):\n\n1. Generate descriptive commit message based on changes\n2. Stage all relevant files (including generated docs)\n3. Commit with the message\n4. Push to current branch\n\n## Usage\n\n```bash\n/commit # Review and commit all changes\n/commit fix login timeout # Commit with specific message context\n```\n\n## Example Output\n\n```\n## Commit Summary\n\n### Changes\n- 3 files changed: the user service, its API endpoint, and their tests\n- Type: New feature (user registration endpoint)\n\n### P&P Review: ✅ PASSED\n- CSR pattern: ✅\n- Public IDs: ✅\n- DTOs: ✅\n- Tests: ✅\n- Security: ✅\n\n### Documentation\nGenerated: docs/features/user-registration.md\n\n### Commit\nMessage: \"Add user registration with email verification\"\nBranch: feature/user-registration\nPushed: ✅\n\n---\n\n(If review fails)\n\n### P&P Review: ❌ 2 ISSUES FOUND\n\n1. [HIGH] Missing input validation on email field\n File: <the endpoint handling registration>:42\n\n2. [MEDIUM] Magic number for token expiry\n File: <the user service>:78\n\nOptions:\na) Fix issues first (recommended)\nb) Commit anyway (issues noted in commit message)\nc) Cancel\n```\n\n## Related\n\n- `/code-review` — Full code review (this command runs a focused version)\n- `/security-review` — Dedicated security audit\n- `/update-docs` — Full documentation update\n- See `rules/git-workflow.md` for commit message standards\n\n**Remember**: Quality commits build quality software.", "variables": [], "notes": "Commit with Patterns & Practices validation and auto-documentation Arguments: [optional message].", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/Wizardworks-AB/wizardworks-client-agent-template", "path": ".claude/commands/commit.md", "ref": "add3d3d756c5a843e170b88a43f597ba02609674", "url": "https://github.com/Wizardworks-AB/wizardworks-client-agent-template/blob/add3d3d756c5a843e170b88a43f597ba02609674/.claude/commands/commit.md", "key": "Wizardworks-AB/wizardworks-client-agent-template/.claude/commands/commit.md" } } }

commit

About

Commit Command

What This Command Does

Workflow

Steps

Step 1: Analyze Changes

Step 2: Code Review

Step 3: Documentation (if applicable)

Step 4: Commit

Usage

Example Output

Related

Install commit and it becomes one more candidate the router can pick - when it fits.

Use it

Manifest

Reviews