Skill: create-commit
Produce a git commit that follows Penpot's commit message conventions. This
skill owns the commit format, staging review, and safety checks — it does not
implement features or push.
When to Use
- After code changes are complete and files need to be committed
- When delegated by a workflow step (e.g. implement-plan) to handle the commit
Required Reading
Before drafting any commit, read mem:workflow/creating-commits end-to-end. It
is the authoritative source for the commit message format, the emoji menu,
subject/body limits, and the AI-assisted-by trailer. Follow it exactly.
Workflow
- Stage the files specified by the calling context. Do not ask for
confirmation.
- Run
git diff --staged to review the content. If you see secrets (API keys,
tokens, passwords, private keys, .env values), debug prints, or anything
that does not match the stated intent, STOP and tell the user before
committing.
- Draft the message following the format in the memory doc, wrapping the body
at 72 characters per line, and run:
git commit -m "<subject>" -m "<body>"
(or git commit -F - if the body has unusual characters).
- The
AI-assisted-by trailer value is provided by the calling context — use
it verbatim.
Constraints
- Do not push. Pushing is a separate workflow handled by the user.
- Do not run
git reset, git checkout, git restore, git clean, or rm.
- Do not pass
--author. Author identity comes from the local git config.
- Do not amend a commit you did not create in this session, unless explicitly asked.
- Do not bypass pre-commit hooks (
--no-verify) unless explicitly asked.
- Do not add untracked files that were not created in this session.
1---2name: create-commit3description: Stage, review, and commit files following Penpot commit conventions.4---5
6# Skill: create-commit
7
8Produce a git commit that follows Penpot's commit message conventions. This
9skill owns the commit format, staging review, and safety checks — it does not
10implement features or push.
11
12## When to Use
13
14- After code changes are complete and files need to be committed
15- When delegated by a workflow step (e.g. implement-plan) to handle the commit
16
17## Required Reading
18
19Before drafting any commit, read `mem:workflow/creating-commits` end-to-end. It
20is the authoritative source for the commit message format, the emoji menu,
21subject/body limits, and the `AI-assisted-by` trailer. Follow it exactly.
22
23## Workflow
24
251. **Stage the files** specified by the calling context. Do not ask for
26 confirmation.
272. Run `git diff --staged` to review the content. If you see secrets (API keys,
28 tokens, passwords, private keys, `.env` values), debug prints, or anything
29 that does not match the stated intent, **STOP** and tell the user before
30 committing.
313. Draft the message following the format in the memory doc, wrapping the body
32 at 72 characters per line, and run:
33 ```bash
34 git commit -m "<subject>" -m "<body>"
35 ```
36 (or `git commit -F -` if the body has unusual characters).
374. The `AI-assisted-by` trailer value is provided by the calling context — use
38 it verbatim.
39
40## Constraints
41
42- Do not push. Pushing is a separate workflow handled by the user.
43- Do not run `git reset`, `git checkout`, `git restore`, `git clean`, or `rm`.
44- Do not pass `--author`. Author identity comes from the local git config.
45- Do not amend a commit you did not create in this session, unless explicitly asked.
46- Do not bypass pre-commit hooks (`--no-verify`) unless explicitly asked.
47- Do not add untracked files that were not created in this session.
penpot