ARQAWA/cursor-pi

목표 정의하기

개요

사용자의 의도를 구체적인 결과물로 형성하고, 요청에서 파생된 완료 근거와 함께 범위를 제한합니다. 일반적인 검증은 기본 프롬프트의 규칙에 따라 읽기와 논리적 평가를 사용합니다. 숫자는 실제 요구 사항을 표현하는 경우에만 사용하십시오.

이 스킬은 목표 정의 및 목표 도구 생성만을 다룹니다. 이 스킬에서 중간 계획 아티팩트, 영구 스냅샷, 원장, 결정 로그 또는 재개 파일을 생성하지 마십시오.

오직 루트 Main만이 네이티브 Goal을 관리합니다. Goal 선택은 테스트, 검토, 위임, 권한 또는 다른 워크플로를 추가하지 않습니다. Gold Standard는 Goal 유무와 관계없이 독립적으로 유용한 작업 상태를 평가합니다. Notebook은 별도의 수동 요청 없이 자체 조건에서 선택된 Goal에 자동으로 참여할 수 있습니다. Goal만으로는 Notebook을 요구하지 않습니다. 이 정책에 따라 유용한 운영 노트를 보관하고, 이 정의 절차 외부에서 관리하십시오. 네이티브 목표와 상태가 권위를 유지합니다.

정의만으로는 제안된 작업의 실행을 승인하지 않습니다. Goal은 필요한 승인 또는 실행 확인을 대체하지 않습니다. ToSpec 준비는 미래의 실행 Goal을 시작하지 않으며, 명시적으로 선택된 준비 Goal은 요청된 준비 결과에만 관련됩니다. 자동 선택은 사용자의 일시 중지를 재정의하거나 차단기, 승인 대기, 종료 전환 또는 폐기되지 않은 취소를 완료로 전환하지 않습니다. 실제 네이티브 상태 규칙을 따르십시오. 완료는 실제 결과와 이미 필수적인 모든 조치를 요구합니다.

워크플로

1. 실제 현재 명령에 Goal이 유용한지 평가합니다.

   • 독립적으로 요청된 결과물이 종속 단계, 실질적인 연구 또는 불확실성, 또는 장기 실행을 통해 연속성이 필요할 때 자동으로 선택하되, 6단계의 권한 확인을 조건으로 합니다.
   • 짧은 질문, 간단한 편집 및 가능한 미래 작업에 대한 토론은 Goal이 필요하지 않습니다. 요청된 발견 자체는 구체적인 결과물을 가질 수 있습니다. 이를 논의하는 것이 실행을 승인하지는 않습니다.
   • 직접적인 /goal, 목표 생성 요청 또는 목표 정의 요청은 복잡성에 관계없이 이 스킬을 선택합니다. Goal 없이 작업하라는 지시는 해당 작업에 대한 자동 선택보다 우선합니다.
   • 모든 도구 호출이 아니라 작업의 중요한 변경 후에 재평가하십시오. 명령, 분, 파일에 대한 임계값을 사용하지 마십시오.

2. 가능한 목표를 구체적인 용어로 다시 표현합니다. 사용 가능한 목표는 다음을 명명합니다:

   • 참이 될 구체적인 결과물
   • 관련된 주요 아티팩트, 시스템, 저장소, 환경 또는 사용자 대면 동작
   • 읽기와 논리적 평가를 통해 실제 결과가 어떻게 확립될지, 그리고 명시적으로 요구된 증거
   • 범위 내에 있는 것
   • 모호함이 중요할 때 범위 밖에 있는 것
   • 사용자에게 묻는 대신 중단해야 하는 조건

3. 요청된 결과를 나타내는 기준을 사용합니다.

   • 요청에서 결과물, 아티팩트 경로, 범위, 형식, 값 및 이진 완료 조건을 도출합니다.
   • 공식적인 측정 가능성을 위해 메트릭, 임계값, 검증기 또는 실행 횟수를 발명하지 마십시오.
   • 테스트, 명령, CI, 측정 및 증거 개수는 명시적으로 요청된 경험적 증거, 특별히 채택된 절차 또는 우선 순위가 높은 의무에 대해서만 옵션입니다.
   • 일반적인 수정, 분석 또는 아키텍처 기반 성능 작업의 경우 실제 결과와 논리적 평가를 통해 완료를 정의합니다.

