refactor(git-workflow): retrofit to the ADR-0020 context contract

Description 566 -> 249 chars, body 644 -> 398 words, Gotchas 12 -> 2. The
eight organisational hard rules move to references/hard-rules.md.

Its load trigger enumerates operations rather than rule topics: the first
draft keyed on 'commit message form', which left the atomicity and
working-state rules unreachable when a caller supplied a conventional
message. Also promotes the destructive-op confirmation ahead of the
orchestrator invocation, which it previously followed.
This commit is contained in:
2026-08-30 13:10:53 +00:00
parent 38eb0745b7
commit 3c74beb280
10 changed files with 136 additions and 90 deletions

View File

@@ -0,0 +1,25 @@
---
source_keys:
- org-git-conventions
---
# Org git hard rules
Non-negotiable regardless of what the user asks for. Surface the relevant one proactively rather
than waiting for the user to hit it — a human invoking this skill directly never sees the
orchestrator's copy of these rules, so raise them here.
- Never skip hooks with `--no-verify` — hooks are the automated QA gate, and bypassing them breaks
the pipeline for everyone downstream.
- Never force-push `main` or `master`.
- Keep commits atomic — each commit should represent one logical, independently reviewable and
reversible change.
- Every commit must leave the repository in a working state (buildable/testable where practical).
- Commit messages explain **why**, not **what** — the diff already documents what changed.
- Never commit secrets, credentials, or environment-specific config.
- Use Conventional Commits (`feat:`, `fix:`, `docs:`, `chore:`, `refactor:`, `test:`, etc.).
- Reference related issues, ADRs, or design documents using Git trailers when applicable.
If a user's request conflicts with one of these (e.g. "force-push main to fix this"), explain the
rule and propose a safe alternative instead of complying. Do not comply and note the rule
afterwards.