322 lines
17 KiB
Markdown
322 lines
17 KiB
Markdown
---
|
|
title: 핵심 도구
|
|
description: 추가 모듈 없이 모든 BMad 설치에서 사용할 수 있는 내장 작업과 워크플로 참조
|
|
sidebar:
|
|
order: 3
|
|
---
|
|
|
|
모든 BMad 설치에는 어떤 작업을 하든 함께 사용할 수 있는 핵심 스킬 모음이 포함됩니다. 모든 프로젝트, 모든 모듈, 모든 단계에서 단독으로 실행할 수 있는 작업과 워크플로입니다. 어떤 선택 모듈을 설치했든 항상 사용할 수 있습니다.
|
|
|
|
:::tip[빠른 경로]
|
|
IDE에서 스킬 이름(예: `bmad-help`)을 입력해 어떤 핵심 도구든 실행하세요. 에이전트 세션은 필요 없습니다.
|
|
:::
|
|
|
|
## 개요
|
|
|
|
| 도구 | 유형 | 목적 |
|
|
| --- | --- | --- |
|
|
| [`bmad-help`](#bmad-help) | 작업 | 다음에 무엇을 해야 할지 상황에 맞게 안내 |
|
|
| [`bmad-brainstorming`](#bmad-brainstorming) | 워크플로 | 대화형 브레인스토밍 세션 진행 |
|
|
| [`bmad-party-mode`](#bmad-party-mode) | 워크플로 | 다중 에이전트 그룹 토론 조율 |
|
|
| [`bmad-spec`](#bmad-spec) | 워크플로 | 모든 의도 입력을 후속 작업의 표준 계약인 SPEC 커널과 동반 파일로 정제 |
|
|
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | 작업 | LLM 출력을 반복 개선 방식으로 끌어올림 |
|
|
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | 작업 | 빠진 것과 틀린 것을 찾는 비판적 리뷰 |
|
|
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | 작업 | 처리되지 않은 엣지 케이스를 찾기 위한 철저한 분기 경로 분석 |
|
|
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | 작업 | 전달 명확성을 위한 엄격한 문장 교정 |
|
|
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | 작업 | 구조 편집 - 삭제, 병합, 재구성 |
|
|
| [`bmad-shard-doc`](#bmad-shard-doc) | 작업 | 큰 Markdown 파일을 정리된 섹션으로 분할 |
|
|
| [`bmad-index-docs`](#bmad-index-docs) | 작업 | 폴더 내 모든 문서 색인 생성 또는 업데이트 |
|
|
| [`bmad-customize`](#bmad-customize) | 작업 | BMad 커스터마이징 오버라이드 생성 및 검증 |
|
|
|
|
## bmad-help
|
|
|
|
**다음에 무엇을 해야 할지 알려주는 지능형 안내자입니다.** 프로젝트 상태를 검사하고, 완료된 것을 감지하며, 다음 필수 또는 선택 단계를 추천합니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- 워크플로를 끝냈고 다음 단계를 알고 싶습니다
|
|
- BMad가 처음이라 방향 안내가 필요합니다
|
|
- 막혀서 상황에 맞는 조언이 필요합니다
|
|
- 새 모듈을 설치했고 사용할 수 있는 것을 보고 싶습니다
|
|
|
|
**작동 방식:**
|
|
|
|
1. 프로젝트에서 기존 산출물(PRD, 아키텍처, 스토리 등)를 스캔합니다
|
|
2. 설치된 모듈과 사용 가능한 워크플로를 감지합니다
|
|
3. 우선순위 순서로 다음 단계를 추천합니다. 필수 단계를 먼저, 선택 단계를 나중에 제시합니다
|
|
4. 각 추천을 스킬 명령과 짧은 설명으로 보여줍니다
|
|
|
|
**입력:** 자연어 선택 쿼리(예: `bmad-help SaaS 아이디어가 있는데 어디서 시작하나요?`)
|
|
|
|
**출력:** 스킬 명령이 포함된 권장 다음 단계의 우선순위 목록
|
|
|
|
## bmad-brainstorming
|
|
|
|
**대화형 창의 기법으로 다양한 아이디어를 생성합니다.** 기법 라이브러리에서 검증된 아이디어 발상법을 로드하고 100개 이상의 아이디어를 향해 안내한 뒤 정리하는 브레인스토밍 세션입니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- 새 프로젝트를 시작하고 문제 영역을 탐색해야 합니다
|
|
- 아이디어 생성이 막혀 구조화된 창의 기법이 필요합니다
|
|
- SCAMPER, 역브레인스토밍 같은 검증된 아이디어 발상 프레임워크를 사용하고 싶습니다
|
|
|
|
**작동 방식:**
|
|
|
|
1. 주제로 브레인스토밍 세션을 설정합니다
|
|
2. 기법 라이브러리에서 창의 기법을 로드합니다
|
|
3. 기법을 하나씩 진행하며 아이디어를 생성합니다
|
|
4. 편향 방지 프로토콜을 적용합니다. 10개 아이디어마다 창의 영역을 바꿔 군집화를 방지합니다
|
|
5. 모든 아이디어를 기법별로 정리한 추가 전용 세션 문서를 만듭니다
|
|
|
|
**입력:** 브레인스토밍 주제 또는 문제 설명, 선택 사항 컨텍스트 파일
|
|
|
|
**출력:** 생성된 모든 아이디어가 담긴 `brainstorming-session-{date}.md`
|
|
|
|
:::note[수량 목표]
|
|
핵심은 아이디어 50-100개 지점에서 나옵니다. 이 워크플로는 정리 전에 100개 이상의 아이디어 생성을 권장합니다.
|
|
:::
|
|
|
|
## bmad-party-mode
|
|
|
|
**다중 에이전트 그룹 토론을 조율합니다.** 설치된 모든 BMad 에이전트를 로드하고 각 에이전트가 고유한 전문성과 페르소나로 기여하는 자연스러운 대화를 진행합니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- 결정에 여러 전문가 관점이 필요합니다
|
|
- 에이전트들이 서로의 가정에 도전하길 원합니다
|
|
- 여러 도메인에 걸친 복잡한 주제를 탐색합니다
|
|
|
|
**작동 방식:**
|
|
|
|
1. 설치된 모든 에이전트 페르소나가 있는 에이전트 매니페스트를 로드합니다
|
|
2. 주제를 분석해 가장 관련 있는 에이전트 2-3개를 선택합니다
|
|
3. 에이전트들이 턴을 나눠 기여하고 자연스러운 상호 대화와 의견 차이를 만듭니다
|
|
4. 시간이 지나며 참여 에이전트를 순환해 다양한 관점을 보장합니다
|
|
5. `goodbye`, `end party`, `quit`로 종료합니다
|
|
|
|
**입력:** 토론 주제 또는 질문, 참여시키고 싶은 페르소나 지정(선택 사항)
|
|
|
|
**출력:** 에이전트 페르소나가 유지되는 실시간 다중 에이전트 대화
|
|
|
|
## bmad-spec
|
|
|
|
**모든 의도 입력을 후속 작업의 표준 SPEC 계약으로 정제합니다.** 간단한 아이디어, PRD, GDD, RFC, 브레인 덤프, 회의록, UX 폴더, 여러 소스가 섞인 입력을 받아 다섯 필드 커널(Why, Capabilities, Constraints, Non-goals, Success signal)을 담은 `SPEC.md`와 커널에 들어가지 않는 핵심 내용을 위한 동반 파일을 만듭니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- 소프트웨어, 게임 디자인, 리서치, 편집, 정책, 비즈니스 등 어떤 작업이든 HOW 전에 WHAT을 고정해야 합니다.
|
|
- 후속 스킬이 모든 상위 산출물을 다시 읽지 않고도 소비할 수 있는 간결하고 군더더기 없는 LLM 최적화 계약이 필요합니다.
|
|
- 기존 spec을 검증하거나 업데이트하고 싶습니다.
|
|
|
|
**작동 방식:**
|
|
|
|
1. 입력과 연결된 보조 자료를 읽습니다.
|
|
2. 설정 가능한 템플릿으로 다섯 필드 커널을 정제하고, 넘치는 내용은 적절한 이름의 동반 파일로 보냅니다.
|
|
3. 두 단계 자체 검증을 실행합니다. 먼저 일관성 규칙을 확인하고, 다음으로 모든 핵심 소스 주장이 보존됐는지 확인합니다.
|
|
4. `{output_folder}/specs/spec-{slug}/` 아래에 `SPEC.md`, 동반 파일, `.decision-log.md`를 씁니다.
|
|
|
|
Spec Law는 여덟 가지 규칙을 강제합니다. capabilities는 의도와 성공 기준을 모두 담고, intents는 HOW가 아니라 WHAT이며, constraints는 실제 의사결정에 영향을 주고, non-goals는 명시적이며, success signals는 구체적이고, capability ID는 안정적이며, 모든 핵심 소스 주장은 보존되고, 문장은 간결해야 합니다.
|
|
|
|
**입력:**
|
|
|
|
- `input`(필수) - 경로 또는 인라인 텍스트. 모호한 아이디어, 브레인 덤프, PRD, GDD, RFC, brief, transcript, mockup 폴더, 여러 소스 조합.
|
|
- `slug`(선택 사항) - 입력이 빈약하고 소스 파일명에서 slug를 만들 수 없을 때만 필요합니다.
|
|
- `target_spec_path`(선택 사항) - 새 spec을 만드는 대신 기존 spec을 업데이트할 때 설정합니다.
|
|
|
|
**출력:** `SPEC.md`, 동반 파일, `.decision-log.md`가 들어 있는 spec 폴더. Headless 호출자는 결과 상태와 작성 또는 수정된 파일 목록을 담은 JSON 응답을 받습니다.
|
|
|
|
:::note[변경 계약]
|
|
`bmad-spec`은 `SPEC.md`와 spec이 작성한 동반 파일을 쓸 수 있는 유일한 도구입니다. 다른 스킬은 자체 네이티브 산출물을 만들고, 의도를 표준 계약으로 표현하거나 업데이트를 제안해야 할 때 headless 모드로 `bmad-spec`을 호출합니다.
|
|
:::
|
|
|
|
## bmad-advanced-elicitation
|
|
|
|
**LLM 출력을 반복 개선 방식으로 개선합니다.** 도출 기법 라이브러리에서 선택해 여러 차례에 걸쳐 내용을 체계적으로 개선합니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- LLM 출력이 얕거나 일반적으로 느껴집니다
|
|
- 여러 분석 관점에서 주제를 탐색하고 싶습니다
|
|
- 중요한 문서를 다듬고 더 깊은 사고가 필요합니다
|
|
|
|
**작동 방식:**
|
|
|
|
1. 5개 이상의 도출 기법이 있는 기법 레지스트리를 로드합니다
|
|
2. 내용 유형과 복잡도에 가장 잘 맞는 기법 5개를 선택합니다
|
|
3. 대화형 메뉴를 제시합니다. 기법 선택, 다시 섞기, 전체 목록 보기가 가능합니다
|
|
4. 선택한 기법을 적용해 내용을 강화합니다
|
|
5. "진행"을 선택할 때까지 반복 개선 옵션을 다시 제시합니다
|
|
|
|
**입력:** 강화할 내용 섹션
|
|
|
|
**출력:** 개선이 적용된 버전
|
|
|
|
## bmad-review-adversarial-general
|
|
|
|
**문제가 있다고 가정하고 찾는 비판적 리뷰입니다.** 허술한 작업을 용납하지 않는 회의적인 리뷰어의 관점을 취합니다. 틀린 것뿐 아니라 빠진 것을 찾습니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- 산출물 확정 전 품질 보증이 필요합니다
|
|
- 사양, 스토리, 문서를 스트레스 테스트하고 싶습니다
|
|
- 낙관적인 리뷰가 놓치는 검토 공백을 찾고 싶습니다
|
|
|
|
**작동 방식:**
|
|
|
|
1. 냉정하고 비판적인 관점으로 내용을 읽습니다
|
|
2. 완전성, 정확성, 품질 전반의 이슈를 식별합니다
|
|
3. 존재하지만 잘못된 것만이 아니라 빠진 것을 특히 찾습니다
|
|
4. 최소 10개 이슈를 찾아야 하며, 부족하면 더 깊게 재분석합니다
|
|
|
|
**입력:**
|
|
|
|
- `content`(필수) - diff, 사양, 스토리, 문서 또는 모든 산출물
|
|
- `also_consider`(선택 사항) - 추가로 염두에 둘 영역
|
|
|
|
**출력:** 설명이 있는 10개 이상의 발견 사항 Markdown 목록
|
|
|
|
## bmad-review-edge-case-hunter
|
|
|
|
**모든 분기 경로와 경계 조건을 따라가며 처리되지 않은 사례만 보고합니다.** 엣지 케이스 유형을 기계적으로 도출하는 순수 경로 추적 기법입니다. 적대적 리뷰와 상호 보완적이며, 태도 기반이 아니라 기법 기반입니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- 코드나 로직에 대한 철저한 엣지 케이스 검토가 필요합니다
|
|
- 적대적 리뷰를 보완하고 싶습니다(다른 기법, 다른 발견 사항)
|
|
- 경계 조건을 확인하기 위해 diff나 함수를 리뷰합니다
|
|
|
|
**작동 방식:**
|
|
|
|
1. 내용의 모든 분기 경로를 열거합니다
|
|
2. 누락된 else/기본값, 보호되지 않은 입력, off-by-one, 산술 오버플로, 암시적 타입 강제 변환, 경쟁 상태, 타임아웃 공백 같은 엣지 케이스 유형을 기계적으로 도출합니다
|
|
3. 각 경로를 기존 방어 로직과 대조합니다
|
|
4. 처리되지 않은 경로만 보고합니다. 이미 처리된 경로는 조용히 버립니다
|
|
|
|
**입력:**
|
|
|
|
- `content`(필수) - diff, 전체 파일, 함수
|
|
- `also_consider`(선택 사항) - 추가로 염두에 둘 영역
|
|
|
|
**출력:** 각 발견 사항이 `location`, `trigger_condition`, `guard_snippet`, `potential_consequence`를 포함하는 JSON 배열
|
|
|
|
:::note[상호 보완 리뷰]
|
|
상호 보완적 검토를 위해 `bmad-review-adversarial-general`과 `bmad-review-edge-case-hunter`를 함께 실행하세요. 적대적 리뷰는 품질과 완전성 이슈를 잡고, 엣지 케이스 헌터는 처리되지 않은 경로를 잡습니다.
|
|
:::
|
|
|
|
## bmad-editorial-review-prose
|
|
|
|
**전달 명확성에 집중한 엄격한 문장 교정입니다.** 이해를 방해하는 문장 문제를 리뷰합니다. Microsoft Writing Style Guide 기준을 적용하고 작성자 목소리를 보존합니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- 문서를 초안으로 작성했고 문장을 다듬고 싶습니다
|
|
- 특정 독자를 위한 명확성을 보장해야 합니다
|
|
- 취향 기반 수정 없이 전달만 개선하고 싶습니다
|
|
|
|
**작동 방식:**
|
|
|
|
1. 코드 블록과 프런트매터를 건너뛰고 내용을 읽습니다
|
|
2. 스타일 선호가 아닌 전달 이슈를 식별합니다
|
|
3. 여러 위치의 같은 이슈를 중복 제거합니다
|
|
4. 세 열 수정 테이블을 생성합니다
|
|
|
|
**입력:**
|
|
|
|
- `content`(필수) - Markdown, 일반 텍스트, XML
|
|
- `style_guide`(선택 사항) - 프로젝트별 스타일 가이드
|
|
- `reader_type`(선택 사항) - 명확성/흐름용 `humans`(기본값) 또는 정밀도/일관성용 `llm`
|
|
|
|
**출력:** 세 열 Markdown 테이블: `Original Text | Revised Text | Changes`
|
|
|
|
## bmad-editorial-review-structure
|
|
|
|
**구조 편집입니다. 삭제, 병합, 이동, 압축을 제안합니다.** 문장 교정 전에 문서 구성을 리뷰하고 명확성과 흐름을 개선하는 실질적 변경을 제안합니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- 여러 하위 프로세스에서 생성된 문서에 구조적 일관성이 필요합니다
|
|
- 이해도를 유지하면서 문서 길이를 줄이고 싶습니다
|
|
- 범위 위반이나 묻힌 핵심 정보를 식별해야 합니다
|
|
|
|
**작동 방식:**
|
|
|
|
1. 5개 구조 모델(튜토리얼, 참조, 설명, 프롬프트, 전략)에 대해 문서를 분석합니다
|
|
2. 중복, 범위 위반, 묻힌 정보를 식별합니다
|
|
3. 우선순위 권장 사항을 생성합니다: `CUT`, `MERGE`, `MOVE`, `CONDENSE`, `QUESTION`, `PRESERVE`
|
|
4. 총 단어 감소량과 감소율을 추정합니다
|
|
|
|
**입력:**
|
|
|
|
- `content`(필수) - 리뷰할 문서
|
|
- `purpose`(선택 사항) - 의도한 목적(예: "빠른 시작 튜토리얼")
|
|
- `target_audience`(선택 사항) - 독자
|
|
- `reader_type`(선택 사항) - `humans` 또는 `llm`
|
|
- `length_target`(선택 사항) - 목표 감소량(예: "30% 줄이기")
|
|
|
|
**출력:** 문서 요약, 우선순위 권장 사항 목록, 예상 감소량
|
|
|
|
## bmad-shard-doc
|
|
|
|
**큰 Markdown 파일을 정리된 섹션 파일로 나눕니다.** 2단계 헤더를 분할 지점으로 사용해 독립적인 섹션 파일과 색인이 있는 폴더를 만듭니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- Markdown 문서가 너무 커져 효과적으로 관리하기 어렵습니다(500줄 이상)
|
|
- 단일 문서를 탐색 가능한 섹션으로 나누고 싶습니다
|
|
- 병렬 편집 또는 LLM 컨텍스트 관리를 위해 별도 파일이 필요합니다
|
|
|
|
**작동 방식:**
|
|
|
|
1. 소스 파일이 존재하고 Markdown인지 검증합니다
|
|
2. 2단계(`##`) 헤더 기준으로 번호가 붙은 섹션 파일로 나눕니다
|
|
3. 섹션 매니페스트와 링크가 있는 `index.md`를 만듭니다
|
|
4. 원본을 삭제, 보관, 유지할지 묻습니다
|
|
|
|
**입력:** 소스 Markdown 파일 경로, 선택 사항 대상 폴더
|
|
|
|
**출력:** `index.md`와 `01-{section}.md`, `02-{section}.md` 등이 있는 폴더
|
|
|
|
## bmad-index-docs
|
|
|
|
**폴더의 모든 문서 색인을 생성하거나 업데이트합니다.** 디렉터리를 스캔하고 각 파일을 읽어 목적을 이해한 뒤 링크와 설명이 있는 정리된 `index.md`를 만듭니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- 사용 가능한 문서를 LLM이 빠르게 스캔할 수 있는 가벼운 색인이 필요합니다
|
|
- 문서 폴더가 커져 정리된 목차가 필요합니다
|
|
- 최신 상태를 유지하는 자동 생성 개요를 원합니다
|
|
|
|
**작동 방식:**
|
|
|
|
1. 대상 디렉터리에서 숨김이 아닌 파일을 모두 스캔합니다
|
|
2. 각 파일을 읽어 실제 목적을 이해합니다
|
|
3. 유형, 목적, 하위 디렉터리 기준으로 파일을 그룹화합니다
|
|
4. 간결한 설명(각 3-10단어)을 생성합니다
|
|
|
|
**입력:** 대상 폴더 경로
|
|
|
|
**출력:** 정리된 파일 목록, 상대 링크, 짧은 설명이 있는 `index.md`
|
|
|
|
## bmad-customize
|
|
|
|
**커스터마이징 오버라이드를 만들고 검증합니다.** TOML을 직접 작성하지 않고도 설치된 BMad 에이전트나 워크플로의 동작을 바꿀 수 있게 도와줍니다.
|
|
|
|
**사용 시점:**
|
|
|
|
- 에이전트나 워크플로 동작을 바꾸고 싶습니다
|
|
- 지속 사실, 활성화 훅, 커스텀 메뉴 항목을 추가해야 합니다
|
|
- 올바른 오버라이드 범위를 자동으로 선택하고 검증하고 싶습니다
|
|
|
|
**작동 방식:**
|
|
|
|
1. 설치된 BMad 스킬에서 커스터마이징 가능한 영역을 스캔합니다
|
|
2. 요청한 변경에 맞는 범위를 선택합니다
|
|
3. `_bmad/custom/` 아래에 오버라이드 파일을 작성합니다
|
|
4. 병합된 설정을 검증합니다
|
|
|
|
**입력:** 원하는 커스터마이징을 설명하는 자연어
|
|
|
|
**출력:** `_bmad/custom/` 아래의 TOML 오버라이드 파일
|
|
|
|
BMad 커스터마이징에 대한 자세한 가이드는 [BMad 커스터마이징 방법](../how-to/customize-bmad.md)을 참고하세요.
|