4. 약한 목표를 설정하기 전에 수정합니다.

   • 요청과 로컬 컨텍스트가 해당 해석을 안전하게 만드는 경우, 모호한 목표를 구체적인 결과 기준으로 다시 작성합니다.
   • 누락된 세부 사항이 의도된 결과물 또는 검증을 변경할 때 하나의 간결한 명확화 질문을 합니다.
   • "진전을 이루기", "계속 조사하기", "개선하기" 또는 "X에 작업하기"와 같은 순수 활동 목표는 검증 가능한 결과물로 구체화되지 않는 한 거부합니다.

5. 목표를 생성하기 전에 활성 목표 상태를 확인합니다.

   • scope_focus_native_context에서 현재 루트 네이티브 Goal 스냅샷을 읽습니다. conversationId, goalId, 목표 및 네이티브 상태(0 지정되지 않음, 1 활성, 2 일시 중지, 3 완료, 4 지워짐)의 유효성을 검증합니다. 유효한 루트 상태가 없으면 목표가 없는 것입니다. 알 수 없는 ID/상태는 알 수 없음이며, 부재가 아닙니다. 자식은 루트 Goal을 관리하지 않습니다. 제공된 경우에만 실제 네이티브 예산 필드를 사용하고, 발명하지 마십시오.
   • 사용 가능한 네이티브 create_goal/update_goal 도구와 현재 스키마를 사용합니다. Cursor create_goal은 objective를 받습니다. Codex 전용 예산 필드를 전달하지 마십시오. 필수 네이티브 기능이 없으면 해당 종속 전환이 중단됩니다. Goal을 시뮬레이션하거나 완전한 준비 상태를 주장하지 마십시오.
   • 완료되지 않은 목표가 없고, objective가 품질 기준을 충족하며 6단계가 생성을 허용하면 create_goal을 호출합니다.
   • 현재 사용자 지침 및 네이티브 상태에 따라 일치하는 완료되지 않은 목표를 재사용합니다. 반복 선택이 중복을 생성하거나 완료된 작업을 반복하지 않습니다.
   • 충돌하는 완료되지 않은 목표를 보존합니다. 공간을 만들기 위해 재설정, 교체 또는 완료로 표시하지 마십시오. 허용된 네이티브 경로 또는 초점 맞춘 사용자 질문을 통해서만 실질적인 충돌을 해결합니다. 새 스레드를 요구하지 마십시오.

6. 품질 기준을 통과한 경우에만 목표를 생성합니다.

   • 이 스킬을 선택한다고 해서 create_goal이 자동으로 승인되는 것은 아닙니다. 실제 도구 지침과 우선 순위가 높은 규칙을 따릅니다. 조건부 자동 Goal에 대한 사용자 수용을 표현하거나, 해당 규칙이 이를 수용하는 경우에만 적용 가능한 시스템/개발자 지시가 상시 요청을 제공합니다. 스킬 가용성 또는 일반 작업만으로는 해당 권한이 아닙니다. 호스트가 별도의 명시적 요청을 요구하는 경우, 해당 요구 사항에 대해 권한을 추론하지 마십시오.
   • 네이티브 Goal을 사용할 수 없거나 허용되지 않는 경우, 파일이나 다른 컨트롤러로 시뮬레이션하지 마십시오. 호환되는 승인된 작업을 계속합니다. 결과 또는 명시적으로 요청된 Goal에 중요한 경우에만 구체적인 제한 사항을 공개합니다.
   • 하나의 간결한 objective 문자열을 사용합니다.
   • 완료를 위한 충분한 근거를 포함합니다. 즉, 읽기와 논리를 통해 평가된 요청된 결과와 명시적으로 필수적인 증거를 포함합니다. 추가된 모든 임계값 또는 방법은 요청을 따라야 합니다. objective에 작성한다고 해서 권한이 생성되는 것은 아닙니다.
   • 작업을 제한할 때 범위 경계를 포함합니다.
   • 예산은 명시적으로 요청되고 실제 네이티브 스키마에서 지원되는 경우에만 제공됩니다. 요청된 예산을 Cursor 네이티브 Goal로 표현할 수 없는 경우, 해당 종속 전환을 중단하고 누락된 기능을 공개합니다. 예산을 묵묵히 폐기하거나 시뮬레이션하지 마십시오.
   • 모드를 활성화하거나 기술적인 문구를 승인하기 위해 다시 묻지 않고 명확하고 허용된 목표를 공식화합니다. 누락된 선택이 요청된 결과, 권한 또는 필수 증거를 실질적으로 변경하는 경우에만 질문합니다. 정의 전용 요청은 정의 전용으로 유지됩니다.

