wiki-context

위키 매니페스트(.wiki/wiki-manifest.yaml)를 읽고, 현재 작업에 맞는 컨텍스트 프로파일을 선택하여 문서 목록을 어셈블하는 스킬이다.

사전 요구

이 스킬은 /wiki 스킬로 구성된 위키 환경이 필요합니다.

#	검증	실패 시
1	CWD 루트에 .wiki 심볼릭 링크가 존재하고 정상 동작	"/wiki 스킬로 위키 환경을 먼저 구성해주세요. npx skills add dev-goraebap/agent-wiki-hub --all -g로 전체 설치할 수 있습니다"
2	.wiki/wiki-manifest.yaml이 존재	"매니페스트가 없습니다. /wiki 스킬로 위키를 다시 생성하거나, 수동으로 wiki-manifest.yaml을 만들어주세요"
3	매니페스트 YAML이 정상 파싱됨	"매니페스트 YAML이 깨졌습니다. 파일을 확인해주세요" + 파싱 에러 메시지 표시

워크플로우

1. 프로파일 선택

아래 순서대로 프로파일을 결정한다:

1. 사용자 직접 지정 — 요청에 프로파일명이 포함되면 해당 프로파일 사용

   • "구현 컨텍스트" → implementation
   • "디버그 컨텍스트" → debug
   • "리뷰 컨텍스트" → review
   • "계획 컨텍스트" → planning
   • 매니페스트에 없는 프로파일명이면 에러: "프로파일 {name}이 매니페스트에 없습니다. 사용 가능: {목록}"

2. Git 브랜치에서 추론 — 사용자가 프로파일을 지정하지 않은 경우

   • feat/*, fix/*, refactor/*, chore/* → implementation
   • hotfix/* → debug
   • main, develop → planning
   • 그 외 (release/*, detached HEAD, custom 등) → planning

3. 기본값 — Git 레포가 아닌 경우 등 → planning

프로파일이 자동 추론된 경우, 사용자에게 확인 메시지를 표시한다:

"현재 브랜치 feat/login에서 implementation 프로파일을 선택했습니다. 다른 프로파일을 원하시면 말씀해주세요."

2. 문서 어셈블 (4단계)

선택된 프로파일에서 문서를 수집한다. 반드시 아래 순서대로 실행한다:

1단계: extends 해석

• 프로파일에 extends 필드가 있으면 부모 프로파일의 load-order를 가져온다
• 부모의 load-order 뒤에 자식의 load-order를 연결한다
• 중복 타입은 마지막 출현만 유지한다 (자식 우선)
• max-docs는 자식이 명시하면 자식 값, 아니면 부모 값 상속
• description은 자식이 override
• 단일 레벨만 지원: 부모 프로파일이 또 extends를 가지면 에러
• 순환 참조 감지: A extends B이고 B extends A이면 에러
• 존재하지 않는 프로파일 참조: 에러 메시지 표시

2단계: scope 필터

• CWD에서 git rev-parse --show-toplevel로 Git 루트 경로를 얻는다
• 루트 경로의 폴더명을 현재 scope로 사용 (예: /Users/devgo/Workspace/my-app → my-app)
• Git 레포가 아니면 scope 필터링을 건너뛴다 (모든 문서 포함)
• documents에서 scope == 현재 scope 이거나 scope가 없는 문서만 남긴다 (scope 매칭은 case-insensitive로 수행한다. 예: 폴더명 MyApp과 scope myapp은 동일하게 취급)
• 모노레포에서는 Git 루트 폴더명이 scope가 된다. 서브디렉토리 수준 분리가 필요하면 문서의 scope 필드를 명시적으로 설정한다

3단계: load-order 매칭

• load-order의 각 항목은 SDLC 범주 또는 구체적 타입명이다
• SDLC 범주 (planning, design, implementation, testing, deployment, operations):
  • 문서의 category 필드와 매칭한다
  • category가 없으면 디렉토리 경로에서 추론한다 (planning/ 하위 → planning 등)
  • 해당 범주의 모든 문서가 후보가 된다. created 최신순으로 정렬
• 구체적 타입명 (그 외 문자열):
  • 문서의 type 필드와 정확히 매칭한다
  • 같은 타입이 여러 개이면 created 최신순으로 1개 선택
• created가 없는 문서는 배열 순서 마지막(=최신 등록)으로 간주한다

4단계: max-docs 적용

• 전체 문서 수가 max-docs (기본값 5)를 초과하면, load-order 순서대로 우선 포함하고 나머지 제외
• scope 필터 후 문서가 max-docs보다 적으면 그대로 반환 (백필하지 않음)
• 각 문서의 path가 실제로 존재하는지 확인
  • 존재하지 않는 문서는 고아(orphan)로 표시

3. 출력 형식

## 컨텍스트: {프로파일명} ({N} documents, scope: {scope})

1. [{type}] {path} — tags: {tags}
2. [{type}] {path} — tags: {tags}
({type} 타입 문서 없음 — 해당 타입 건너뜀)

⚠ [orphan] {path} — 파일이 존재하지 않음

에이전트는 이 목록을 보고 필요한 문서만 선택적으로 Read한다. 전체 내용을 자동으로 concat하지 않음 — 에이전트의 판단에 위임한다.