# Release Manager Rules

- Only create commits when explicitly requested by the user
- NEVER update git config
- NEVER run destructive commands unless explicitly requested
- NEVER skip hooks (--no-verify, --no-gpg-sign) unless requested
- NEVER use interactive git commands (-i flag)

## Commit Process

1. Run `git status` to see untracked files
2. Run `git diff` to see staged and unstaged changes
3. Run `git log --oneline -5` to see recent commits for style
4. Add relevant files and create commit
5. Run `git status` after commit to verify success

## Security Hardening

- Bash permission for release-manager operations: `ask` (never `allow`)
- Git commands allowed without ask: `git status`, `git log`, `git diff`, `git branch --list`, `git remote -v`
- Git commands requiring ask: `git push`, `git merge`, `git rebase`, `git reset`, `git cherry-pick`
- NEVER run `git push --force` without explicit user confirmation
- NEVER skip git hooks (`--no-verify`, `--no-gpg-sign`) unless explicitly requested

## Commit Message Style

- Concise 1-2 sentences focusing on "why" not "what"
- Use appropriate prefixes: feat, fix, refactor, test, docs
- Match repository's existing commit message style

## Examples

```
feat: add authentication middleware for API routes
fix: resolve race condition in async handler
refactor: extract validation logic to separate module
test: add integration tests for payment flow
docs: update API documentation with new endpoints
```

## Branch Safety

- Never force push to main/master without warning
- Check if branch tracks remote before pushing
- Use `-u` flag when pushing new branches

## Amending Rules

- ONLY amend when: user requested OR pre-commit hook modified files AND commit created by you AND not pushed
- Never amend pushed commits without explicit request

## Security and Credentials

- NEVER commit secrets, passwords, or API keys to git repository
- NEVER hardcode credentials in configuration files or skills
- Use environment variables for sensitive data
- Use git credential helper for authentication:
  ```bash
  git config credential.helper store
  # On first push, credentials will be saved securely
  ```
- Use SSH keys instead of passwords when possible
- Use API tokens instead of passwords for Gitea authentication
- Check .gitignore for sensitive files: .env, config/secrets/*
   Добавь в .gitignore если их нет:
   ```bash
   echo ".env" >> .gitignore
   echo "*.secret" >> .gitignore
   echo "config/secrets/" >> .gitignore
   ```

## Authentication Flow

When running git commands:
1. Check if git credentials are stored (git config credential.helper)
2. If authentication fails, report: "Authentication required. Configure one of:"
   - "SSH: git remote set-url origin git@git.softuniq.eu:Owner/Repo.git"
   - "HTTPS with token: git remote set-url origin https://oauth2:${GITEA_TOKEN}@git.softuniq.eu/Owner/Repo.git"
   - "Store credentials securely: git config credential.helper store"
   - "Set env vars: GITEA_TOKEN or GITEA_USER+GITEA_PASS (see .kilo/shared/gitea-auth.md)"
3. NEVER request or suggest using plain passwords in commands