목표 품질 기준

create_goal 전에, objective는 다음을 답해야 합니다:

• 이 작업이 완료되면 실제로 어떤 구체적인 것이 참이 될까요?
• 이를 확립하는 실제 자료 및 논리적 근거는 무엇이며, 사용자가 명시적으로 요구한 경험적 증거는 무엇입니까?
• 성공을 정의하는 요청된 결과물 또는 의미 있는 이진 또는 정량적 조건은 무엇입니까?
• 어떤 범위 경계가 중요합니까?
• 에이전트가 중단하고 물어봐야 하는 원인은 무엇입니까?

좋음:

지정된 설정에서 A를 B로 교체합니다. 편집이 존재하고 영향을 받는 코드를 읽음으로써 요청과의 일관성이 확립되면 완료됩니다.

좋음:

관련 소스와 논리에서 지정된 설계 질문을 해결합니다. 결론이 뒷받침되고 물질적 모순이 해결되면 완료됩니다.

약함:

체크아웃 속도를 높입니다.

약함:

PR 댓글을 계속 조사합니다.

정량화 휴리스틱

• 버그의 경우, 필요한 수정을 정의하고 영향을 받는 코드와 논리를 통해 설명합니다. 재현 및 실패 후 통과 검증기는 해당 증거에 대한 명시적 요청이 필요합니다.
• 명시적으로 요청된 테스트의 경우, 순서가 지정된 시나리오와 통과 조건을 명명하고, 지정된 명령을 존중합니다.
• 성능의 경우, 메커니즘, 작업 및 컨텍스트에서 추론합니다. 계산된 복잡성을 계산으로 레이블 지정합니다. 실제 측정에서만 측정된 개선을 주장합니다. 메트릭, 목표, 방법 또는 실행 횟수를 발명하지 마십시오.
• 품질 작업의 경우, 일반적으로 읽기와 논리를 통해 평가되는 요청된 결과물을 사용합니다. 린트, 타입 검사 또는 테스트를 자동으로 추가하지 마십시오.
• 연구의 경우, 연구가 가능하게 해야 하는 결정, 범위 내 소스 또는 시스템 및 증거 기준을 정의합니다.
• 운영의 경우, 요청된 결과 상태를 정의합니다. 모니터링 기간, 임계값 또는 롤백 작업을 발명하지 마십시오.

명확화 질문

합리적인 재작성이 잘못된 결과를 추구할 위험이 있을 때만 질문하십시오. 질문을 짧게 유지하고 누락된 검증자 또는 범위 경계를 중심으로 구성하십시오.

유용한 질문 형태:

• "여기서 성공을 정의하는 메트릭은 무엇입니까: 지연 시간, 비용, 정확성 또는 사용자에게 표시되는 동작?"
• "로컬, 스테이징, 프로덕션 중 어떤 환경에 대해 검증해야 합니까?"
• "이 목표를 완료로 표시하기 전에 원하는 최소 증거는 무엇입니까?"

의미 있는 기준이 요청에서 직접적으로 따르는 경우, 추가 확인 없이 공식화하십시오. 해결되지 않은 선택이 결과물 또는 필수 증거를 실질적으로 변경하는 경우에만 질문하십시오.