CLAUDE.md の階層、スキルとコマンド、plan mode、CI/CD統合。~/.agent/ 組織はこのドメインの「模範解答の実物大模型」なので、実務貯金が最も効く。公式用語との対応確認が中心。
~/.claude/CLAUDE.md・自分専用）→ プロジェクト（.claude/CLAUDE.md かルート直下・チーム共有）→ ディレクトリ（サブフォルダごと）。「チームに効かせたい指示がユーザー階層に書かれている」が典型トラブル。@import 構文で外部ファイルを参照し、CLAUDE.md をモジュール化する（パッケージごとに関係する規約ファイルだけ読み込む）.claude/rules/ ディレクトリでトピック別ファイル（testing.md, api-conventions.md…）に分割する/memory コマンドで「いまどのメモリファイルが読み込まれているか」を確認し、セッション間の挙動ブレを診断するこの構成そのものを運用中：~/.claude/CLAUDE.md（ユーザー・グローバル設定）＋ ~/.agent/CLAUDE.md（プロジェクト）＋ rules/ 26ファイル（トピック別分割）。⚠️実務メモ: feedback-claude-code-import-misconception「@import はcontext削減効果なし（読み込まれれば消費は同じ）」——@importの利点は整理と選択的読み込みであって魔法の圧縮ではない、という理解が正確。
.claude/commands/（プロジェクト・git共有）、個人用は ~/.claude/commands/。スキル（SKILL.md）には frontmatter で fork実行・ツール制限・引数ヒントを設定できる。.claude/commands/（clone/pullで全員に配布）vs user の ~/.claude/commands/（個人）——サンプル問題Q4はこの一択問題context: fork（隔離された子コンテキストで実行し、冗長な出力が本会話を汚さない）／allowed-tools（スキル実行中のツール制限＝破壊的操作の防止）／argument-hint（引数なし起動時に必要パラメータを促す）~/.claude/skills/ に別名の変種を作る（チームに影響させない）129本のスキル運用と rules/extension-layer-decision.md の6問フローチャート（「毎セッション必要→CLAUDE.md、オンデマンド手順→Skills」）が、まさに最後の選択基準の実装。rules/skill-tier.md（T0/T1/T2品質保証）は試験範囲外だが、スキル濫造を防ぐ運用として上位互換。
.claude/commands/（Q4。config.json方式は存在しない機能）context: fork で隔離が正解.claude/rules/ のYAML frontmatter に paths: ["**/*.test.*"] のようなglobパターンを書くと、該当ファイル編集時だけルールが発動し、無関係なコンテキスト消費を減らせる。paths frontmatter による条件付きルール読み込みの仕組みと、コンテキスト（トークン）節約効果paths: ["src/api/**/*"] でAPI規約、paths: ["**/*.test.*"] でテスト規約——場所でなくファイルの種類で規約を当てる2026-05の rules-optimization で path-scoped 化を実施済み（232行削減）。「常時ロードすべきか、パスで絞れるか」の判断を実際にやった経験がそのまま答案になる。ただし全rulesをpath化しても大きく減らなかった（3829→3804行）という限界も体験済み——「pathsは万能の圧縮ではなく、対象が明確なルールにだけ効く」という肌感は試験でも正しい。
rules/impact-assessment.md のリスク判定がこの上位互換：LOW→直接実装 / MEDIUM→/plan→/implement / HIGH・CRITICAL→/research→/plan→レビュー→/implement。試験の「complexity assessment」を、依存ファイル数とクリティカルパスで定量化した運用。Explore サブエージェントも日常使用。
インタビューパターンは rules/communication.md の「インタビュー形式（曖昧さが多いタスクで一問ずつ、アーキテクチャが変わる質問を優先）」として運用済み。テスト駆動は tdd-workflow スキル。「相互作用する問題は一括で」は、複数バグ修正依頼の日常運用と同じ。
claude -p "…"（--print＝非対話モード）が鉄則。対話待ちでジョブが永久にハングするのを防ぐ。構造化した結果が欲しければ --output-format json ＋ --json-schema。-p/--print：プロンプトを処理して結果をstdoutに出して終了する非対話モード（サンプル問題Q10。CLAUDE_HEADLESS環境変数や--batchフラグは存在しない機能として誤答に配置される）--output-format json ＋ --json-schema：CIでの機械可読な出力の強制→PRへの自動インラインコメント投稿などに使う「生成者と検証者を分ける」は rules/audit-independence.md（盲検・独立コンテキスト・Generator-Evaluator分離）の中核思想と完全一致。週次調査ルーチン（GitHub Actions）は headless 運用の実例。CLAUDE.md の「無人実行時は AskUserQuestion 禁止」ルールも同じ問題意識（対話待ちハング）。
-p（Q10）ユーザー階層（~/.claude/・個人にだけ効く・git共有されない）→ プロジェクト階層（リポジトリ内・チーム共有）→ ディレクトリ階層（サブフォルダ限定）。「誰に効かせたいか」で置き場所を決める。
CLAUDE.md から外部ファイルを参照して取り込む構文。モジュール化・選択的読み込みのための機能で、読み込んだ分のトークンは普通に消費する（圧縮ではない）。
トピック別ルールファイルの置き場。YAML frontmatter の paths: ["glob"] を書くと、一致するファイルを編集するときだけルールが読み込まれる（条件付きロード）。
SKILL.md frontmatter の3設定。fork=隔離コンテキストで実行（冗長出力が本会話を汚さない）、allowed-tools=スキル実行中のツール制限、argument-hint=引数なし起動時の入力促し。
実行前に読み取り専用で探索・設計し、計画を承認してから実装に移るモード。大規模・多ファイル・アーキテクチャ判断を含むタスク用。小さな明確な修正には過剰。
冗長なコードベース探索を隔離コンテキストで行い、要約だけを本会話に返す読み取り専用の子エージェント。長時間タスクのコンテキスト枯渇対策。
CI/CD用のCLIフラグ。-p=非対話モードで処理して終了（ハング防止）、--output-format json + --json-schema=構造化された機械可読出力の強制。
実装前にClaudeの側から設計上の質問を出させ、開発者が想定していない考慮点（キャッシュ無効化・障害モード等）を表面化させる手法。