home / skills / prowler-cloud / prowler / prowler-commit

prowler-commit skill

/skills/prowler-commit

This skill creates professional commits using conventional-commits format, clarifying changes and prompting confirmation before committing.

npx playbooks add skill prowler-cloud/prowler --skill prowler-commit

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.0 KB
---
name: prowler-commit
description: >
  Creates professional git commits following conventional-commits format.
  Trigger: When creating commits, after completing code changes, when user asks to commit.
license: Apache-2.0
metadata:
  author: prowler-cloud
  version: "1.1.0"
  scope: [root, api, ui, prowler, mcp_server]
  auto_invoke:
    - "Creating a git commit"
    - "Committing changes"
---

## Critical Rules

- ALWAYS use conventional-commits format: `type(scope): description`
- ALWAYS keep the first line under 72 characters
- ALWAYS ask for user confirmation before committing
- NEVER be overly specific (avoid counts like "6 subsections", "3 files")
- NEVER include implementation details in the title
- NEVER use `-n` flag unless user explicitly requests it
- NEVER use `git push --force` or `git push -f` (destructive, rewrites history)
- NEVER proactively offer to commit - wait for user to explicitly request it

---

## Commit Format

```
type(scope): concise description

- Key change 1
- Key change 2
- Key change 3
```

### Types

| Type | Use When |
|------|----------|
| `feat` | New feature or functionality |
| `fix` | Bug fix |
| `docs` | Documentation only |
| `chore` | Maintenance, dependencies, configs |
| `refactor` | Code change without feature/fix |
| `test` | Adding or updating tests |
| `perf` | Performance improvement |
| `style` | Formatting, no code change |

### Scopes

| Scope | When |
|-------|------|
| `api` | Changes in `api/` |
| `ui` | Changes in `ui/` |
| `sdk` | Changes in `prowler/` |
| `mcp` | Changes in `mcp_server/` |
| `skills` | Changes in `skills/` |
| `ci` | Changes in `.github/` |
| `docs` | Changes in `docs/` |
| *omit* | Multiple scopes or root-level |

---

## Good vs Bad Examples

### Title Line

```
# GOOD - Concise and clear
feat(api): add provider connection retry logic
fix(ui): resolve dashboard loading state
chore(skills): add Celery documentation
docs: update installation guide

# BAD - Too specific or verbose
feat(api): add provider connection retry logic with exponential backoff and jitter (3 retries max)
chore(skills): add comprehensive Celery documentation covering 8 topics
fix(ui): fix the bug in dashboard component on line 45
```

### Body (Bullet Points)

```
# GOOD - High-level changes
- Add retry mechanism for failed connections
- Document task composition patterns
- Expand configuration reference

# BAD - Too detailed
- Add retry with max_retries=3, backoff=True, jitter=True
- Add 6 subsections covering chain, group, chord
- Update lines 45-67 in dashboard.tsx
```

---

## Workflow

1. **Analyze changes**
   ```bash
   git status
   git diff --stat HEAD
   git log -3 --oneline  # Check recent commit style
   ```

2. **Draft commit message**
   - Choose appropriate type and scope
   - Write concise title (< 72 chars)
   - Add 2-5 bullet points for significant changes

3. **Present to user for confirmation**
   - Show files to be committed
   - Show proposed message
   - Wait for explicit confirmation

4. **Execute commit**
   ```bash
   git add <files>
   git commit -m "$(cat <<'EOF'
   type(scope): description

   - Change 1
   - Change 2
   EOF
   )"
   ```

---

## Decision Tree

```
Single file changed?
├─ Yes → May omit body, title only
└─ No → Include body with key changes

Multiple scopes affected?
├─ Yes → Omit scope: `feat: description`
└─ No → Include scope: `feat(api): description`

Fixing a bug?
├─ User-facing → fix(scope): description
└─ Internal/dev → chore(scope): fix description

Adding documentation?
├─ Code docs (docstrings) → Part of feat/fix
└─ Standalone docs → docs: or docs(scope):
```

---

## Commands

```bash
# Check current state
git status
git diff --stat HEAD

# Standard commit
git add <files>
git commit -m "type(scope): description"

# Multi-line commit
git commit -m "$(cat <<'EOF'
type(scope): description

- Change 1
- Change 2
EOF
)"

# Amend last commit (same message)
git commit --amend --no-edit

# Amend with new message
git commit --amend -m "new message"
```

Overview

This skill creates professional git commits following the Conventional Commits format and Prowler conventions. It drafts concise commit titles under 72 characters and a focused bullet list of key changes. It always asks for explicit user confirmation before performing the commit.

How this skill works

When you ask to commit after finishing code changes, the skill inspects the working tree and recent commit history to choose an appropriate commit type and scope. It drafts a one-line title in the form type(scope): description and, when needed, a short body with 2–5 high-level bullet points. It shows the files to be committed and the proposed message, then waits for your confirmation before running the git commit commands.

When to use it

  • After completing code changes and you want a conventional-commits message
  • When you need help selecting type and scope for a commit
  • Before committing changes across multiple files or scopes
  • When you want a concise, review-friendly commit summary
  • When you want to avoid including implementation details in the title

Best practices

  • Keep the title under 72 characters and avoid implementation specifics
  • Use the recommended type and scope mapping (feat, fix, docs, chore, refactor, test, perf, style)
  • Include 2–5 high-level bullet points for multi-file or multi-change commits
  • Omit a scope when multiple scopes or root-level files are affected
  • Always confirm the proposed message before the skill executes git commit

Example use cases

  • Add a retry mechanism in the SDK and produce a feat(sdk) commit
  • Fix a dashboard loading bug and draft fix(ui) with key changes
  • Update installation docs and generate docs: update installation guide
  • Refactor internal modules without claiming a feature using refactor(sdk)
  • Bump CI configuration or dependencies with chore(ci) messages

FAQ

Will you push commits automatically?

No. The skill limits itself to drafting and running git commit; pushing is left to the user unless explicitly requested.

Can you amend the last commit?

Yes, on request the skill can perform amend operations using the documented git commit --amend commands, but it will ask for confirmation first.