Communitygithub.com

trace

증거 기반 추적 레인으로, Claude 내장 팀 모드에서 경쟁하는 추적 가설을 오케스트레이션합니다.

trace란 무엇인가요?

이 스킬은 모호하고 인과 관계가 중요하며 증거가 많이 필요한 질문(예: 런타임 버그, 성능 저하, 아키텍처 분석)을 해결하기 위해 설계된 오케스트레이션 레이어입니다. Claude 내장 팀 모드 위에서 동작하며, 관찰 결과를 재진술하고, 여러 경쟁 가설을 생성한 후, 병렬로 증거를 수집하고 순위를 매겨 최종 설명을 제시합니다. 기본적으로 코드 경로, 구성/환경, 측정/가정 불일치라는 세 가지 추적 레인을 제공하며, 각 레인은 전담 트레이서 워커가 담당합니다. 또한 반박 라운드를 통해 최고 가설을 검증하고, 시스템/프리모템/과학 렌즈를 적용하여 더 강건한 결론을 도출하도록 돕습니다.

지원 대상✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Yeachan-Heo/oh-my-claudecode/tree/main/skills/trace

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

Trace Skill

이 스킬은 모호하고, 인과 관계가 중요하며, 증거가 많이 필요한 질문에 사용하세요. 목표는 관찰된 결과가 왜 발생했는지 설명하는 것이며, 코드를 즉시 수정하거나 재작성하는 것이 아닙니다.

이는 내장 tracer 에이전트 위의 오케스트레이션 레이어입니다. 목표는 추적을 재사용 가능한 OMC 운영 레인으로 만드는 것입니다: 관찰 내용을 재진술하고, 경쟁 설명을 생성하며, 병렬로 증거를 수집하고, 설명을 순위화하며, 불확실성을 가장 빠르게 줄일 수 있는 다음 탐침을 제안합니다.

적절한 사용 사례

/oh-my-claudecode:trace는 다음과 같은 문제에 사용하세요:

  • 모호함
  • 인과 관계
  • 증거 중심
  • 병렬로 경쟁 설명을 탐색하는 것이 가장 좋은 답변

예시:

  • 런타임 버그 및 회귀
  • 성능 / 지연 시간 / 리소스 동작
  • 아키텍처 / 프리모템 / 포스트모템 분석
  • 과학적 또는 실험적 결과 추적
  • 설정 / 라우팅 / 오케스트레이션 동작 설명
  • "이 출력이 주어졌을 때, 가능한 원인을 추적하라"

핵심 추적 계약

항상 다음 구분을 유지하세요:

  1. 관찰 -- 실제로 관찰된 것
  2. 가설 -- 경쟁 설명
  3. 지지 증거 -- 각 설명을 뒷받침하는 것
  4. 반증/결함 증거 -- 이를 반박하거나 아직 누락된 것
  5. 현재 최선의 설명 -- 현재 최고의 설명
  6. 중요한 미지수 -- 상위 설명들을 구분 짓는 누락된 사실
  7. 판별 탐침 -- 불확실성을 줄이기 위한 가장 가치 있는 다음 단계

다음으로 축소하지 마세요:

  • 일반적인 수정-코딩 루프
  • 일반적인 디버거 요약
  • 워커 출력의 원시 덤프
  • 증거가 불완전할 때의 가짜 확실성

증거 강도 계층

증거를 평평하지 않고 순위가 매겨진 것으로 취급하세요.

강한 순서대로:

  1. 통제된 재현 / 직접 실험 / 고유하게 판별하는 아티팩트
  2. 엄격한 출처 증명이 있는 1차 소스 아티팩트 (추적 이벤트, 로그, 메트릭, 벤치마크 출력, 설정, git 히스토리, 파일:라인 동작)
  3. 동일한 설명으로 수렴하는 여러 독립적인 출처
  4. 단일 소스 코드 경로 또는 동작 추론
  5. 약한 상황 증거 (타이밍, 명명, 스택 순서, 이전 버그와의 유사성)
  6. 직관 / 유추 / 추측

더 강한 반증 증거가 존재할 때 하위 계층에 주로 의존하는 가설은 명시적으로 순위를 낮추세요.

