One convention everywhere. The rule lives in data (.aspis/config/commit-convention.yaml) and is applied by aspis commit (which composes the message) and enforced by the F-006 commit-msg hook. This skill is the human-facing "how" — you supply the parts, the tool builds and validates the message.

Format

type(F-NNN[/T-NN | /T-NN..T-MM | /SYS]): short imperative title

- what changed, as a person would say it — one short line per point
- 2–5 points (3–5 typical), sized to the change; the why when it isn't obvious
- only go past 5 when the change truly needs it

Tasks: T-NN, …        # only on a multi-task commit (auto-added from a span)

type — one of: feat, fix, refactor, docs, chore, test, style, perf.
scope — almost always the active feature id, optionally a task or span: F-007, F-007/T-02, F-007/T-01..T-05. Use F-NNN/SYS for an aspis system/config change routed through the system-lead. Omit scope only for true repo-lifecycle commits (init/bootstrap/release) — not for ordinary feature work.
title — imperative, lower-case, ≤ 72 chars, no trailing period.
body — required; 2–5 concise single-line points (3–5 typical), no filler; a point wraps to a second line only for a genuinely large change. Real change/notes, not diff narration.

Compose with the tool, don't hand-format

aspis commit <path> [<path> ...] \
  --type feat --task T-02 --title "add the committer agent" \
  --bullet "single git writer, composes per the convention" \
  --bullet "reuses the F-006 validator as the one rule source"

--task T-01..T-05 for a multi-task commit (the Tasks: trailer is auto-added).
omit --task for a feature-wide commit; --no-scope for a lifecycle commit.
The tool self-validates before committing and the commit-msg hook validates again, so a malformed or non-conventional message never lands.

Hard rule — no attribution

A commit message must never contain any AI / model / tool / co-author attribution (Co-Authored-By, model names, "generated with", 🤖, …). History reads as fully human-authored; both the composer and the hook reject any such token.

Sizing

Keep each commit atomic — one logical change. When a change set mixes concerns (code + docs + config), split it; see the commit-splitting skill.

Más de este repositorio

mismo repositorio

commit-splitting

mahmoud-emad-dev/aspis

Keep commits atomic — split a mixed change set into scoped, reviewable commits.

2026-07-012

project-onboarding

mahmoud-emad-dev/aspis

The one-time procedure to take an exported project to live — understand it, confirm the name/goal/stack with the user, run the deterministic `aspis bootstrap`, enrich the judgment files (AGENTS.md, ARCHITECTURE, context), verify, and let the package self-clean. Followed by the bootstrap agent.

2026-06-292

architecture-memory

mahmoud-emad-dev/aspis

Keep per-subsystem architectural intent current through the planning loop — read before designing, record an impact report on change, confirm with the user, apply a dated update, and verify the build against approved intent.

2026-06-292

dependency-audit

mahmoud-emad-dev/aspis

Audit a plan's task dependency graph for structural integrity — circular dependencies, missing prerequisites, orphan tasks, and dependency classification (hard/soft/warning). Produces a pass/warn/fail audit report per dependency so planners catch graph errors before build starts.

2026-06-272

clean-tree-precondition

mahmoud-emad-dev/aspis

Every editing agent should start on a clean working tree so parallel work never collides.

2026-06-272

commit-readiness

mahmoud-emad-dev/aspis

Verify hooks ran, no secrets, protected paths untouched, and commit message valid before committing. Owned by the reviewer.

2026-06-272

Commit message

Format

type(F-NNN[/T-NN | /T-NN..T-MM | /SYS]): short imperative title - what changed, as a person would say it — one short line per point - 2–5 points (3–5 typical), sized to the change; the why when it isn't obvious - only go past 5 when the change truly needs it Tasks: T-NN, … # only on a multi-task commit (auto-added from a span)

type — one of: feat, fix, refactor, docs, chore, test, style, perf.

scope — almost always the active feature id, optionally a task or span: F-007, F-007/T-02, F-007/T-01..T-05. Use F-NNN/SYS for an aspis system/config change routed through the system-lead. Omit scope only for true repo-lifecycle commits (init/bootstrap/release) — not for ordinary feature work.

title — imperative, lower-case, ≤ 72 chars, no trailing period.

body — required; 2–5 concise single-line points (3–5 typical), no filler; a point wraps to a second line only for a genuinely large change. Real change/notes, not diff narration.

Compose with the tool, don't hand-format

aspis commit <path> [<path> ...] \ --type feat --task T-02 --title "add the committer agent" \ --bullet "single git writer, composes per the convention" \ --bullet "reuses the F-006 validator as the one rule source"

--task T-01..T-05 for a multi-task commit (the Tasks: trailer is auto-added).

omit --task for a feature-wide commit; --no-scope for a lifecycle commit.

The tool self-validates before committing and the commit-msg hook validates again, so a malformed or non-conventional message never lands.

Hard rule — no attribution

Sizing

Keep each commit atomic — one logical change. When a change set mixes concerns (code + docs + config), split it; see the commit-splitting skill.