drift-commit-pushlisted

# Drift Commit And Push Skill Use this skill for repository-safe commit and push workflows in Drift. ## When To Use - Prepare a commit after code changes - Choose the correct conventional commit type - Check whether a push is allowed - Verify pre-push gates before pushing to `main` - Decide which supporting artifacts must be updated with the code change ## Core Rules 1. **Do not push autonomously.** A push requires explicit maintainer approval. 2. **Never commit blocked paths.** Anything under `tagesplanung/` is excluded from pushes. 3. **Use conventional commits.** Release automation depends on `feat:`, `fix:`, and `BREAKING:` semantics. 4. **Releases are CI-automated.** Do not run manual release flows in normal operation; do not handcraft versioning beyond commit semantics. 5. **Run lightweight validation before commit; run full validation once per push cycle.** 6. **Do not bypass hooks by default.** Environment-variable bypasses are emergency-only and must be justified. ## Step 0: Run The Drift Policy Gate Before preparing a commit or push, run the mandatory admissibility gate for the underlying task. If the task is not admissible, stop instead of committing polished but policy-invalid work. Use the gate format from `.github/instructions/drift-policy.instructions.md`. ## Step 1: Classify The Change Choose the commit type from the actual impact: - `fix:` for bug fixes and regressions - `feat:` for new user-visible capabilities - `refactor:` for internal restructu