목표 명령어 작성기

목표 명령어 작성기은(는) 무엇을 하나요?

모호한 요청을 에이전트가 성공, 진행 또는 중단의 의미를 추측하지 않고 실행할 수 있는 즉시 사용 가능한 목표(Goal) 명령어로 변환합니다. 사용자의 의도, 언어, 권한 경계 및 요청된 범위를 유지하십시오. 이 스킬은 명령어 계약을 설계하고 감사합니다. 런타임 접근, 권한 및 외부 승인은 여전히 호스트 에이전트와 사용자에게 있습니다. 목표를 작성하는 동안 검사를 설명하고, 사용자가 실행을 요청한 경우에만 기본 작업을 실행하십시오.

작성 또는 감사 시 references/goal-contract.md를 읽으십시오. 작업 예시가 요청된 작업을 명확히 하는 경우에만 references/examples.md를 읽으십시오. 여러 단계, 산출물 또는 여러 번의 반복에 걸친 작업의 경우 references/drift-control.md도 읽으십시오. 미리 보기 우선 워크플로우의 경우 references/loop-preview.md를 읽으십시오.

모드 선택

• 초안: 대략적인 요청에서 목표를 구성합니다.
• 개선: 누락된 목표, 증거, 루프 또는 종료 필드를 채우면서 기존 목표를 유지합니다.
• 감사: 모호함, 무제한 반복, 검증 불가능한 기준 및 안전하지 않거나 승인되지 않은 전환을 식별하고 최소한의 수정을 제안합니다.
• 변환: 체크리스트, 티켓 또는 프로젝트 개요를 범위를 확장하지 않고 목표로 전환합니다.
• 미리 보기: 최종 목표를 작성하기 전에 구체적인 루프, 분기, 표류 게이트 및 중지 조건을 보여줍니다. 이 모드에서는 실행 가능한 목표를 내보내거나 외부 작업을 수행하지 마십시오.

모드가 명시되지 않은 경우 입력에서 유추하십시오. 답변이 목표, 권한, 수용 증거 또는 법적 종료 상태를 변경할 수 있는 질문만 하십시오. 그렇지 않으면 가정을 명시하고 계속 진행하십시오.

초안 작성 전 미리 보기

사용자가 "先看循环", "preview", "先设计流程" 등과 같이 요청할 때 미리 보기 우선을 사용하십시오. 또한 다단계, 비용이 많이 들거나, 되돌릴 수 없거나, 실질적으로 불확실한 작업에 선호하십시오. 짧고 되돌릴 수 있는 작업의 경우 직접 초안 작성으로 충분합니다.

미리 보기는 실행 승인이 아닌 설계 확인 지점입니다:

1. 잠정적 결과, 기준선 및 가정을 명시합니다.
2. 첫 번째 작업 단위, 성공 및 실패 분기, 진행 증거, 표류 검사, 단계 게이트 및 합법적인 중지 상태를 포함하여 루프를 구체적인 상태 전환으로 보여줍니다. 반복 검사와 광범위한 단계 또는 전달 검사를 구별하고, 증거 재사용 및 비용이 많이 드는 검사의 한계를 포함합니다.
3. 루프 또는 범위를 변경할 수 있는 결정을 나열합니다. 피드백, 채택, 파일럿, 출시 또는 검증 작업의 경우 증거 임계값, 집계 대상 및 피드백 기간을 포함합니다.
4. 명확한 전환으로 끝냅니다: 최종 목표를 생성하기 전에 사용자가 루프를 확인하거나 수정할 때까지 기다립니다.

사용자가 확인하면, 수락된 미리 보기를 루프, 범위 또는 종료 규칙을 조용히 변경하지 않고 최종 목표에 반영합니다. 사용자가 수정하면, 미리 보기를 재생성하거나 먼저 변경된 결정을 기록합니다. 미리 보기 응답은 목표가 완료되었다고 주장하거나 루프가 설명되었다는 이유만으로 외부 부작용을 수행해서는 안 됩니다.

3계층 계약 구축

1. 목표: 결과 정의

관찰 가능한 최종 상태를 가진 한 문장을 작성합니다. 작업이 완료될 때 어떤 산출물, 행동, 결정 또는 검증된 변경이 존재할지 명시해야 합니다. 그런 다음 계약을 구체화합니다:

