commit_skill

This skill helps you create conventional commits with project-specific branch rules and proper scope, ensuring consistent history across the monorepo.
  • TypeScript

181

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill first-fluke/fullstack-starter --skill commit

  • SKILL.md3.1 KB

Overview

This skill creates git commits that follow the Conventional Commits specification and enforces project-specific branch naming rules. It analyzes repository changes, suggests one or more well-formed commit messages, and asks for confirmation before staging and committing. The skill is tuned for a production-ready fullstack monorepo using Next.js, FastAPI, Flutter, Terraform, and mise.

How this skill works

The skill inspects git status, staged diffs, and recent history to determine change scope and appropriate commit type. If changes span multiple features or domains it recommends splitting into separate commits and maps types to branch prefixes (e.g., feat → feature/). It assembles a Conventional Commit message with optional body and Co-Authored-By lines and prompts the user to confirm or edit before executing git add for specific files and git commit. It refuses to stage or commit secrets and will never run mass-add without explicit permission.

When to use it

  • User asks to save or commit changes (e.g., “commit this”, “save changes”)
  • When the /commit command is invoked in the agent
  • Preparing commits in a monorepo with multiple modules or languages
  • Enforcing consistent commit messages and branch naming across the project

Best practices

  • Stage only specific files; avoid git add -A or git add . without permission
  • Split commits by logical feature/scope when changes touch multiple domains
  • Use concise imperative descriptions under 72 characters and lowercase first letter
  • Include scope when it clarifies the area affected (e.g., auth, api, ui)
  • Never commit secrets or environment files; confirm with user before committing

Example use cases

  • Make a single bugfix commit: analyze diff, choose fix(api), create message, confirm, commit specific files
  • Add a new feature in a subpackage: detect new files → suggest feat(orchestrator) and branch prefix feature/
  • Split a mixed change set into multiple commits by scope (workflows, skills, docs)
  • Prepare a commit with co-author attribution for pair programming or external contributions
  • Create chore commits for dependency or build config updates while avoiding accidental secret commits

FAQ

No. It always displays a preview and requires explicit confirmation before staging or committing.

How does it decide to split changes into multiple commits?

It recommends splitting when changes span different scopes, types, or logically independent features; it won’t split when changes belong to a single feature, are few files, or the user requested one commit.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
commit skill by first-fluke/fullstack-starter | VeilStrat