Commit

Automate the full commit workflow: inspect changes, format only affected files, stage tracked and untracked files individually, generate a Conventional Commit message, and create the commit. The user asked for a commit because they want the commit created, not a plan.

Workflow

1. Check git state

Run git status.

Stop and tell the user if the repo is mid-merge, rebase, or cherry-pick. If there are no tracked or untracked changes, say Nothing to commit and stop.

2. Inspect changes

Run these in parallel:

• git diff
• git diff --cached
• git status --porcelain
• git log --oneline -5

Untracked files shown as ?? are often part of the current task and should normally be included.

3. Run targeted formatting

Collect candidate files with:

• git diff --name-only
• git diff --name-only --cached
• git ls-files --others --exclude-standard

Only run formatters for changed files.

If any .sol files under contracts/tests/ changed:

forge fmt <those-files>

If any .sol files not under contracts/tests/ changed:

npx prettier --write --plugin=prettier-plugin-solidity <those-files>

If files under src/js/ or JS config files changed:

yarn lint --fix
yarn prettier --write <changed-js-files>

Do not format the whole repository. If formatting fails and cannot be auto-fixed, report the issue and stop unless the user explicitly wants to proceed.

4. Stage files

Stage files individually. Do not use git add -A or git add ..

Include:

• modified tracked files
• new untracked files
• files updated by formatters

Skip and warn on likely secrets:

• .env and .env.*
• names containing credential or secret
• *.pem, *.p12, *.pfx
• *.key private keys

5. Generate commit message

Base the message on the staged diff from git diff --cached.

Format:

type(scope): description

Types:

• feat
• fix
• refactor
• perf
• test
• docs
• chore

Suggested scopes in this repo:

• lido
• etherfi
• ethena
• origin
• arm
• deploy
• js
• cap
• zapper
• market
• pendle
• skill

If the change spans multiple unrelated areas, omit the scope. Use imperative mood, lowercase, no trailing period, and keep the subject under 72 characters.

6. Commit

Always run git commit unless an earlier safety stop applied. Do not stop after staging and do not ask for confirmation if the user already requested a commit.

Check the original user request for:

• whether a co-author trailer was requested
• whether a push was requested

Create the commit with git commit -m .... Afterward run git status to confirm success and report:

Committed <short-hash>: type(scope): description

7. Push only if requested

If the user explicitly asked to push, run git push or git push -u origin <branch> when needed. Otherwise do not push and do not ask.

Safety rules

• Never amend unless the user explicitly asks
• Never force push
• Never use --no-verify
• If hooks fail, fix the issue, re-stage, and create a new commit
• If there is nothing to commit, stop