npm - @k2works/claude-code-booster - Versions diffs - 6.3.1 → 6.4.0 - Mend

@k2works/claude-code-booster 6.3.1 → 6.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (292) hide show

package/lib/assets/docs/template//343/202/244/343/203/263/343/202/273/343/203/227/343/202/267/343/203/247/343/203/263/343/203/207/343/203/203/343/202/255.md CHANGED Viewed

@@ -1,22 +1,22 @@
----
-type: Template
-title: "インセプションデッキ"
-description: "インセプションデッキ（10 の問い）のテンプレート。"
-tags: [template]
-status: stable
-generated: { by: human:kakimomokuri, at: 2025-09-03T06:27:58Z }
----
-# インセプションデッキ
-- [ ] なぜやるのか？ 解決しようとしている問題を簡潔かつ明確に説明しよう。
-- [ ] どんなビジョンなのか？ 一つ目の問いに答えることで共有された問題を、提案されたソフトウェアシステムがどのように解決するかを簡潔に説明する。
-- [ ] どんな価値をもたらすのか？ プロジェクトのビジネス目標を一覧にする。
-- [ ] スコープの範囲はどこか？ 現状、スコープ内にあることが分かっている最も優先順位の高い機能要求を一覧にする。これは通常、必須科目となる。また、スコープ外のフィーチャ、スコープがまだ決まっていないアーキテクチャ上重要性を持つ機能も一覧にする。
-- [ ] 主なステークホルダーは？ 主なステークホルダーとその主な関心事を一覧にする。
-- [ ] 基本的な解決策はどのようなものになるか？ 概念的なアーキテクチャのスケッチを共有する。
-- [ ] 主なリスクは何か？（このプロジェクトが失敗するとしたら、どんな理由からか）
-- [ ] どのくらい作業があり、費用はいくらか？ スコープと概念上のアーキテクチャについて分かっていることから、作業を完了するのにかかるおよその作業量とコストを見積もる。チームサイズとスキルセットについて仮定したことをすべて一覧にする。
-- [ ] トレードオフにどう向き合うか？ 難しい判断を下すことになる前に、重要なトレードオフについて率直に話し合う。代表的な4つの要素「時間」「予算」「品質」「スコープ」について話そう。特に対立する可能性がある場合は、興味深い品質特性や優先順位の高い品質特性についても話し合おう。
-- [ ] 初回リリースが可能になるのはいつか？ ソフトウェアを提供するのにかかる期間の見込みをステークホルダーに伝える。この見積は、重要なマイルストーンについて会話を始める機会となる。分かっている作業のタイムラインのドラフトやプロジェクトスケジュールを作成する。スケジュールは完璧である必要はなく、プロジェクトが進むにつれて変更されるべきだ。
+---
+type: Template
+title: "インセプションデッキ"
+description: "インセプションデッキ（10 の問い）のテンプレート。"
+tags: [template]
+status: stable
+generated: { by: human:kakimomokuri, at: 2025-09-03T06:27:58Z }
+---
+# インセプションデッキ
+- [ ] なぜやるのか？ 解決しようとしている問題を簡潔かつ明確に説明しよう。
+- [ ] どんなビジョンなのか？ 一つ目の問いに答えることで共有された問題を、提案されたソフトウェアシステムがどのように解決するかを簡潔に説明する。
+- [ ] どんな価値をもたらすのか？ プロジェクトのビジネス目標を一覧にする。
+- [ ] スコープの範囲はどこか？ 現状、スコープ内にあることが分かっている最も優先順位の高い機能要求を一覧にする。これは通常、必須科目となる。また、スコープ外のフィーチャ、スコープがまだ決まっていないアーキテクチャ上重要性を持つ機能も一覧にする。
+- [ ] 主なステークホルダーは？ 主なステークホルダーとその主な関心事を一覧にする。
+- [ ] 基本的な解決策はどのようなものになるか？ 概念的なアーキテクチャのスケッチを共有する。
+- [ ] 主なリスクは何か？（このプロジェクトが失敗するとしたら、どんな理由からか）
+- [ ] どのくらい作業があり、費用はいくらか？ スコープと概念上のアーキテクチャについて分かっていることから、作業を完了するのにかかるおよその作業量とコストを見積もる。チームサイズとスキルセットについて仮定したことをすべて一覧にする。
+- [ ] トレードオフにどう向き合うか？ 難しい判断を下すことになる前に、重要なトレードオフについて率直に話し合う。代表的な4つの要素「時間」「予算」「品質」「スコープ」について話そう。特に対立する可能性がある場合は、興味深い品質特性や優先順位の高い品質特性についても話し合おう。
+- [ ] 初回リリースが可能になるのはいつか？ ソフトウェアを提供するのにかかる期間の見込みをステークホルダーに伝える。この見積は、重要なマイルストーンについて会話を始める機会となる。分かっている作業のタイムラインのドラフトやプロジェクトスケジュールを作成する。スケジュールは完璧である必要はなく、プロジェクトが進むにつれて変更されるべきだ。