shape-commits

Imported from Darius-Theodor/skills (skills/shape-commits/SKILL.md). Install upstream with npx skills add Darius-Theodor/skills --skill shape-commits. Copyright stays with the author.

Shape Commits

Create a clean history in which each commit represents one coherent concept. Let repository-specific instructions add constraints without duplicating the general commit standard here.

Inspect the task and repository

1. Read the applicable repository instructions.
2. Inspect the complete working tree and relevant history before staging anything.
3. Identify which changes belong to the current task and preserve every unrelated pre-existing change.
4. Determine the repository's established Conventional Commit types and scopes from recent history when they are not documented.

Find the commit concepts

Treat a commit as one concept when its changes:

• express one behavior, fix, refactor, or supporting repository change;
• make sense when reviewed together; and
• should normally be reverted together.

Use the concept as the primary boundary. Apply these refinements when they create a clearer history:

• Place an independently useful behavior-neutral refactor before the behavior change that uses it.
• Separate behavior-defining logic from broad mechanical propagation when each part forms a valid, verifiable commit on its own.
• Keep an inseparable implementation and its direct tests together.
• Order multiple commits by dependency so each commit leaves the repository coherent for the next one.

Prefer the smallest set of commits that expresses the real conceptual structure.

Plan before staging

For each intended commit, state internally:

• the concept;
• the exact paths or hunks it owns;
• why those changes belong together; and
• which verification establishes that state.

Resolve ambiguous or overlapping changes before committing. Ask the user only when ownership or intent cannot be established safely from the task and repository.

Verify and commit

1. Stage only the selected concept, using path- or hunk-level staging as needed.
2. Inspect the staged diff for completeness, coherence, secrets, and unrelated changes.
3. Run the relevant available verification for that commit's state.
4. Commit only after verification succeeds.
5. Repeat for the remaining concepts, then verify the final combined state.

Create local commits only. Treat pushing, published-history rewriting, and other remote operations as separate actions governed by explicit user and repository instructions.

Write the message

Use this subject form:

type(scope): observable effect in domain terms

Write one concise, human-friendly line that says what changed in the language of the project. Prefer the observable result over implementation trivia.

Examples:

fix(kurse): keep filter state when switching views
feat(buildings): reject properties outside the selected object
refactor(import): share parcel row normalization

Add a short body only when essential context or consequences would otherwise be lost. Keep authorship human-only and omit tool-generated attribution.

Report the result

Return the created commit subjects and SHAs, the verification run, and any task changes intentionally left uncommitted.