From base
Enforce Conventional Commits format for git commits. Always consult this skill when committing code changes — including "commit", "コミット", "コミットして", "変更を記録", "save changes", "stage and commit", asking whether to use feat or fix, deciding between squash and new commit, or any request to record, amend, or finalize changes in git. Contains mandatory project-specific conventions for type/scope format (plugin name as scope), squash-vs-new-commit strategy selection, and message structure that differ from defaults and cannot be inferred without this skill.
npx claudepluginhub kkhys/claude-code-marketplaceThis skill is limited to using the following tools:
The goal is a clean, reviewable commit history. Two strategies:
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
The goal is a clean, reviewable commit history. Two strategies:
Create a new commit when:
A new commit preserves the narrative of how the work evolved. Each commit should be a self-contained, meaningful unit — something a reviewer can understand in isolation.
Amend the previous commit when:
Squashing keeps the history focused on intent rather than process. After amending a pushed commit, use git push --force-with-lease — never --force.
If the branch has multiple commits that need reorganizing, use the splitting-commit skill instead of manual rebase.
<type>(<scope>): <description>
[body]
[footer]
Select by the primary intent of the change:
| Type | When to use |
|---|---|
feat | New user-facing capability |
fix | Correcting broken behavior |
refactor | Restructuring without behavior change |
perf | Performance improvement |
test | Adding or modifying tests |
docs | Documentation only |
style | Code formatting, whitespace |
build | Build system, dependencies |
ci | CI/CD configuration |
chore | Everything else (version bumps, config) |
When changes span multiple types, pick the dominant one. A feature that includes its tests is feat, not test.
The scope identifies the area of the codebase affected. In this marketplace, use the plugin name:
feat(base): add memo command
fix(writing): correct language-editor agent prompt
chore(base): bump version to 0.0.19
Omit scope only when the change is truly cross-cutting (e.g., root-level config).
Good: add OAuth2 login flow
Bad: Added the OAuth2 login flow implementation
Optional but valuable for non-trivial changes. Explain why the change was needed — the subject already says what. Wrap at 72 characters.
Closes #123 to auto-close issuesBREAKING CHANGE: or ! after type for breaking changes: feat(api)!: remove legacy endpointgit status and git log --oneline origin/main..HEAD to understand the branch stategit log -1 --stat