원클릭으로 Manus에서 모든 스킬 실행

conventional-commits

스타0

포크0

업데이트2026년 5월 30일 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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

ziwon

ziwon/skills

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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.

이 저장소의 다른 Skills

같은 저장소

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.