Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

commit

Étoiles8

Forks4

Mis à jour2 juillet 2026 à 09:30

Stage changes and author a Conventional Commit that drives release-please versioning. Use when the user asks to commit work. Handles branch-name sanity, commit type/scope/subject, and reminds not to hand-edit CHANGELOG or version.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

SongshGeo

SongshGeo/Python-Project-Template

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	commit
description	Stage changes and author a Conventional Commit that drives release-please versioning. Use when the user asks to commit work. Handles branch-name sanity, commit type/scope/subject, and reminds not to hand-edit CHANGELOG or version.

commit

Create a well-formed commit that this repo's release-please automation can consume.

Before committing

Confirm the working tree contains what the user intends to commit (git status, git diff). Stage deliberately (git add …), not blindly.
Check the branch name follows the convention (feature/, fix/, hotfix/, refactor/, docs/, test/). If on main/master, offer to branch first.
Consider running the quality-check skill first.

Message format

Conventional Commits: <type>(<scope>): <subject>

type ∈ feat, fix, docs, style, refactor, test, chore.
feat → minor bump, fix → patch bump; feat!/fix! or a BREAKING CHANGE: footer → major bump. release-please derives the version and CHANGELOG.md from these — never hand-edit the version or CHANGELOG.
Keep the subject imperative and ≤ ~72 chars; add a body for the "why" if needed.

Commit

git commit -m "<type>(<scope>): <subject>"

Only push when the user asks.

Plus depuis ce dépôt

même dépôt

quality-check

SongshGeo/Python-Project-Template

Run the project's full quality gate — pytest, pre-commit (black/ruff/isort/flake8/mypy), interrogate docstring coverage, and optionally the tox matrix — then summarize failures with fixes. Use before committing, before opening a PR, or when the user asks to check code quality.

2026-07-028

setup-project

SongshGeo/Python-Project-Template

Bootstrap a freshly cloned copy of this Python template into a working project — set the project name/description, install dependencies, wire pre-commit, install the recommended external skills, and initialize the memory bank. Use right after applying or cloning the template, or whenever pyproject.toml still shows the placeholder name "songshgeo".

2026-07-028

update-memory-bank

SongshGeo/Python-Project-Template

Update the shared memory bank (architecture.md / model-design.md / progress.md) after design or progress changes, so the persistent context stays accurate for both Cursor and Claude Code. Use when the codebase structure, data model, or project status has changed, or at the end of a work session.

2026-07-028

upgrade-project

SongshGeo/Python-Project-Template

Idempotently migrate an existing project built from an older version of this template to the new Claude Code workflow — move .cursor/cache into the shared memory-bank, add missing .claude scaffolding (CLAUDE.md, skills, settings, recommended-skills), and optionally install the external skill pack. Use to modernize an old repo without touching already-configured metadata. Safe to run repeatedly.

2026-07-028

name	commit
description	Stage changes and author a Conventional Commit that drives release-please versioning. Use when the user asks to commit work. Handles branch-name sanity, commit type/scope/subject, and reminds not to hand-edit CHANGELOG or version.

commit

Create a well-formed commit that this repo's release-please automation can consume.

Before committing

Confirm the working tree contains what the user intends to commit (git status, git diff). Stage deliberately (git add …), not blindly.
Check the branch name follows the convention (feature/, fix/, hotfix/, refactor/, docs/, test/). If on main/master, offer to branch first.
Consider running the quality-check skill first.

Message format

Conventional Commits: <type>(<scope>): <subject>

type ∈ feat, fix, docs, style, refactor, test, chore.
feat → minor bump, fix → patch bump; feat!/fix! or a BREAKING CHANGE: footer → major bump. release-please derives the version and CHANGELOG.md from these — never hand-edit the version or CHANGELOG.
Keep the subject imperative and ≤ ~72 chars; add a body for the "why" if needed.

Commit

git commit -m "<type>(<scope>): <subject>"

Only push when the user asks.