AgentSkillsCN

commit-message

撰写清晰且结构化的提交信息指南

SKILL.md
--- frontmatter
name: commit-message
description: Guidelines for writing clear and structured commit messages

Commit Message Guidelines

Generate a markdown commit message using the following structure and formatting, including emojis and scopes. Do NOT enclose the commit message in code blocks. Use git diff output to understand the changes made.

1. Title (First Line)

  • Write a concise summary (50-72 characters max).
  • Use imperative mood and present tense (e.g., "Add patient CRUD endpoints").
  • Add a scope in parentheses after the emoji and before the title (e.g., ✨(patient): Add patient CRUD endpoints).
  • Capitalize the first letter.
  • Add a blank line after the title.

2. Summary Paragraph

  • Write a 1-2 sentence summary of all relevant changes (100-200 characters).
  • Focus on what and why, not how.
  • Use present tense.
  • Add a blank line after the summary.

3. Detailed Description

  • Use section headers for major features/areas, each with a relevant emoji (e.g., ✨ for features, 🔧 for refactoring, 🖥️ for UI, 🐛 for bug fixes, etc.).
  • Under each section, use bullet points for detailed changes.
  • Group related changes together. Mention file names or layers when appropriate.
  • Explain the "why" behind significant changes.
  • Reference issue numbers with #123 if applicable.
  • Make the message clear, concise, and easy to understand.
  • Adjust the length of the description to fit the changes made.
  • Limit lines in the body to 72-80 characters for readability.
  • Never use "WIP", "temp", or similar placeholders in commit messages.
  • Clearly mark breaking changes with a section (e.g., ## 💥 Breaking Changes) and describe the impact.
  • Reference related documentation, specs, or design docs if relevant.
  • Optionally, include a checklist section for reviewers if the commit introduces new patterns, migrations, or requires special attention.

4. Formatting Example

Follow the formatting, emoji usage, and scope tagging shown in the example below:

markdown
✨🔧(patient): Patient Management Service Refactor (Domain Layer)

Refactor patient management logic in the domain and application layers for improved testability and maintainability.
Update related tests and documentation.

## 5. ✨ Patient Management Feature (Phase 1)
- Implement patient CRUD operations in domain/application layers
- Refactor PatientService using dependency injection (custom DI container)
- Update patient model and validation logic

## 6. 🔧 Packages/Layers Affected
- Migrate all core services and commands to dependency injection using custom DI container.
## 7. 🛠️ Github workflow
- Implement CI/CD pipeline for automated testing and deployment
- Configure linting and formatting checks
- Set up issue templates and pull request templates

## 8. 🖥️ UI
- Update patient form to use new validation logic

## 9. 🔧 Drag and Drop Refactoring
- Refactor drag-and-drop logic to use new service structure

## 10. 🛡️ Refactoring
- Refactor data access layer to use repository pattern

## 11. 🐛 Bug Fixes & Technical Debt Reduction
- Fix patient data serialization issue

## 12. 📊 Metrics & Results
- Add logging for patient operations

## 13. 🚀 Benefits
- Improve code maintainability and testability

## 14. 📄 Documentation
- Update patient management section in docs/ai/2025-09-14-PATIENT_MANAGEMENT.md

## 15. 🛡️ Compliance
- Ensure patient data encryption (HIPAA compliance)

## 16. 💥 Breaking Changes
- Remove deprecated patient endpoints; update API consumers

## 17. 🧪 Tests
- Add unit tests for PatientService
- Update integration tests for patient endpoints

## 18. 📚 Related Docs
- See design spec in docs/specs/patient-management.md

## 19. ✅ Reviewer Checklist
- [ ] Migration steps documented
- [ ] New patterns reviewed

Do not include any explanations or additional text.