Communitygithub.com

외부 인과 작업 공간

작업이 복잡하거나, 모호하거나, 아키텍처적이거나, 디버깅 중심이거나, 리팩토링 위주이거나, 전략적이거나, 인과적이거나, 성능 민감하거나, 보안 민감하거나, 다중 파일이거나, 영향도가 높거나, 환각 검증의 위험이 있을 때 사용합니다. 답변, 계획, 또는 파일 수정 전에 디스크 기반 인과 작업 공간을 구축합니다. 사소한 편집, 간단한 서식 지정, 직접적인 사실 답변에는 사용하지 마십시오.

외부 인과 작업 공간란 무엇인가요?

이 스킬은 터미널 에이전트를 외부에서 검사 가능한 작업 공간을 갖춘 추론 시스템으로 전환합니다. 복잡하거나 영향도가 큰 작업(예: 아키텍처 분석, 디버깅, 근본 원인 분석, 리팩토링, 다중 파일 변경, 전략적 의사 결정, 인과 분석, 성능 또는 보안 민감 작업)에서 에이전트가 단순한 텍스트 생성기로 동작하지 않도록 방지합니다. 에이전트는 결론, 계획, 패치, 또는 권장 사항을 생성하기 전에 객체, 관계, 제약 조건, 인과성, 불변성, 경쟁 가설, 테스트, 검증 증거, 결정, 잔여 불확실성으로 구성된 로컬 문제 모델을 디스크에 구축하고 조작합니다. 필수 파일(`owner.md`, `task.md`, `world.md`, `hypotheses.md`, `claims.md`, `verification.md`, `decision.md`)은 외부 작업 기억 장치 역할을 하며, 최종 응답은 `decision.md`와 일관성을 유지하고 최종 작업 공간 무결성 게이트를 통과해야 합니다.

지원 대상✓Claude Code✓Codex CLI~Cursor✓OpenCode
npx skills add https://github.com/Venorium/external-causal-workspace/tree/main

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

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

문서

외부 인과 작업 공간 스킬

목적

이 스킬은 터미널 에이전트를 외부에서 검사 가능한 작업 공간을 갖춘 추론 시스템으로 전환합니다.

작업이 복잡한 경우 에이전트는 단순한 텍스트 생성기처럼 동작해서는 안 됩니다. 결론, 계획, 패치, 또는 권장 사항을 생성하기 전에 문제의 로컬 모델을 구축하고 조작해야 합니다.

목표는 도구 사용과 명시적 상태를 통해 객체, 관계, 제약 조건, 인과성, 불변성, 경쟁 가설, 테스트, 검증 증거, 결정, 잔여 불확실성으로 구성된 임시 외부 세계 모델을 근사하는 것입니다.

이는 신경망 잠재 공간이 아닙니다. 읽고, 업데이트하고, 확인하고, 공유하고, 감사할 수 있는 실용적인 디스크 기반 대체재, 즉 외부 인지 작업 공간입니다.

이 스킬을 사용해야 하는 경우

복잡하거나 영향도가 큰 작업, 특히 다음에 이 스킬을 사용하십시오:

  • 아키텍처 분석
  • 디버깅
  • 근본 원인 분석
  • 리팩토링
  • 다중 파일 변경
  • 불명확하거나 불안정한 요구 사항
  • 전략적 기술 결정
  • 인과 분석
  • 성능 민감 작업
  • 보안 민감 작업
  • 여러 그럴듯한 설명이 있는 작업
  • 잘못된 답변이 미래에 기술 부채를 만들 수 있는 작업
  • 검증, 추적 가능성, 또는 반증이 중요한 작업

이 스킬을 다음과 같은 경우에는 과도하게 사용하지 마십시오:

  • 사소한 질문
  • 아주 작은 격리된 편집
  • 간단한 서식 지정
  • 로컬 프로젝트 현실에 의존하지 않는 직접적인 사실 답변
  • 전체 작업 공간이 가치보다 노이즈를 더 많이 추가하는 작업

작업이 간단하다면 직접 답변하고 스킬이 필요하지 않았다고 간략히 설명하십시오.

대상 작업 공간

활성 작업 공간은 에이전트가 실행된 디렉토리이거나 사용자가 명시적으로 식별한 프로젝트 루트입니다.

인과 작업 공간은 스킬 디렉토리가 아닌 대상 프로젝트에 속합니다.

다음을 사용하십시오:

<project-root>/.agent/current/

스킬 디렉토리에는 프로토콜이 포함됩니다. 프로젝트 디렉토리에는 작업 상태가 포함됩니다.

에이전트는 작업별 추론 상태를 스킬 패키지 자체에 기록해서는 안 됩니다.

현재 작업 공간 검사

리포지토리별 또는 환경별 작업에 대해 작업을 수행하기 전에 필요한 만큼만 현재 작업 공간을 검사하십시오.

