skills提案 2026-09-20

2026-09-20

提案1: オートモード用の4段階権限ポリシー（Hard Deny / Soft Deny / Allow / Environment）

何が良くなるか オートモードは「危険操作だけを検知してブロックする分類器」であり、全自動ではありません（2026-08-22 Kn9J9NrTr9kのナレッジ）。ルールを曖昧なままにすると誤検知で毎回止まったり、逆に危険操作が漏れたりします。社内組織名・クラウドバケット名・社内ドメインなどを「Environment」として明記し、本番デプロイやDBマイグレーションだけは常にAskに固定することで、安全性と作業速度を両立できます。

導入手順

まず1週間、リスクの低い読み取りタスクだけでオートモードを試し、ブロックログを確認する（同ナレッジの推奨手順）。
.claude/settings.jsonに以下のような形で4段階を明記する（キー名はプロジェクトの既存設定に合わせて調整）。

{
  "permissions": {
    "deny": [
      "Bash(rm -rf /*)",
      "Bash(git push --force*)",
      "Bash(*prod-db-migrate*)"
    ],
    "ask": [
      "Bash(*deploy*prod*)",
      "Bash(*migrate*)",
      "Bash(git push*)"
    ],
    "allow": [
      "Bash(git status)",
      "Bash(git diff*)",
      "Read(*)"
    ]
  },
  "environment": {
    "internalGithubOrg": "your-org-name",
    "internalDomains": ["example.internal.com"],
    "cloudBuckets": ["your-bucket-name"]
  }
}

「正当な操作なのに毎回止まる」ケースが出たら、都度Allow/Environmentに追記して誤検知を減らしていく（同ナレッジ）。
本番デプロイ・DBマイグレーションなど目視確認したい操作は、慣れてもAskから外さない。

提案2: PostToolUseフックでリンター結果にスメル別の修正指針を自動付与

何が良くなるか リンター結果をそのまま貼ると、Claude Codeは「行数を減らす」等の表面指標だけを満たそうとして無意味な関数分割や重複作成をしがちです。問題検出（lintエラー）と直し方のガイダンスを1つのプロンプト内で隣接させると、注意が分散せず高品質な修正が得られます（2026-08-21 6AgndHSkHFIのナレッジ）。

導入手順

.claude/hooks/lint-guidance.shのようなスクリプトを用意し、PostToolUse（Edit/Write後）でリンターをJSON出力で実行する。
ルールID（例: max-lines-per-function, too-many-params）ごとに「このスメルはこう直す」という具体的指針をマッピングしたテーブルを作る。

#!/bin/bash
# .claude/hooks/lint-guidance.sh
LINT_JSON=$(eslint --format json "$1" 2>/dev/null)

echo "$LINT_JSON" | jq -r '.[].messages[] | .ruleId' | sort -u | while read -r rule; do
  case "$rule" in
    max-lines-per-function)
      echo "・長い関数: 単一責務ごとに意味のある名前で分割し、同名関数の重複作成は避けること" ;;
    complexity)
      echo "・分岐過多: early returnやガード節で条件分岐をフラット化すること" ;;
  esac
done

.claude/settings.jsonのhooksにPostToolUseとして登録する。

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

出力（lintエラー＋隣接する修正指針）がそのままエージェントのコンテキストに渡るようにし、単なる「行数を減らせ」という抽象指示は書かない。

提案3: セッションコストヒギーン・スキル（モデル固定／compact／clear の徹底）

何が良くなるか 「モデル・エフォートは途中変更でキャッシュが失効しコスト増になる」「休憩前は/compact」「話題転換で/clear」「新セッションでは/context確認」は複数のナレッジ（2026-08-26 aIzceig3XLo、2026-09-01 sBfvvj9cQPE、2026-09-05 ysKugt1NNLY、2026-09-13 t22FELAl-BM）に共通して出てくる実践で、最大20倍のコスト差が生まれると言われています。これを毎回思い出す代わりに、CLAUDE.mdから自動的に読み込まれるスキルとして固定化します。

導入手順

.claude/skills/session-cost-hygiene/SKILL.mdを作成する。

---
name: session-cost-hygiene
description: セッション開始時と作業の節目でトークン・コストを最適化するためのチェックリスト。モデル/effortの固定、compact/clearのタイミング判断に使う。
---

# セッションコストヒギーン

## セッション開始時に必ず行うこと
- `/model`と`/effort`をタスクの難易度に応じて一度だけ決め、以降は変更しない（変更するとキャッシュが失効しコストが増える）
- `/context`で現在のコンテキスト内容を確認する

## 作業中の判断基準
- 話題が変わったら`/clear`で新しいセッションを開始する（古い履歴を引きずらない）
- 同じ話題のまま会話が長くなったら`/compact`で要約する
- 休憩・離席前はキャッシュが有効なうちに`/compact`しておく

## 注意
- サブエージェントを使うとメイン/サブでキャッシュが分かれてコストが増える場合があるため、単一モデルで完結できるなら使わない

ルートのCLAUDE.mdに「セッション開始時はsession-cost-hygieneスキルを読み込む」という一文を追記し、明示的なスラッシュコマンドなしでも自動起動するようにする（2026-08-27 D3Ftx4KjLywのナレッジにある「文脈判断で自動起動」の手法）。
1〜2週間運用し、/usageや利用枠の消費ペースを見て効果を確認する。