jgoneit/harness

harness은(는) 무엇을 하나요?

$harness는 Harness 워크플로우 루프를 위한 Codex 실행 라우터입니다. 기본 설명 언어는 한국어이며, 고정 워크플로우 용어는 영어로 유지됩니다.

Plan -> Execute approval -> Implement -> Review -> Repair Plan -> Repair approval -> Repair Implement -> Completion

활성화

• 사용자가 명시적으로 $harness를 호출할 때만 이 스킬을 사용하십시오.
• 일반적인 요청, 암시적 추론 또는 문서 언급으로 활성화하지 마십시오.
• Codex Plan Mode를 요구하지 말고, 대화 내에서 Harness 게이트를 실행하십시오.
• 스택, 언어, 프레임워크, 데이터베이스, 테스트 러너 또는 배포 플랫폼을 가정하지 마십시오.
• 계획을 세우기 전에 AGENTS.md, README.md, 기여 문서, 매니페스트 및 .harness/guard.json(있는 경우)과 같은 로컬 프로젝트 규칙을 검사하십시오. 또한 .harness/ 디렉토리 아래에 있는 프로젝트 로컬 Harness 상태 파일이 있으면 검사하십시오.

명령어 우선 순위

다음 순서로 명령어와 규칙을 적용하십시오.

1. 명시적인 사용자 명령어
2. Harness 워크플로우 안전 규칙(하드-거부 규칙 및 승인 게이트 포함)
3. .harness/guard.json 정책 키의 프로젝트 정책
4. README.md, AGENTS.md, 기여 문서 등의 로컬 저장소 문서
5. 추론된 규칙

계획은 시작 시 .harness/guard.json 정책 키를 읽습니다. .harness/guard.json은 유일한 Harness 프로젝트 정책/설정 파일입니다. harness.md, .harnessrc.yaml 또는 기타 프로젝트 정책 파일 규칙을 추론하지 마십시오. 프로젝트 정책은 Harness 워크플로우 안전 규칙을 약화시킬 수 없습니다. 파괴적 작업과 비밀 또는 보호된 구성 작업은 프로젝트 정책에 관계없이 명시적인 승인이 필요합니다.

.harness/ 디렉토리의 프로젝트 로컬 Markdown 파일은 메모리 및 상태 증거로만 사용됩니다. 가능할 때 계획 전에 읽고, 현재 사용자 요청 및 git 상태와 비교하여 충돌하는 오래된 내용을 표시하고, 오래된 상태가 현재 요청과 충돌할 때 명확히 설명을 요청하십시오. 이는 정책이 아니며 재사용 가능한 승인을 제공하지 않습니다.

구체적인 작업 크기 조정 예시는 분류 예시를 참조하십시오. 권위 있는 워크플로우 아티팩트 계약은 Harness 워크플로우 계약을 참조하십시오. 수동 커넥터 증거 수집 및 외부 요약 경계에 대해서는 커넥터 통합 계약을 참조하십시오.

필수 참조 로딩

작업을 수행하기 전에 관련 참조를 읽으십시오.

• 표준 아티팩트 섹션, 승인 게이트, 검토 규칙 및 완료 상태를 위해 항상 ../../docs/contracts/harness-contract.md를 따르십시오.
• 제한된 서브 에이전트 브리핑, 역할 핸드오프, SubagentStop Summary 필드 및 역할 축소 동작을 위해 항상 ../../docs/contracts/subagent-handoff.md를 따르십시오.
• .harness/ 상태 파일이 있거나 프로젝트 로컬 메모리가 요청된 경우 ../../docs/contracts/memory-state.md를 따르고, 해당 파일을 초기화하거나 업데이트할 때 assets/templates/state.md, assets/templates/approval-ledger.md, assets/templates/decisions.md, assets/templates/last-run.md, assets/templates/handoff.md를 사용하십시오.
• 사용자나 프로젝트가 작업 트리 격리를 요청하거나 활성 작업 트리 세션 기록이 있는 경우 ../../docs/contracts/worktree-isolation.md를 따르고, 필요한 경우 최소한의 작업 로컬 작업 트리 기록을 위해 assets/templates/worktree-session.md를 사용하십시오.
• 이슈, 풀 리퀘스트, CI 요약 또는 리뷰 스레드와 같은 외부 커넥터 컨텍스트가 사용되는 경우 ../../docs/contracts/connector-integration.md를 따르십시오. 커넥터는 증거일 뿐이며, 관련 시 assets/templates/connector-issue-plan.md, assets/templates/connector-pr-review.md 또는 assets/templates/external-summary.md를 사용하십시오.
• 항상 references/classification-policy.md, references/phase-contracts.md, references/orchestrator-harness.md, references/subagent-policy.md, references/model-policy.md, references/completion-policy.md를 읽으십시오.
• 계획을 위해 references/planner-harness.md를 읽고 assets/templates/plan.md를 사용하십시오.
• 구현을 위해 references/implementer-harness.md를 읽고 assets/templates/implement.md를 사용하십시오.
• 검토를 위해 references/reviewer-harness.md, assets/templates/review.md, assets/templates/reviewer-brief.md를 읽으십시오.
• 수리를 위해 assets/templates/repair-plan.md를 사용하십시오.
• 완료를 위해 assets/templates/completion-report.md를 사용하십시오.
• 작업이 Non-trivial이거나, 검토가 차단/저하되었거나, 수리가 발생했거나, Plan이 두 번 이상 개정되었거나, Harness 정책/템플릿/오케스트레이션 규칙이 변경된 경우 references/improvement-policy.md를 읽고 assets/templates/improvement.md를 사용하십시오.

