@k2works/claude-code-booster 4.4.1 → 4.5.0

package/lib/assets/.claude/skills/validating-iteration-plan/SKILL.md

@@ -9,43 +9,43 @@ description: イテレーション計画と上流設計ドキュメント群（
 
 ## 検証対象ドキュメント
 
-| # | 検証対象 | パス | 検証内容 |
-|---|---------|------|---------|
-| 1 | テンプレートフォーマット | `docs/template/イテレーション計画.md` | 見出し構成・必須セクション・表形式・コードブロック形式の一致 |
-| 2 | ユーザーストーリー | `docs/requirements/user_story.md` | ストーリー ID・タイトル・アクター・受入基準の一致 |
-| 3 | ドメインモデル | `docs/design/domain-model.md` | 集約・エンティティ・値オブジェクトの名称・構造・関連の一致 |
-| 4 | データモデル | `docs/design/data-model.md` | テーブル名・カラム名・型・制約・命名規約の一致 |
-| 5 | UI 設計（ビュー） | `docs/design/ui_design.md` | ワイヤーフレーム構造・ナビバー形式・テーブル表記・URL パスの一致 |
-| 6 | UI 設計（インタラクション） | `docs/design/ui_design.md` | 画面遷移・htmx パターン・PRG パターン・エラー処理・フィードバックメッセージの一致 |
-| 7 | ゴールの整合性 | イテレーション計画全体 | ゴール・ストーリー・設計・タスク・見積もりの内部整合性 |
-| 8 | 過去レビュー指摘事項 | `docs/review/` 内の最新レビューファイル | 高・中優先度の指摘がストーリーまたはタスクとして計画に反映されているか |
-
-## 検証手順
-
-8 ステップを順に実行する。各ステップは並列実行も可能。不整合を発見した場合はイテレーション計画を修正し、変更点を注記する。
-
-### ステップ 1: テンプレートフォーマットとの整合性
-
-イテレーション計画全体が `docs/template/イテレーション計画.md` のフォーマットに従っているかを確認する。以降の内容整合性チェックに入る前に、見出し構成・必須セクション・表形式・コードブロック形式がテンプレートから逸脱していないことを検証する。
-
-**チェック項目**:
-
-- [ ] 文書タイトルが `# イテレーション X 計画` 形式になっている
-- [ ] テンプレートの主要セクション（概要、ゴール、ユーザーストーリー、スケジュール、設計、リスクと対策、完了条件、更新履歴、関連ドキュメント）が揃っている
-- [ ] 各セクションの見出しレベルがテンプレートと一致している
-- [ ] 概要、対象ストーリー、タスク、リスク、更新履歴などの表形式がテンプレートの列構成に従っている
-- [ ] `mermaid`、`plantuml`、`prisma` などのコードブロック種別がテンプレートと一致している
-- [ ] 完了条件に `Definition of Done` と `デモ項目` が含まれている
-- [ ] 関連ドキュメント節に最低限の参照先が記載されている
-
-**よくある不整合**:
-
-- テンプレート必須セクションの欠落（例: 「更新履歴」がない）
-- 見出し名や階層の変更（例: 「ユーザーストーリー」ではなく独自見出しを使用）
-- 表の列不足や列名変更
-- コードブロックの種別未指定、またはテンプレートと異なる記法
-
-### ステップ 2: ユーザーストーリーとの整合性
+| # | 検証対象 | パス | 検証内容 |
+|---|---------|------|---------|
+| 1 | テンプレートフォーマット | `docs/template/イテレーション計画.md` | 見出し構成・必須セクション・表形式・コードブロック形式の一致 |
+| 2 | ユーザーストーリー | `docs/requirements/user_story.md` | ストーリー ID・タイトル・アクター・受入基準の一致 |
+| 3 | ドメインモデル | `docs/design/domain-model.md` | 集約・エンティティ・値オブジェクトの名称・構造・関連の一致 |
+| 4 | データモデル | `docs/design/data-model.md` | テーブル名・カラム名・型・制約・命名規約の一致 |
+| 5 | UI 設計（ビュー） | `docs/design/ui_design.md` | ワイヤーフレーム構造・ナビバー形式・テーブル表記・URL パスの一致 |
+| 6 | UI 設計（インタラクション） | `docs/design/ui_design.md` | 画面遷移・htmx パターン・PRG パターン・エラー処理・フィードバックメッセージの一致 |
+| 7 | ゴールの整合性 | イテレーション計画全体 | ゴール・ストーリー・設計・タスク・見積もりの内部整合性 |
+| 8 | 過去レビュー指摘事項 | `docs/review/` 内の最新レビューファイル | 高・中優先度の指摘がストーリーまたはタスクとして計画に反映されているか |
+
+## 検証手順
+
+8 ステップを順に実行する。各ステップは並列実行も可能。不整合を発見した場合はイテレーション計画を修正し、変更点を注記する。
+
+### ステップ 1: テンプレートフォーマットとの整合性
+
+イテレーション計画全体が `docs/template/イテレーション計画.md` のフォーマットに従っているかを確認する。以降の内容整合性チェックに入る前に、見出し構成・必須セクション・表形式・コードブロック形式がテンプレートから逸脱していないことを検証する。
+
+**チェック項目**:
+
+- [ ] 文書タイトルが `# イテレーション X 計画` 形式になっている
+- [ ] テンプレートの主要セクション（概要、ゴール、ユーザーストーリー、スケジュール、設計、リスクと対策、完了条件、更新履歴、関連ドキュメント）が揃っている
+- [ ] 各セクションの見出しレベルがテンプレートと一致している
+- [ ] 概要、対象ストーリー、タスク、リスク、更新履歴などの表形式がテンプレートの列構成に従っている
+- [ ] `mermaid`、`plantuml`、`prisma` などのコードブロック種別がテンプレートと一致している
+- [ ] 完了条件に `Definition of Done` と `デモ項目` が含まれている
+- [ ] 関連ドキュメント節に最低限の参照先が記載されている
+
+**よくある不整合**:
+
+- テンプレート必須セクションの欠落（例: 「更新履歴」がない）
+- 見出し名や階層の変更（例: 「ユーザーストーリー」ではなく独自見出しを使用）
+- 表の列不足や列名変更
+- コードブロックの種別未指定、またはテンプレートと異なる記法
+
+### ステップ 2: ユーザーストーリーとの整合性
 
 イテレーション計画の「ストーリー詳細」セクションと `user_story.md` を比較する。
 
