@k2works/claude-code-booster 0.1.0

package/lib/assets/docs/assets/css/extra.css

@@ -0,0 +1,30 @@
+/* Custom styles for diagrams */
+
+/* Mermaid diagrams */
+.mermaid {
+    text-align: center;
+    margin: 20px 0;
+}
+
+/* PlantUML diagrams */
+.plantuml {
+    text-align: center;
+    margin: 20px 0;
+}
+
+/* General diagram container */
+.diagram-container {
+    background-color: #f8f8f8;
+    border-radius: 5px;
+    padding: 15px;
+    margin: 20px 0;
+    box-shadow: 0 2px 5px rgba(0,0,0,0.1);
+}
+
+/* Responsive diagrams */
+@media only screen and (max-width: 600px) {
+    .mermaid, .plantuml {
+        max-width: 100%;
+        overflow-x: auto;
+    }
+}

package/lib/assets/docs/assets/js/extra.js

@@ -0,0 +1,45 @@
+// Initialize Mermaid with custom configuration
+document.addEventListener('DOMContentLoaded', function() {
+    if (typeof mermaid !== 'undefined') {
+        mermaid.initialize({
+            startOnLoad: true,
+            theme: 'default',
+            securityLevel: 'loose',
+            flowchart: {
+                useMaxWidth: true,
+                htmlLabels: true,
+                curve: 'basis'
+            },
+            sequence: {
+                diagramMarginX: 50,
+                diagramMarginY: 10,
+                actorMargin: 50,
+                width: 150,
+                height: 65,
+                boxMargin: 10,
+                boxTextMargin: 5,
+                noteMargin: 10,
+                messageMargin: 35
+            }
+        });
+
+        // Force render any mermaid diagrams
+        setTimeout(function() {
+            mermaid.init(undefined, document.querySelectorAll('.mermaid'));
+        }, 1000);
+    } else {
+        console.error('Mermaid library not loaded');
+    }
+});
+
+// Add PlantUML image error handling
+document.addEventListener('DOMContentLoaded', function() {
+    const plantumlImages = document.querySelectorAll('.plantuml img');
+
+    plantumlImages.forEach(function(img) {
+        img.onerror = function() {
+            const container = img.parentElement;
+            container.innerHTML = '<div class="diagram-error">Error loading PlantUML diagram. Please check your syntax or server connection.</div>';
+        };
+    });
+});

package/lib/assets/docs/index.md

@@ -0,0 +1,13 @@
+# まずこれを読もうリスト
+
+- [コンテキスト図](./requirements/コンテキスト図.md) - 情勢をつかむ。
+- [インセプションデッキ](./requirements/インセプションデッキ.md) - プロジェクトの最初の週に作成された。ここにあるものの大部分は変更されたが、このドキュメントは我々がなぜこのシステムを構築しているかを示している。
+- [要件定義](./requirements/要件定義.md) - システムの全体的な要件をまとめる。プロジェクトの基盤となる重要なドキュメント。
+- [ユーザーストーリー](./requirements/ユーザーストーリー.md) - ユーザーの視点からシステムの要件をまとめる。ユーザーが何を求めているかを理解するために重要。
+- [ユースケース](./requirements/ユースケース.md) - システムの機能を表す。システムが何をするかを理解するのに必要。
+- [アーキテクチャドキュメント](./design/アーキテクチャ.md) - システムのアーキテクチャを示す。システムの全体像を把握するために重要。
+- [設計キュメント](./design) - システムの設計に関する詳細をまとめる。具体的な実装方法や技術選定を記録する。
+- [開発ドキュメント](./development) - 開発の具体的な手順やガイドラインをまとめる。
+- [運用ドキュメント](./operation) - システムの運用に関する情報を提供する。運用チームがシステムを管理するために必要。
+- [アーキテクチャ決定ログ](./adr) - システムのアーキテクチャに関する重要な決定を記録する。将来の参照や説明に役立つ。
+- [日誌](./journal) - 開発の進捗や問題点を記録する。開発の履歴を追うために重要。

package/lib/assets/docs/reference//343/202/210/343/201/204/343/202/275/343/203/225/343/203/210/343/202/246/343/202/247/343/202/242/343/201/250/343/201/257.md

