skills提案 2026-09-13

2026-09-13

提案1: Auto Mode向け4段階権限ルール(Hard Deny/Soft Deny/Allow/Environment)の設定

何が良くなるか 2026-08-22-Kn9J9NrTr9k.mdにある「Hard Deny/Soft Deny/Allow/Environment」の4段階設計を.claude/settings.jsonのpermissionsに落とし込むことで、Auto Mode(権限バイパス)運用時の誤ブロック・誤許可を減らせます。特に「社内ドメイン・GitHub組織名・クラウドバケット名を明記すると誤検知が減る」という知見は、CLAUDE.mdに書くだけで実効性が上がる具体的な改善点です。

導入手順

.claude/settings.jsonのpermissionsに4段階を反映する。例:

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)"
    ],
    "ask": [
      "Bash(*deploy*)",
      "Bash(*migrate*)",
      "Bash(git push*)"
    ],
    "allow": [
      "Bash(git status)",
      "Bash(git diff*)",
      "Bash(npm test*)"
    ]
  }
}

deny = Hard Deny(絶対禁止)
ask = Soft Deny(本番デプロイ/DBマイグレーションなど、必ず自分の目で確認したい操作)
allow = 誤検知を減らすための明示的許可(Environment運用)

CLAUDE.mdに「Environment」セクションを追加し、社内固有の判断材料を明記する:

## Environment
- 社内GitHub組織: `your-org-name`
- 本番バケット/DB: `prod-*` で始まるものは常にAsk対象
- 外部送信(Slack/メール/API)は常にAsk対象

update-configスキルを使って上記をレビューさせながら反映する(/update-config または該当依頼文でスキル起動)。
1週間ほど運用し、頻繁にaskで止まる操作があればallowへ、想定外に通ってしまった操作があればdenyへ都度移動する。

提案2: PostToolUseフックによる「Lintスメル→具体的な直し方」自動ガイダンス

何が良くなるか 2026-08-21-6AgndHSkHFI.mdの指摘どおり、「行数を減らせ」のような表面的指標だけを渡すと、Claude Codeは指標をごまかす改悪(無意味な関数分割・重複関数の量産)をしがちです。lintエラーの検出結果と「そのスメル固有の直し方」を1つのプロンプト内で隣接させる仕組みをフックで自動化すると、リファクタ品質が安定します。

導入手順

スメル種別ごとのガイダンスをマッピングするJSONを用意する。.claude/lint-guidance.json:

{
  "max-lines-per-function": "関数を機能単位で分割せよ。行数を減らすためだけの無意味な分割(同じ処理を別名関数に切るだけ)は禁止。",
  "complexity": "早期returnで条件分岐をフラット化せよ。ネストを減らすためのラップ関数の追加は禁止。",
  "no-duplicate-code": "共通処理を1箇所に抽出せよ。同名・同内容の関数を複数ファイルに複製することは禁止。"
}

.claude/settings.jsonにPostToolUseフックを追加し、Edit/Write後にlintを実行してガイダンス付きメッセージを返す:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "$CLAUDE_PROJECT_DIR/.claude/scripts/lint-guidance.sh"
          }
        ]
      }
    ]
  }
}

.claude/scripts/lint-guidance.shでlinterをJSON出力させ、lint-guidance.jsonと突き合わせて「検出されたスメルの種類 + 直し方」を1つのテキストにまとめてhook出力(additionalContext)として返す。
効果検証: 同じリファクタ依頼を「素のlint結果だけ渡す場合」と「ガイダンス付きの場合」で比較し、無意味な分割が減っているか確認する。

提案3: Cloudflare/Wrangler デプロイ操作のスキル化

何が良くなるか 2026-08-18-wN2byhrfqN4.md・2026-08-31-UtchKt8dRgk.md・2026-08-31-oJuSoHxMDqg.mdの3本で独立に「Wrangler CLI経由でD1/R2/Workersのセットアップ〜デプロイを一括指示できる」ことが触れられており、再現性の高い定型作業として繰り返し価値が確認されています。2026-08-17-TAcCfKXEfjo.mdの「スキル=固定レシピ」という設計方針にも合致するため、SKILL.md化する優先度が高い候補です。

導入手順

Wrangler CLIをインストール済みであることを確認(npm install -g wrangler)。
.claude/skills/cloudflare-deploy/SKILL.mdを作成:

---
name: cloudflare-deploy
description: Cloudflare WorkersへのデプロイやD1/R2/KVのセットアップ・操作が必要なとき(「Cloudflareにデプロイして」「D1データベースを作って」「R2に画像を保存する設定をして」等)に使う。単なるWebサイト制作全般や、Cloudflare以外のホスティング先の話では使わない。
---

# Cloudflare Deploy

## 手順
1. `wrangler whoami` でログイン状態を確認。未ログインなら `wrangler login` を実行。
2. `wrangler.toml` の有無を確認し、なければ `wrangler init` でプロジェクトを初期化。
3. 要件に応じてリソースを作成する:
   - D1: `wrangler d1 create <db-name>` → `wrangler.toml` にbinding追記
   - R2: `wrangler r2 bucket create <bucket-name>`
   - KV: `wrangler kv namespace create <ns-name>`
4. ローカル動作確認: `wrangler dev`
5. 本番デプロイ: `wrangler deploy`
6. デプロイ後、`wrangler tail` でログを確認しエラーがないか確認する。

## 禁止事項
- 既存の本番DB/バケットへの破壊的操作(削除・上書き)は必ず事前にユーザーへ確認する。
- シークレットキーは `wrangler secret put` で設定させ、チャットに貼らせない。

/cloudflare-deployで呼び出せることを確認(会話内で「Cloudflareにデプロイして」と依頼して自動発動するかもテスト)。
実際に小さなWorkerでD1作成→デプロイまで一度通し、手順に不足があれば追記して育てる。