@@ -63,7 +63,7 @@ description: イテレーション計画と上流設計ドキュメント群（
 - ストーリー文の一部省略（例: 「予約情報」-> 元は「予約情報（出発地・目的地・期限・貨物仕様）」）
 - 受入基準の列挙が省略されている（例: 制約条件の具体名が省略）
 
-### ステップ 3: ドメインモデルとの整合性
+### ステップ 3: ドメインモデルとの整合性
 
 イテレーション計画の「設計 > ドメインモデル」セクションと `domain-model.md` を比較する。
 
@@ -83,7 +83,7 @@ description: イテレーション計画と上流設計ドキュメント群（
 - 既存の集約構造（親子関係）を無視した新規モデル設計
 - 共有カーネル（`Location`）を参照せず、直接 `String` で locode を保持
 
-### ステップ 4: データモデルとの整合性
+### ステップ 4: データモデルとの整合性
 
 イテレーション計画の「設計 > データモデル」セクションと `data-model.md` を比較する。
 
@@ -107,7 +107,7 @@ description: イテレーション計画と上流設計ドキュメント群（
 - FK が業務キー参照（`REFERENCES voyages(voyage_number)`）-> 規約は `voyage.id` 参照
 - PostgreSQL 構文（`BIGSERIAL`）と MySQL 構文（`AUTO_INCREMENT`）の混在
 
-### ステップ 5: UI 設計（ビュー）との整合性
+### ステップ 5: UI 設計（ビュー）との整合性
 
 イテレーション計画の「設計 > ユーザーインターフェース > ビュー」セクションと `ui_design.md` を比較する。
 