• 기준선: 현재 존재하는 것과 어떤 개정판, 출처 또는 사실이 권위 있는지.
• 범위: 변경될 수 있는 것과 동결된 것.
• 수용 기준: "계속 작업" 또는 "더 노력"과 같은 활동이 아닌 증거와 연결된 관찰 가능한 검사.
• 종속성 및 권한: 에이전트가 넘을 수도 넘지 못할 수도 있는 도구, 접근 권한, 소유자 결정 및 외부 게이트.
• 산출물: 반환될 파일, 결정, 보고서 또는 메시지.

피드백, 채택, 파일럿, 출시 또는 검증에 관한 목표의 경우, 초안 작성 전에 피드백 증거 임계값을 정의합니다: 피드백으로 간주되는 것, 진입점만으로 충분한지 최소한 N명의 비작성자 응답이 필요한지, 시간 제한 또는 시도 기간. 사용자가 명시적으로 선택하지 않는 한 작성자 전용 활동은 계산하지 마십시오.

목표당 하나의 부하 지지 결과를 선호합니다. 관련 없는 결과는 별도의 목표로 분할하십시오. "개선", "처리" 또는 "완료"와 같은 모호한 동사를 측정 가능한 결과로 대체하십시오.

장기 실행 작업에서 표류 방지

길거나 다단계 목표의 경우, 첫 번째 반복 전에 간결한 목표 앵커(Goal Anchor)를 고정합니다: 한 문장 결과, 기준 ID, 동결 범위 및 현재 단계. 이를 불변으로 취급합니다. 새로운 발견은 계획을 변경할 수 있지만 결과, 수용 기준 또는 권한을 조용히 변경해서는 안 됩니다. 명시적인 소유자 결정은 새로운 목표 버전 또는 범위 변경 기록을 생성합니다.

모든 반복에서 행동하기 전에 세 가지 링크를 기록합니다:

1. 대상 기준: 이 작업이 발전시키는 수용 기준.
2. 예상 델타: 작동할 경우 변경되어야 하는 관찰 가능한 증거.
3. 범위 사유: 이 작업이 현재 동결 경계 내에 있는 이유.

검증 후 결과를 다음과 같이 분류합니다:

• ON_TARGET: 명명된 기준이 이동했으며 증거가 다음 단계를 지원합니다.
• SIDE_QUEST: 유용하지만 이 목표에 필요하지 않음; 루프를 확장하는 대신 지연 목록에 보관합니다.
• DRIFTED: 이동된 기준이 없거나, 작업이 목표 또는 범위를 변경했거나, 다음 단계를 앵커에서 정당화할 수 없음; 중지하고 재정렬합니다.

기본적으로 3-5회 반복마다, 각 마일스톤에서, 그리고 되돌릴 수 없거나 고비용 작업 전에 단계 게이트를 실행합니다. 앵커를 다시 읽고, 현재 상태를 기준선과 비교하고, 기준을 열림 또는 확인됨으로 표시하고, 지연된 사이드 퀘스트를 검토하고, 하나의 정당화된 다음 작업을 선택합니다. 완료된 작업이 목표에 있는 것처럼 보이게 하기 위해 기준을 다시 작성하지 마십시오.

2. 루프: 진행 방법 정의

표시 가능한 진행 신호와 함께 제한된 반복을 사용합니다:

1. 검사: 현재 상태와 마지막 내구성 커서를 검사합니다.
2. 선택: 다음으로 가장 작은 작업 단위를 선택하고, 대상 기준, 예상 델타 및 범위 사유를 명명합니다.
3. 실행: 허용된 범위와 권한 내에서 실행합니다.
4. 검증: 아래 검증 전략을 사용하여 관련 기준에 대해 결과를 검증하고 증거를 캡처합니다.
5. 분류: 결과를 ON_TARGET, SIDE_QUEST 또는 DRIFTED로 분류하고 해당 표류 규칙을 적용합니다.
6. 기록: 다른 반복 전에 델타, 남은 격차, 결정 및 다음 커서를 기록합니다.

작업에 맞는 반복 제한을 명시합니다: 시간 제한, 도구 또는 토큰 예산, 최대 시도 횟수 또는 유한한 작업 단위 목록. 무작동 규칙을 추가합니다: 새로운 정보 없이 동일한 작업을 반복하지 마십시오; 반복된 실패 후에는 가설을 변경하거나 차단기와 함께 중지하십시오. 루프는 다음 반복이 이전 반복과 다른 이유를 설명할 수 있어야 합니다.

검증 전략

목표에 짧은 검증 전략을 포함합니다. 검사 실행 시기를 제어하면서 명시적인 사용자 및 저장소 수용 요구 사항을 유지합니다:

