workflow-commit

Files (2)

• SKILL.md
• security.md

SKILL.md (first lines)

# Workflow Commit

Create a safe, intentional git commit from the current worktree.

## Trigger Phrases

- `workflow:commit`
- `commit workflow`
- `make a commit`
- `create a commit`
- `stage and commit this`
- `commit these changes`

## Process

1. Inspect repository state:
   - Run `git status --short --branch`.
   - Run `git diff --staged`.
   - If nothing is staged, inspect `git diff` and `git status --short`, then propose what should be staged.

2. Protect user work:
   - Never revert, reset, discard, or overwrite user changes.
   - If unrelated changes are present, leave them untouched and stage only the files needed for the commit.
   - If the intended commit scope is ambiguous, ask before staging.

3. Honor main-branch policy:
   - Run `git branch --show-current` and `git rev-parse --show-toplevel`.
   - If on `main` or `master` and `.claude/allow-main-commits` is absent at the repo root, stop and create a feature branch before committing.
   - If on `main` or `master` and `.claude/allow-main-commits` exists, allow content-only commits but block commits touching `.claude/` or `06-system/`.
   - Check both already staged files and any files being staged for this commit before deciding.
   - If protected paths are involved, stop and create a feature branch before committing.

4. Run pre-commit checks:
   - Always run `git diff --check`.
   - If `package.json` exists, inspect scripts before choosing checks.
   - Prefer existing repo scripts in this order when present: lint, typecheck, test.
   - Do not invent missing scripts. If no check command is discoverable, say so clearly.
   - If checks fail, stop and help fix the issue before committing.

5. Review security gates:
   - Read the bundled `security.md` in this skill's directory before proposing the commit.
   - If the checklist reveals a blocker, stop and help resolve it.

6. Propose the commit:
   - Choose one conventional commit type: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, or `chore`.
   - Use a concise subject: `<type>: <description>`.
   - Add a body only when the change is complex or the why is not obvious.
   - Suggest splitting into multiple commits when the staged changes contain unrelated concerns.

7. Ask for approval before creating the commit:
   - Offer to use the message as-is, modify it, add a body, or stage different files.
   - After approval, create the commit.
   - Show the resulting commit hash and subject.

8. Offer the next step:
   - Ask whether to push, open a PR, or ship the branch.

## Command Notes

- Follow the active agent and project shell rules.
- Use non-interactive git commands whenever possible.
- Do not run destructive commands unless the user explicitly asks for them.

From fimoklei/pm-ai-playbook, MIT.

More from fimoklei/pm-ai-playbook