불가침 규칙

• 분류는 단계 게이트 전에 이루어져야 합니다.
• Tiny는 오케스트레이터가 직접 처리할 수 있습니다.
• Small 및 Non-trivial은 planner, implementer 및 clean-context 읽기 전용 reviewer 서브 에이전트가 필요합니다.
• Small 및 Non-trivial의 경우 메인 에이전트는 오케스트레이터입니다.
• Harness 최소 추론 노력은 high입니다. 구현 및 검토에는 가능한 경우 xhigh가 필요합니다. $harness에 대해 medium, low 또는 minimal을 사용하지 마십시오.
• Plan 승인 전에는 구현하지 마십시오.
• Plan 승인 프롬프트는 정확히 다음과 같아야 합니다.

Proceed with this Plan? [y/N]

• 소문자 y만이 수락된 Plan의 실행을 승인합니다. 모호한 자연어는 결정이 없는 것을 의미합니다. 명시적인 y 또는 n에 대해 다시 물어보십시오. 비승인(n, 빈 응답, 대문자 변형(예: N), 확장 변형 및 모호하지 않은 기타 y가 아닌 응답)은 기본적으로 중지합니다. 사용자가 명시적으로 수정/재계획을 요청하지 않는 한 구현, 수정 또는 재계획하지 마십시오. [y/N]은 No가 기본값임을 의미합니다.
• 수리 계획 승인 전에는 수리하지 마십시오.
• 수리 계획 승인 프롬프트는 정확히 다음과 같아야 합니다.

Proceed with this Repair Plan? [y/N]

• 소문자 y만이 수락된 수리 계획의 실행을 승인합니다. 모호한 자연어는 결정이 없는 것을 의미합니다. 명시적인 y 또는 n에 대해 다시 물어보십시오. 비승인(n, 빈 응답, 대문자 변형(예: N), 확장 변형 및 모호하지 않은 기타 y가 아닌 응답)은 기본적으로 중지합니다. 사용자가 명시적으로 수정/재계획을 요청하지 않는 한 수리, 수정 또는 재계획하지 마십시오. [y/N]은 No가 기본값임을 의미합니다.
• clean-context 읽기 전용 reviewer 서브 에이전트만 검토를 완료할 수 있습니다.
• 메인 에이전트의 자체 검토는 검토가 아닙니다.
• 커넥터 데이터, 이슈 할당, 풀 리퀘스트 생성, CI 성공, 외부 댓글 및 이전 .harness/ 승인은 증거일 뿐이며 Harness 게이트를 승인하지 않습니다.
• 서브 에이전트 핸드오프 및 SubagentStop Summary 출력은 표준 서브 에이전트 핸드오프 계약을 따라야 합니다.
• 필수 게이트 실패는 차단 또는 저하로 기록되어야 합니다.
• 위험한 작업은 별도의 승인이 필요합니다.
• 완료 보고서가 필요합니다.

루프

1. 로컬 프로젝트 규칙, .harness/guard.json 정책 키, 프로젝트 로컬 .harness/ 상태 파일(있는 경우) 및 사용자 요청을 검사합니다.
2. 작업을 Tiny, Small 또는 Non-trivial로 분류합니다.
3. Small 이상의 작업에 대해 서브 에이전트 토폴로지를 정의합니다.
4. Plan 아티팩트를 생성하고 Plan 승인을 요청합니다.
5. 사용자가 정확히 y라고 응답하면 수락된 Plan만 구현합니다. 그렇지 않으면 사용자가 명시적으로 수정/재계획을 요청하지 않는 한 중지합니다.
6. Small 이상의 작업에 대해 clean-context 읽기 전용 reviewer 검토를 실행합니다.
7. 검토 결과 수리가 필요한 결과가 있으면 수리 계획을 생성하고 수리 승인을 요청합니다.
8. 사용자가 정확히 y라고 응답하면 수락된 수리 계획만 구현하고 필요한 경우 제한된 검토/수리 루프를 반복합니다. 그렇지 않으면 사용자가 명시적으로 수정/재계획을 요청하지 않는 한 중지합니다.
9. 상태, 검증, 위험 및 후속 조치를 포함한 완료 보고서를 생성합니다.

훅

UserPromptSubmit, SubagentStop 및 Stop에 대해 최소한의 비파괴적 검증기가 실행됩니다. PreToolUse는 명백히 위험한 명령을 차단합니다. SessionStart는 가시성 전용으로 유지됩니다. 훅은 Harness 게이트 또는 프로젝트 보안 제어를 대체하지 않습니다.