Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

conventional-commits

Sterne0

Forks0

Aktualisiert30. Mai 2026 um 09:38

Write git commit messages using Conventional Commits. Use whenever I ask to commit, draft a commit message, split commits, amend a commit, prepare a PR commit stack, or say "커밋", "commit", "commit message", "커밋메세지", "커밋 메시지", "conventional commit". Never invent a free-form commit subject when a Conventional Commit type/scope can be chosen.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

ziwon

ziwon/skills

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name	conventional-commits
description	Write git commit messages using Conventional Commits. Use whenever I ask to commit, draft a commit message, split commits, amend a commit, prepare a PR commit stack, or say "커밋", "commit", "commit message", "커밋메세지", "커밋 메시지", "conventional commit". Never invent a free-form commit subject when a Conventional Commit type/scope can be chosen.

Conventional Commits

Use Conventional Commits for every commit message unless I explicitly request a different format.

Format

<type>(<scope>): <description>

<body>

Scope is optional. Body is optional. Keep the subject imperative, lowercase after the colon, and under ~72 characters when practical.

Types

Prefer these types:

feat: user-visible feature or new capability
fix: bug fix or correctness repair
docs: documentation-only change
test: tests only
refactor: behavior-preserving code change
perf: performance improvement
build: build system, dependencies, packaging
ci: CI configuration or workflow
chore: repo maintenance with no user-facing behavior
style: formatting-only change

Use ! for breaking changes:

feat(api)!: remove legacy token format

Procedure

Inspect the staged diff before writing the message. If nothing is staged, inspect the intended diff and say what needs staging.
Pick the narrowest type. Use docs for skill prose/docs changes; use feat when adding a new reusable skill; use chore for lockfiles, ignores, and repository housekeeping.
Add a scope when it clarifies the affected area, e.g. skills, autoresearch, youtube-summary, gitignore.
If the commit bundles unrelated changes, recommend splitting before committing.
When making the commit yourself, use a non-interactive command:
```
git commit -m "<type>(<scope>): <description>"
```
Add -m "<body>" only when the why/risk is not obvious from the subject.

Guardrails

Do not use vague subjects like update files, misc changes, fix stuff, or wip.
Do not include generated noise in the commit.
Do not commit unrelated user changes unless I explicitly include them.
If unsure between two types, recommend the default and explain in one short sentence.

Mehr aus diesem Repository

gleiches Repository

mermaid-dark-theme

ziwon/skills

Produce Mermaid diagrams styled with my dark theme — a #171717 canvas, light hairline borders, and a fixed categorical palette via classDef. Use whenever I ask for a Mermaid diagram, flowchart, sequence/state/ER/class diagram, an architecture/system diagram, a README diagram, or say "mermaid", "dark theme diagram", "다이어그램 그려줘", "머메이드", "아키텍처 다이어그램". Default to this dark theme unless I explicitly ask for the default/light Mermaid look. Always emit the `%%{init}%%` header and reuse the canonical classDef library for diagram grammars that support it.

2026-07-150

grok-tool-augmented-research

ziwon/skills

Use Grok Build's current web_search/web_fetch tools as a bounded external-evidence layer inside coding, debugging, dependency evaluation, and autoresearch loops. Use for "Grok으로 검색해", fresh release/API/CVE evidence, recent community signal, or search-grounded hypotheses. Treat dedicated X corpus search as optional and only claim it when an installed MCP/tool explicitly provides it; never leak private repo data.

2026-07-150

headless-grok-automation

ziwon/skills

Automate Grok Build with current headless (-p/--single), JSON/streaming output, resumable sessions, bounded toolsets, permission rules, worktrees, and ACP. Use for "grok -p", CI/cron/batch reviews, unattended refactors, Grok as an engine, or custom ACP clients. Verify flags against the installed Grok docs and prefer explicit tool allowlists plus deny rules over unrestricted execution.

2026-07-150

milestone-delivery

ziwon/skills

Execute a repository milestone from GOAL.md through parallel implementation, staged review, CI, PR merge, and GitHub milestone closure. Use when Aaron asks to start, deliver, or complete the next milestone.

2026-07-140

orca-unrestricted-guardrails

ziwon/skills

Keep unrestricted/YOLO Orca and coding-agent execution fast while constraining destructive filesystem actions, secret exposure, external writes, and confidential data disclosure. Use whenever an agent runs with bypassed approvals or sandboxing, before rm/cleanup commands, infrastructure or remote writes, secret-bearing commands, force-push/history rewrites, or work in confidential repositories.

2026-07-130

n8n-mcp

ziwon/skills

Use when building, reviewing, debugging, validating, or safely deploying n8n workflows with the czlonkowski/n8n-mcp MCP server. Trigger on requests like "n8n workflow 만들어줘", "n8n-mcp 연결", "n8n 노드 찾아줘", "n8n 자동화 설계", "n8n credential/workflow 관리", or any task where an agent needs n8n node docs, templates, workflow JSON validation, or n8n API management. Always prefer read-only documentation/search first, work on copied workflows before production edits, and validate before deploy.

2026-06-060

name	conventional-commits
description	Write git commit messages using Conventional Commits. Use whenever I ask to commit, draft a commit message, split commits, amend a commit, prepare a PR commit stack, or say "커밋", "commit", "commit message", "커밋메세지", "커밋 메시지", "conventional commit". Never invent a free-form commit subject when a Conventional Commit type/scope can be chosen.

Conventional Commits

Use Conventional Commits for every commit message unless I explicitly request a different format.

Format

<type>(<scope>): <description>

<body>

Scope is optional. Body is optional. Keep the subject imperative, lowercase after the colon, and under ~72 characters when practical.

Types

Prefer these types:

feat: user-visible feature or new capability
fix: bug fix or correctness repair
docs: documentation-only change
test: tests only
refactor: behavior-preserving code change
perf: performance improvement
build: build system, dependencies, packaging
ci: CI configuration or workflow
chore: repo maintenance with no user-facing behavior
style: formatting-only change

Use ! for breaking changes:

feat(api)!: remove legacy token format

Procedure

Inspect the staged diff before writing the message. If nothing is staged, inspect the intended diff and say what needs staging.
Pick the narrowest type. Use docs for skill prose/docs changes; use feat when adding a new reusable skill; use chore for lockfiles, ignores, and repository housekeeping.
Add a scope when it clarifies the affected area, e.g. skills, autoresearch, youtube-summary, gitignore.
If the commit bundles unrelated changes, recommend splitting before committing.
When making the commit yourself, use a non-interactive command:
```
git commit -m "<type>(<scope>): <description>"
```
Add -m "<body>" only when the why/risk is not obvious from the subject.

Guardrails

Do not use vague subjects like update files, misc changes, fix stuff, or wip.
Do not include generated noise in the commit.
Do not commit unrelated user changes unless I explicitly include them.
If unsure between two types, recommend the default and explain in one short sentence.