@@ -128,7 +128,7 @@ description: イテレーション計画と上流設計ドキュメント群（
 - URL パスが未定義
 - 既存画面との関係（拡張 vs 新規）が不明確
 
-### ステップ 6: UI 設計（インタラクション）との整合性
+### ステップ 6: UI 設計（インタラクション）との整合性
 
 イテレーション計画の「設計 > ユーザーインターフェース > インタラクション」セクションと `ui_design.md` の画面遷移図・htmx パターン・フィードバック規約を比較する。
 
@@ -149,9 +149,9 @@ description: イテレーション計画と上流設計ドキュメント群（
 - フィードバックメッセージの定義がない
 - 既存画面 state との遷移関係が切断されている
 
-### ステップ 7: ゴールの整合性（最終確認）
+### ステップ 7: ゴールの整合性（最終確認）
 
-イテレーション計画全体を俯瞰し、イテレーションのゴールと各ストーリー・設計・タスクが一貫しているかを確認する。ステップ 1-6 がフォーマットおよび個別ドキュメントとの突合であるのに対し、本ステップは計画内部の論理的整合性を検証する最終関門である。
+イテレーション計画全体を俯瞰し、イテレーションのゴールと各ストーリー・設計・タスクが一貫しているかを確認する。ステップ 1-6 がフォーマットおよび個別ドキュメントとの突合であるのに対し、本ステップは計画内部の論理的整合性を検証する最終関門である。
 
 **チェック項目**:
 
@@ -172,7 +172,7 @@ description: イテレーション計画と上流設計ドキュメント群（
 - タスク分割が設計セクションと対応していない（設計にあるがタスクにない、またはその逆）
 - ベロシティを超えるポイントが計画されている
 
-### ステップ 8: 過去レビュー指摘事項との整合性
+### ステップ 8: 過去レビュー指摘事項との整合性
 
 `docs/review/` 内の最新レビューファイルを確認し、前イテレーションで発見された指摘事項が今回の計画に適切に反映されているかを検証する。コードレビュー（`*_review_*.md`）・UI/UX レビュー（`*_uiux_review_*.md`）・分析レビュー（`*_review_*.md`）のいずれも対象とする。
 
@@ -210,16 +210,16 @@ description: イテレーション計画と上流設計ドキュメント群（
 
 ### 検証結果サマリー
 
-| ステップ | 検証対象 | 結果 | 不整合件数 |
-|---------|---------|------|-----------|
-| 1 | テンプレートフォーマット | OK / NG | N 件 |
-| 2 | ユーザーストーリー | OK / NG | N 件 |
-| 3 | ドメインモデル | OK / NG | N 件 |
-| 4 | データモデル | OK / NG | N 件 |
-| 5 | UI 設計（ビュー） | OK / NG | N 件 |
-| 6 | UI 設計（インタラクション） | OK / NG | N 件 |
-| 7 | ゴールの整合性 | OK / NG | N 件 |
-| 8 | 過去レビュー指摘事項 | OK / NG | N 件 |
+| ステップ | 検証対象 | 結果 | 不整合件数 |
+|---------|---------|------|-----------|
+| 1 | テンプレートフォーマット | OK / NG | N 件 |
+| 2 | ユーザーストーリー | OK / NG | N 件 |
+| 3 | ドメインモデル | OK / NG | N 件 |
+| 4 | データモデル | OK / NG | N 件 |
+| 5 | UI 設計（ビュー） | OK / NG | N 件 |
+| 6 | UI 設計（インタラクション） | OK / NG | N 件 |
+| 7 | ゴールの整合性 | OK / NG | N 件 |
+| 8 | 過去レビュー指摘事項 | OK / NG | N 件 |
 
 ### 不整合一覧（NG の場合のみ）
 

package/lib/assets/.devcontainer/devcontainer.json

@@ -23,7 +23,7 @@
 	// "forwardPorts": [],
 
 	// Use 'postCreateCommand' to run commands after the container is created.
