Defame1297
3c74beb280
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.
26 lines
1.2 KiB
Markdown
26 lines
1.2 KiB
Markdown
---
|
|
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.
|