• 반복 검사: 영향을 받는 동작에 충분한 최소 검사를 선택합니다. 변경 영향, 새로운 실패, 해결되지 않은 불확실성 또는 필요한 게이트에 대해 확장합니다.
• 단계 및 전달 검사: 관련 구현이 안정화되면 필요한 나머지 회귀, 빌드, 통합 및 산출물 검사를 완료합니다. 단계 게이트는 현재 증거를 검토합니다. 전체 검증 및 전달 파이프라인을 자동으로 반복하지 않습니다.
• 증거 재사용: 결과를 확인된 소스 또는 산출물, 관련 입력, 종속성 및 환경에 연결합니다. 해당 조건이 유효한 한 결과를 전달합니다. 문서 또는 영수증 변경은 관련 없는 런타임 검사를 무효화하지 않습니다. 재사용된 증거와 새로 실행된 검사를 구별합니다.
• 재실행 이유: 검사를 반복하기 전에 결과를 무효화하는 변경 또는 새로운 증거를 명명하고 영향을 받는 검사를 선택합니다. 소스 또는 산출물 변경은 종속 증거를 무효화하며, 소비된 산출물이 변경될 때 소비자 검사를 포함합니다.
• 비용 및 완료: 비용이 많이 드는 검사에 적합한 명령 시간 제한 또는 시도 한계를 제공합니다. 시간 초과는 기준을 검증되지 않은 상태로 둡니다. 격차를 보고합니다. 모든 기준에 유효한 증거가 있고 전달이 완료되면 완료합니다. 추가 검사는 구체적인 해결되지 않은 우려 또는 무효화된 결과가 필요합니다.

3. 종료: 합법적 종료 정의

터미널 상태를 명시적이고 상호 이해 가능하게 만듭니다:

• 완료: 모든 수용 기준이 검증되었고 산출물을 사용할 수 있습니다.
• 차단됨: 명명된 종속성, 누락된 권한 또는 해결되지 않은 실패가 다음 의미 있는 작업을 방해합니다. 정확히 필요한 해제를 보고합니다.
• 일시 중지됨: 소유자가 명시적으로 일시 중지를 요청합니다. 커서를 보존하고 승인 없이 재개하지 마십시오.
• 시간 제한/예산 초과: 완료 전에 제한에 도달했습니다. 검증된 진행 상황, 남은 격차 및 가장 안전한 다음 작업을 보고합니다.
• 중지됨: 소유자가 작업을 취소하거나 작업이 부여된 권한을 초과합니다. 조용히 계속하지 마십시오.
• 재정렬 필요: 표류 검사가 실패했습니다. 현재 루프를 중지하고, 체크포인트를 보존하며, 다음 작업이 재앵커된 후에만 재개합니다. 로컬 터미널 레이블이 필요할 때 GOAL PAUSED: realignment required를 사용하십시오.

"만족할 때까지 계속", "무기한 시도" 또는 노력에만 기반한 성공 주장을 사용하지 마십시오. 작업에 터미널 문자열에 대한 로컬 규칙이 있으면 유지하십시오. 그렇지 않으면 각 상태에 짧고 정확한 레이블을 지정하고 최종 응답에 포함하도록 요구하십시오. 현재 작업이 어렵거나 흥미로워졌다고 해서 목표나 수용 기준을 변경할 수 없습니다.

답변 생성

사용자의 언어로 결과를 반환합니다. 다른 형식을 요청하지 않는 한 다음 순서를 사용합니다:

1. 설계 노트: 목표, 루프, 종료 및 표류 제어 선택 사항을 설명하는 짧은 단락 하나. 가정이나 가치 있는 미해결 질문을 나열합니다.
2. 루프 미리 보기: 미리 보기 모드에서 상태 전환, 분기, 증거, 표류 게이트, 터미널 상태 및 해결되지 않은 결정을 표시합니다. 거기서 멈추고 확인을 기다립니다.
3. 붙여넣기 가능한 목표: 초안, 개선 또는 변환 모드에서 Objective, Goal anchor, Baseline and scope, Acceptance criteria, Feedback evidence(해당되는 경우), Verification strategy, Execution loop, Drift control, Limits and no-op rule, Termination 및 Reporting 섹션과 함께 펜스 블록에 전체 명령어를 포함합니다.
4. 감사 노트: 개선 또는 감사 중인 경우 각각의 남은 모호함과 이를 해결하는 가장 작은 변경 사항을 명명합니다.

붙여넣기 가능한 블록은 명령어 작성 방법에 대한 논의가 아닌 명령어 자체로 실행 가능해야 합니다. 수용 검사와 터미널 상태는 나중에 검토자가 증거를 기반으로 결정할 수 있을 만큼 구체적으로 유지하십시오.