release-please-protection

Release-Please の保護

すべてのプロジェクトで、release-please が管理するファイルへの手動編集を自動検出して防止します。

概要

このスキルは、Google の自動化ツール release-please が管理するファイルに対する事前検出と警告を提供します。問題のある編集が発生する前に特定することで、マージの競合やワークフローの中断を防ぐのに役立ちます。

このスキルが有効になる場合

このスキルは、次のような状況で自動的に有効になります。

1. 保護対象ファイルへの直接的な編集依頼
2. バージョン更新、リリース、変更履歴の更新に関するユーザーの言及
3. バージョン管理下のファイルに影響する可能性がある広範なリファクタリング
4. CHANGELOG.md を含む可能性のあるドキュメントの更新
5. **「すべての問題を修正」**などの包括的な依頼

保護対象ファイル

強制保護（権限システム）

これらのファイルは、Claude Code の権限システムによって編集が完全にブロックされます。

• **/CHANGELOG.md - すべての場所にあるすべての変更履歴ファイル

ブロックされる操作： 編集、書き込み、複数箇所の編集
許可される操作： 読み取り（分析とコンテキストの把握）

ソフト保護（スキルによる検出）

これらのファイルは、編集前に警告と提案を表示します。

パッケージマネージャーのマニフェスト（バージョンフィールド）

• package.json → "version": "x.y.z"（npm／Node.js）
• pyproject.toml → version = "x.y.z"（Python／uv）
• Cargo.toml → version = "x.y.z"（Rust／cargo）
• .claude-plugin/plugin.json → "version": "x.y.z"（Claude Code プラグイン）
• pom.xml → <version>x.y.z</version>（Maven／Java）
• build.gradle → version = 'x.y.z'（Gradle）
• pubspec.yaml → version: x.y.z（Dart／Flutter）

ソフト保護の理由： Claude Code の権限システムは、フィールド単位ではなくファイル単位で動作します。マニフェストファイル全体をブロックすると、自動化ツール（npm、cargo、uv など）を使った正当な依存関係の更新まで妨げてしまいます。

検出ロジック

編集を試みる前に、スキルは次の点を確認します。

1. ファイルパスの分析

if file_path ends with "CHANGELOG.md":
    → Inform user of hard permission block
    → Explain release-please workflow
    → Suggest conventional commit approach

2. コンテンツのパターンマッチング

if file is package manifest AND edit touches version field:
    → Warn about release-please management
    → Explain why manual edits cause conflicts
    → Offer to edit OTHER fields (but not version)
    → Provide conventional commit template

3. 意図の認識

if user request contains keywords: "version", "release", "bump", "changelog":
    → Proactively explain release-please workflow
    → Check if files in scope are protected
    → Suggest proper approach before attempting edits

応答テンプレート

CHANGELOG.md の編集を試みた場合

⚠️ CHANGELOG.md Protection Active

I cannot edit CHANGELOG.md files - they're protected by Claude Code's permission
system because they're managed by release-please automation.

**Why this matters:**
Manual edits to CHANGELOG.md cause merge conflicts with automated release PRs,
breaking your release workflow.

**Proper workflow:**
1. Make your changes with conventional commit messages:
   - feat: adds new features (minor version bump)
   - fix: bug fixes (patch version bump)
   - chore: maintenance tasks (no version bump)
   - BREAKING CHANGE: breaking changes (major version bump)

2. Release-please automatically:
   - Detects conventional commits
   - Generates CHANGELOG entries
   - Creates a release PR with version bumps
   - Tags releases when PR is merged

**Example commit:**

feat(auth): add OAuth2 support

Implements OAuth2 authentication flow with PKCE. Includes refresh token rotation and session management.

**Need to override?**
For emergency fixes, temporarily edit ~/.claude/settings.json:
1. Comment out the CHANGELOG.md deny rules
2. Make your edits
3. Re-enable protection

バージョンフィールドの編集を検出した場合

⚠️ Version Field Protection Warning

I notice you're asking me to modify the version field in [file_name]. This field
is typically managed by release-please automation.

**Current version:** [current_version]
**Requested change:** [requested_change]

**Why manual edits are problematic:**
- Creates merge conflicts with release-please PRs
- Can cause version numbering inconsistencies
- Bypasses conventional commit history tracking

**I can help in two ways:**

1. **Automated approach (recommended):**
   I'll help you craft a conventional commit message that will trigger the
   appropriate version bump when release-please creates its next release PR.

   For [requested_change], you should use:
   - `feat:` for minor version bump
   - `fix:` for patch version bump
   - `feat!:` or `BREAKING CHANGE:` for major version bump

