golem15/msd-core
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: hard-fork GSD -> MSD (Make Software Done)

Browse Source 
Mechanical rename produced by scripts/msd-rename.cjs: gsd/Gsd/GSD -> msd/Msd/MSD
across contents and paths, upstream package/repo coordinates -> @golem15/msd-core
and golem15com/msd-core. Deep links into upstream history, sibling upstream
packages, the GSD-2 import feature, CHANGELOG.md and .changeset/ are kept as-is.

Hand edits on top: MSD block-letter banner and logos, LICENSE copyright line,
package/plugin identity, regenerated lockfile, install-tree fixtures, derived
registries and benchmark baseline; migration checksum baseline re-locked
(MSD keeps its own install state, so no install had applied the old sums);
sort-order and regex-escaped expectations in tests adjusted.
This commit is contained in:
Jakub Zych
2026-10-06 01:47:40 +02:00
parent fe069b2a56
commit a9a7a328e6
2763 changed files with 78465 additions and 78434 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
docs/ja-JP/tutorials/onboarding-an-existing-codebase.md
View File

@@ -1,12 +1,12 @@
# 既存コードベースのオンボーディング
このチュートリアルでは、すでにコードが存在するリポジトリに GSD Core を導入します。コードベースをマッピングし、*追加する*内容を説明するプロジェクトを作成して、小さな変更に対して最初の議論・計画サイクルを実行します。最終的に、GSD Core の計画パイプラインがあなたのスタック、規約、懸念事項を把握し、計画するたびにその知識を活用できる状態になります。
このチュートリアルでは、すでにコードが存在するリポジトリに MSD Core を導入します。コードベースをマッピングし、*追加する*内容を説明するプロジェクトを作成して、小さな変更に対して最初の議論・計画サイクルを実行します。最終的に、MSD Core の計画パイプラインがあなたのスタック、規約、懸念事項を把握し、計画するたびにその知識を活用できる状態になります。
---
## 作るもの
既存の Express アプリケーションに `GET /health` エンドポイントを1つ追加します。変更は小さく、本来のレッスン — GSD Core が計画前にコードベースを学習する仕組み — から注意がそれることはありません。
既存の Express アプリケーションに `GET /health` エンドポイントを1つ追加します。変更は小さく、本来のレッスン — MSD Core が計画前にコードベースを学習する仕組み — から注意がそれることはありません。
---
@@ -18,12 +18,12 @@
---
## ステップ 1 — GSD Core のインストール
## ステップ 1 — MSD Core のインストール
リポジトリのルートで以下を実行します:
```bash
npx @opengsd/gsd-core@latest
npx @golem15/msd-core@latest
```
プロンプトが表示されたら **Claude Code** と **local** を選択してください。以下が表示されます:
@@ -31,7 +31,7 @@ npx @opengsd/gsd-core@latest
```text
✓ Installed 86 skills to .claude/commands/
✓ Installed agents to .claude/agents/
✓ GSD Core ready — run /gsd-new-project to start
✓ MSD Core ready — run /msd-new-project to start
```
---
@@ -44,7 +44,7 @@ claude --dangerously-skip-permissions
> [!CAUTION]
> **The permissions flag is optional.** It skips per-file confirmation while
> GSD's sub-agents read and write files. Use it only in low-stakes or
> MSD's sub-agents read and write files. Use it only in low-stakes or
> throwaway contexts. To keep confirmations enabled, start with `claude` instead.
> For real work, read the [security model](../explanation/security-model.md) first.
@@ -53,13 +53,13 @@ claude --dangerously-skip-permissions
## ステップ 3 — Brownfield オンボーディングの開始
プロジェクトを作成する前に、GSD Core にリポジトリ状態を確認させ、安全な次のトップレベルコマンドを表示させます。これにより、コードベースコンテキストの取りこぼしや既存 planning ファイルの上書きを防げます。
プロジェクトを作成する前に、MSD Core にリポジトリ状態を確認させ、安全な次のトップレベルコマンドを表示させます。これにより、コードベースコンテキストの取りこぼしや既存 planning ファイルの上書きを防げます。
```text
/gsd-onboard
/msd-onboard
```
オンボーディングがコードベースマップ不足を示したら、推奨オプションを選び、表示された `/gsd-map-codebase` ハンドオフを実行してから `/gsd-onboard` を再実行します。`/gsd-onboard --fast` は軽量な初回パスには使えますが、`/gsd-new-project` の前には完全なマップが必要です。`/gsd-map-codebase` が4つの並行マッパーサブエージェントを生成します（「Spawning 4 parallel codebase mapper agents…」という通知が表示されます。1〜5分かかりますので中断しないでください）。各エージェントはそれぞれ異なる観点に注目します:
オンボーディングがコードベースマップ不足を示したら、推奨オプションを選び、表示された `/msd-map-codebase` ハンドオフを実行してから `/msd-onboard` を再実行します。`/msd-onboard --fast` は軽量な初回パスには使えますが、`/msd-new-project` の前には完全なマップが必要です。`/msd-map-codebase` が4つの並行マッパーサブエージェントを生成します（「Spawning 4 parallel codebase mapper agents…」という通知が表示されます。1〜5分かかりますので中断しないでください）。各エージェントはそれぞれ異なる観点に注目します:
| エージェント | 観点 |
|-------|-------|
@@ -83,9 +83,9 @@ Created .planning/codebase/:
- CONCERNS.md (33 lines) - Technical debt and issues
```
`.planning/codebase/STACK.md` を開いてください。GSD Core が検出した言語、ランタイム、フレームワークのバージョン、主要な依存関係が表示されます。これは推測ではなく、実際に読み込んだファイルに基づいています。
`.planning/codebase/STACK.md` を開いてください。MSD Core が検出した言語、ランタイム、フレームワークのバージョン、主要な依存関係が表示されます。これは推測ではなく、実際に読み込んだファイルに基づいています。
`.planning/codebase/CONVENTIONS.md` を開いてください。ソースコードから観察した命名規則、エラーハンドリングパターン、コードスタイルのルールが表示されます。このリポジトリで GSD Core が生成するすべてのプランは、これらの規約に自動的に従います。
`.planning/codebase/CONVENTIONS.md` を開いてください。ソースコードから観察した命名規則、エラーハンドリングパターン、コードスタイルのルールが表示されます。このリポジトリで MSD Core が生成するすべてのプランは、これらの規約に自動的に従います。
`.planning/codebase/CONCERNS.md` を開いてください。新機能の作業前に読む最も有用なファイルです。計画に影響しうる技術的負債や脆弱なエリアが表面化されています。
@@ -99,15 +99,15 @@ Created .planning/codebase/:
/clear
```
`/gsd-onboard` をもう一度実行します。GSD Core が ADR、PRD、spec、RFC、またはルートレベルの要件ドキュメントを検出した場合は、先に推奨される `/gsd-ingest-docs` ハンドオフを実行し、その後 `/gsd-onboard` を再実行してください。コンテキストが整うと、オンボーディングはプロジェクト初期化のハンドオフを表示します:
`/msd-onboard` をもう一度実行します。MSD Core が ADR、PRD、spec、RFC、またはルートレベルの要件ドキュメントを検出した場合は、先に推奨される `/msd-ingest-docs` ハンドオフを実行し、その後 `/msd-onboard` を再実行してください。コンテキストが整うと、オンボーディングはプロジェクト初期化のハンドオフを表示します:
```text
/gsd-new-project
/msd-new-project
```
前のステップで GSD Core が既存のコードを見つけているため、`/gsd-new-project` はこれがブラウンフィールドプロジェクトだと分かっています。質問は既存のものを再説明するのではなく、*追加する*内容に焦点を当てます:
前のステップで MSD Core が既存のコードを見つけているため、`/msd-new-project` はこれがブラウンフィールドプロジェクトだと分かっています。質問は既存のものを再説明するのではなく、*追加する*内容に焦点を当てます:
GSD Core が何を作りたいかを尋ねます。コードベース全体の説明ではなく、追加する機能で答えてください:
MSD Core が何を作りたいかを尋ねます。コードベース全体の説明ではなく、追加する機能で答えてください:
```text
Add a GET /health endpoint to the Express app. It should return
@@ -115,7 +115,7 @@ Add a GET /health endpoint to the Express app. It should return
health checks.
```
GSD Core が少数の確認質問をした後、要件とロードマップの作成に進みます。すでに `ARCHITECTURE.md` と `STACK.md` を読み込んでいるため、既存の機能を `PROJECT.md` の **Validated** セクションに自動的にマッピングします。既存の API サーフェスを説明する必要はありません。
MSD Core が少数の確認質問をした後、要件とロードマップの作成に進みます。すでに `ARCHITECTURE.md` と `STACK.md` を読み込んでいるため、既存の機能を `PROJECT.md` の **Validated** セクションに自動的にマッピングします。既存の API サーフェスを説明する必要はありません。
すべてのワークフロー設定は推奨デフォルトを選択してください。
@@ -133,7 +133,7 @@ Proposed Roadmap
ロードマップを承認してください。
プロジェクト設定が完了したら、もう一度 `/gsd-onboard` を実行します。`PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` がすべて存在するため、オンボーディングは `.planning/onboarding/SUMMARY.md` を作成または確認します。
プロジェクト設定が完了したら、もう一度 `/msd-onboard` を実行します。`PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` がすべて存在するため、オンボーディングは `.planning/onboarding/SUMMARY.md` を作成または確認します。
**`.planning/` に作成されるファイル:**
@@ -148,7 +148,7 @@ Proposed Roadmap
codebase/ ← ステップ 3 の7つのマップファイル
```
`.planning/codebase/` はすでにステップ 3 から存在しています。GSD Core は `PROJECT.md` を書く際にこれらのファイルを読み込んでいるため、あなたが説明しなくても Validated 要件を入力できたのです。
`.planning/codebase/` はすでにステップ 3 から存在しています。MSD Core は `PROJECT.md` を書く際にこれらのファイルを読み込んでいるため、あなたが説明しなくても Validated 要件を入力できたのです。
---
@@ -159,10 +159,10 @@ Proposed Roadmap
```
```text
/gsd-discuss-phase 1
/msd-discuss-phase 1
```
GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込んでいるため、質問は汎用的なアドバイスではなく、実際のコードベースに基づいています。以下のような内容が表示される場合があります:
MSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込んでいるため、質問は汎用的なアドバイスではなく、実際のコードベースに基づいています。以下のような内容が表示される場合があります:
```text
> Your routes are registered in src/routes/index.js. Should the health
@@ -177,7 +177,7 @@ GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込ん
process.uptime() is fine.
```
議論が終了すると、GSD Core が以下のファイルを書き込みます:
議論が終了すると、MSD Core が以下のファイルを書き込みます:
```text
.planning/phases/01-health-endpoint/CONTEXT.md
@@ -190,7 +190,7 @@ GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込ん
## ステップ 6 — フェーズ 1 の計画
```text
/gsd-plan-phase 1
/msd-plan-phase 1
```
4つのリサーチサブエージェントが並行して実行されます（1〜5分）。完了すると、プランナーが `CONTEXT.md`、リサーチ結果、コードベースマップを読み込み、あなたの規約に合ったタスクプランを作成します。
@@ -204,7 +204,7 @@ GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込ん
01-02-PLAN.md ← タスク: src/routes/index.js へのヘルスルートの登録
```
`01-01-PLAN.md` を開いてください。`<files>` タグが `src/routes/health.js` を参照していることに注目してください。これは議論で指定した正確なパスであり、GSD Core がコードベースマップで観察したルーティングパターンと一致しています。これがコードベースマップの効果です。
`01-01-PLAN.md` を開いてください。`<files>` タグが `src/routes/health.js` を参照していることに注目してください。これは議論で指定した正確なパスであり、MSD Core がコードベースマップで観察したルーティングパターンと一致しています。これがコードベースマップの効果です。
---
@@ -213,21 +213,21 @@ GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込ん
コードベースマップ、議論の意思決定記録、検証済みタスクプランが揃ったプロジェクトができました。すべてが実際のコードに基づいています。ここからのワークフローはグリーンフィールドプロジェクトと同じです:
```text
/gsd-execute-phase 1
/gsd-verify-work 1
/gsd-ship 1
/msd-execute-phase 1
/msd-verify-work 1
/msd-ship 1
```
今後の機能追加ごとに、構造が大幅に変わった際は `/gsd-map-codebase` を再実行してコードベースマップを最新の状態に保ってください。
今後の機能追加ごとに、構造が大幅に変わった際は `/msd-map-codebase` を再実行してコードベースマップを最新の状態に保ってください。
---
## 学んだこと
- `/gsd-onboard` が対話型コマンドをネストしたり既存 planning ファイルを上書きしたりせずに、ブラウンフィールド設定を安全に順序付ける仕組み。
- `/gsd-map-codebase` が4つの並行エージェントを実行して `.planning/codebase/` に `STACK.md`、`ARCHITECTURE.md`、`CONVENTIONS.md`、`CONCERNS.md`、`STRUCTURE.md`、`TESTING.md`、`INTEGRATIONS.md` を生成する仕組み。
- ブラウンフィールドリポジトリで `/gsd-new-project` を実行すると、*追加する*内容に焦点を当てた質問がされ、既存コードから Validated 要件が自動入力される仕組み。
- コードベースマップが `/gsd-discuss-phase` のすべての質問を形成する方法 — ファイルパス、パターン、規約が実際のコードから導出される。
- `/msd-onboard` が対話型コマンドをネストしたり既存 planning ファイルを上書きしたりせずに、ブラウンフィールド設定を安全に順序付ける仕組み。
- `/msd-map-codebase` が4つの並行エージェントを実行して `.planning/codebase/` に `STACK.md`、`ARCHITECTURE.md`、`CONVENTIONS.md`、`CONCERNS.md`、`STRUCTURE.md`、`TESTING.md`、`INTEGRATIONS.md` を生成する仕組み。
- ブラウンフィールドリポジトリで `/msd-new-project` を実行すると、*追加する*内容に焦点を当てた質問がされ、既存コードから Validated 要件が自動入力される仕組み。
- コードベースマップが `/msd-discuss-phase` のすべての質問を形成する方法 — ファイルパス、パターン、規約が実際のコードから導出される。
- プランナーが `CONTEXT.md` と `CONVENTIONS.md` を読み込んでリポジトリのスタイルに合ったプランを生成する仕組み。
---
@@ -235,5 +235,5 @@ GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込ん
## Related
- [はじめてのプロジェクト](your-first-project.md) — インストールから PR まで完全なグリーンフィールドループ
- [コマンドによるコードベースマッピング](../COMMANDS.md) — `/gsd-map-codebase` のすべてのフラグとサブコマンド
- [コマンドによるコードベースマッピング](../COMMANDS.md) — `/msd-map-codebase` のすべてのフラグとサブコマンド
- [ドキュメントインデックス](../README.md)