해당되는 경우 다음을 식별하십시오:

  • 프로젝트 구조
  • 관련 파일 및 폴더
  • 사용 가능한 문서
  • 빌드, 테스트 및 검증 명령어
  • 기존 아키텍처에 의해 부과된 제약 조건
  • 기존 AGENTS.md, 재정의 파일, 로컬 명령 파일 또는 작업별 지침
  • .agent/current/가 이미 존재하는지 여부

에이전트는 작업이 로컬 프로젝트 현실에 의존하는 경우 메모리에서 아키텍처를 가정해서는 안 됩니다.

새 실행 의미론

이 스킬을 사용하는 각 새 작업의 시작 시 대상 프로젝트에서 .agent/current/를 재설정하십시오.

규칙:

  • .agent/가 없으면 생성합니다.
  • .agent/current/가 없으면 생성합니다.
  • .agent/current/가 이전 작업에서 이미 존재하는 경우 새 작업을 시작하기 전에 이전 내용을 삭제하거나 덮어씁니다.
  • 사용자가 명시적으로 요청하지 않는 한 .agent/notes/, .agent/reports/, .agent/tmp/ 또는 .agent/archive/는 삭제하지 마십시오.
  • 기본적으로 이전 상태를 보존하지 마십시오.
  • 사용자가 명시적으로 기록 보존을 요청하는 경우 재설정하기 전에 이전 .agent/current/를 .agent/archive/<timestamp-or-task-name>/에 복사합니다.

.agent/current/의 목적은 현재 작업만을 나타내는 것입니다. 이전 프롬프트의 오래된 추론을 조용히 축적해서는 안 됩니다.

작업 공간 소유권

주어진 작업에 대해 .agent/current/는 단일 작성자를 가져야 합니다.

다음을 생성하거나 덮어씁니다:

.agent/current/owner.md

owner.md는 다음을 명시해야 합니다:

  • 작업 이름 또는 짧은 목표
  • 소유 에이전트 또는 역할(알고 있는 경우)
  • 가능한 경우 시작 시간
  • 상태: active, completed, partial, blocked, abandoned
  • 작업 공간이 새로 재설정되었는지 여부

다른 활성 소유자가 감지되었고 사용자가 명시적으로 새 작업을 시작하지 않은 경우, 조용히 덮어쓰지 마십시오. 작업 공간을 읽기 전용으로 처리하거나 새 실행을 위해 .agent/current/를 재설정해야 한다고 명시하십시오.

필수 디스크 기반 파일

복잡하거나, 모호하거나, 아키텍처적이거나, 디버깅, 리팩토링, 전략적, 인과적 또는 영향도가 큰 모든 작업에 대해 최소한 다음을 생성하거나 업데이트하십시오:

.agent/current/owner.md
.agent/current/task.md
.agent/current/world.md
.agent/current/hypotheses.md
.agent/current/claims.md
.agent/current/verification.md
.agent/current/decision.md

이 파일들은 장식이 아닙니다. 이는 에이전트의 외부 작업 기억 장치입니다.

에이전트는 작업 중에 이 파일들을 읽고 업데이트해야 합니다. 최종 응답은 .agent/current/decision.md 및 .agent/current/claims.md의 유지된 클레임 상태와 일관성이 있어야 합니다. 최종 응답 전에 .agent/current/owner.md는 더 이상 active 상태가 아니어야 합니다.

필수 파일 역할

owner.md

현재 실행을 식별하고 다른 작업이나 에이전트에 의한 우발적 덮어쓰기를 방지합니다.

다음을 포함해야 합니다:

  • 현재 작업
  • 소유자
  • 모드: direct, delegated, exploratory, diagnostic, implementation-support
  • 상태
  • 재설정 결정

task.md

작업 경계를 정의합니다.

다음을 포함해야 합니다:

  • 사용자 목표
  • 해석된 목표
  • 범위
  • 범위 외
  • 제약 조건
  • 성공 기준
  • 명시적 사용자 금지 사항
  • 여전히 검증이 필요한 가정

world.md

문제의 로컬 모델을 구축합니다.

다음을 포함해야 합니다:

  • 객체: 구성 요소, 파일, 서비스, 행위자, 개념, 데이터 구조
  • 관계: 종속성, 소유권, 데이터 흐름, 호출 흐름, 수명 주기, 시간적 순서
  • 제약 조건: 기술적, 기능적, 보안, 아키텍처, 성능, 호환성
  • 인과성: 무엇이 무엇을 생성하는지, 무엇이 무엇을 깨뜨리는지, 무엇이 무엇에 의존하는지
  • 불변성: 개입 후에도 참이어야 하는 것
  • 불확실성 영역: 아직 확인되지 않은 사실

hypotheses.md

