Carlomos7/commander-vault

Skill: Commander Deck Vault (lead)

Agent Role: Lead Orchestrator for building a multi-commander deck vault page.

이 스킬은 여러 커맨더(Commander) 덱을 위한 중앙 집중식 '볼트(vault)' 페이지를 자동으로 구축합니다. 사용자가 하나의 요청(예: '이 덱' 또는 특정 커맨더명)을 제공하면, 볼트는 해당 덱을 분석하고, 그 주변의 다른 브래킷(bracket)이나 커맨더로 확장하여 통합된 HTML 페이지로 결과물을 생성합니다. 이 과정은 G0에서 G5까지의 단계별 게이트(gate)를 통해 진행되며, 각 게이트는 데이터 정확성과 일관성을 보장합니다. 특히 G2의 덱 검증과 G4의 독립적 검증 단계는 오류를 최소화하고 신뢰할 수 있는 정보만을 최종 페이지에 포함시키도록 설계되었습니다. Claude Code, Cursor, Codex, Cline, Copilot 등 다양한 AI 에이전트 플랫폼에서 사용할 수 있도록 설계되었으며, mtgdb.py 스크립트를 통해 카드 데이터, 가격, 콤보 등을 정확하게 조회합니다. 또한, vault-verifier라는 독립 에이전트가 생성된 덱 목록과 주장(claims)을 재검증하여 사실과 의견을 분리하고, 검증되지 않은 정보는 '미검증' 라벨과 함께 표시함으로써 사용자에게 투명한 정보를 제공합니다.

Commander Deck Vault (lead)

안내: $ARGUMENTS

지금 로드: mtg-research 및 commander-deckbuilding (지식), 그런 다음 references/theme-rules.md를 읽으십시오. 플러그인으로 설치 시 /mtg:commander-vault로 호출됩니다. 브리프 경로: MTGDB=${CLAUDE_PLUGIN_ROOT}/scripts/mtgdb.py (mtgdb MCP 도구와 동일한 명령어, 하위 에이전트는 둘 중 하나를 사용 가능). 페이지 스크립트: PAGES=${CLAUDE_SKILL_DIR}/scripts (references/pages.md 참조). 모든 스크립트는 uv run으로 실행하십시오. 테마가 있는 볼트 실행 시 --themes vault/themed-printings.json (및 --reasons vault/<slug>/off-theme.json)을 전달하십시오.

현재 상태

test -f vault/plan.md && { echo "재개 중. plan.md:"; cat vault/plan.md; } || echo "새 실행, 여기에 vault/ 없음."
test -f deck-brief.md && { echo "진행 중인 덱. deck-brief.md:"; cat deck-brief.md; ls *.txt 2>/dev/null; } || echo "여기에 진행 중인 덱 없음."

재개: 확인되지 않은 첫 번째 게이트부터 계속하십시오. 통과된 게이트는 요청하지 않는 한 다시 수행하지 마십시오.

현재 작업 중인 덱부터 시작합니다. 요청이 비어 있거나 "이 덱"(또는 덱 파일 이름)이라고 말하고, 이 폴더나 이전 대화에 진행 중인 덱(deck-brief.md 및 이전 덱빌딩 스킬의 <commander-slug>.txt)이 있는 경우, 붙여넣기를 요청하는 대신 그 덱을 중심으로 볼트를 구축하십시오:

• 브리프가 요청을 미리 채웁니다: 커맨더, 브래킷, 하드 라인, 머니 대답, 컬렉션 선호도, 반드시/절대 포함, 테마.
• 기존 목록은 해당 브래킷의 커맨더 덱이 됩니다: vault/<slug>/b<N>.txt에 복사하고, G2 검사를 실행하며, 검사가 실패하지 않는 한 재구축하지 마십시오.
• 한 가지 질문(AskUserQuestion): "볼트에 무엇을 추가할까요?"와 함께 "이 커맨더의 인접 브래킷(권장)" · "다른 커맨더도 함께(이름 지정)" · "이 덱에 대한 페이지 하나만" (마지막 옵션: references/pages.md에 따라 렌더링하고 중지, 에이전트 필요 없음)을 선택지로 제시하십시오.

