commit-hygiene-public
Apply public, contributor-safe commit hygiene without maintainer-private automation, timestamps, ledger rules, or push policy.
- License 许可
- MIT
- 所属仓库
- clawic/Clawix
- 最近更新
- 2026-06-06
- Stars
- ★ 8
- Forks
- 0
01 前言 Front Matter
- name
- commit-hygiene-public
- keywords
- [ "commits", "conventional-commits", "changesets", "privacy", "public" ]
- description
- Apply public, contributor-safe commit hygiene without maintainer-private automation, timestamps, ledger rules, or push policy.
03 SKILL.md 正文
commit-hygiene-public
Use public commit hygiene only.
Procedure
- Scope each commit to one verifiable intention: one user-visible behavior, fix, doc update, test update, guardrail, or mechanical refactor that preserves coherent build/test validation.
- Use Conventional Commits:
type(scope): description. - Write every commit subject and body in English. Non-English commit text is blocked except for exact user-facing strings, proper nouns, protocol literals, or quoted external identifiers that must stay unchanged.
- Add a commit body for every non-trivial commit. The body must explain why the change exists, what behavior or contract changed, and which validation was run or why validation is pending.
- Keep the subject as a concise imperative summary. Put rationale, tradeoffs, follow-up risk, and validation evidence in the body, not in an overloaded subject.
- Do not split commits only by file, line count, or raw size; a large commit is acceptable when it has one verifiable intention and coherent validation.
- Do not group distinct intentions into one commit, even when each individual change is small.
- Do not create tiny guardrail-only commits just to atomize review; consolidate repeated guardrail changes when they serve the same verification intent.
- Do not sweep unrelated edits from a dirty worktree.
- Commit
.changeset/*.mdwith the functional change it documents when a published package surface changes. - Run relevant validation before proposing merge or release.
- Treat push, publish, upload, tag creation, and release actions as explicit separate approvals.
Constraints
- Do not include maintainer-private commit-manager, ledger, timestamp, external-session-review, or automation procedures.
- Do not publish secrets, local paths, signing identities, bundle IDs, Team IDs, or private workflow details in commits.
- Do not rewrite public history unless the project's public contribution docs explicitly allow it.
04 同仓库更多 Skills
visual-regression
Run and interpret Clawix UI geometry, screenshot, protected-surface, and debt-baseline checks without authorizing visual repair.
ui-performance-budget
Capture and compare Clawix UI performance budgets for critical flows before optimizing visible or runtime UI behavior.
ui-implementation
Implement functional Clawix UI wiring while respecting visual mutation boundaries, pattern contracts, protected surfaces, and debt baselines.
ui-canon-review
Review whether a Clawix UI pattern, visual decision, copy change, or component extraction belongs in canon, debt, exception, or protected-surface scope.
theme-factory
Produce variants of an existing Style by shifting tone (light/dark), density (compact/relaxed), or accent (palette rotation) while preserving the brand identity. Use when the user wants alternate themes derived from one brand.
template-render
Render a Template + data + Style into a final artifact in one of HTML, PDF, PNG, SVG or PPTX. Use whenever the user asks for a concrete deliverable like "make me a poster", "render a card", "give me a one-pager".