강력한 반증/반증 규칙

모든 중요한 /trace 실행은 자신이 선호하는 설명을 반증하려고 시도해야 합니다.

각 상위 가설에 대해:

  • 지지 증거 수집
  • 반대 증거 수집
  • 그것이 만들어내는 독특한 예측을 명시
  • 그것과 조화시키기 어려운 관찰을 명시
  • 그것을 차선책과 구분할 수 있는 가장 저렴한 탐침을 식별

다음과 같은 경우 가설의 순위를 낮추세요:

  • 직접 증거가 그것을 반박할 때
  • 새로운 검증되지 않은 가정을 추가함으로써만 유지될 때
  • 경쟁자와 비교하여 독특한 예측을 하지 못할 때
  • 더 강한 대안이 더 적은 가정으로 동일한 사실을 설명할 때
  • 지지가 대부분 상황 증거이며 경쟁자가 더 강한 증거 계층을 가질 때

팀 모드 오케스트레이션 형태

/trace에 Claude 내장 팀 모드를 사용하세요.

리드는 다음을 수행해야 합니다:

  1. 관찰된 결과 또는 "왜" 질문을 정확히 재진술
  2. 추적 대상을 추출
  3. 의도적으로 다른 여러 후보 가설 생성
  4. 팀 모드에서 기본적으로 3개의 추적 레인 생성
  5. 레인당 하나의 트레이서 워커 할당
  6. 각 트레이서 워커에게 해당 레인에 대한 지지 및 반대 증거 수집 지시
  7. 최고 가설과 가장 강력한 나머지 대안 간의 반박 라운드 실행
  8. 상위 레인이 진정으로 다른지 또는 실제로 동일한 근본 원인으로 수렴하는지 감지
  9. 명시적인 중요한 미지수와 판별 탐침이 포함된 순위 합성으로 결과 병합

중요: 워커는 동일한 설명을 병렬로 추구하지 말고 의도적으로 다른 설명을 추구해야 합니다.

v1의 기본 가설 레인

프롬프트가 더 나은 분할을 강력히 제안하지 않는 한, 다음 3개의 기본 레인을 사용하세요:

  1. 코드 경로 / 구현 원인
  2. 설정 / 환경 / 오케스트레이션 원인
  3. 측정 / 아티팩트 / 가정 불일치 원인 -- 시스템 결함뿐만 아니라 검증 방법 결함도 다룹니다. 예: 검증 쿼리가 여러 엔티티, 테넌트, 스트림 또는 그룹에서 단일 차원 키를 재사용합니다. 비교 필터 모양이 스키마 그레인과 일치하지 않습니다. 또는 카탈로그 또는 컬럼 이름이 열거 없이 런타임 간에 이식 가능하다고 가정했습니다. 여기에는 다중 엔티티 전제/키-가정 불일치가 포함됩니다.

레인 3의 경우, 교차 엔터티 불일치는 확대 전에 전제 감사가 필요합니다: 엔터티 차원을 열거하고 결과가 시스템 결함이 아닌 여러 엔터티에 하나의 키를 적용하여 0-행 또는 불일치 결과가 발생했는지 확인하세요. 결과는 검증 방법론 결함일 수 있습니다.

이 기본값은 의도적으로 광범위하여 첫 번째 슬라이스가 버그, 성능, 아키텍처 및 실험 추적 전반에서 작동하도록 합니다.

필수 교차 확인 렌즈

초기 증거 패스 후, 관련이 있을 때 다음 렌즈로 선두를 압력 테스트하세요:

  • 시스템 렌즈 -- 큐, 재시도, 백프레셔, 피드백 루프, 업스트림/다운스트림 종속성, 경계 실패, 조정 효과
  • 프리모템 렌즈 -- 현재 최선의 설명이 불완전하거나 틀렸다고 가정하세요. 어떤 실패 모드가 나중에 추적을 당황스럽게 만들까요?
  • 과학 렌즈 -- 통제, 교란 변수, 측정 편향, 대안 변수, 반증 가능한 예측

이 렌즈는 단순한 채우기가 아닙니다. 놓친 설명, 숨겨진 종속성 또는 약한 추론을 표면화할 수 있을 때 사용하세요.

