Skip to content
Back to skills

644 Ops Guide 5991f949

ASecurity

This guide provides detailed information for Git operations and release management in IntentKit.

  • 9 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 11, 2026
documentationgit

Security analysis

A100/100

Scanned October 11, 2026

npx -y skills add tools-only/X-Skills --skill 644-ops_guide_5991f949 --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of 644 Ops Guide 5991f949?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for 644 Ops Guide 5991f949
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/tools-only-644-ops-guide-5991f949/badge)](https://www.skillsdirectory.com/skills/tools-only-644-ops-guide-5991f949)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

SKILL.md
# Operations Guide

This guide provides detailed information for Git operations and release management in IntentKit.

## Git Commit

### Pre-commit Steps

1. Run `ruff format && ruff check --fix` before commit.

### Commit Message Format

When you generate git commit message, always start with one of `feat/fix/chore/docs/test/refactor/improve`. 

**Format**: `<type>: <subject>`

- Subject should start with lowercase
- Only one-line needed, do not generate commit message body

**Examples**:
- `feat: add new twitter skill`
- `fix: resolve circular dependency in models`
- `chore: update dependencies`

## Github Release

### Version Number Rules

Follow Semantic Versioning:
- **Pre-release**: `vA.B.C-devD`
- **Release**: `vA.B.C`

#### Version Calculation

- **Release**: +1 to patch version `C`
- **Pre-release**: +1 to `D` of `-devD`, but if `vA.B.C` already released, next pre-release should restart from next patch version `vA.B.(C+1)-dev1`

**Examples**:
- Next pre-release of `v0.1.2-dev3` → `v0.1.2-dev4`
- If `v0.1.2` production release already published, next pre-release → `v0.1.3-dev1`

### Release Steps

1. Make a `git pull --rebase` first. If the local branch is main,  `git push` it.
2. Find the last version number in release or pre-release.
3. Leave the version number in `pyproject.toml` there, it will be changed in CI.
4. Diff `origin/main` with it, summarize release notes to business language, not a technical one. List new features. For bug fixes and improvements, provide vague descriptions, such as "fixed bugs in the xxx module". Then save it to `release_notes.md` for later use. Add a diff link to release note too, the from and to should be the version number.
5. If the release is **not pre-release**, also insert the release note to the beginning of `CHANGELOG.md` (This file contains all history release notes, don't use it in gh command). Commit and push `release_notes.md` and `CHANGELOG.md`.
6. Construct `gh release create` command, use `release_notes.md` as notes file in gh command.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.