Smart Commit

Adapted from PRPs-agentic-eng by Wirasm. Part of the PRP workflow series.

Operational context: Interpret input as a glob, a filter such as "except tests" or "only new files", a topic such as "the auth changes", or "staged" to preserve staging; blank input selects all changes. Use /git-workflow for documentation updates, parallel agents, or full PR orchestration.

Input: $ARGUMENTS

This is the lightweight counterpart to /git-workflow. Use this skill when the user wants a quick, single-message commit without the full documentation/agent orchestration that git-workflow provides.

---

Phase 1 — ASSESS

git status --short

If output is empty → stop: "Nothing to commit."

Show the user a summary of what's changed (added, modified, deleted, untracked).

---

Phase 2 — INTERPRET & STAGE

Interpret $ARGUMENTS to determine what to stage:

Input	Interpretation	Git Command
(blank / empty)	Stage everything	git add -A
staged	Use whatever is already staged	(no git add)
*.ts or *.py etc.	Stage matching glob	git add '*.ts'
except tests	Stage all, then unstage tests	git add -A && git reset -- '**/*.test.*' '**/*.spec.*' '**/test_*' 2>/dev/null || true
only new files	Stage untracked files only	git ls-files --others --exclude-standard | xargs -r git add
the auth changes	Topic phrase — cross-reference git status/git diff to find matching files	git add <matched files>
Specific filenames	Stage those files	git add <files>

For topic phrases (like "the auth changes"), cross-reference git status output and git diff to identify relevant files. Show the user which files you're staging and why before running git add.

After staging, verify:

git diff --cached --stat

If nothing staged, stop: "No files matched your description."

---

Phase 3 — COMMIT

Craft a single-line commit message in imperative mood:

{type}: {description}

Types:

• feat — New feature or capability
• fix — Bug fix
• refactor — Code restructuring without behavior change
• docs — Documentation changes
• test — Adding or updating tests
• chore — Build, config, dependencies
• perf — Performance improvement
• ci — CI/CD changes

Rules:

• Imperative mood ("add feature" not "added feature")
• Lowercase after the type prefix
• No period at the end
• Under 72 characters
• Describe WHAT changed, not HOW

git commit -m "{type}: {description}"

---

Phase 4 — OUTPUT

Report to user:

Committed: {hash_short}
Message:   {type}: {description}
Files:     {count} file(s) changed

Next steps:
  - git push           → push to remote
  - /prp-pr        → create a pull request
  - /code-review   → review before pushing

---

Examples

You say	What happens
/prp-commit	Stages all, auto-generates message
/prp-commit staged	Commits only what's already staged
/prp-commit *.ts	Stages all TypeScript files, commits
/prp-commit except tests	Stages everything except test files
/prp-commit the database migration	Finds DB migration files from status, stages them, commits
/prp-commit only new files	Stages untracked files only

---

When to use this vs /git-workflow

Use /prp-commit when	Use /git-workflow when
You want a quick, single commit	You want commit + documentation updates
You have a clear scope or natural-language filter	You want to run documentation agents in parallel
You want minimal orchestration	You want to commit + push + PR in one flow
Single-purpose changes	Multi-file features touching docs + code