git-workflow-enforcer
Gitワークフロー標準の適用
チームは、変更の追跡を困難にする一貫性のないコミットメッセージとブランチ名に悩まされています。このスキルは、Conventional Commits、ブランチ命名パターン、PRテンプレートを検証し、リポジトリを整理された状態に保ち、自動changelog生成に対応させます。
下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「git-workflow-enforcer」。 最新の10件のコミットを検証
預期結果:
- ✓ feat(api): add user endpoint - valid format
- ✓ fix(auth): handle token expiration - valid format
- ✗ Added login feature - missing conventional format
- Suggested: feat(auth): add login functionality
- ✓ docs: update readme installation - valid format
- ✓ refactor(utils): simplify helper functions - valid format
正在使用「git-workflow-enforcer」。 ユーザー認証用のブランチを作成
預期結果:
- Suggested branch name: feature/user-authentication
- First commit format: feat(auth): add OAuth2 login support
- Use conventional commit pattern: type(scope): description
- Available types: feat, fix, docs, style, refactor, perf, test, chore
正在使用「git-workflow-enforcer」。 PRテンプレートを生成
預期結果:
- Template created at .github/PULL_REQUEST_TEMPLATE.md
- Includes sections: Description, Type of Change, Testing, Checklist
- Checklist items: Code style, Self-review, Comments, Documentation, Tests, Warnings
- All sections have descriptive headers and placeholder text
安全審計
安全This is a pure documentation skill containing only SKILL.md with Git workflow guidance. The pre-computed static analysis flagged 67 pattern-based findings, but ALL are false positives after semantic evaluation. Shell script examples in documentation were misidentified as code execution; references to GPG signing and secret detection were misclassified as cryptographic operations and credential theft; git operations were flagged as reconnaissance. No network tools means no data exfiltration possible. The skill is safe for publication.
風險因素
🌐 網路存取 (1)
⚙️ 外部命令 (41)
📁 檔案系統存取 (3)
🔑 環境變數 (1)
品質評分
你能建構什麼
チームワークフローの標準化
すべてのチームメンバーが同じコミット規則に従うことで、履歴をクリーンに保ち、自動リリースを可能にします
コントリビューターへのガイダンス
テンプレートと検証を通じて、外部コントリビューターに明確なコミットおよびPR標準を提供します
リリースプロセスの自動化
適切にフォーマットされたコミットから、自動changelog生成とセマンティックバージョニングを可能にします
試試這些提示
最近のコミットがConventional Commits形式に従っているか確認してください。パターンに一致しないコミットを表示し、修正版を提案してください。
OAuth2サポート付きのユーザー認証を追加するためのブランチ名を作成してください。次に、最初のコミットのconventional commit形式を表示してください。
プロジェクト用のプルリクエストテンプレートを作成してください。説明、変更の種類、テスト、チェックリスト項目のセクションを含めてください。
コミットを許可する前にConventional Commits形式を検証するcommit-msgフックスクリプトを生成してください。
最佳實務
- コミットメッセージには命令形を使用(addedではなくadd)
- 件名行を50文字以内に保つ
- Closes #123やFixes #456でissueを参照
避免
- 'fix bug'や'update code'のような一般的なメッセージの使用
- 該当する場合にコミットタイプのスコープを省略
- 無関係な変更を含む大きなコミットの作成