단일 가설 추론을 방지합니다.

경쟁하는 설명 또는 솔루션 경로를 포함해야 합니다:

| 가설 | 지지 증거 | 반박 증거 | 반증 테스트 | 상태 |
|---|---|---|---|---|
| H1 | ... | ... | ... | retained/rejected/suspended |
| H2 | ... | ... | ... | retained/rejected/suspended |

가설은 명시적으로 rejected, retained 또는 suspended 되어야 합니다.

claims.md

진실 체계 혼란을 방지합니다.

작업에 실질적으로 영향을 미치는 중요한 주장을 유형과 상태와 함께 나열해야 합니다:

| ID | 주장 | 유형 | 출처/증거 | 상태 | 영향 | 비고 |
|---|---|---|---|---|---|---|
| C-001 | ... | fact / inference / hypothesis / constraint / invariant / risk / value / decision | 파일, 명령어, 사용자 진술, 도구 결과, 추론 | verified / inferred / plausible / suspended / rejected / not-checked | low / medium / high / critical | ... |

규칙:

  • fact는 증거 앵커가 필요합니다.
  • inference는 의존하는 사실의 이름을 밝혀야 합니다.
  • hypothesis는 반증되거나 유지될 때까지 fact와 구별 가능해야 합니다.
  • value는 판단을 안내할 수 있지만 경험적 증거로 가장해서는 안 됩니다.
  • decision은 유지된 클레임에 의해 뒷받침되어야 하며 거부된 클레임에 조용히 의존해서는 안 됩니다.

실질적으로 중요한 클레임만 사용하십시오. 작업 공간을 장황한 클레임 덤프로 만들지 마십시오.

verification.md

잘못된 검증을 방지합니다.

다음을 포함해야 합니다:

  • 실제로 실행된 명령어
  • 실제로 검사된 파일
  • 중요한 출력 또는 관찰
  • 통과, 실패, 건너뜀 또는 실행되지 않은 검사
  • 검증 한계
  • 더 강력한 검증이 불가능했거나 의도적으로 건너뛴 이유

검증 클레임은 증거 앵커(명령어, 검사된 파일, 관찰된 출력, 도구 결과, 또는 검증을 수행할 수 없었던 명시적 이유)가 있는 경우에만 유효합니다.

decision.md

최종 응답 전에 결론을 안정화합니다.

다음을 포함해야 합니다:

  • 유지된 모델
  • 거부된 경로
  • 권장 조치
  • 최소 안전 다음 단계
  • 위험
  • 검증 상태
  • 남은 불확실성
  • 구현이 허용되는지 또는 기다려야 하는지

핵심 운영 원칙

모든 복잡한 작업에 대해 먼저 문제의 로컬 모델을 구축하십시오.

모델은 다음을 포함해야 합니다:

  • 객체
  • 관계
  • 제약 조건
  • 인과성
  • 불변성
  • 경쟁 가설
  • 불확실성 영역
  • 검증 기회
  • 중요한 주장에 대한 클레임 유형 및 상태

그런 다음 다음을 통해 가설을 테스트하십시오:

  • 반전
  • 모순
  • 경계 사례
  • 터무니없음 검사
  • 인과 메커니즘 검사
  • 가능하고 안전할 때마다 실행 가능한 검증

이 안정화 이후에만 에이전트가 답변, 계획, 패치 또는 권장 사항을 생성할 수 있습니다.

필수 참조

이 스킬이 사용될 때, 해당되는 경우 스킬 패키지의 다음 프로토콜 파일을 따르십시오:

프로토콜 파일은 스킬의 일부입니다. .agent/current/ 파일은 대상 프로젝트 작업 공간의 일부입니다.

기본 실행 루프

복잡한 작업의 경우 다음 루프를 사용하십시오:

  1. 실제 목표와 이 스킬이 필요한지 확인합니다.
  2. 필요한 만큼만 작업 공간을 검사합니다.
  3. 새 작업을 위해 .agent/current/를 재설정하거나 생성합니다.
  4. owner.md, task.md, world.md, hypotheses.md, claims.md, verification.md 및 decision.md를 생성합니다.
  5. 문제의 로컬 모델을 구축합니다.
  6. 불변성과 제약 조건을 식별합니다.
  7. 실질적으로 중요한 사실, 제약 조건, 불변성, 가설, 위험, 가치 및 결정을 claims.md에 기록합니다.
  8. 경쟁 가설 또는 솔루션 경로를 생성합니다.
  9. 논리적으로 그리고 가능한 경우 도구를 사용하여 테스트합니다.
  10. 증거와 건너뛴 검증을 verification.md에 기록하고 claims.md에서 영향을 받는 클레임 상태를 업데이트합니다.
  11. 불안정한 가설을 제거합니다.
  12. 유지된 클레임에서만 유지된 결론을 decision.md에 초안합니다.
  13. 허용되는 경우 검증된 범위 내에서만 작업합니다.
  14. 변경이 있었다면 결과를 검증합니다.
  15. decision.md를 마무리합니다.
  16. owner.md 상태를 completed, partial, blocked 또는 abandoned로 업데이트합니다.
  17. 최종 작업 공간 무결성 게이트를 수행합니다.
  18. 그런 다음에만 최종 답변을 생성합니다.

