Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

commit-assistant

Help create git commits and PRs with properly formatted messages and release notes following CockroachDB conventions. Use when committing changes or creating pull requests.

Ejecutar en Manus

Estrellas4

Forks2

Actualizado16 de enero de 2026, 08:07

Fuente

PeterFile

PeterFile/my-common-skills

Abrir repositorio de GitHub Ver repositorios del creador

Comando de instalación

Descarga

Ejecutar en Manus

Útil paraSOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas15-1252L4

SKILL.md

readonly

name	commit-assistant
description	Help create git commits and PRs with properly formatted messages and release notes following CockroachDB conventions. Use when committing changes or creating pull requests.

Git Commit Assistant

Create general-purpose Commit, PR, and release notes text.

Workflow

Read any project-specific rules (if provided).
Collect change context: git status -sb, git diff --stat, git diff.
Determine the primary change type.
Ask only for missing inputs:
- What changed and why
- Breaking change status
- Release notes need, audience, and category
- Issue/Epic/Tracking reference (if the project uses them)
Produce Commit/PR/Release notes and validate.

Commit rules

Format: type: Subject
Suggested type: feat fix docs style refactor test chore revert
Subject rules (seven rules):
- Separate subject from body with a blank line
- Limit subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use imperative mood
Body rules:
- Explain what and why, not how
- Wrap at 72 characters per line (hard max 100)
- Use English, imperative
Breaking changes:
- Use type!: Subject or
- Add footer BREAKING CHANGE: ...
Add issue references only if the project uses them (e.g., Refs: #123)
🔒 Never include secrets or credentials

PR rules

Title: short imperative phrase, no period
Description must answer:
- What changed?
- Why?
- Breaking changes?
Reuse Commit Subject when appropriate

Release notes rules

Include only user-facing changes
Use Release notes: None for internal refactors/tests/infra
Prefer categories when useful: Added / Changed / Fixed / Breaking / Security / Performance
Describe what changed, why it matters, and how users notice it
🔒 Never include secrets or private data

Output templates

Commit:

<type>: <Subject>

<What changed.>
<Why it changed.>

BREAKING CHANGE: <Impact>  # only if needed

PR:

<Title>

What changed
- ...

Why
- ...

Breaking changes
- None | ...

Release notes:

Release notes: None

# or

Release notes (Added): ...
Release notes (Fixed): ...
Release notes (Breaking): ...

Validation checklist

Subject length <= 50, imperative, capitalized, no period
Blank line between subject and body
Body lines wrap at 72 (<= 100)
Body explains what/why only
No secrets or private data 🔒

Más de este repositorio

mismo repositorio

kiro-specs

PeterFile/my-common-skills

Create a Kiro spec for a feature in .kiro/specs create/update feature spec/PRD/RFC—requirements, design doc, and implementation tasks checklist.Trigger on spec/specification/PRD/RFC/tech spec, requirements/user story/acceptance criteria/EARS, design doc/architecture, task breakdown/implementation plan/checklist; 需求/验收/设计/任务.

2026-02-084

multi-agent-orchestration

PeterFile/my-common-skills

Orchestrate multi-agent workflows from a Kiro spec using codex (code) + Gemini (UI), including dispatch/review/state sync via AGENT_STATE.json + PROJECT_PULSE.md; triggers on user says "Start orchestration from spec at <path>", "Run orchestration for <feature>", or mentions multi-agent execution.

2026-02-084

oss-issue-scout

PeterFile/my-common-skills

Analyze a user-provided Git repository and GitHub issues to confirm contribution rules (CONTRIBUTING, CLA/DCO, templates) and shortlist high-value, maintainer-friendly issues likely to be accepted. Use when a user wants help selecting open-source issues to contribute to, or when triaging a GitHub repo for good first contributions.

2026-02-084

sequential-orchestration

PeterFile/my-common-skills

Execute spec tasks one at a time with tmux visibility. Python-based orchestrator with transparent serial execution. Triggers on: rate limit, overnight run, throttled execution, avoid quota exhaustion, sequential mode, slow execution, or user says 'Run sequential orchestration for <spec>'.

2026-02-084

test-driven-development

PeterFile/my-common-skills

Use when implementing any feature or bugfix, before writing implementation code

2026-01-284

docs-write

PeterFile/my-common-skills

Write documentation following Metabase's conversational, clear, and user-focused style. Use when creating or editing documentation files (markdown, MDX, etc.).

2026-01-164

Git Commit Assistant

Create general-purpose Commit, PR, and release notes text.

Workflow

Read any project-specific rules (if provided).

Collect change context: git status -sb, git diff --stat, git diff.

Determine the primary change type.

Ask only for missing inputs:

What changed and why
Breaking change status
Release notes need, audience, and category
Issue/Epic/Tracking reference (if the project uses them)

Produce Commit/PR/Release notes and validate.

Commit rules

Format: type: Subject

Suggested type: feat fix docs style refactor test chore revert

Subject rules (seven rules):

Separate subject from body with a blank line
Limit subject line to 50 characters
Capitalize the subject line
Do not end the subject line with a period
Use imperative mood

Body rules:

Explain what and why, not how
Wrap at 72 characters per line (hard max 100)
Use English, imperative

Breaking changes:

Use type!: Subject or
Add footer BREAKING CHANGE: ...

Add issue references only if the project uses them (e.g., Refs: #123)

🔒 Never include secrets or credentials

PR rules

Title: short imperative phrase, no period

Description must answer:

What changed?
Why?
Breaking changes?

Reuse Commit Subject when appropriate

Release notes rules

Include only user-facing changes

Use Release notes: None for internal refactors/tests/infra

Prefer categories when useful: Added / Changed / Fixed / Breaking / Security / Performance

Describe what changed, why it matters, and how users notice it

🔒 Never include secrets or private data

Output templates

Commit:

<type>: <Subject> <What changed.> <Why it changed.> BREAKING CHANGE: <Impact> # only if needed

PR:

<Title> What changed - ... Why - ... Breaking changes - None | ...

Release notes:

Release notes: None # or Release notes (Added): ... Release notes (Fixed): ... Release notes (Breaking): ...

Validation checklist

Subject length <= 50, imperative, capitalized, no period

Blank line between subject and body

Body lines wrap at 72 (<= 100)

Body explains what/why only

No secrets or private data 🔒