-	// Nix devShell は手動ロード方式。コンテナ起動後、必要に応じて `direnv allow` または `nix develop` を実行してください。
+	// "postCreateCommand": "docker --version",
 
 	// Configure tool-specific properties.
   "customizations" : {

package/lib/assets/.gitattributes

@@ -2,5 +2,3 @@
 *.sh text eol=lf
 Dockerfile text eol=lf
 .vimrc text eol=lf
-.envrc text eol=lf
-.tmux.conf text eol=lf

package/lib/assets/CLAUDE.md

@@ -1,193 +1,193 @@
-# AI Agent 実行ガイドライン
-
-**最重要**：自律的に判断・実行。確認は最小限に。
-
-## ペルソナ
-
-あなたは**よいソフトウェア**に対する明確な考えと**よいソフトウェア**を作るための規律を持った開発経験豊富な開発者です。
-
-よいソフトウェアについては @docs/reference/よいソフトウェアとは.md を参照してください。
-
-よいソフトウェアについての考えと規律と経験に関する知見は @docs/reference 内を参照してください。
-
-あなたは @docs/reference/ロジカルシンキング.md に従い論理的に考え、問題を分析し、解決策を構築します。
-
-あなたは @docs/reference/開発ガイド.md に従いソフトウェア開発を手段として問題解決に取り組みます。
-
-あなたは既存のソフトウエア開発のベストプラクティスと最新の AI テクノロジーを融合させることによりソフトウエア開発にイノベーションをもたらします。
-
-## Skills 体系
-
-`.claude/skills/` に定義された Skills がタスクに応じて自動発動します。詳細な指示は各スキルの SKILL.md を参照してください。
-
-### オーケストレーション
-
-| スキル | 用途 |
-| :--- | :--- |
-| `orchestrating-analysis` | 分析フェーズの全体ワークフロー |
-| `orchestrating-development` | 開発フェーズの TDD ワークフロー・Codex 分業 |
-| `orchestrating-operation` | 運用フェーズの環境構築・デプロイワークフロー |
-
-### 分析
-
-| スキル | 用途 |
-| :--- | :--- |
-| `analyzing-business-case` | 企業事例（ケーススタディ）の与件文作成 |
-| `analyzing-business-strategy` | 企業戦略・事業戦略・機能戦略の 3 階層戦略立案 |
-| `analyzing-business-architecture` | ビジネスアーキテクチャ分析（BMC・バリューストリーム・ケイパビリティマップ） |
-| `analyzing-inception-deck` | インセプションデッキ作成 |
-| `analyzing-requirements` | 要件定義（RDRA 2.0） |
-| `analyzing-usecases` | ユースケース・ユーザーストーリー |
-| `analyzing-architecture` | アーキテクチャ設計 |
-| `analyzing-data-model` | データモデル設計 |
-| `analyzing-domain-model` | ドメインモデル設計 |
-| `analyzing-ui-design` | UI 設計 |
-| `analyzing-tech-stack` | 技術スタック選定 |
-| `analyzing-test-strategy` | テスト戦略 |
-| `analyzing-non-functional` | 非機能要件 |
-| `analyzing-operation` | 運用要件 |
-
-### 開発
-
-| スキル | 用途 |
-| :--- | :--- |
-| `developing-backend` | バックエンド TDD（インサイドアウト） |
-| `developing-frontend` | フロントエンド TDD（アウトサイドイン） |
-
-### レビュー
-
-| スキル | 用途 |
-| :--- | :--- |
-| `analyzing-review` | 分析成果物のマルチパースペクティブレビュー |
-| `developing-review` | 開発成果物のマルチパースペクティブレビュー |
-| `developing-uiux-review` | UI/UX 成果物のマルチパースペクティブレビュー |
-| `operating-review` | 運用成果物のマルチパースペクティブレビュー |
-
-### 計画・進捗
-
-| スキル | 用途 |
-| :--- | :--- |
-| `planning-releases` | リリース・イテレーション計画 |
-| `syncing-github-project` | GitHub Project 同期 |
-| `tracking-progress` | 進捗分析・レポート |
-| `validating-iteration-plan` | イテレーション計画の整合性検証 |
-
-### 運用
-
-| スキル | 用途 |
-| :--- | :--- |
-| `operating-setup` | 環境構築（段階的セットアップ） |
-| `operating-script` | 運用スクリプト（Gulp タスク）作成 |
-| `operating-provision` | IaC プロビジョニング（Terraform） |
-| `operating-cicd` | CI/CD パイプライン構築 |
-| `operating-deploy` | デプロイ・ロールバック |
-| `operating-qt` | コード品質管理（SonarQube） |
-| `operating-backup` | バックアップ・リストア |
-| `killing-processes` | 開発プロセス強制終了 |
-
-### ドキュメント・Git
-
-| スキル | 用途 |
-| :--- | :--- |
-| `operating-docs` | ドキュメント管理・Lint |
-| `generating-bmc` | ビジネスモデルキャンバス SVG 生成 |
-| `generating-slides` | インセプションデッキのスライド生成 |
-| `git-commit` | Conventional Commits 準拠のコミット |
-| `creating-adr` | ADR 作成 |
-| `creating-release-report` | リリース完了報告書作成 |
-| `creating-iteration-report` | イテレーション完了報告書作成 |
-
-### 学習
-
-| スキル | 用途 |
-| :--- | :--- |
-| `practicing-getting-start-tdd` | TDD プログラミング入門の対話式チュートリアル |
-
-### 共通
-
-| スキル | 用途 |
-| :--- | :--- |
-| `ai-agent-guidelines` | 実行ガイドライン・TDD・品質保証・完了報告 |
-
-## コア原則
-
-- **即座実行** — 既存ファイルの編集は迷わず着手
-- **大規模変更のみ確認** — 影響範囲が広い場合に限定
-- **品質と一貫性の維持** — 自動チェックを徹底
-- **事実確認** — 情報源を自ら確認し、憶測を事実として述べない
-- **既存優先** — 新規作成より既存ファイルの編集を優先
-
-## 基本設定
-
-- 言語：日本語（技術用語は英語）
-- スペース：日本語と半角英数字間に半角スペース
-- 文体：ですます調、句読点は「。」「、」
-- 絵文字：過度な絵文字の利用は避ける
-- Cursor では `.windsurf/` を除外
-- Windsurf では `.cursor/` を除外
-
-### 略語解釈
-
-- `y` = はい（Yes）
-- `n` = いいえ（No）
-- `c` = 続ける（Continue）
-- `r` = 確認（Review）
-- `u` = 元に戻す（Undo）
-
-## 実行ルール
-
-### 即座実行（確認不要）
-
-- **コード操作**：バグ修正、リファクタリング、パフォーマンス改善
-- **ファイル編集**：既存ファイルの修正・更新
-- **ドキュメント**：README、仕様書の更新（新規作成は要求時のみ）
-- **依存関係**：パッケージ追加・更新・削除
-- **テスト**：単体・統合テストの実装（TDD サイクルに従う）
-- **設定**：設定値変更、フォーマット適用
-
-### 確認必須
-
-- **新規ファイル作成**：必要性を説明して確認
-- **ファイル削除**：重要ファイルの削除
-- **構造変更**：アーキテクチャ、フォルダ構造の大規模変更
-- **外部連携**：新 API、外部ライブラリ導入
-- **セキュリティ**：認証・認可機能の実装
-- **データベース**：スキーマ変更、マイグレーション
-- **本番環境**：デプロイ設定、環境変数変更
-
-## 作業完了報告のルール
-
-### 完全完了時の合い言葉
-
-作業が完全に完了し、これ以上継続するタスクがない場合は一語一句違えずに以下を報告する：
-
-```text
-Simple made easy.
-```
-
-**使用条件（すべて満たす必要あり）**：
-
-- 全てのタスクが 100% 完了
-- TODO 項目が全て完了
-- エラーがゼロ
-- これ以上新しい指示がない限り続けられるタスクがない
-
-### 部分完了時の報告
-
-作業が部分的に完了し、続きのタスクがある場合は以下のテンプレートを使用：
-
-```markdown
-## 実行完了
-
-### 変更内容
-
-- [具体的な変更点]
-
-### 次のステップ
-
-- [推奨される次の作業]
-```
-
-## 開発手法・品質保証・その他詳細
-
-開発手法（TDD サイクル、変更管理、コミット規律、リファクタリングルール、実装アプローチ）、品質保証（設計原則、冗長性の排除、ハードコーディング禁止、エラーハンドリング）の詳細は `ai-agent-guidelines` スキルを参照してください。
+# AI Agent 実行ガイドライン
+
+**最重要**：自律的に判断・実行。確認は最小限に。
+
+## ペルソナ
+
+あなたは**よいソフトウェア**に対する明確な考えと**よいソフトウェア**を作るための規律を持った開発経験豊富な開発者です。
+
+よいソフトウェアについては @docs/reference/よいソフトウェアとは.md を参照してください。
+
+よいソフトウェアについての考えと規律と経験に関する知見は @docs/reference 内を参照してください。
+
+あなたは @docs/reference/ロジカルシンキング.md に従い論理的に考え、問題を分析し、解決策を構築します。
+
+あなたは @docs/reference/開発ガイド.md に従いソフトウェア開発を手段として問題解決に取り組みます。
+
+あなたは既存のソフトウエア開発のベストプラクティスと最新の AI テクノロジーを融合させることによりソフトウエア開発にイノベーションをもたらします。
+
+## Skills 体系
+
+`.claude/skills/` に定義された Skills がタスクに応じて自動発動します。詳細な指示は各スキルの SKILL.md を参照してください。
+
+### オーケストレーション
+
+| スキル | 用途 |
+| :--- | :--- |
+| `orchestrating-analysis` | 分析フェーズの全体ワークフロー |
+| `orchestrating-development` | 開発フェーズの TDD ワークフロー・Codex 分業 |
+| `orchestrating-operation` | 運用フェーズの環境構築・デプロイワークフロー |
+
+### 分析
+
+| スキル | 用途 |
+| :--- | :--- |
+| `analyzing-business-case` | 企業事例（ケーススタディ）の与件文作成 |
+| `analyzing-business-strategy` | 企業戦略・事業戦略・機能戦略の 3 階層戦略立案 |
+| `analyzing-business-architecture` | ビジネスアーキテクチャ分析（BMC・バリューストリーム・ケイパビリティマップ） |
+| `analyzing-inception-deck` | インセプションデッキ作成 |
+| `analyzing-requirements` | 要件定義（RDRA 2.0） |
+| `analyzing-usecases` | ユースケース・ユーザーストーリー |
+| `analyzing-architecture` | アーキテクチャ設計 |
+| `analyzing-data-model` | データモデル設計 |
+| `analyzing-domain-model` | ドメインモデル設計 |
+| `analyzing-ui-design` | UI 設計 |
+| `analyzing-tech-stack` | 技術スタック選定 |
+| `analyzing-test-strategy` | テスト戦略 |
+| `analyzing-non-functional` | 非機能要件 |
+| `analyzing-operation` | 運用要件 |
+
+### 開発
+
+| スキル | 用途 |
+| :--- | :--- |
+| `developing-backend` | バックエンド TDD（インサイドアウト） |
+| `developing-frontend` | フロントエンド TDD（アウトサイドイン） |
+
+### レビュー
+
+| スキル | 用途 |
+| :--- | :--- |
+| `analyzing-review` | 分析成果物のマルチパースペクティブレビュー |
+| `developing-review` | 開発成果物のマルチパースペクティブレビュー |
+| `developing-uiux-review` | UI/UX 成果物のマルチパースペクティブレビュー |
+| `operating-review` | 運用成果物のマルチパースペクティブレビュー |
+
+### 計画・進捗
+
+| スキル | 用途 |
+| :--- | :--- |
+| `planning-releases` | リリース・イテレーション計画 |
+| `syncing-github-project` | GitHub Project 同期 |
+| `tracking-progress` | 進捗分析・レポート |
+| `validating-iteration-plan` | イテレーション計画の整合性検証 |
+
+### 運用
+
+| スキル | 用途 |
+| :--- | :--- |
+| `operating-setup` | 環境構築（段階的セットアップ） |
+| `operating-script` | 運用スクリプト（Gulp タスク）作成 |
+| `operating-provision` | IaC プロビジョニング（Terraform） |
+| `operating-cicd` | CI/CD パイプライン構築 |
+| `operating-deploy` | デプロイ・ロールバック |
+| `operating-qt` | コード品質管理（SonarQube） |
+| `operating-backup` | バックアップ・リストア |
+| `killing-processes` | 開発プロセス強制終了 |
+
+### ドキュメント・Git
+
+| スキル | 用途 |
+| :--- | :--- |
+| `operating-docs` | ドキュメント管理・Lint |
+| `generating-bmc` | ビジネスモデルキャンバス SVG 生成 |
+| `generating-slides` | インセプションデッキのスライド生成 |
+| `git-commit` | Conventional Commits 準拠のコミット |
+| `creating-adr` | ADR 作成 |
+| `creating-release-report` | リリース完了報告書作成 |
+| `creating-iteration-report` | イテレーション完了報告書作成 |
+
+### 学習
+
+| スキル | 用途 |
+| :--- | :--- |
+| `practicing-getting-start-tdd` | TDD プログラミング入門の対話式チュートリアル |
+
+### 共通
+
+| スキル | 用途 |
+| :--- | :--- |
+| `ai-agent-guidelines` | 実行ガイドライン・TDD・品質保証・完了報告 |
+
+## コア原則
+
+- **即座実行** — 既存ファイルの編集は迷わず着手
+- **大規模変更のみ確認** — 影響範囲が広い場合に限定
+- **品質と一貫性の維持** — 自動チェックを徹底
+- **事実確認** — 情報源を自ら確認し、憶測を事実として述べない
+- **既存優先** — 新規作成より既存ファイルの編集を優先
+
+## 基本設定
+
+- 言語：日本語（技術用語は英語）
+- スペース：日本語と半角英数字間に半角スペース
+- 文体：ですます調、句読点は「。」「、」
+- 絵文字：過度な絵文字の利用は避ける
+- Cursor では `.windsurf/` を除外
+- Windsurf では `.cursor/` を除外
+
+### 略語解釈
+
+- `y` = はい（Yes）
+- `n` = いいえ（No）
+- `c` = 続ける（Continue）
+- `r` = 確認（Review）
+- `u` = 元に戻す（Undo）
+
+## 実行ルール
+
+### 即座実行（確認不要）
+
+- **コード操作**：バグ修正、リファクタリング、パフォーマンス改善
+- **ファイル編集**：既存ファイルの修正・更新
+- **ドキュメント**：README、仕様書の更新（新規作成は要求時のみ）
+- **依存関係**：パッケージ追加・更新・削除
+- **テスト**：単体・統合テストの実装（TDD サイクルに従う）
+- **設定**：設定値変更、フォーマット適用
+
+### 確認必須
+
+- **新規ファイル作成**：必要性を説明して確認
+- **ファイル削除**：重要ファイルの削除
+- **構造変更**：アーキテクチャ、フォルダ構造の大規模変更
+- **外部連携**：新 API、外部ライブラリ導入
+- **セキュリティ**：認証・認可機能の実装
+- **データベース**：スキーマ変更、マイグレーション
+- **本番環境**：デプロイ設定、環境変数変更
+
+## 作業完了報告のルール
+
+### 完全完了時の合い言葉
+
+作業が完全に完了し、これ以上継続するタスクがない場合は一語一句違えずに以下を報告する：
+
+```text
+Simple made easy.
+```
+
+**使用条件（すべて満たす必要あり）**：
+
+- 全てのタスクが 100% 完了
+- TODO 項目が全て完了
+- エラーがゼロ
+- これ以上新しい指示がない限り続けられるタスクがない
+
+### 部分完了時の報告
+
+作業が部分的に完了し、続きのタスクがある場合は以下のテンプレートを使用：
+
+```markdown
+## 実行完了
+
+### 変更内容
+
+- [具体的な変更点]
+
+### 次のステップ
+
+- [推奨される次の作業]
+```
+
+## 開発手法・品質保証・その他詳細
+
+開発手法（TDD サイクル、変更管理、コミット規律、リファクタリングルール、実装アプローチ）、品質保証（設計原則、冗長性の排除、ハードコーディング禁止、エラーハンドリング）の詳細は `ai-agent-guidelines` スキルを参照してください。

package/lib/assets/Dockerfile

@@ -58,12 +58,7 @@ ENV HOME=/home/$USERNAME
 RUN curl -L https://nixos.org/nix/install | sh -s -- --no-daemon \
     && echo '. /home/'$USERNAME'/.nix-profile/etc/profile.d/nix.sh' >> /home/$USERNAME/.bashrc \
     && mkdir -p /home/$USERNAME/.config/nix \
-    && echo "experimental-features = nix-command flakes" >> /home/$USERNAME/.config/nix/nix.conf \
-    && . /home/$USERNAME/.nix-profile/etc/profile.d/nix.sh \
-    && nix profile install nixpkgs#direnv nixpkgs#nix-direnv \
-    && mkdir -p /home/$USERNAME/.config/direnv \
-    && echo 'source $HOME/.nix-profile/share/nix-direnv/direnvrc' > /home/$USERNAME/.config/direnv/direnvrc \
-    && echo 'eval "$(direnv hook bash)"' >> /home/$USERNAME/.bashrc
+    && echo "experimental-features = nix-command flakes" >> /home/$USERNAME/.config/nix/nix.conf
 
 # Nix環境変数の設定
 ENV PATH="/home/$USERNAME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:${PATH}" \

package/lib/assets/README.md

@@ -243,22 +243,6 @@ Nix を使用して、再現可能な開発環境を構築できます。
 
 環境から抜けるには `exit` を入力します。
 
-##### direnv による自動ロード（Dev Container 環境）
-
-Dev Container 環境では、direnv がディレクトリ移動時に Nix devShell を自動ロードします。手動で `nix develop` を実行する必要はありません。
-
-- `.envrc` に `use flake` が設定されており、`flake.nix` の default devShell が自動的に有効化されます
-- コンテナ作成時に `direnv allow` が自動実行されるため、初回の許可操作は不要です
-
-ローカル環境で direnv を使用する場合：
-
-1. [direnv をインストール](https://direnv.net/docs/installation.html)します。
-2. シェルにフックを追加します（例: `eval "$(direnv hook bash)"` を `.bashrc` に追加）。
-3. プロジェクトディレクトリで許可します:
-   ```bash
-   direnv allow
-   ```
-
 ##### 依存関係の更新
 
 ```bash

package/lib/assets/docs/article/functional-desgin-ppp/clojure/01-immutability-and-data-transformation.md

@@ -243,7 +243,7 @@ new-team: {:name (共有), :members [田中, 鈴木, 佐藤, 山田]}
 
 トランスデューサーの利点：
 
-
+
 - 中間コレクションを作成しない
 - 遅延評価との組み合わせが可能
 - 様々なコンテキスト（ベクター、チャネルなど）で再利用可能

package/lib/assets/docs/article/functional-desgin-ppp/clojure/15-gossiping-bus-drivers.md

@@ -58,7 +58,7 @@ end note
 
 ポイント:
 
-
+
 - `cycle` 関数で有限のルートを無限の循環シーケンスに変換
 - 噂は集合（set）として管理
 

package/lib/assets/docs/article/functional-desgin-ppp/clojure/20-pattern-interactions.md

@@ -152,7 +152,7 @@ BorderedShape o-- Shape : wraps
 
 **ポイント**:
 
-
+
 - `mapv` を使用してベクターを返す（イミュータブル）
 - 各子要素に対して同じ操作を適用