워커 계약

각 워커는 일반 실행자가 아닌 tracer 레인 소유자여야 합니다.

각 워커는 다음을 수행해야 합니다:

  • 정확히 하나의 가설 레인 소유
  • 해당 레인 가설을 명시적으로 재진술
  • 레인에 대한 지지 증거 수집
  • 레인에 대한 반대 증거 수집
  • 자신의 주장 뒤에 있는 증거 강도 순위 매기기
  • 누락된 증거, 실패한 예측 및 남은 불확실성 지적
  • 레인에 대한 중요한 미지수 명명
  • 최선의 레인별 판별 탐침 권장
  • 명시적으로 지시되지 않는 한 구현으로 축소하지 않음

유용한 증거 출처:

  • 관련 코드, 테스트, 설정, 문서, 로그, 출력 및 벤치마크 아티팩트
  • trace_timeline을 통한 기존 추적 아티팩트
  • trace_summary를 통한 기존 집계 추적 증거

권장 워커 반환 구조:

  1. 레인
  2. 가설
  3. 지지 증거
  4. 반증/결함
  5. 증거 강도
  6. 중요한 미지수
  7. 최선의 판별 탐침
  8. 신뢰도

리드 합성 계약

최종 /trace 답변은 단순히 연결하지 않고 합성해야 합니다.

반환:

  1. 관찰된 결과
  2. 순위별 가설
  3. 가설별 증거 요약
  4. 반증/누락 증거
  5. 반박 라운드
  6. 수렴/분리 참고 사항
  7. 가장 가능성 높은 설명
  8. 중요한 미지수
  9. 권장 판별 탐침
  10. 추가 추적 레인 (선택 사항, 불확실성이 여전히 높은 경우에만)

하나의 설명이 현재 우세하더라도 순위가 매겨진 후보 목록을 유지하세요.

반박 라운드 및 수렴 감지

추적을 종료하기 전에:

  • 가장 강력한 비선두 가설이 현재 선두에 대한 최선의 반박을 제시하도록 하세요
  • 선두가 주장이 아닌 증거로 반박에 답변하도록 강제하세요
  • 반박이 선두를 실질적으로 약화시키면 순위표를 다시 매기세요
  • 두 개의 "다른" 가설이 동일한 기본 메커니즘으로 축소되면 병합하고 명시적으로 말하세요
  • 두 가설이 여전히 다른 다음 탐침을 암시하면 비슷하게 들리더라도 분리하여 유지하세요

여러 워커가 유사한 언어를 사용한다고 해서 수렴을 주장하지 마세요. 수렴은 다음 중 하나가 필요합니다:

  • 동일한 근본 인과 메커니즘, 또는
  • 동일한 설명을 가리키는 독립적인 증거 스트림

명시적 순위 하향 지침

리드는 왜 가설이 아래로 이동했는지 명시적으로 말해야 합니다:

  • 더 강한 증거에 의해 반박됨
  • 예측한 관찰이 없음
  • 추가 임시 가정 필요
  • 선두보다 더 적은 사실을 설명함
  • 반박 라운드에서 패배
  • 더 강한 상위 설명으로 수렴됨

이는 /trace가 독자에게 단순히 최종 표를 제시하는 것이 아니라 왜 한 설명이 다른 설명보다 우위에 있는지 가르쳐야 하기 때문에 중요합니다.

제안된 리드 프롬프트 스켈레톤

팀 지향 오케스트레이션 프롬프트를 다음과 같이 사용하세요:

  1. "관찰을 정확히 재진술하세요."
  2. "의도적으로 다른 3개의 가설을 생성하세요."
  3. "Claude 내장 팀 모드를 사용하여 가설당 하나의 트레이서 레인을 만드세요."
  4. "각 레인에 대해 지지 및 반대 증거를 수집하고, 증거 강도를 순위 매기고, 중요한 미지수와 최선의 판별 탐침을 명명하세요."
  5. "유용한 경우 시스템, 프리모템 및 과학 렌즈를 선두에 적용하세요."
  6. "상위 두 설명 간의 반박 라운드를 실행하세요."
  7. "순위 설명 표, 수렴 참고 사항, 중요한 미지수 및 단일 최선의 판별 탐침을 반환하세요."