행동 규칙

  • 즉흥보다 구조를 선호합니다.
  • 유창한 가정보다 검증된 사실을 선호합니다.
  • 광범위한 추측성 편집보다 최소한의 가역적 변경을 선호합니다.
  • 관련 없는 파일을 수정하지 마십시오.
  • 불확실성을 숨기지 마십시오.
  • 실제로 실행되지 않은 테스트가 통과했다고 주장하지 마십시오.
  • 클레임이 증거 앵커와 연결되지 않은 한 verified, validated, confirmed, tested, passed, failed, inspected 또는 checked와 같은 단어를 사용하지 마십시오.
  • 정적 읽기에 기반한 경우 "다음에서 추론됨"이라고 말하고 검사된 파일을 지정하십시오.
  • 검사할 수 있는 프로젝트 규칙을 추론하지 마십시오.
  • 재설정 후 새 작업에 오래된 .agent/current/ 내용이 영향을 미치지 않도록 하십시오.
  • 결론에 실질적으로 영향을 미치는 경우 유형이 지정되지 않은 가정이 최종 답변에 들어가지 않도록 하십시오.
  • 작업이 간단한 경우 추론 프로세스를 과도하게 설계하지 마십시오.

도구 사용 및 검증

개념적 논의에는 언어 전용 답변이 허용됩니다.

구현, 디버깅, 아키텍처 검증, 리포지토리별 클레임 또는 환경별 클레임의 경우 다음을 선호합니다:

  • 파일 읽기
  • 심볼 검색
  • 구성 검사
  • 테스트 실행
  • 타입 검사 실행
  • 린터 실행
  • diff 생성
  • 작은 스크립트 사용
  • 재현 가능한 검사 생성

사용자 제약 조건을 위반하지 않고 사용 가능한 가장 강력한 합리적 검증을 사용하십시오.

명령어가 파괴적이거나, 프로덕션에 영향을 미치거나, 비용이 많이 들거나, 명시적으로 금지된 경우 실행하지 마십시오. 건너뛴 검증과 그 이유를 verification.md에 기록하십시오.

최종 작업 공간 무결성 게이트

최종 답변을 작성하기 전에 에이전트는 최종 작업 공간 무결성 게이트를 반드시 수행해야 합니다.

이 게이트는 .agent/current/가 생성될 때마다 필수입니다.

에이전트는 다음을 다시 열거나 재확인해야 합니다:

  • .agent/current/owner.md
  • .agent/current/task.md
  • .agent/current/world.md
  • .agent/current/hypotheses.md
  • .agent/current/claims.md
  • .agent/current/verification.md
  • .agent/current/decision.md

다음 조건이 충족될 때까지 최종 답변이 허용되지 않습니다:

  1. 모든 필수 파일이 존재합니다.
  2. .agent/current/owner.md에 더 이상 status: active가 포함되지 않습니다.
  3. 상태가 다음 중 하나입니다:
    • completed
    • partial
    • blocked
    • abandoned
  4. .agent/current/decision.md에 유지된 결론이 포함됩니다.
  5. .agent/current/verification.md에 검증 모드가 명시됩니다.
  6. 최종 작업 공간 추적은 실제로 존재하는 파일만 언급합니다.

작업이 사용 가능한 결론에 도달한 경우 다음을 사용하십시오:

status: completed

작업이 유용한 분석을 생성했지만 검증이 불완전한 경우 다음을 사용하십시오:

status: partial

필요한 정보가 누락된 경우 다음을 사용하십시오:

status: blocked

에이전트는 최종 응답 전에 마지막 작업 공간 쓰기로 owner.md를 업데이트해야 합니다.

최종 답변을 생성한 후 owner.md를 status: active로 절대 남겨두지 마십시오.

출력 기대치

최종 응답은 간결하지만 완전해야 합니다. .agent/current/decision.md에서 파생되어야 합니다.

해당되는 경우 다음을 포함해야 합니다:

  • 이해된 내용
  • 검사된 내용
  • 구축된 모델 또는 가설
  • 유지 및 거부된 클레임
  • 수행된 검증
  • 건너뛴 검증 및 그 이유
  • 권장 조치, 다음 단계 또는 변경 사항
  • 결정 이면의 근거
  • 잔여 불확실성
  • 범위 한계
  • 추가 조사가 필요한 경우 재개 지점

관련 스킬