70
docs/ja-JP/tutorials/your-first-project.md
View File

@@ -1,6 +1,6 @@
# はじめてのプロジェクト
このチュートリアルでは、GSD Core をインストールし、シンプルなコマンドライン To-Do アプリをゼロから作成します。1フェーズ、1プルリクエスト、完全なループを体験します。終わる頃には、コアフェーズループのすべてのコマンドを少なくとも一度は実行し、各コマンドが生成する計画アーティファクトを確認しているはずです。
このチュートリアルでは、MSD Core をインストールし、シンプルなコマンドライン To-Do アプリをゼロから作成します。1フェーズ、1プルリクエスト、完全なループを体験します。終わる頃には、コアフェーズループのすべてのコマンドを少なくとも一度は実行し、各コマンドが生成する計画アーティファクトを確認しているはずです。
---
@@ -16,16 +16,16 @@ To-Do アイテムをローカルの JSON ファイルに保存し、追加・
- **Claude Code** — 使用するプロジェクトディレクトリで開いていること。
- 初回インストール用のインターネット接続。
他のツールは不要です。GSD Core 自体は次のステップでインストールします。
他のツールは不要です。MSD Core 自体は次のステップでインストールします。
---
## ステップ 1 — GSD Core のインストール
## ステップ 1 — MSD Core のインストール
プロジェクトディレクトリでターミナルを開き、以下を実行します:
```bash
npx @opengsd/gsd-core@latest
npx @golem15/msd-core@latest
```
インストーラーが、使用している AI コーディングランタイムとグローバルインストールかカレントプロジェクトへのインストールかを確認します。今は **Claude Code** と **local**（このプロジェクトのみ）を選択してください。
@@ -35,10 +35,10 @@ npx @opengsd/gsd-core@latest
```text
✓ Installed 86 skills to .claude/commands/
✓ Installed agents to .claude/agents/
✓ GSD Core ready — run /gsd-new-project to start
✓ MSD Core ready — run /msd-new-project to start
```
プロジェクト内に `.claude/` ディレクトリが作成されます。これが GSD Core のコマンドとエージェントの格納場所です。
プロジェクト内に `.claude/` ディレクトリが作成されます。これが MSD Core のコマンドとエージェントの格納場所です。
> ローカルとグローバルの違いについて: ローカルインストールはスキルのバージョンをこのプロジェクトに固定します。グローバルインストールを行う場合は、[ランタイムへのインストール](../how-to/install-on-your-runtime.md) を参照してください。
@@ -46,7 +46,7 @@ npx @opengsd/gsd-core@latest
## ステップ 2 — 権限フラグ付きで Claude Code を起動
GSD Core は、ファイルの読み書きを行うサブエージェントを生成します。すべてのファイル操作に対して確認を求められないよう、権限フラグを付けて Claude Code を起動してください:
MSD Core は、ファイルの読み書きを行うサブエージェントを生成します。すべてのファイル操作に対して確認を求められないよう、権限フラグを付けて Claude Code を起動してください:
```bash
claude --dangerously-skip-permissions
@@ -61,10 +61,10 @@ claude --dangerously-skip-permissions
Claude Code のプロンプトで以下のスラッシュコマンドを入力します:
```text
/gsd-new-project
/msd-new-project
```
GSD Core が会話を開始し、最初に1つの質問をします:
MSD Core が会話を開始し、最初に1つの質問をします:
```text
What do you want to build?
@@ -78,13 +78,13 @@ A Node.js CLI tool for managing to-do items. Users run `todo add "buy milk"`,
No external dependencies — Node built-ins only.
```
GSD Core がいくつかの確認事項について質問します。自然に答えてください。1つのプランも書く前に、あなたの意図を理解しようとしています。
MSD Core がいくつかの確認事項について質問します。自然に答えてください。1つのプランも書く前に、あなたの意図を理解しようとしています。
質問が終わると、ドメインリサーチの実行を提案します。この規模のプロジェクトであればリサーチをスキップできます。プロンプトが表示されたら **Skip research** を選択してください。
次に GSD Core がワークフロー設定（モード、粒度、リサーチエージェント）を選択するよう求めます。それぞれ推奨デフォルトを選択してください。これらの設定は `.planning/config.json` に書き込まれます。
次に MSD Core がワークフロー設定（モード、粒度、リサーチエージェント）を選択するよう求めます。それぞれ推奨デフォルトを選択してください。これらの設定は `.planning/config.json` に書き込まれます。
最後に、ロードマッパーのサブエージェントが実行されます（「Spawning roadmapper…」という通知が表示されますが、これは正常です。約1分かかります）。完了すると、GSD Core が提案するロードマップを提示します。単一フェーズのプロジェクトでは次のようになります:
最後に、ロードマッパーのサブエージェントが実行されます（「Spawning roadmapper…」という通知が表示されますが、これは正常です。約1分かかります）。完了すると、MSD Core が提案するロードマップを提示します。単一フェーズのプロジェクトでは次のようになります:
```text
Proposed Roadmap
@@ -115,7 +115,7 @@ Proposed Roadmap
## ステップ 4 — コンテキストをクリアしてフェーズ 1 を議論
GSD Core はフレッシュなコンテキストを前提に設計されています。各フェーズの前にメインセッションウィンドウをクリアしてください:
MSD Core はフレッシュなコンテキストを前提に設計されています。各フェーズの前にメインセッションウィンドウをクリアしてください:
```text
/clear
@@ -124,10 +124,10 @@ GSD Core はフレッシュなコンテキストを前提に設計されてい
次に、フェーズ 1 の議論を開始します:
```text
/gsd-discuss-phase 1
/msd-discuss-phase 1
```
GSD Core がフェーズのゴールを読み取り、実装の方針について質問します。これは「何を」作るかではなく、「どのように」作るかを決める質問です。会話の例:
MSD Core がフェーズのゴールを読み取り、実装の方針について質問します。これは「何を」作るかではなく、「どのように」作るかを決める質問です。会話の例:
```text
> How should done items be stored — mark them in place or move them?
@@ -140,7 +140,7 @@ GSD Core がフェーズのゴールを読み取り、実装の方針につい
Create it silently on first add.
```
議論が終了すると、GSD Core が以下のファイルを書き込みます:
議論が終了すると、MSD Core が以下のファイルを書き込みます:
```text
.planning/phases/01-core-cli/CONTEXT.md
@@ -153,7 +153,7 @@ GSD Core がフェーズのゴールを読み取り、実装の方針につい
## ステップ 5 — フェーズ 1 の計画
```text
/gsd-plan-phase 1
/msd-plan-phase 1
```
4つのリサーチサブエージェントが並行して実行されます（「Spawning 4 researchers…」という通知が表示されます。1〜5分かかります。中断しないでください）。
@@ -169,17 +169,17 @@ GSD Core がフェーズのゴールを読み取り、実装の方針につい
01-02-PLAN.md ← タスク: add / list / done コマンドの実装
```
`01-01-PLAN.md` を開いてください。タスク名、対象ファイル、アクションステップ、検証コマンド、完了条件が含まれた `<task>` ブロックがあります。`<verify>` タグに注目してください。GSD Core のエグゼキューターはコードを書いた後にそのコマンドを実行します。
`01-01-PLAN.md` を開いてください。タスク名、対象ファイル、アクションステップ、検証コマンド、完了条件が含まれた `<task>` ブロックがあります。`<verify>` タグに注目してください。MSD Core のエグゼキューターはコードを書いた後にそのコマンドを実行します。
---
## ステップ 6 — フェーズ 1 の実行
```text
/gsd-execute-phase 1
/msd-execute-phase 1
```
GSD Core はプランをウェーブ（独立したプランが並行実行される単位）にグループ化し、プランごとに新しい 200k コンテキストのエグゼキューターを生成し、各タスクをアトミックにコミットします。
MSD Core はプランをウェーブ（独立したプランが並行実行される単位）にグループ化し、プランごとに新しい 200k コンテキストのエグゼキューターを生成し、各タスクをアトミックにコミットします。
以下のような出力が表示されます:
@@ -215,17 +215,17 @@ node todo.js done 1
node todo.js list
```
アイテムが表示され、完了マークを付けた後にアイテム 1 がデフォルトリストから消えているはずです。これが GSD Core によって実現された最初の成果です。
アイテムが表示され、完了マークを付けた後にアイテム 1 がデフォルトリストから消えているはずです。これが MSD Core によって実現された最初の成果です。
---
## ステップ 7 — 成果物の検証
```text
/gsd-verify-work 1
/msd-verify-work 1
```
GSD Core がフェーズの成功基準を抽出し、それぞれについて確認します:
MSD Core がフェーズの成功基準を抽出し、それぞれについて確認します:
```text
[1/3] Can you run `node todo.js add "buy milk"` without errors?
@@ -240,7 +240,7 @@ GSD Core がフェーズの成功基準を抽出し、それぞれについて
All 3 checks passed. Phase 1 verified.
```
いずれかのチェックが失敗した場合、GSD Core が根本原因を診断して修正プランを作成します。`/gsd-execute-phase 1` を再度実行して修正を適用し、その後 `/gsd-verify-work 1` を再実行してください。
いずれかのチェックが失敗した場合、MSD Core が根本原因を診断して修正プランを作成します。`/msd-execute-phase 1` を再度実行して修正を適用し、その後 `/msd-verify-work 1` を再実行してください。
**作成されるファイル:**
@@ -253,10 +253,10 @@ All 3 checks passed. Phase 1 verified.
## ステップ 8 — リリース
```text
/gsd-ship 1
/msd-ship 1
```
GSD Core が自動生成された本文付きのプルリクエストを作成します。PR の本文には常に Summary、Changes、Requirements Addressed、Verification、Key Decisions が含まれます。
MSD Core が自動生成された本文付きのプルリクエストを作成します。PR の本文には常に Summary、Changes、Requirements Addressed、Verification、Key Decisions が含まれます。
以下のような出力が表示されます:
@@ -272,15 +272,15 @@ Title: feat(phase-1): core CLI — add / list / done commands
## 学んだこと
- `npx @opengsd/gsd-core@latest` を使った GSD Core のインストール方法。
- `/gsd-new-project` が会話を `.planning/` アーティファクトに裏付けられたロードマップに変換する仕組み。
- `/gsd-discuss-phase` が計画前に実装の意思決定を記録する仕組み。
- `/gsd-plan-phase` が並行リサーチャーを生成してアトミックなタスクプランを作成する仕組み。
- `/gsd-execute-phase` がプランを並行ウェーブで実行し各タスクをコミットする仕組み。
- `/gsd-verify-work` が成功基準を確認し、必要に応じて修正プランを生成する仕組み。
- `/gsd-ship` が検証済みフェーズをプルリクエストに変換する仕組み。
- `npx @golem15/msd-core@latest` を使った MSD Core のインストール方法。
- `/msd-new-project` が会話を `.planning/` アーティファクトに裏付けられたロードマップに変換する仕組み。
- `/msd-discuss-phase` が計画前に実装の意思決定を記録する仕組み。
- `/msd-plan-phase` が並行リサーチャーを生成してアトミックなタスクプランを作成する仕組み。
- `/msd-execute-phase` がプランを並行ウェーブで実行し各タスクをコミットする仕組み。
- `/msd-verify-work` が成功基準を確認し、必要に応じて修正プランを生成する仕組み。
- `/msd-ship` が検証済みフェーズをプルリクエストに変換する仕組み。
マルチフェーズプロジェクトの場合は、各フェーズでステップ 4〜8 を繰り返し、`/gsd-progress --next` を実行して GSD Core に次のステップを自動検出させてください。
マルチフェーズプロジェクトの場合は、各フェーズでステップ 4〜8 を繰り返し、`/msd-progress --next` を実行して MSD Core に次のステップを自動検出させてください。
---
@@ -288,4 +288,4 @@ Title: feat(phase-1): core CLI — add / list / done commands
- [フェーズループ](../explanation/the-phase-loop.md) — ループがこの形状である理由
- [ハウツーガイド](../README.md#how-to-guides) — 特定の状況に対応したタスク重視のレシピ
- [既存コードベースのオンボーディング](onboarding-an-existing-codebase.md) — ブラウンフィールドリポジトリへの GSD Core の導入
- [既存コードベースのオンボーディング](onboarding-an-existing-codebase.md) — ブラウンフィールドリポジトリへの MSD Core の導入