정확성 모델 (게이트가 존재하는 이유)

1. 계산된 사실(합법성, 인쇄 정보, 가격, 게임 체인저, 개수): mtgdb.py에서만 가능합니다. 에이전트는 다른 방식으로 이를 진술할 수 없습니다.
2. 출처가 있는 주장(계획, 필수 플레이, 콤보, cEDH): claims.jsonl에 기록되며, 스크립트에 의해 감사됩니다.
3. 독립 검증: 작업을 작성하지 않은 vault-verifier가 출처를 다시 열고 검사를 다시 실행합니다.
4. 리드 조정: 반박되거나 검증 불가능한 영향력이 큰 주장은 모두 사용자가 해결합니다.
5. 공개: 페이지는 데이터 날짜, 실행된 검사 및 검증되지 않은 상태로 남은 항목을 보여줍니다.

인테이크

요청은 명령 뒤에 붙여넣거나 파일로 전달되며, 일반적으로 저장소의 vault-request.md 템플릿을 따릅니다(Brackets: 2 and 3 같은 줄, 괄호 안의 텍스트는 힌트이며 답변이 아님)(섹션: 무엇에 관한 것인지, 테이블과 지갑, 당신의 카드, 페이지에 들어갈 내용). 다음을 해결하십시오: 커맨더, 브래킷 + 기본값, 예산, 가격 스타일, 하드 라인, 컬렉션 및 소유 카드 선호도, 반드시/절대 포함, 탭 그룹화, 페이지 추가 항목, 라벨 스타일(기본 중립 평결: 플레이, 좋음, 상황에 따라 다름, 바인더, 브래킷 4+, 절대 "약함" 없음), 테마(기본값 없음, 원할 경우 themes.md 인테이크 질문: 모드, 프랜차이즈, 한계, 프리미엄). 페이지 템플릿이 아직 렌더링할 수 없는 추가 항목(대체 커맨더, 컬렉션 플래너, 플레이어 간 분할)은 vault/에 Markdown 파일(alternatives.md, collection-plan.md)로 출력됩니다: 모든 배치는 해당 덱에 대해 mtgdb.py validate 색상 정체성을 통과하며, 어떤 커맨더에도 맞지 않는 카드는 색상과 함께 나열됩니다. plan.md에 템플릿 격차를 기록하십시오. 해당 항목에 대해서만 질문(AskUserQuestion, 객관식)을 하십시오. 나머지는 기본값을 사용하십시오. 사용자가 질문을 하면 답변하고 구축하지 마십시오. 커맨더가 6명 또는 덱이 18개를 초과하는 경우 규모를 제시하고 확인을 받으십시오. vault/plan.md를 작성하십시오: 입력, 슬러그, 브래킷 매트릭스, 기본값, 비용 추정치, 체크리스트 G0 ~ G5.

G0 설정 (리드)