@@ -0,0 +1,220 @@
+---
+title: よいソフトウェアとは
+description: 
+published: true
+date: 2025-06-27T09:48:46.154Z
+tags: 
+editor: markdown
+dateCreated: 2025-06-27T09:35:43.840Z
+---
+
+# よいソフトウェアとは
+
+## ソフトウェアの目的
+
+- 問題解決: 
+  - 単なる「動くプログラム」ではなく問題を解決するもの
+- 本質的な目的:
+  - ユーザーの問題解決: 課題や不便を解消
+  - ビジネス価値の創出: 組織やビジネスに利益をもたらす
+  - 効率化と自動化: 時間や労力を節約
+  - イノベーションの実現: 新しい体験や可能性を提供
+  
+## ソフトウェアの価値
+
+- 機能性: ユーザーの問題をちゃんと解決できるか
+- 使いやすさ: 優れた機能でも使いにくければ意味がない
+- 信頼性: 安定して動作するか
+- 保守性: 長期間にわたって改善・維持できるか
+
+## よいソフトウェアの必要十分条件
+
+変更を楽に安全にできて役に立つソフトウェアであることが必要十分条件である。
+変更を楽に安全にできて役に立つソフトウェアであればよいソフトウェアである。
+
+変更を楽に安全にできなくても役に立つソフトウェアはあるのではないか？
+
+## よいソフトウェアの内部要因と外部要因
+
+### 内部要因
+
+
+```plantuml
+@startuml
+title 内部要因
+
+folder "ビジネス" {
+  folder "チーム" {
+    folder "技術" {
+    }
+  }
+}
+@enduml
+```
+
+内部要因:自分でコントロールできる部分
+
+### 外部要因
+
+外部要因:自分でコントロールできない部分
+
+## だめなソフトウェア
+
+### へろへろスクラム
+
+へろへろスクラムが続くと、チームは疲弊し、顧客満足度は低下し、技術的負債が蓄積する。スクラムの名を借りた単なる「現代的な搾取システム」になりかねない。結局、アジャイルの見かけだけで本質を理解していないマネージャーの自己満足だけが残る。
+
+### 動作するきれいなゴミ
+
+技術的には完璧なソフトウェアのように見えるが、誰も使わないただのゴミ
+
+## よいソフトウェア
+
+本当に良いソフトウェアを作るには、以下のバランスが必要：
+
+1. 技術的な卓越性 - コードの品質、保守性、拡張性
+1. ビジネス価値 - 市場ニーズ、収益創出、競争優位性
+1. ユーザー中心設計 - 使いやすさ、問題解決力4. 健全なチーム文化 - 心理的安全性、自己組織化、継続的改善
+
+## よいソフトウェアを作るための規律
+
+### 規律とは
+
+> ”規律とは「本質的な部分」と「任意の部分」で構成される一連のルールである。”
+> Clean Craftsmanship　規律、基準、倫理 (アスキードワンゴ)
+
+本質的な部分・・・よいソフトウェアを作るパワーを与える
+任意の部分・・・よいソフトウェアを作るために従うプラクティス
+
+### ソフトウエア開発の3P(プリンシパル・パターン・プラクティス)
+
+- SOLID原則: 単一責任、開放閉鎖、リスコフの置換、インターフェース分離、依存性逆転
+- デザインパターン: 再利用可能な設計ソリューション
+- アーキテクチャパターン：ソフトウェアアーキテクチャで発生する問題の解決策
+- ドメイン駆動設計: ビジネスドメインに焦点を当てた設計
+- テスト駆動開発: テストを先に書いてから実装
+- 継続的デリバリー: 小さな変更を頻繁にリリース
+
+### サークルオブライフ
+
+```plantuml
+@startuml
+title 内部要因
+
+folder "ビジネス" {
+  object チーム全体
+  object 受入テスト
+  object 小さなリリース
+  object 計画ゲーム
+  folder "チーム" {
+    object 継続的インテグレーション
+    object 共同所有
+    object 持続可能なペース
+    object メタファー
+    folder "技術" {
+      object テスト駆動開発
+      object リファクタリング
+      object シンプルな設計
+      object ペアリング
+    }
+  }
+}
+@enduml
+```
+
+#### ビジネスプラクティス
+
+```plantuml
+@startuml
+title 内部要因
+
+folder "ビジネス" {
+  object チーム全体
+  object 受入テスト
+  object 小さなリリース
+  object 計画ゲーム
+  folder "チーム" {
+    folder "技術" {
+    }
+  }
+}
+@enduml
+```
+
+#### チームプラクティス
+
+```plantuml
+@startuml
+title 内部要因
+
+folder "ビジネス" {
+  folder "チーム" {
+    object 継続的インテグレーション
+    object 共同所有
+    object 持続可能なペース
+    object メタファー
+    folder "技術" {
+    }
+  }
+}
+@enduml
+```
+
+
+#### テクニカルプラクティス
+
+```plantuml
+@startuml
+title 内部要因
+
+folder "ビジネス" {
+  folder "チーム" {
+    folder "技術" {
+      object テスト駆動開発
+      object リファクタリング
+      object シンプルな設計
+      object ペアリング
+    }
+  }
+}
+@enduml
+```
+
+### 拡張サークルオブライフ
+
+```plantuml
+@startuml
+title 内部要因
+
+folder "ビジネス" {
+  object チーム全体
+  object 受入テスト
+  object 小さなリリース
+  object 計画ゲーム
+  folder "チーム" {
+    object 継続的インテグレーション
+    object 共同所有
+    object 持続可能なペース
+    object ドメイン駆動設計
+    object 戦略的設計
+    object 戦術的設計
+    object ユビキタス言語
+    folder "技術" {
+      object テスト駆動開発
+      object リファクタリング
+      object シンプルな設計
+      object ペアリング
+    }
+  }
+}
+@enduml
+```
+
+
+## 結論
+
+短期的には変更を楽に安全にできなくても役に立つソフトウェアを作ることはできる。
+しかし、時間の経過・外部環境の変化とともに変更を楽に安全にできないため役に立つソフトウェアでなくなる。
+変更を楽に安全にできて役に立つソフトウェアであることが必要十分条件である。
+上記の条件を満たし外部環境の変化に適応し続けるソフトウェアこそよいソフトウェアである。
+よって、良いソフトウェアとは変更を楽に安全にできて役に立つソフトウェアである。