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

62
docs/ko-KR/tutorials/onboarding-an-existing-codebase.md
View File

@@ -1,12 +1,12 @@
# 기존 코드베이스 온보딩
이 튜토리얼에서는 이미 코드가 있는 저장소에 GSD Core를 도입합니다. 코드베이스를 매핑하고, *추가하려는* 내용을 설명하는 프로젝트를 생성한 다음, 작은 변경 사항에 대한 첫 번째 논의-계획 사이클을 실행합니다. 튜토리얼이 끝나면 GSD Core의 계획 파이프라인이 여러분의 기술 스택, 컨벤션, 그리고 관심사를 파악하게 됩니다 — 이후 계획을 수립할 때마다 이 지식을 활용합니다.
이 튜토리얼에서는 이미 코드가 있는 저장소에 MSD Core를 도입합니다. 코드베이스를 매핑하고, *추가하려는* 내용을 설명하는 프로젝트를 생성한 다음, 작은 변경 사항에 대한 첫 번째 논의-계획 사이클을 실행합니다. 튜토리얼이 끝나면 MSD Core의 계획 파이프라인이 여러분의 기술 스택, 컨벤션, 그리고 관심사를 파악하게 됩니다 — 이후 계획을 수립할 때마다 이 지식을 활용합니다.
---
## 만들 것
기존 Express 애플리케이션에 `GET /health` 엔드포인트 하나를 추가합니다. 변경 사항이 충분히 작아서 진짜 핵심 교훈, 즉 GSD Core가 계획을 수립하기 전에 코드베이스를 어떻게 학습하는지에 집중할 수 있습니다.
기존 Express 애플리케이션에 `GET /health` 엔드포인트 하나를 추가합니다. 변경 사항이 충분히 작아서 진짜 핵심 교훈, 즉 MSD Core가 계획을 수립하기 전에 코드베이스를 어떻게 학습하는지에 집중할 수 있습니다.
---
@@ -18,12 +18,12 @@
---
## Step 1 — GSD Core 설치
## Step 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
## Step 3 — 브라운필드 온보딩 시작
프로젝트를 생성하기 전에 GSD Core가 저장소 상태를 검사하고 안전한 다음 top-level 명령을 알려주게 하세요. 이 단계는 코드베이스 컨텍스트를 건너뛰거나 기존 planning 파일을 덮어쓰는 일을 방지합니다.
프로젝트를 생성하기 전에 MSD Core가 저장소 상태를 검사하고 안전한 다음 top-level 명령을 알려주게 하세요. 이 단계는 코드베이스 컨텍스트를 건너뛰거나 기존 planning 파일을 덮어쓰는 일을 방지합니다.
```text
/gsd-onboard
/msd-onboard
```
온보딩이 코드베이스 맵 누락을 보고하면 권장 옵션을 선택하고 출력된 `/gsd-map-codebase` handoff를 실행한 뒤 `/gsd-onboard`를 다시 실행합니다. `/gsd-onboard --fast`는 가벼운 첫 패스에는 충분하지만, `/gsd-new-project` 전에는 완전한 맵이 필요합니다. `/gsd-map-codebase`가 4개의 병렬 매퍼 서브 에이전트를 생성합니다("Spawning 4 parallel codebase mapper agents…" 메시지가 표시되며, 1–5분 소요됩니다. 중단하지 마세요). 각 에이전트는 서로 다른 관심사에 집중합니다:
온보딩이 코드베이스 맵 누락을 보고하면 권장 옵션을 선택하고 출력된 `/msd-map-codebase` handoff를 실행한 뒤 `/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,13 +99,13 @@ Created .planning/codebase/:
/clear
```
이제 `/gsd-onboard`를 다시 실행합니다. GSD Core가 ADR, PRD, spec, RFC 또는 루트 요구사항 문서를 감지하면 먼저 권장되는 `/gsd-ingest-docs` handoff를 실행하고 이후 `/gsd-onboard`를 다시 실행하세요. 컨텍스트가 준비되면 온보딩이 프로젝트 초기화 handoff를 출력합니다:
이제 `/msd-onboard`를 다시 실행합니다. MSD Core가 ADR, PRD, spec, RFC 또는 루트 요구사항 문서를 감지하면 먼저 권장되는 `/msd-ingest-docs` handoff를 실행하고 이후 `/msd-onboard`를 다시 실행하세요. 컨텍스트가 준비되면 온보딩이 프로젝트 초기화 handoff를 출력합니다:
```text
/gsd-new-project
/msd-new-project
```
GSD Core가 무엇을 만들고 싶은지 묻습니다. 전체 코드베이스에 대한 설명이 아닌 추가하려는 기능으로 답변합니다:
MSD Core가 무엇을 만들고 싶은지 묻습니다. 전체 코드베이스에 대한 설명이 아닌 추가하려는 기능으로 답변합니다:
```text
Add a GET /health endpoint to the Express app. It should return
@@ -113,7 +113,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 표면을 직접 설명할 필요가 없습니다.
모든 워크플로 설정에서 권장 기본값을 선택합니다.
@@ -131,7 +131,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/`에 생성되는 파일:**
@@ -146,7 +146,7 @@ Proposed Roadmap
codebase/ ← Step 3에서 생성된 7개의 맵 파일
```
`.planning/codebase/`는 Step 3에서 이미 생성된 것입니다. `PROJECT.md` 작성 시 GSD Core가 해당 파일들을 읽었기 때문에, 여러분이 직접 설명하지 않아도 Validated 요구사항을 채울 수 있었습니다.
`.planning/codebase/`는 Step 3에서 이미 생성된 것입니다. `PROJECT.md` 작성 시 MSD Core가 해당 파일들을 읽었기 때문에, 여러분이 직접 설명하지 않아도 Validated 요구사항을 채울 수 있었습니다.
---
@@ -157,10 +157,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
@@ -175,7 +175,7 @@ GSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들
process.uptime() is fine.
```
논의가 끝나면 GSD Core가 다음 파일을 생성합니다:
논의가 끝나면 MSD Core가 다음 파일을 생성합니다:
```text
.planning/phases/01-health-endpoint/CONTEXT.md
@@ -188,7 +188,7 @@ GSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들
## Step 6 — Phase 1 계획
```text
/gsd-plan-phase 1
/msd-plan-phase 1
```
4개의 리서치 서브 에이전트가 병렬로 실행됩니다(1–5분). 완료되면 플래너가 `CONTEXT.md`, 리서치 결과, 코드베이스 맵을 읽어 컨벤션에 맞는 태스크 계획을 생성합니다.
@@ -202,7 +202,7 @@ GSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들
01-02-PLAN.md ← 태스크: src/routes/index.js에 health 라우트 등록
```
`01-01-PLAN.md`를 열어봅니다. `<files>` 태그에 `src/routes/health.js`가 참조되어 있습니다 — 논의에서 지정한 정확한 경로이며, GSD Core가 코드베이스 맵에서 관찰한 라우팅 패턴과 일치합니다. 코드베이스 맵이 실제로 작동하는 모습입니다.
`01-01-PLAN.md`를 열어봅니다. `<files>` 태그에 `src/routes/health.js`가 참조되어 있습니다 — 논의에서 지정한 정확한 경로이며, MSD Core가 코드베이스 맵에서 관찰한 라우팅 패턴과 일치합니다. 코드베이스 맵이 실제로 작동하는 모습입니다.
---
@@ -211,21 +211,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`를 함께 읽어 저장소 스타일에 맞는 계획을 생성하는 방법.
---
@@ -233,5 +233,5 @@ GSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들
## Related
- [Your first project](your-first-project.md) — 설치부터 PR까지 전체 그린필드 루프
- [Map codebase via Commands](../COMMANDS.md) — `/gsd-map-codebase`의 모든 플래그와 서브커맨드
- [Map codebase via Commands](../COMMANDS.md) — `/msd-map-codebase`의 모든 플래그와 서브커맨드
- [Documentation index](../README.md)

70
docs/ko-KR/tutorials/your-first-project.md
View File

@@ -1,6 +1,6 @@
# 첫 번째 프로젝트
이 튜토리얼에서는 GSD Core를 설치하고, 간단한 커맨드라인 할 일(to-do) 앱을 처음부터 만들어봅니다 — 하나의 단계(phase), 하나의 PR, 그리고 전체 루프를 경험합니다. 튜토리얼이 끝나면 핵심 단계 루프의 모든 명령어를 최소 한 번씩 실행해보고, 각 명령어가 생성하는 계획 산출물도 확인하게 됩니다.
이 튜토리얼에서는 MSD Core를 설치하고, 간단한 커맨드라인 할 일(to-do) 앱을 처음부터 만들어봅니다 — 하나의 단계(phase), 하나의 PR, 그리고 전체 루프를 경험합니다. 튜토리얼이 끝나면 핵심 단계 루프의 모든 명령어를 최소 한 번씩 실행해보고, 각 명령어가 생성하는 계획 산출물도 확인하게 됩니다.
---
@@ -16,16 +16,16 @@
- **Claude Code** — 사용하려는 프로젝트 디렉터리에서 열어둡니다.
- 초기 설치를 위한 인터넷 연결.
그 외 도구는 필요하지 않습니다. GSD Core는 다음 단계에서 설치합니다.
그 외 도구는 필요하지 않습니다. MSD Core는 다음 단계에서 설치합니다.
---
## Step 1 — GSD Core 설치
## Step 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의 명령어와 에이전트가 이곳에 저장됩니다.
> 로컬 vs 전역 설치 이유? 로컬 설치는 이 프로젝트에 스킬 버전을 고정합니다. 전역 설치가 필요하다면 [런타임에 설치하기](../how-to/install-on-your-runtime.md)를 참고하세요.
@@ -46,7 +46,7 @@ npx @opengsd/gsd-core@latest
## Step 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가 대화를 시작합니다. 먼저 질문을 하나 합니다:
MSD Core가 대화를 시작합니다. 먼저 질문을 하나 합니다:
```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는 몇 가지 후속 질문을 합니다. 자연스럽게 답변하면 됩니다. 계획을 하나도 작성하기 전에 먼저 여러분이 중요하게 생각하는 것을 파악합니다.
MSD Core는 몇 가지 후속 질문을 합니다. 자연스럽게 답변하면 됩니다. 계획을 하나도 작성하기 전에 먼저 여러분이 중요하게 생각하는 것을 파악합니다.
질문이 끝나면 도메인 리서치 실행 여부를 묻습니다. 이 정도 규모의 프로젝트는 리서치를 건너뛰어도 됩니다 — 프롬프트가 표시될 때 **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
## Step 4 — 컨텍스트 초기화 후 Phase 1 논의
GSD Core는 새로운 컨텍스트를 기반으로 동작하도록 설계되었습니다. 각 단계를 시작하기 전에 메인 세션 창을 초기화합니다:
MSD Core는 새로운 컨텍스트를 기반으로 동작하도록 설계되었습니다. 각 단계를 시작하기 전에 메인 세션 창을 초기화합니다:
```text
/clear
@@ -124,10 +124,10 @@ GSD Core는 새로운 컨텍스트를 기반으로 동작하도록 설계되었
그런 다음 Phase 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가 단계 목표를 읽고 구현 방식에 대해 질문합니다. 이
## Step 5 — Phase 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의 실행기가 코드 작성 후 해당 명령어를 실행합니다.
---
## Step 6 — Phase 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가 전달하는 첫 번째 가시적인 결과입니다.
---
## Step 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.
## Step 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`이 검증된 단계를 풀 리퀘스트로 전환하는 방법.
멀티 단계 프로젝트의 경우 각 단계마다 Step 4–8을 반복한 다음, `/gsd-progress --next`를 실행해 GSD Core가 다음 단계를 자동으로 감지하도록 합니다.
멀티 단계 프로젝트의 경우 각 단계마다 Step 4–8을 반복한 다음, `/msd-progress --next`를 실행해 MSD Core가 다음 단계를 자동으로 감지하도록 합니다.
---
@@ -288,4 +288,4 @@ Title: feat(phase-1): core CLI — add / list / done commands
- [The phase loop](../explanation/the-phase-loop.md) — 루프가 이런 구조를 가지는 이유
- [How-to guides](../README.md#how-to-guides) — 특정 상황에 대한 태스크 중심 레시피
- [Onboarding an existing codebase](onboarding-an-existing-codebase.md) — 브라운필드 레포에 GSD Core 도입하기
- [Onboarding an existing codebase](onboarding-an-existing-codebase.md) — 브라운필드 레포에 MSD Core 도입하기