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.
1.2 KiB
1.2 KiB
source_keys
| source_keys | |
|---|---|
|
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
mainormaster. - 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.