• mtgdb.py status --remote, 그런 다음 오래된 항목(카드, 태그, 판결, 콤보, 규칙, 약 1분 소요)에 대해 mtgdb.py sync를 실행하고, 그런 다음 mtgdb.py selftest를 실행하십시오. 실패는 설명될 때까지 실행을 중단시킵니다.
• 최신 Wizards 브래킷/게임 체인저/금지 발표를 읽으십시오. commander-deckbuilding/references/brackets.md보다 최신인 경우 변경 사항을 plan.md에 기록하고 모든 브리프에 포함시키십시오.
• 애드온을 이름 읽기가 아닌 호출을 통해 확인하십시오(mtg-research 스킬(references/sources.md, "Optional MCP servers")의 애드온 규칙에 따라): 기능(EDHREC 데이터, 덱 링크, 브래킷 추정, 대본, 웹 검색)당 하나의 저렴한 호출. 응답한 기능을 plan.md에 기록하고, 누락된 각 기능에 대해 어떤 검사가 실행되지 않을지 명시하십시오.
• 테마(모드가 none인 경우 건너뜀): vault/theme-spec.json을 작성하고 theme-build로 vault/themed-printings.json을 구축하십시오(theme-rules.md). 엄격 모드의 경우 커맨더별로 theme-pool을 실행하십시오. 그런 다음 양방향 맵을 확인하십시오:
  • 오탐지: 매핑된 모든 Secret Lair 프린팅의 contact-sheet를 직접 보고 테마에서 벗어난 항목을 제거하십시오.
  • 격차: 모든 세트에서 이름, 아트(art:) 및 플레이버 텍스트(ft:)에 대해 테마 search를 실행하고 맵과 비교하십시오.
  • 최종 드롭/세트 목록을 한 줄로 사용자에게 보여주십시오.
• 최신 금지/게임 체인저 업데이트 날짜로 최신성 기준 SINCE를 설정하십시오.
• vault/config.json을 작성하십시오: {"since": SINCE, "budget": <숫자 또는 null>, "commanders": {"<slug>": 1 또는 2}}. 플러그인의 훅이 이를 읽습니다: 누군가 vault/<slug>/b<N>.txt 또는 claims*.jsonl을 쓸 때마다 훅이 이를 검증하고 실패를 작성자에게 직접 전달합니다. 훅은 게이트를 대체하지 않으며, 잘못된 파일을 조기에 차단합니다.
• 데이터 추가 사항: mtgdb.py sync prices (실행당 한 번, 가격 사다리의 공급업체 가격용), 사용자가 컬렉션을 가지고 있는 경우 collection show를 실행하고 소유 카드를 선호할지 질문하십시오.

G1 연구 (vault-researcher, 병렬, 커맨더 2~3명씩)

브리프: references/briefs.md §1. 게이트: 각 커맨더에 대해 mtgdb.py audit-claims vault/<slug>/claims.jsonl --since SINCE가 통과되고, research.md에 모든 섹션이 있어야 합니다.

G2 파일럿, 그 다음 덱 (vault-deckbuilder)

먼저 한 커맨더에 대한 기본 브래킷을 구축하십시오(§2). 해당 덱에 대해 G2 검사를 실행하십시오. 에이전트가 무언가를 잘못 읽은 경우 브리프를 수정하십시오. 그런 다음 확장하십시오. 게이트, 모든 덱, 사용자가 직접 실행(에이전트 보고서 신뢰 금지):

• mtgdb.py --themes vault/themed-printings.json validate <deck> --bracket N [--budget X]
• mtgdb.py combos <deck> (로컬 Spellbook 데이터, B1~B3: 2장 콤보 없음) 및 애드온이 제공하는 경우 브래킷 추정
• themed_printing_available 경고 수정 또는 정당화
• 모든 consider.json 페어링이 swaptest 통과

G3 병합 (vault-merger, 탭당 하나)

§3. 게이트: merged.json의 모든 카드가 해당 탭의 consider.json 파일 중 하나 이상에 나타나야 함, 개수 일치, 모든 페어링이 swaptest 통과 (직접 25% 표본 재실행, B3 이하는 모두)

G4 검증 (vault-verifier, 새 컨텍스트, 커맨더 3~4명당 하나)

§4. 영향력이 큰 주장의 100%와 나머지의 20% 표본을 검증하고, 모든 덱 검사를 재실행하며, 아트를 보고 분쟁 중인 프린팅을 확인합니다. 게이트: mtgdb.py audit-claims vault/<slug>/claims.verified.jsonl --since SINCE --require-verified가 통과하고, verification.md의 모든 refuted / unverifiable 항목이 사용자에 의해 해결됨: 수정, 제거 또는 눈에 띄는 "미검증" 라벨과 함께 유지.

G5 페이지 (리드, references/pages.md 따름)

