共通ルール

日本語で応答する。

モデル運用

仕様が固まっていない依頼は、メインの sonnet セッションを保ったまま Agent ツールで委譲する。セッションそのものは切り替えない。

• 設計・仕様の判断 → Agent（model: "opus" か "fable"、subagent_type は省略してよい）を起動し、skill: spec をそのサブエージェントにやらせる
• 実装・実験の実行・記録 → メインの sonnet セッションのまま続ける

Agent の prompt には依頼の背景とここまでに分かっている制約を要約して 渡す（サブエージェントは文脈を持たずに始まる）。起動したサブエージェントは AskUserQuestion で詰めて doc-storage に仕様を書き出し、ファイルパスだけを 最終報告として返す。パスを受け取ったら、確認を挟まずそのまま skill: feature <パス> に進む。

仕様を詰めた対話の文脈はメインに持ち越さない。実装は安いモデルの セッションで回す方針は変わらない。

実装と委譲

実装は自分で書く。サブエージェントには投げない。 仕様も文脈も自分が持っていて、渡し直すと落ちる。

委譲するのは2つの場合だけ。出力が大量で自分の文脈を埋めてしまうときと、 別のモデルに見せる価値があるとき。

• 仕様の対話（上位モデルの判断が要るとき） → skill: spec（Agent 経由。詳細は「モデル運用」）
• テストの作成・実行 → test-runner
• 広範囲の調査 → Explore
• プランの批評 → plan-reviewer
• 行き詰まったときの前提の点検 → advisor
• ドキュメントの記録 → doc-writer
• 差分のレビュー → /code-review（組み込み）
• アプリを動かしての確認 → /run（組み込み）

数回のツール呼び出しで終わる作業は委譲しない。 自分の仕事を確かめるためのサブエージェントも使わない。

作業の進め方

ゴールが明確でなければ実装を始めない。 まず完了条件を「検証可能な1文」で書けるか試す。書けたかどうかで進み方が決まる。

• 書けて、diff も1文で説明できる規模 → そのまま実装する
• 書けるが、触るファイルが複数で実装方針が1本に決まらない → skill: feature
• 書けない → 書けるところまで聞く。それでも固まらない大きめの依頼は skill: spec に委譲する（起動の仕方は「モデル運用」）

この判断は自分でする。 ユーザーがスキル名やスラッシュコマンドを打つのを待たない。 ユーザーは作りたいものを言うだけでよく、どの手順に入るかはこちらの責任。

依頼された範囲を実装する。頼まれていないリファクタや抽象化は足さない。 仕様の判断に迷ったら妥当な方を選んで進め、選んだことを報告に含める。 どちらを選んでも成果物が変わる場合だけ手を止めて聞く。

テストが落ちているなら落ちていると報告する。出力を添える。 飛ばした手順があるなら飛ばしたと書く。

自律の範囲

完了条件が検証可能な1文で書けているなら、そのまま自走してよい。 分岐は観測できる事象だけで決める。「難しそうか」「自信があるか」では決めない。 レビューも停止も、条件に当たったら自分から起動する。 指示を待たない。

「異なる手で2回」は、同じ修正のリトライを1回に数える。 ビルドエラーを3回直したのは1アプローチの反復であって、2回失敗ではない。

応答の書き方

結論から書く。最初の1文で「何が起きたか」「何が分かったか」に答える。 根拠と詳細はその後。単純な質問には単純に答える。見出しや表で膨らませない。

ドキュメント

プロジェクトのドキュメントはリポジトリ内に置かず、doc-storage に集約する。 配置ルートと規約は skill: doc-storage。

リポジトリ内でドキュメントを管理する慣習のプロジェクトは対象外。

検証

ビルド・テスト・lint のコマンドは各プロジェクトの CLAUDE.md か .claude/skills/run-*/ にある。そこに書かれたコマンドで検証する。 どちらにも無ければ /run-skill-generator で記録させる。

ハーネス

このハーネス（~/.claude のルール・エージェント・スキル）は作業中に書き換えない。 気付いたことは worklog の「ハーネスへの示唆」欄に書き、変更は skill: harness-review で行う。