heithmurray/agent-skills

bcp-finish

실제 작업을 위한 완료 단계입니다. 한 모델이 작업을 만들고, 다른 모델이 이를 공격하며, 운영자가 최종 결정을 내립니다. 빌더-챌린저 프로토콜 v1.7 기반 (https://github.com/heithmurray/builder-challenger-protocol, CC BY 4.0, Heith Murray).

사용 시점

• 실행: 간단한 변경을 넘어서는 모든 작업에 대해 완료 승인을 요청하기 전에 실행합니다. 요청을 기다리지 마십시오.
• 건너뛰기: 명백하고, 작으며, 되돌리기 쉬운 빠른 작업의 경우 건너뜁니다. 집중된 검증으로 충분합니다.
• 한 번에 하나의 주제만 처리합니다: 제출하려는 변경 사항 하나만을 대상으로 합니다.

역할

• 빌더 (Builder): 작업을 수행한 에이전트(당신)입니다. 모든 이의제기에 대해 수정하거나 답변합니다.
• 챌린저 (Challenger): 읽기 전용으로 실행되는 다른 모델입니다. 문제를 찾지만, 파일을 편집하거나 전달 가능한 텍스트를 작성하지 않습니다.
• 운영자 (Operator): 작업을 소유한 인간입니다. 오직 운영자만이 승인, 위험 수락, 라운드 제한 연장, 진실 재정의 또는 REFRAME 발행, 범위에 대한 판결을 내릴 수 있습니다. 당신은 빌더와 챌린저 사이를 중계하며, 형식 위반에 대해서만 표준 RESET — [지시사항]을 발행할 수 있습니다.

누가 누구에게 도전하는가

• 챌린저는 항상 빌더와 다른 모델 패밀리이며, 헤드리스(headless) 읽기 전용 모드로 시작됩니다. 페어링 및 정확한 명령어는 references/tools.md에 있습니다.
• 각 도구의 설정된 기본 모델을 사용하고, 직접 선택하지 마십시오.
• 각 호출은 공유 기록이 없는 새로운 세션입니다. 매번 전체 라운드 입력(Handoff 참조)을 제공합니다.
• 각 호출에 최대 10분까지 허용합니다. 각 라운드는 보통 1~5분입니다.

핸드오프 (챌린저가 받는 내용)

각 라운드마다 다음 부분을 순서대로 포함하는 하나의 프롬프트를 작성합니다:

1. references/challenger-prompt.md 파일 전체 (역할, 규칙 및 형식).
2. ROUND [n] — BUILDER OUTPUT — v1.[n-1].
3. 주제: 이 변경 사항이 달성해야 할 목표를 한 문장으로, 가능하면 운영자의 표현을 사용하고 승인 기준을 포함합니다.
4. 확인 위치: 저장소 경로, 기본(base) 및 헤드(head) 커밋, diff를 확인하는 명령어(예: git diff <base>..<head>), 그리고 관련 파일들.
5. 빌더의 증거: 실행한 검증과 그 결과.
6. 2라운드부터: 빌더 응답(아래 빌더 응답 형식 참조)과 챌린저의 마지막 이의제기 기록부를 그대로 포함합니다.

다른 것은 포함하지 않습니다. 설명, 이전 라운드 내역(기록부 제외)은 넣지 않습니다.

챌린저는 자신의 주장을 증명하기 위해 파일을 읽고 읽기 전용 명령어를 실행할 수 있습니다. 증거 계층이 중요합니다: 코드 실행이나 수학적 증명이 출처 인용보다 우선하며, 출처 인용은 단순 의견보다 우선합니다.

루프

라운드 제한은 운영자가 1라운드 전에 설정하지 않은 경우 5입니다. 제한에 도달했는데 APPROVED가 없으면 중단하고 운영자에게 문의합니다. 운영자는 사유와 함께 한 번 연장할 수 있습니다: EXTEND — [현재 라운드] to [새 제한]. Reason: [아직 해결되지 않은 특정 작업]. 두 번째 연장은 없습니다. 제한에 다시 도달하면 교착 상태(deadlock)입니다.

1. 1라운드: 핸드오프를 전송합니다. 챌린저의 답변을 있는 그대로 1라운드로 저장합니다.

2. 평결 REVISE 또는 FAIL: 빌더 응답 형식으로 답변합니다:

   • 평결에 대한 응답.
   • 수락된 이의제기 (ID별): 변경한 내용. 각각에 대해: "이의제기 [ID]는 계층 [X]였습니다. 제 수정으로 [Y]가 변경되었습니다. 비율이 적절한 이유는 [Z]입니다."
   • 거부된 이의제기 (ID별): 동등하거나 더 높은 계층의 증거와 함께 사유.
   • 약한 이의제기 도전.
   • 가정에 대한 응답.
   • 수행된 수정 사항.
   • 남아 있는 미해결 질문.

   수정 사항을 적용하고 브랜치에 커밋합니다. 그런 다음 다음 라운드의 핸드오프를 전송합니다.

3. 범위, 동작 또는 설계를 변경하는 이의제기: 조용히 수정해서는 안 됩니다. 중단하고 챌린저의 텍스트를 그대로 운영자에게 결정 사항으로 제시합니다.

   • 직접 작성한 스펙이나 계획은 범위를 결정하지 않습니다. 이를 근거로 이의제기를 거부하지 마십시오. 운영자의 말이나 운영자가 승인한 스펙만이 유효합니다. 거부 사유가 범위뿐이라면 "운영자 범위 판결 필요"로 보고합니다.

4. 평결 PASS: 미해결 항목이 0이고 최종 평결이 APPROVED인 서명 완료 체크리스트(Sign-Off Checklist)가 있는 경우에만 유효합니다. 그렇지 않으면 REVISE로 처리합니다.

5. APPROVED 없이 라운드 제한 도달: 중단하고 미해결 기록부를 운영자에게 제시합니다. 운영자가 연장(한 번)하면 계속합니다. 그렇지 않거나 연장된 제한에 도달하면 교착 상태입니다: 챌린저에게 한 문단 분량의 최종 입장문(Final Position Statement)을 요청하고, 자신의 입장문을 작성하여 둘 다 운영자에게 제시합니다.

6. SELF-FAIL: 접근 방식 자체가 잘못된 경우, 세 가지 필수 부분과 함께 이를 명시합니다: (a) 무엇이 잘못되었는지, (b) 왜 도전을 통해 표면화되었는지, (c) 다른 접근 방식이 작동하게 하려면 무엇이 필요한지. 이를 운영자에게 제시합니다.

챌린저의 답변을 편집, 축소 또는 완화하지 마십시오. 이의제기가 해결되었다고 주장하지 마십시오. 오직 챌린저의 기록부만이 해결되었다고 표시할 수 있습니다.

기록 저장 위치

• 작업에 변경 폴더 또는 작업 기록이 있는 경우, 해당 라운드를 BCP-LEDGER.md로 저장합니다: 각 챌린저 답변과 각 빌더 응답을 순서대로.
• 그렇지 않으면 저장소 외부의 임시 폴더에 저장하고 최종 기록부를 보고서에 포함합니다.
• 이를 위해 새로운 최상위 폴더를 만들지 마십시오.

운영자 보고서 (완료 승인)

• 빌더와 챌린저에 사용된 모델 및 라운드 수.
• 최종 버전과 챌린저의 최종 평결.
• 최종 이의제기 기록부를 그대로.
• 챌린저의 양보 사항 및 미제기 위험 자체 감사 내용을 그대로.
• 검증 증거.
• 요청이 모호했던 부분에 대한 모든 해석 (예: "6~29일은 무료"), 운영자가 확인하거나 수정할 수 있도록.
• 운영자의 결정이 필요한 모든 사항: 교착 상태, SELF-FAIL, 범위 판결, 범위 변경 이의제기, 수락해야 할 위험.
• 그런 다음 진행(go) 또는 중단(no-go)을 요청합니다. 푸시, 병합 및 게시는 운영자의 진행 승인을 기다립니다.

챌린저를 실행할 수 없는 경우

1. 한 번 재시도합니다. 모델 오류가 지원되지 않는 모델을 언급하면 보고하고, 조용히 모델을 변경하지 마십시오.
2. 다른 도구를 계속 사용할 수 없는 경우, 자신의 도구 헤드리스 읽기 전용 명령어를 챌린저로 사용하여 동일한 루프를 실행합니다(references/tools.md 참조). 공유 컨텍스트가 없는 새 세션입니다.
3. 전체 결과를 보고서에 SELF-CHALLENGE로 표시하고, 두 번째 모델을 사용할 수 없었던 이유를 명시합니다. 자체 챌린지는 빌더의 맹점을 공유하므로 운영자는 이를 낮게 평가해야 합니다.
4. 이 단계를 조용히 건너뛰지 마십시오.