2. **Manual override (emergency only):**
   If you absolutely need to manually set the version (e.g., aligning with
   external requirements), I can edit other fields in [file_name] but will
   skip the version field. You'll need to edit that manually or temporarily
   disable the skill protection.

Which approach would you prefer?

広範なリファクタリングを依頼された場合

📋 Release-Please Files Detected

I've identified several release-please managed files in the scope of this
refactoring:

**Protected files found:**
- plugins/dotfiles-core/CHANGELOG.md (hard block)
- plugins/dotfiles-toolkit/.claude-plugin/plugin.json (version field)
- [other files...]

**My approach:**
✅ I'll refactor all other files as requested
⚠️ I'll skip protected files and explain why
📝 I'll provide a summary of skipped changes

**If you need version/changelog updates:**
I'll generate appropriate conventional commit messages that will trigger
release-please to make those changes automatically.

Should I proceed with this approach?

Conventional Commit ガイド

このスキルは、変更の種類に応じた Conventional Commit のテンプレートをすぐに提供します。

機能の追加

feat(scope): brief description

Detailed explanation of what was added and why.
Can be multiple paragraphs.

Refs: #issue-number

バグ修正

fix(scope): brief description

Explanation of the bug and how it was fixed.

Fixes: #issue-number

破壊的変更

feat(scope)!: brief description

BREAKING CHANGE: Explanation of what breaks and migration path.

Details about the new behavior.

Refs: #issue-number

雑務（バージョン更新なし）

chore(scope): brief description

Maintenance work that doesn't affect functionality.
Examples: dependency updates, refactoring, docs.

他のスキルとの連携

このスキルは、次のスキルと連携します。

• Chezmoi Expert - dotfiles のテンプレートでバージョンを手動編集しないようにします
• Git Workflow - PR 作成前に Conventional Commit を徹底します
• GitHub Actions - release-please のワークフロー設定を把握します

スキルの設定

dot_claude/skills/release-please-protection/（ソース）に配置されています。chezmoi apply 後は ~/.claude/skills/release-please-protection/ になります。

• SKILL.md - このファイル（スキルの定義）
• patterns.md - 保護対象ファイルのパターン一覧
• workflow.md - release-please ワークフローの詳細ガイド

制限事項

このスキルでは防止できないこと

1. 明示的な上書き - 警告を無視して編集するよう明示的に指示された場合
2. コンテキスト外のファイル - 現在のコンテキストウィンドウに含まれていないファイル
3. 外部ツール - sed、awk などのコマンドや、bash による直接編集
4. Git 操作 - 保護対象ファイルを変更した状態での手動 git commit

このスキルで防止できること

1. 誤った編集 - ミスが起きる前に検出します
2. ワークフロー違反 - 適切な release-please のパターンを説明します
3. マージの競合 - 自動化された PR での競合を防ぎます
4. バージョンの不整合 - セマンティックバージョニングの規律を維持します

緊急時の上書き

保護対象ファイルをどうしても手動で編集する必要がある場合：

一時的な権限の上書き

# 1. Edit global settings
vim ~/.claude/settings.json

# 2. Comment out deny rules
"deny": [
  "Bash(git add .)",
  "Bash(git add -A)",
  "Bash(git add --all)",
  // "Edit(**/CHANGELOG.md)",
  // "Write(**/CHANGELOG.md)",
  // "MultiEdit(**/CHANGELOG.md)"
]

# 3. Make your edits

# 4. Re-enable protection (uncomment the lines)

# 5. Verify with chezmoi
chezmoi diff ~/.claude/settings.json
chezmoi apply  # If template is out of sync

スキルの回避（推奨されません）

# Temporarily disable skill
mv .claude/skills/release-please-protection .claude/skills/release-please-protection.disabled

# Make edits

# Re-enable
mv .claude/skills/release-please-protection.disabled .claude/skills/release-please-protection

成功指標

このスキルが適切に機能している状態：

✅ CHANGELOG.md のすべての編集試行が、わかりやすい説明とともにブロックされる ✅ バージョンフィールドの変更時に警告と代替案が提示される ✅ Conventional Commits の提案が、依頼された変更内容に合致する ✅ 最初の警告を受けた後、ユーザーが release-please のワークフローを理解している ✅ 自動リリース PR とのマージコンフリクトが発生しない ✅ バージョン番号がセマンティックバージョニングに一貫して準拠している

参考資料

• 保護対象のファイルパターンの一覧については、patterns.md を参照してください
• release-please のワークフローに関する詳細なドキュメントについては、workflow.md を参照してください
• release-please のドキュメント：https://github.com/googleapis/release-please
• Conventional Commits：https://www.conventionalcommits.org/