decision-path — 보류 중인 결정들의 ASCII 의존성 그래프은(는) 무엇을 하나요?
결정은 진공에서 발생하지 않습니다. 고립된 상태에서는 합리적으로 보이는 것이 종종 후속 작업을 차단하거나, 구축되지 않은 선행 조건을 가정하거나, 확립된 안전 게이트를 우회합니다. decision-path는 인과 관계, 실행 순서 및 모순을 터미널에서 투명하게 보여줍니다.
사용 시기
- 열린 결정들의 기존 인벤토리(decision-briefing 1단계, 세션 컨텍스트 또는 티켓-마스터 결정 브리핑에서)를 구조화해야 할 때.
- 즉시 실행할 수 있는 결정(루트 노드)과 선행 조건 또는 외부 차단기에 의존하는 결정을 식별해야 할 때.
- 어떤 권장 사항이 서로 조화롭게 맞아떨어지고, 두 권장 사항이 논리적 또는 운영적으로 충돌하는지에 대한 개요가 필요할 때.
- 트리거 단어:
/decision-path, "which decisions depend on each other", "decision dependency graph", "visualize decision path", "ASCII decision tree", "contradictions between decisions", "check causal dependencies". - 사용하지 말아야 할 경우:
- 열린 질문을 처음 발견하고 인벤토리화하는 경우 — 이는 decision-briefing 1단계에서 수행합니다.
- 권장 선택 사항을 승인을 위해 하나의 일관된 개념으로 묶는 경우 — 이는 decision-draw에서 수행합니다.
- 옵션과 옵션별 찬반론이 포함된 간결한 5부분 블록을 위한 경우 — 이는 decision-shot에서 수행합니다.
- 프레임워크(가중 점수, 시나리오 분석)로 단일 복잡한 결정을 체계적으로 평가하는 경우 — 이는 decide에서 수행합니다.
결정 패밀리의 경계
| 스킬 | 역할 | 입력 | 출력 |
|---|---|---|---|
decide | 단일 결정을 체계적으로 구조화 | 기준, 옵션 | 점수 매트릭스, 단일 결정 |
decision-briefing | 많은 열린 결정을 옵션이 있는 개별 질문으로 분해 | 보류 중인 항목 목록 | 번호가 매겨진 A/B/C/D 브리핑, 대략적인 의존성 마커, 일괄 예약 |
decision-path | 여러 결정에 걸친 인과 관계와 모순을 검증 및 시각화 | 브리핑/레지스터의 대략적인 마커 | 5개 노드 평가와 에지 상태가 포함된 ASCII 의존성 그래프 |
decision-draw | 권장 사항을 승인을 위해 일관된 전체로 묶음 | decision-path의 번들 | 개념, 상호 작용(권장 변형만), 역전달 |
decision-shot | 완료된 분석을 경영진 본질로 압축(1개 결정 또는 긴밀한 번들) | 1개의 분석된 질문 또는 그룹 | 옵션, 찬반론, 전체 분석 링크가 포함된 5부분 단축 형식 |
decision-avatar | 사용자 선호도 및 행동 기록 모델링 | 컨텍스트, 과거 선택 | 신뢰도 등급 🟢 / 🟡 / 🔴 |
decision-briefing과의 계약 및 책임
decision-briefing 1단계는 이미 인테이크 중에 대략적인 의존성과 실행 순서를 도출합니다(예: "Afterwards automatically:", 차단기, 티켓 참조 등의 신호로부터). decision-path는 이 도출을 중복하지 않고 이러한 대략적인 마커 위에 직접 구축합니다:
- decision-briefing이 대략적인 마커 제공: 보류 중인 항목의 원시 인벤토리와 초기 결합 신호를 제공합니다.
- decision-path가 검증, 평가 및 시각화: 문서화된 사실에 대해 신호를 확인하고, 확인된 에지와 추정된 에지를 분리하며, 노드당 5가지 평가를 할당하고 게이트 충돌을 노출합니다.
- 불일치에 대한 피드백 루프:
decision-path가 브리핑에서 누락되거나 잘못 표현된 의존성을 발견하면 절대 조용히 흡수하지 않고 명시적으로 수정 노트로 브리핑에 다시 보고합니다.
노드당 5가지 평가(및 에지 검증 상태)
다섯 차원 [S E U Z W]는 노드(시스템적 맥락에서 보류 중이거나 확정된 결정)를 평가합니다. 에지는 의미론적 관계 유형(예: 해제, 차단, 선행 조건)과 검증 상태(확인 vs. 추정)를 전달합니다.
그래프의 모든 노드는 간결한 5요소 평가 문자열을 표시합니다:
[S+ E:<Option> U<Direction><Confidence> Z+ W-]
-
합리적(
S) — 기술적 및 아키텍처적 건전성:S+: 솔루션이 견고하고 실제 문제를 해결하며 인위적인 복잡성을 피합니다.S~: 부분적으로 건전하지만 유지 관리 또는 운영 오버헤드가 있습니다.S-: 잘못된 솔루션, 표면적 활동, 또는 입증된 막다른 길(예: 잘못된 지점에서 필터링).
-
권장(
E) — 구체적이고 증거 기반의 권장 조치:E:<Option>: 명확한 선택(예:E:A,E:B,E:resolve,E:Step1).E-: 실행 가능한 권장 사항 없음(사실 누락 또는 높은 수준의 정책 질문).
-
사용자-전형적(
U) — 사용자의 과거 습관 및 성문화된 규칙과의 정렬(decision-avatar통해): 방향(선택 사항이 습관에 맞는가?)과 검증 신뢰도를 별도로 코딩:- 방향(U 다음 첫 문자):
+: 사용자-전형적 — 과거 결정, 정책(CLAUDE.md), 또는 명시적 선호도와 일치.~: 중립 / 열림 — 문서화된 지배적 역사적 선호도 없음.-: 비전형적 — 관례적 워크플로우 또는 확립된 습관에서 벗어남.
- 검증 신뢰도(두 번째 문자):
- ASCII 그래프 내부의 순수 ASCII:
!: 높음 / 근거 있음(산문에서는 🟢 문서화됨).~: 중간 / 그럴듯함(산문에서는 🟡 트레이드오프는 기본적으로 사용자에게 속함).?: 낮음 / 미검증(산문에서는 🔴 정책 질문, 전례 없음). 추측하기보다 에스컬레이션!
- ASCII 그래프 내부의 순수 ASCII:
- 예:
U+!(전형적이고 문서화됨),U+~(전형적이지만 사용자 판단 필요),U-!(문서화된 비전형적),U~?(열림, 전례 없음 -> 에스컬레이션).
- 방향(U 다음 첫 문자):
-
일관성(
Z) — 인접 노드와의 부드러운 아키텍처 및 스타일 조화:Z+: 선행 조건 및 다운스트림 결정과 완벽하게 통합됨; 마찰 없이 응집력 있는 전체를 형성.Z~: 사소한 스타일 마찰 또는 운영 오버헤드, 그러나 기능적으로 실행 가능.Z-: 시스템적 상호 작용에서 눈에 띄는 마찰(예: 구성 확산, 어색한 결합), 그러나 하드 규칙을 위반하지 않음.
-
모순(
W) — 하드 모순 및 정책/게이트 위반(가장 중요한 출력 — 알람!):W-: 다른 권장 사항, 정책 및 활성 안전 게이트에 대해 모순 없음.W+: 하드 충돌 / 알람! 다른 권장 사항을 무효화하거나, 확립된 정책(CLAUDE.md, P-00x)을 위반하거나, 활성 안전 게이트를 우회. 충돌 노드는 항상CONTRADICTIONS섹션에서 근본 원인 및 해결 경로와 함께 명시적으로 강조 표시됨.
에지 유형 및 도출 규칙
의존성은 소스 텍스트에서 엄격히 도출되며 절대 발명되지 않습니다. 에지는 관계 유형과 검증 상태를 전달합니다:
| 소스의 신호 | 에지 유형 | 표기법 | 의미 |
|---|---|---|---|
| "Afterwards automatically: ...", "unlocks", "enables" | 해제 | +--> | 대상 결정이 소스 결정 후에만 실행 가능(문서화됨) |
| "blocks", "prevents", "safety gate triggers" | 차단 | => | 소스가 해결될 때까지 대상이 차단됨 |
| "requires", "needs beforehand", "prerequisite" | 필요 | --> | 대상이 논리적 및 시간적으로 소스를 필요로 함 |
| "follow-up decision", "step 2 afterwards" | 순서 | --> | 실행 후 다운스트림 논리적 진행 |
| "refuted by measurement", "obsolete", "superseded" | 무효화 | --X--> | 소스 통찰력이 대상을 쓸모없게 만듦 |
| 공유 D-ID, Ticket-ID 또는 동일 하위 시스템(텍스트 증거 없음) | 추정 | ?--> | 문서화된 인과 증거 없는 그럴듯한 결합(미검증) |
미검증 에지 규칙: 텍스트에 명시적 인과 진술이 없는 경우 에지는 추정(
?-->)으로 표시되어야 하며, 결코 확인된 사실로 표시되지 않습니다. 관계가 문서화되지 않은 경우 노드는 연결되지 않은 상태로 나란히 유지됩니다.
ASCII 그래프 형식 지침
- 고정폭 및 터미널 최적화: 최대 줄 너비 100열. 터미널 레이아웃을 깨뜨리는 넓은 테이블 없음.
- 문자 집합 및 순수성: 순수 ASCII. 그래프 코드 펜스 내부에는 이모지(🟢🟡🔴)가 나타날 수 없습니다. 신뢰도는 ASCII 마커(
!,~,?)로만 표현됩니다. - 노드 ID: 기존 식별자만 사용(
PD-A,MD-A,BH-A,VM-A,QR-A,CL-A,MO-A,D-001,732597768). 합성 ID를 절대 발명하지 마십시오! 항목에 약어가 없으면 항목 번호가 사용됩니다. 후속 내부 단계는 번호가 없는 에지 주석(...)으로 표시됩니다. - 계층 구조:
LEVEL 0 - independent: 루트 노드, 차단 해제된 항목, 외부 트리거.LEVEL 1 - depends on exactly one: 직접 후속 조치.LEVEL 2 - depends on multiple / deep chain: 다중 의존성 또는 깊은 순차 노드.CONTRADICTIONS: 하드 충돌, 게이트 위반 및 상충하는 권장 사항(W+).LEGEND: 모든 그래프 출력에 필수. 그래프에 사용된 모든 구조 문자(|,=Option,(...), 에지 화살표)는 범례에 나열되고 설명되어야 합니다.
- 선택적 Mermaid 펜스: 유용한 경우 추가
mermaid코드 블록이 추가될 수 있습니다. ASCII 그래프는 기본적이고 권위 있는 출력으로 남습니다.
예제(파일럿 데이터셋: Ticket-Master 2026-09-13)
Ticket-Master 결정 브리핑(732597768, MO-A, CL-A, QR-A, 387521104, CL-B)의 실제 발췌:
====================================================================================================
DECISION-PATH: DEPENDENCY GRAPH (Pilot Ticket-Master 2026-09-13)
====================================================================================================
LEVEL 0 - independent (Root decisions & external blockers)
[732597768] Resolve GitHub billing issue [S+ E:resolve U+! Z+ W-]
| unlocks
+--> [MO-A] Release Wave 2 [S+ E:A U+~ Z+ W-]
[CL-A] clutch admin merge PR #6 & PR #8 [S+ E:A U+! Z+ W-]
| blocked by: [Gate "1 Approving Review" (self-approval impossible)]
--> (follow-up decision: set branch protection to 0 or bot)
[QR-A] Queue rename NTFS junction (_TICKETS -> TICKETS) [S+ E:B U+! Z+ W-]
+--> [387521104] Night window runs (documented: only under B)
[CL-B] Review gate pilot: Mac signing key [S+ E:Step1 U+~ Z+ W-]
--> (follow-up steps 2-4: model automation after key provisioning)
LEVEL 1 - depends on exactly one precursor
[MO-A] Release Wave 2 [S+ E:A U+~ Z+ W-]
| requires: [732597768] (billing resolved, remote CI gates active again)
| requires: [Gate PRIVATE.txt "green remote CI"]
--> (follow-up step: toggling visibility remains user-only action)
LEVEL 2 - depends on multiple / deep chain
[387521104] Autonomous migration run in night window [S+ E:B U+! Z+ W-]
| requires: [QR-A]=B (NTFS junction established)
| requires: (junction set on the second host via transfer ticket -
| ticket number not stated in the briefing)
----------------------------------------------------------------------------------------------------
CONTRADICTIONS & GATE COLLISIONS
----------------------------------------------------------------------------------------------------
[MO-A]=B X [Gate PRIVATE.txt "green remote CI"]
Conflict: Option B would release Wave 2 based solely on local tests,
even though two module contracts explicitly demand green remote CI.
Resolution: Recommendation A forces [732597768] (billing) first, resolving collision.
[CL-A]=StatusQuo X [Gate "1 Approving Review" (self-approval impossible)]
Conflict: master demands 1 review, but sole repository account is lukisch.
Resolution: Recommendation A (admin merge) legitimately breaks the dead end.
----------------------------------------------------------------------------------------------------
LEGEND & RATING KEY
----------------------------------------------------------------------------------------------------
Edges & Structure:
+--> unlocks / enables (causality documented in source)
=> blocks / prevents (gate or external blocker)
--> requires / sequence (precondition or follow-up step)
?--> presumed dependency (plausible coupling, but undocumented)
--X--> invalidates / supersedes (source insight renders target obsolete)
X contradiction / collision (gate or policy violation)
| vertical hierarchy line / attribute mapping
[ID] decision node (item abbreviation or item number from briefing)
[Gate] external gate / rule / contract - NOT a decision node
=Opt specific option for a node (e.g. [MO-A]=B)
(...) unnumbered edge annotation / follow-up step (no invented synthetic ID)
Node Assessment [S E U Z W]:
S: Sensible (+ sound / ~ qualified / - unsound)
E: Recommended (A, B, C, resolve, Step1, - none)
U: User-typical (direction: + typical / ~ neutral / - atypical;
confidence: ! grounded / ~ trade-off / ? escalation)
[! = documented (prose green), ~ = user trade-off (prose yellow),
? = unverified / escalation (prose red)]
Z: Coherent (+ harmonizes / ~ slight friction / - architectural break)
W: Contradictory (- conflict-free / + hard collision with gate or policy)
====================================================================================================
decision-path가 하지 않는 일
- 결정을 내리지 않음: 이 스킬은 구조적 투명성을 제공합니다. 결정 권한은 사용자에게 있습니다.
- 옵션을 발명하지 않음: 이 스킬은 새로운 대안이나 가중치 기준을 브레인스토밍하지 않습니다. 이는 decide 또는 decision-briefing에 속합니다.
- 합성 ID를 생성하지 않음: 모든 노드는 실제 브리핑 항목 약어 또는 번호를 사용합니다. 가상 식별자는 도입되지 않습니다.
- 추정 사실을 확인된 것으로 제시하지 않음: 에지가 소스 텍스트 증거로 뒷받침되지 않으면 명시적으로 추정(
?-->)으로 표시됩니다. 도출은 엄격하며 추측하지 않습니다. - 결정 아바타를 대체하지 않음:
U(사용자-전형적) 평가는decision-avatar의 프로파일 데이터를 사용하지만 아바타 시스템 자체를 구현하지는 않습니다.
관련 스킬
- decision-briefing — 결정 분해 및 인벤토리(1단계) + 옵션이 있는 포맷된 브리핑(2단계).
- decide — 가중 점수 및 시나리오를 사용한 단일 결정을 위한 체계적인 방법.
- decision-draw — 여러 권장 사항을 승인을 위한 응집력 있는 개념으로 묶음.
- decision-shot — 의미 있고 책임 있는 단축 경로(1개 결정 또는 번들에 대해 5부분).
- decision-avatar — 사용자 습관 및 행동 규칙 모델링.
이 스킬은 ELLMOS(https://github.com/ellmos-ai) 생태계의 일부입니다.