Stats
Actions
Tags
How this skill is triggered — by the user, by Claude, or both
Slash command
/oh-my-gx:gx-context [도메인명] [--from <파일경로>] [--sync][도메인명] [--from <파일경로>] [--sync]This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
도메인 컨텍스트를 관리한다. 상황에 따라 자동으로 적절한 모드를 선택한다.
도메인 컨텍스트를 관리한다. 상황에 따라 자동으로 적절한 모드를 선택한다.
Arguments 문자열에서 아래 규칙으로 파싱한다:
--from <경로>: --from 다음 토큰을 파일 경로로 사용. 경로에 공백이 있으면 따옴표로 감싸진 것으로 간주.--sync: 진행도 동기화 모드. git 히스토리 기반으로 status.md 갱신.--from과 --sync를 제외한 나머지 토큰: 도메인명으로 사용.--sync와 --from은 동시 사용 불가. 동시 지정 시 "--sync와 --from은 동시에 사용할 수 없습니다." 안내 후 중단.--from, --sync 모두 없음.예시:
결제 → 도메인명=결제, from=없음, sync=없음정산 --from docs/req.md → 도메인명=정산, from=docs/req.md--from docs/req.md → 도메인명=없음, from=docs/req.md결제 --sync → 도메인명=결제, sync=true(Recommended) 라벨로 반드시 제시한다.인자와 현재 상태를 기반으로 모드를 결정한다:
| 조건 | 모드 | 동작 |
|---|---|---|
context/ 폴더 없음 + 인자 없음 | 스캔 | 코드베이스 분석 → context 초안 자동 생성 |
context/ 폴더 없음 + 도메인명 지정 | 스캔+신규 | 코드베이스 스캔 후 해당 도메인 우선 생성 |
context/ 있음 + 도메인명 지정 + --from 없음 | 신규 | Q&A 기반 새 도메인 생성 |
context/ 있음 + 도메인명 지정 + --from <파일> | 문서 기반 | 파일 읽고 → 내용 기반으로 context 생성/갱신 |
context/ 있음 + --from <파일> + 도메인명 없음 | 문서 기반 | 파일에서 도메인명을 추론하여 생성/갱신 |
context/ 있음 + 인자 없음 | 선택 | 사용자에게 질문: 새 도메인 추가 / 기존 도메인 갱신 / 코드베이스 재스캔 |
context/{도메인}/ 이미 존재 + --from <파일> | 갱신 | 파일 읽고 기존 context와 비교 → 변경 제안 |
context/{도메인}/ 이미 존재 + --from 없음 | 갱신 | 사용자에게 갱신 대상 확인 후 Q&A |
context/{도메인}/ 존재 + --sync | 동기화 | git log/PR 분석 → status.md 갱신 |
context/ 폴더가 없거나 사용자가 재스캔을 선택한 경우 실행한다.
AskUserQuestion(
questions: [{
header: "context 생성",
question: "context/ 디렉토리가 없습니다. 코드베이스를 분석하여 도메인 구조를 자동 생성할까요?",
multiSelect: false,
options: [
{ label: "자동 생성", description: "코드베이스 스캔으로 도메인 구조를 자동 생성합니다" },
{ label: "수동 생성", description: "모드 B(신규)로 전환하여 수동 생성합니다" }
]
}]
)
아래 항목을 병렬로 탐색한다:
src/ 하위 최상위 2레벨을 스캔하여 도메인 분류를 추론한다.
src/main/java/{base-package}/ 하위 패키지를 도메인 후보로 식별src/ 하위 디렉토리 구조를 분석 (modules/, features/, domains/ 등)*Entity.java, *.entity.ts, *Model.* 등 도메인 모델 파일을 탐색한다.*Controller.java, *Router.*, routes/ 등을 스캔한다.application.yml, application.properties, .env, package.json 등을 읽는다.README.md, docs/ 디렉토리를 확인한다.스캔 결과에서 도메인을 추론한다:
com.example.payment → 결제 도메인/api/orders/** → 주문 도메인각 감지된 도메인에 대해:
mkdir -p context/{도메인}/context/ 루트 파일 초기화 (필요시):
test -f context/README.md 가 false인 경우, B-0과 동일하게 context/README.md 생성test -f context/glossary.md 가 false인 경우, B-0과 동일하게 context/glossary.md 생성git remote get-url origin, svn: svn info --show-item repos-root-url에서 레포명 추출)생성된 초안을 사용자에게 보여주고 확인을 받는다:
사용자 확인 후:
context/README.md 도메인 테이블을 업데이트한다.Q&A 기반으로 새 도메인을 생성한다.
프로젝트 루트에 context/ 디렉토리가 없으면 자동 생성한다:
test -d context/ 로 존재 여부 확인mkdir -p context/context/README.md 생성 (도메인 목록 인덱스 템플릿):
# 프로젝트 컨텍스트
도메인 지식, 아키텍처, 용어 사전을 정리하는 공간입니다.
## 도메인
| 도메인 | 설명 | 상세 |
|--------|------|------|
## 공통
- [공통 용어 사전](glossary.md)
context/glossary.md 생성 (공통 용어 사전 스켈레톤):
# 공통 용어 사전
> 도메인을 가리지 않고 프로젝트 전체에서 쓰이는 용어입니다.
> 도메인별 용어는 `context/{도메인}/glossary.md`를 참조하세요.
| 용어 | 설명 |
|------|------|
AskUserQuestion(
questions: [{
header: "도메인명",
question: "등록할 도메인명과 한 줄 설명을 입력해주세요. (예: payment — 결제 처리)",
multiSelect: false,
options: [
{ label: "Other로 입력", description: "Other로 이동해서 도메인명과 설명을 자연어로 입력해주세요" },
{ label: "취소", description: "도메인 등록을 중단합니다" }
]
}]
)
context/{도메인}/이 이미 존재하면 다음과 같이 묻는다:
AskUserQuestion(
questions: [{
header: "기존 도메인",
question: "'{도메인}'은 이미 존재합니다. 어떻게 진행할까요?",
multiSelect: false,
options: [
{ label: "갱신", description: "기존 도메인의 context를 갱신합니다 (모드 D)" },
{ label: "취소", description: "작업을 중단합니다" }
]
}]
)
아래 5개 질문을 프레임으로 삼아 1개씩 순차적으로 질문한다. 각 답변에 따라 다음 행동이 결정된다.
질문 프레임 (순서대로):
순차 질문 루프 (모든 프레임이 완전히 해소될 때까지):
현재 프레임의 질문을 AskUserQuestion(questions: [질문 1개])으로 제시한다. 권장 답변(코드베이스/git blame/맥락에서 추정한 답)을 options 첫 번째에 (Recommended) 라벨로 제시한다. 단, Q1(문제)·Q3(안 하면) 같은 주관 영역으로 추정이 어색한 경우, 발상 기준점을 주기 위해 예시 후보 1개를 { label: "예: ..." } 형식으로 대체 제시한다.
options 구조:
{ label: "{권장 답변} (Recommended)", description: "권장 답변 설명" }{ label: "예: {예시}", description: "발상 기준점" } (선택적){ label: "Other로 입력", description: "Other로 이동해서 자연어로 답변을 입력해주세요" }{ label: "모르겠음", description: "아직 불명확합니다" }답변을 평가한다:
모든 프레임이 해소되면 공유 이해 확인(align) 단계를 거친다. 수렴된 답변을 "프레임 → 답변" 형식으로 요약하여 다음과 같이 확인한다:
AskUserQuestion(
questions: [{
question: "정리된 답변을 context 작성에 사용하기 전에 확인해주세요.\n\nQ1: 문제 → ...\nQ2: 현재 프로세스 → ...\nQ3: 안 하면 → ...\nQ4: 사용자/규모 → ...\nQ5: 담당 → ...",
header: "정리 확인",
options: [
{ label: "맞습니다 (Recommended)", description: "이대로 context 작성으로 진행" },
{ label: "수정 필요", description: "Other로 이동해서 수정할 질문 번호와 새 답변을 입력해주세요 (예: 'Q3: 마이그레이션 리스크 누적')" }
],
multiSelect: false
}]
)
"맞습니다"면 B-4로 진행. "수정 필요"면 사용자가 Other에 입력한 Q번호: 새 답변 패턴을 파싱하여 해당 프레임을 재질문 큐에 추가한 뒤 루프 재진입한다. 입력이 패턴과 일치하지 않거나 번호를 식별할 수 없으면, 어떤 프레임을 수정할지 선택형 질문으로 다시 묻는다.
모호함 판단 기준:
파고들기 예시:
AskUserQuestion(
questions: [{
header: "관련 레포",
question: "이 도메인과 관련된 GHE 레포가 있습니까? (예: xx/factory-api, yy/factory-admin)",
multiSelect: false,
options: [
{ label: "Other로 입력", description: "Other로 이동해서 관련 레포 목록을 자연어로 입력해주세요" },
{ label: "없음", description: "빈 테이블로 생성합니다" }
]
}]
)
Other로 입력받은 레포 목록을 파싱하여 각 레포의 역할도 함께 기록한다. "없음"이면 빈 테이블로 생성한다.
mkdir -p context/{도메인}/ 로 도메인 디렉토리를 생성한다.
context/{도메인}/
├── README.md ← 검증 질문 답변 정리
├── PROJECTS.md ← 관련 프로젝트(레포) 목록
├── glossary.md ← 용어 사전 스켈레톤
├── architecture.md ← 전체 구조 요약 + 주제 문서 링크 (인덱스)
└── status.md ← 구현 추적
검증 질문 답변을 아래 구조로 정리한다:
# {도메인명}
{한 줄 설명}
## 배경
{문제 + 현재 프로세스를 서술형으로 정리}
## 안 하면 어떻게 되는가
{답변 정리. 정량 수치 포함}
## 사용자와 규모
{누가, 몇 명, 얼마나 자주}
## 성공 기준
{정량적 기준. 미확인 시 ❓ 표기}
## 담당자
| 역할 | 이름 | 비고 |
|------|------|------|
| PM/PO | {이름} | |
| 개발 리드 | {이름} | |
## 현재 상태
탐색 중
# {도메인명} 관련 프로젝트
| 레포 | 역할 | 담당 |
|------|------|------|
| {org/repo} | {역할} | {담당자} |
관련 레포가 없으면 빈 테이블로 생성한다.
# {도메인명} 용어 사전
| 용어 | 설명 |
|------|------|
# {도메인명} 아키텍처
> 전체 구조 요약과 주제별 상세 문서 링크를 관리합니다.
## 시스템 구조
(확정 시 작성)
## 주제 문서
| 주제 | 설명 |
|------|------|
# {도메인명} 구현 추적
> PRD 요구사항별 구현 상태를 추적합니다.
## 범례
- ✅ 반영됨 — 코드에 구현 완료
- ⬜ 미반영 — 정책/설계만 확정, 코드 미구현
context/README.md의 도메인 테이블에 새 행을 추가한다.
생성된 파일 목록과 ❓ 항목(있다면)을 안내한다.
PM이 정리한 텍스트 파일을 읽어서 context를 생성하거나 갱신한다.
--from 으로 지정된 파일을 Read한다.
.md, .txt, .pdf (PDF는 최대 20페이지).png, .jpg): Read로 멀티모달 분석파일 내용에서 다음을 추출한다:
문서에서 추출한 내용을 아래 형식으로 사용자에게 먼저 보여준다:
📄 문서 분석 결과
- 도메인명: {추론한 도메인명 또는 ❓}
- 배경/문제: {추출한 내용 요약 또는 ❓}
- 요구사항: {추출한 FR/NFR 수} 건
- 용어: {추출한 용어 수} 건
- 아키텍처: {추출 여부}
- 담당자: {추출한 정보 또는 ❓}
아래 5개 항목을 1개씩 순차적으로 질문한다. 문서에서 이미 파악된 항목은 확인형으로, 파악되지 않은 항목은 개방형으로 제시한다.
질문 프레임 (순서대로):
순차 질문 루프 (모든 프레임이 완전히 해소될 때까지):
현재 프레임을 AskUserQuestion(questions: [질문 1개])으로 제시한다. 확인형이든 개방형이든 권장 답변(문서에서 추출된 내용 또는 합리적 추정)을 options 첫 번째에 (Recommended) 라벨로 반드시 제시한다.
options: [
{ label: "맞습니다 (Recommended)", description: "다음 항목으로 이동" },
{ label: "수정 필요", description: "Other로 이동해서 수정/보완 내용을 자연어로 입력해주세요" }
]
options: [
{ label: "{권장 답변} (Recommended)", description: "권장 답변 설명" },
{ label: "Other로 입력", description: "Other로 이동해서 자연어로 답변을 입력해주세요" },
{ label: "모르겠음", description: "아직 불명확합니다" }
]
답변을 평가한다. 확인형의 "수정 필요" + Other 입력은 개방형 응답과 동일한 평가 규칙을 적용한다:
모든 프레임이 해소되면 공유 이해 확인(align) 단계를 거친다. B-2의 align 절차와 동일하게 Q → A 요약을 { label: "맞습니다 (Recommended)" } / { label: "수정 필요" } 형태로 확인한다. "수정 필요" 시 Q번호: 새 답변 패턴 파싱 및 패턴 불일치 시 선택형 재질문 규칙도 B-2와 동일. "맞습니다"면 C-4로 진행. "수정 필요"면 해당 프레임을 재질문하여 루프 재진입한다.
모호함 판단 기준 및 파고들기 방식: 모드 B-2와 동일하게 적용한다.
context/{도메인}/이 없으면: 모드 B의 B-5~B-11 절차로 디렉토리와 문서를 생성한다. 다만 Q&A 답변 대신 파일에서 추출한 내용을 사용한다.context/{도메인}/이 이미 있으면: 모드 D(갱신)로 진행한다. 파일 내용과 기존 context를 비교하여 변경 제안을 생성한다.기존 도메인의 context를 갱신한다.
context/{도메인}/의 README.md, glossary.md, architecture.md를 Read한다.
--from 파일이 있으면: 파일 내용과 기존 context를 비교하여 변경 항목을 식별한다.--from 없으면:
AskUserQuestion(
questions: [{
header: "갱신 항목",
question: "어떤 내용을 갱신하시겠습니까?",
multiSelect: true,
options: [
{ label: "용어 추가", description: "glossary.md에 새 용어를 추가합니다" },
{ label: "아키텍처 변경", description: "architecture.md를 갱신합니다" },
{ label: "담당자 변경", description: "README.md의 담당자 정보를 갱신합니다" }
]
}]
)
변경 항목을 구체적으로 제안한다:
사용자가 승인한 변경만 Edit으로 반영한다. 문서 수정 시 수정일을 갱신한다.
/gx-dev를 거치지 않고 개발한 내용을 git 히스토리에서 분석하여 status.md를 갱신한다.
--sync 사용 시 도메인명은 필수. 없으면 context/ 하위 도메인 목록을 수집하여 다음과 같이 선택을 요청한다:
AskUserQuestion(
questions: [{
header: "도메인 선택",
question: "동기화할 도메인을 선택해주세요.",
multiSelect: false,
options: [
{ label: "<도메인1>", description: "context/<도메인1>/" },
{ label: "<도메인2>", description: "context/<도메인2>/" }
]
}]
)
context/{도메인}/status.md ReadPENDING_ITEMS 배열로 저장git log --oneline -20으로 최근 커밋 20개 확인. svn: svn log -l 20으로 최근 커밋 20개 확인.gh pr list --state merged --limit 10으로 최근 머지된 PR 확인 (gh 없으면 건너뜀). svn: 건너뜀 (PR 개념 없음).PENDING_ITEMS의 FR/AC/설명과 매칭되는 항목을 식별status.md 동기화 분석 결과:
1. ✅ AC-1 (FR-1): 로그인 기능 — 커밋 a1b2c3d "feat: 로그인 기능 추가"
2. ✅ AC-4 (FR-16): 비밀번호 변경 — PR #125 "FEATURE: 비밀번호 변경"
3. ⬜ AC-2 (FR-2): 회원가입 — 매칭되는 커밋/PR 없음
위 항목을 반영할까요?
다음과 같이 확인한다. 사용자가 항목을 조정할 수 있다 (제외/추가).
AskUserQuestion(
questions: [{
header: "status.md 갱신",
question: "위 항목을 status.md에 반영할까요?",
multiSelect: false,
options: [
{ label: "전체 반영", description: "제안된 항목을 모두 반영합니다" },
{ label: "조정 후 반영", description: "Other로 제외/추가할 항목을 지정합니다" },
{ label: "건너뛰기", description: "갱신하지 않고 종료합니다" }
]
}]
)
사용자가 승인한 항목만 Edit으로 반영:
status.md 갱신 완료: ✅ {N}건 반영 (AC-1, AC-4)
남은 미반영: ⬜ {M}건
아래는 /gx-dev 환류 등으로 주제 문서를 생성할 때 사용하는 헤더 형식이다. /gx-context 실행 시에는 생성하지 않는다.
# {제목}
- 작성일: YYYY-MM-DD
- 수정일: YYYY-MM-DD
- 관련 레포: {org/repo}
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub bs-koo/oh-my-gx --plugin oh-my-gx