/vt-c-commit¶
Create a commit with enforced message standards and pre-commit checks
Plugin: core-standards
Usage: /vt-c-commit [message]
Commit with Standards¶
Create a git commit following company conventions with automatic security checks.
Pre-Commit Checks¶
Before committing, this command runs: 1. Secret scanning - Detect hardcoded credentials 2. Security lint - Check for obvious vulnerabilities 3. TypeScript check - Ensure no type errors
Commit Message Format¶
Types¶
- feat: New feature
- fix: Bug fix
- refactor: Code change that neither fixes a bug nor adds a feature
- docs: Documentation only changes
- test: Adding or correcting tests
- chore: Maintenance tasks
Examples¶
feat(auth): add multi-tenant JWT validation
- Added tenant ID to JWT payload
- Updated middleware to validate tenant context
- Added tests for cross-tenant access prevention
Closes #123
Usage¶
# Commit with message
/vt-c-commit "feat(api): add rate limiting to webhooks"
# Interactive mode (prompts for message)
/vt-c-commit
Workflow¶
- Run pre-commit checks (security-scan, lint)
- If checks pass, stage all changes (or use already staged)
- Generate commit message if not provided
- Create commit with standardized AI attribution footer: Use this exact format — model-agnostic, no version number. Do NOT use model-specific variants like "Claude Opus 4.6".
- Show commit summary
- Verify attribution: Confirm the Co-Authored-By footer is present in the commit. If missing, warn the user and offer to amend.
- Append build-log entry (spec-driven mode only — see below)
Blocked Commits¶
Commits are blocked if: - Secrets detected in staged files - Critical security vulnerabilities found - P1 review findings unresolved
Run /vt-c-wf-review to see and resolve blocking issues.
Build Log (Spec-Driven Mode)¶
When working on a spec branch (feature/spec-NNN-*), the commit command automatically appends a build-log entry after each successful commit. This creates a navigable link between git history and design documentation.
When it runs¶
Build-log entries are generated only when ALL of these are true:
- Current branch matches feature/spec-NNN-*
- .design-state.yaml exists and has a specs_dir for SPEC-NNN
- The specs/N-feature/ directory exists
On any other branch (main, fix/, chore/, etc.), this step is skipped silently.
What it captures¶
Each entry records: - Commit hash (short, 7 chars) and message - Timestamp - Files changed (count and top-level summary) - Related journal entry (if a session-journal entry exists for today)
Step 6: Build-Log Entry¶
After Step 5 (show commit summary), execute this step:
- Run
git branch --show-current - If branch matches
feature/spec-NNN-*: a. Extract NNN from the branch name b. Read.design-state.yamland findspecs_dirforSPEC-NNNunderspecs_statusc. Ifspecs_direxists and the directory is present:- Get commit hash:
git log -1 --pretty=%h - Get commit message:
git log -1 --pretty=%s - Get file change summary:
git diff --stat HEAD~1 HEAD - Get current timestamp
- Check for today's journal entries: look for files matching
docs/vt-c-journal/YYYY-MM/entries/YYYY-MM-DD-*(where YYYY-MM-DD is today's date). If found, note the path to the most recent one (sorted alphabetically, last entry). - If
specs/N-feature/build-log.mddoes NOT exist, create it with this header: - Append an entry to
specs/N-feature/build-log.md: - Omit the "Related journal" line entirely if no journal entry exists for today
- Leave
build-log.mdas an unstaged change — do NOT amend the commit - Display:
Build log updated: specs/N-feature/build-log.md
- Get commit hash:
- If branch does NOT match
feature/spec-NNN-*: skip silently