1. site_data.py init vault/site-data.json (--themes 포함 가능), 그런 다음 각 덱에 대해 add-deck (에이전트의 deck-notes.md를 덱당 notes.json으로 요약), 티어 탭당 add-tier (EDHREC 번호와 n), 탭당 add-swaps, 모든 claims.verified.jsonl로 add-claims.
2. build_site.py vault/site-data.json --out vault/site. 모든 오류를 수정하십시오.
3. pages.md의 4단계와 5단계를 따르십시오: 데스크톱 및 390px에서 보고, mtgdb.py로 무작위 카드 10장을 점검하고, 게시하십시오.
4. 몇 줄로 답변하십시오: 포함 내용, 테마 수(테마 볼트), 정확성 요약(검증된 주장/미검증 라벨, 데이터 날짜), 수락된 예외.

페이지를 수동으로 구축하거나 스타일을 변경하지 마십시오. 템플릿에 모든 볼트에 필요한 것이 누락된 경우 plan.md에 나중을 위한 템플릿 변경 사항으로 기록하십시오.

실행 중 변경 사항 처리

• 사용자 방향 변경(새 브래킷 포커스, 테마 규칙, 예산): 먼저 plan.md와 config.json을 업데이트한 다음, 실행 중인 모든 에이전트에 정확한 변경 사항을 SendMessage하고, 이전 규칙으로 이미 구축된 모든 항목을 다시 게이트하십시오.
• 에이전트 중단(세션 재시작, 충돌): 어떤 파일이 존재하는지 확인하고, 누락된 작업만 다시 시작하거나 작업이 적은 경우 직접 수행하십시오. 실행 중이 아닌 에이전트를 기다리지 마십시오.
• 도구 다운: 어떤 검사가 실행되지 않았는지 말하고 영향을 받은 항목을 미검증으로 표시하십시오. 수동으로 격차를 메우지 마십시오.

규모 및 비용 (인테이크에서 결정, plan.md에 기록)

대략적인 에이전트 시간: 연구에 커맨더당 약 10~20분, 덱 구축에 약 10분, 검증은 구축 시간의 약 절반. 12명의 커맨더, 40개 덱 볼트는 몇 시간 동안 실행되었습니다.

• 기본 범위: 사용자의 브래킷과 그 위의 하나. B5는 요청 시에만, 그리고 실제 cEDH 증거(EDHTop16 항목)가 있는 커맨더에 대해서만. 다른 커맨더의 경우 아무도 플레이하지 않을 B5 목록을 구축하는 대신 "실제 cEDH 커맨더가 아닙니다"라고 말하십시오.
• 기본 크기: 최대 6명의 커맨더. 그 이상은 먼저 추정치를 확인하거나 여러 볼트로 분할하십시오.
• 검증기 범위: 영향력이 큰 주장의 100%, 단 커맨더당 40개로 제한. 더 많은 경우 페이지에 표시되는 40개(필수 플레이, 콤보, cEDH)를 검증하고 나머지는 미검증으로 표시하십시오.
• 선택적 대용량 데이터: prices-sync --history (대규모 다운로드)는 페이지가 가격 추세를 표시하는 경우에만.
• 건너뛰어도 되는 항목: B5의 커뮤니티 패스 없음(토너먼트 데이터가 결정), EDHREC 덱이 약 200개 미만인 커맨더에 대한 YouTube 연구 없음(콘텐츠가 거의 없음, 데이터 및 Spellbook만).
• 절대 생략 금지: 검증, Spellbook 콤보 확인, 훅, 테마 맵 확인, G5 렌더 확인.

비용 및 컨텍스트

• 에이전트는 파일을 작성하고 짧은 보고서를 반환합니다. 게이트에서만 파일을 읽으십시오.
• 카드당 실시간 Scryfall 호출 없음, 인덱스가 처리합니다.
• 재개된 실행이 알 수 있도록 plan.md에 모든 수정 사항을 기록하십시오.