출력 품질 기준

좋은 /trace 출력은:

  • 증거 기반
  • 간결하지만 엄격함
  • 조기 확신에 회의적
  • 누락된 증거에 대해 명시적
  • 다음 조치에 대해 실용적
  • 약한 설명이 왜 순위가 낮아졌는지 명시적

예시 최종 합성 형태

관찰된 결과

[무슨 일이 일어났는지]

순위별 가설

순위가설신뢰도증거 강도선두 이유
1...높음 / 중간 / 낮음강함 / 중간 / 약함...

가설별 증거 요약

  • 가설 1: ...
  • 가설 2: ...
  • 가설 3: ...

반증/누락 증거

  • 가설 1: ...
  • 가설 2: ...
  • 가설 3: ...

반박 라운드

  • 선두에 대한 최선의 반박: ...
  • 선두가 유지/실패한 이유: ...

수렴/분리 참고 사항

  • ...

가장 가능성 높은 설명

[현재 최선의 설명]

중요한 미지수

[불확실성을 열어두는 단일 누락 사실]

권장 판별 탐침

[단일 다음 탐침]

추가 추적 레인

[불확실성이 여전히 높은 경우에만]

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

agent-doc-discipline

Writing-time discipline for documents agents consume (the five surfaces, specs, tickets, .omc/skills/) — every rule checkable and carrying a why, steps before reference, one meaning in one home, no restating what the environment already says. Mandatory at drydock seed generation and the launch C5 sediment pass; opt-in for any other agent-facing doc edit. The companion of minimal-code-discipline: that one disciplines code, this one disciplines papers.

ai-slop-cleaner

Clean AI-generated code slop with a regression-safe, deletion-first workflow and optional reviewer-only mode

ask

Process-first advisor routing for Claude, Codex, Gemini, Antigravity, Grok, or Cursor via `omc ask`, with artifact capture and no raw CLI assembly

ask-navigator

Shipyard

autopilot

Full autonomous execution from idea to working code

autoresearch

Stateful single-mission improvement loop with strict evaluator contract, markdown decision logs, and max-runtime stop behavior

cancel

Cancel any active OMC mode (autopilot, ralph, ultragoal, swarm, ultrapilot, pipeline, team) and clean up retired legacy state

configure-notifications

Configure notification integrations (Telegram, Discord, Slack) via natural language

debug

Diagnose the current OMC session or repo state using logs, traces, state, and focused reproduction

deepinit

Deep codebase initialization with hierarchical AGENTS.md documentation

deep-interview

Socratic deep interview with mathematical ambiguity gating before explicit execution approval

drydock

Lay the keel of the shipyard harness in any repo — the 4-pillar shared environment (Context, Rules, Tools, Standards) across 5 surfaces (CLAUDE.md, skills, design-system, mcp/cli, shared context) so that every human and agent inherits the same design language and anyone can ship. Run once per repo; re-run with --check to audit drift.

execute

Carry an approved task through to working, verified code

external-context

Invoke parallel document-specialist agents for external web searches and documentation lookup

graph

Deterministic orchestration graph runtime - declarative DAG pipelines with journal-based crash recovery

harbor

Harbor intake for external work — the captain only handles unresolved decisions. Sweeps incoming issues and PRs, verifies every claim before disposition, reuses every decision already made, and hands the maintainer a docket whose pending items each carry one question with options, recommendation, impact and evidence. Agent-autonomous for facts and for actions covered by standing authorization; signed for every new judgment. Never merges.

hud

Configure HUD display options (layout, presets, display elements)

launch

Shipyard

loft

Loft the shape before cutting steel — answer a design question that prose cannot settle by building a throwaway artifact: a pure logic module in a clickable shell, or structurally different UI variants behind one route. The captain reacts to the artifact; the answer folds into the decision; the artifact never docks. Use when a design question stalls in words, when a navigator map carries a loft ticket, or when a spec discussion reaches

minimal-code-discipline

YAGNI-ladder coding discipline for writing changes — existence-first, reuse before writing, dependency ladder, shortest correct diff, with non-negotiables that must never be minimized away

관련 스킬