| name | commit_standard |
| description | Defines the standard format and rules for git commit messages in this project. |
Commit Message Standard
This project uses a standardized git commit message format based on Conventional Commits, with an added touch of our project's specific context.
Format
<type>(<scope>): <subject>
<body>
<footer>
Rules
1. Type
Must be one of the following:
feat: A new feature (e.g., adding a new user profile section)
fix: A bug fix (e.g., fixing tooltip text)
docs: Documentation only changes (e.g., updating README or dictionaries)
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing tests or correcting existing tests
chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
2. Scope (Optional but Recommended)
Indicates the area of the codebase the commit affects. Common scopes in this project:
dashboard: Admin/User dashboard UI or logic
components: Reusable UI elements
utils: Shared utility functions
auth: Authentication flows
payment: Payment and webhook integrations
i18n: Dictionaries and localization
3. Subject
- Use the imperative, present tense: "change" not "changed" nor "changes".
- Don't capitalize the first letter.
- No dot (.) at the end.
- Keep it concise (under 50 characters if possible).
4. Body
- Just like in the subject, use the imperative, present tense: "change" not "changed" nor "changes".
- The body should include the motivation for the change and contrast this with previous behavior.
- Wrap the body at 72 characters.
5. Footer (Optional)
- Reference issue tracker IDs if applicable.
- Note any BREAKING CHANGES here.
Example
feat(auth): add OAuth login support
Implement Google and GitHub OAuth providers for faster
user onboarding and integrate them into the login screen.
Agent Instructions
When you are asked to commit changes, ALWAYS reference this skill and follow the format precisely. If committing multiple diverse changes, try to group them logically or use feat(core) / chore(all) if they span the entire project.
CRITICAL RULE FOR AI AGENTS (Jules):
All commit subjects and bodies MUST be written in Japanese (日本語), regardless of the prompt language. The <type>(<scope>) prefix remains in English.
Example: feat(auth): Googleログインを追加
Branch Strategy
命名規則
feat/<short-description> — 新機能
fix/<short-description> — バグ修正
refactor/<short-description> — リファクタリング
docs/<short-description> — ドキュメント変更
運用ルール
- コード変更(
.ts, .tsx, .css, .json 等)は必ず feature ブランチで作業する
- PR を作成し、CI(lint, typecheck, test, e2e)が全てパスしてからマージする
main への直接 push はドキュメントのみの変更に限定する
- 許容例:
blueprint.md, AGENTS.md, GEMINI.md, .agents/skills/*.md
- 禁止例:
lib/, app/, components/, __tests__/ 配下の変更