Skip to content

git-commit.md

Latest commit

 

History

History
150 lines (96 loc) · 3.29 KB

git-commit.md

File metadata and controls

150 lines (96 loc) · 3.29 KB
Raw
description Assist in creating a safe, intentional, ticket-aware commit with a clear message and scoped changes.

Delegated Authority

This workflow operates under the following mandatory skills:

  • tickets-and-logbook
  • evidence-and-inference
  • shell-and-output

The workflow MUST defer to these skills and MUST NOT restate or override their rules.

1. Mission

Assist the user in producing a single, intentional, well-scoped commit.

This workflow does NOT decide whether a commit should happen.
It assumes the user has already chosen to commit and wants help doing it correctly.

2. Preconditions (MANDATORY)

Before proceeding, confirm:

  • The current changes correspond to one coherent intent
  • Any required ticket exists or the absence of a ticket is explicitly justified
  • The user understands that this workflow will NOT:
    • Split commits automatically
    • Clean unrelated changes
    • Guess intent

If these conditions are not met, STOP and ask for clarification.

3. Change Review (Read-Only)

Inspect the current working state to understand:

  • Which files are modified
  • Which files are new
  • Which files are deleted
  • Whether changes span multiple concerns

This step is read-only.
No files are staged automatically.

Summarize findings clearly for the user.

4. Scope Confirmation

Ask the user (or infer from ticket context):

  • Which files should be included in this commit
  • Which files should be excluded or deferred

If changes span multiple intents:

  • Recommend splitting into multiple commits
  • STOP unless the user explicitly overrides

5. Ticket Association

Apply the tickets-and-logbook skill.

  • If a ticket exists:
    • Require the ticket ID
    • Confirm the commit maps to ticket acceptance criteria
  • If no ticket exists:
    • Require an explicit justification
    • Record this in the logbook if applicable

Commits without intent tracking are discouraged but may proceed with justification.

6. Commit Message Generation

Generate a commit message that:

  • Follows Conventional Commits format
  • Reflects the actual changes, not aspirations
  • Includes the ticket ID when available

Required structure:

  • Type (feat, fix, chore, docs, etc.)
  • Short, specific summary
  • Optional body explaining why, not what
  • Ticket reference (if applicable)

Do NOT fabricate scope or intent.

7. Commit Execution

Delegate all execution mechanics to the shell-and-output skill.

This includes:

  • Staging selected files
  • Performing the commit
  • Handling errors or conflicts
  • Optional push

The workflow MUST NOT embed command syntax or assume shell behaviour.

8. Post-Commit Discipline

After a successful commit:

  • Update ticket status if applicable
  • Add or update a logbook entry summarizing:
    • What was committed
    • Why
    • Which ticket it advances

If the commit closes a ticket, record that explicitly.

9. Refusal Conditions

The workflow MUST refuse to proceed if:

  • Changes are incoherent and user refuses to scope
  • No ticket exists and no justification is given
  • Execution safety cannot be confirmed
  • The user requests “just commit everything” without review

Final Reminder

This workflow exists to:

  • Preserve intent
  • Maintain traceability
  • Prevent accidental damage

Speed is secondary to correctness.