ci

Conventional Commit

Be autonomous. Commit the work this session produced without asking for confirmation. Do not halt on junk or unrelated files — exclude them, commit the rest, and report.

Workflow

1. Survey the working tree:

   git status --short
   git branch --show-current
   

2. Decide what belongs in this commit (see Selecting Files below). Sort every dirty path into one of four buckets:

   • Commit — changes produced by the work done in this session (files you edited or created, plus their direct byproducts like lockfiles, generated output, or migrations).
   • Exclude (secret) — .env, keys, credentials. Never commit these; call them out explicitly (see Junk & Secret Detection).
   • Exclude (junk) — build artifacts, caches, dependencies, OS/editor cruft (see Junk & Secret Detection).
   • Exclude (unrelated) — pre-existing dirty files unrelated to this session's work.

3. Stage only the Commit bucket, with explicit pathspecs — never git add -A or git add .:

   git add -- <path1> <path2> ...
   git diff --cached --stat
   git diff --cached
   

4. Analyze the staged diff — determine type, scope, subject.

5. Commit immediately (no confirmation needed). Add a second -m for a body when the change is non-trivial:

   git commit -m "<type>(<scope>): <subject>"
   

6. Report:

   • the commit hash and message,
   • a short list of anything excluded and why — call out junk that should be added to .gitignore and any secrets that were left uncommitted, as information for the user. Do not block on these.

Selecting Files

Prefer precision over completeness. The goal is a commit that matches the work you actually did this session.

• You have session context (you edited files in this conversation): stage exactly those files and their direct byproducts. Leave everything else for the user.
• No session context (e.g. /devx-git:ci run cold at the start of a session): treat all dirty tracked + untracked paths as the Commit bucket, minus anything caught by Junk & Secret Detection.
• Ambiguous (a dirty file might or might not relate to the work): if it plausibly belongs to the change, include it; if it clearly doesn't, exclude it and mention it in the report.
• Distinct concerns in one working tree: it's fine to stage only the cohesive subset that forms one logical commit and tell the user what you left for a follow-up commit.