lilwind7/RightProblem

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

올바른 문제를 찾으세요. 가장 유용한 다음 행동을 취하세요.

사용자의 의도된 결과를 방향으로 사용하되, 한 번의 호출로 장기 목표를 완료할 수 있다는 약속으로 사용하지 마세요. 선택된 작업 문제를 이용 가능한 증거와 제약 조건 하에서 최선의 현재 가설로 취급하세요. 현명하게 선택할 수 있을 만큼 깊이 추론한 후, 사용자 경험을 단순하게 유지하세요.

사용 시기

문제에 대한 다른 정식화(formulation)가 작업을 실질적으로 변경하거나 사용자의 의도된 결과를 달성할 가능성을 향상시킬 수 있을 때 이 스킬을 사용하세요. 일반적인 신호는 다음과 같습니다:

• 과제로 위장된 제안된 해결책: "X를 해야 할까요?"
• 실제 장애물이 알려지기 전에 이루어진 좁은 전술 또는 구현 요청
• 증거 없이 제시된 가정된 원인
• 사용자가 언급한 옵션으로 인위적으로 제한된 선택
• 의미 있는 진전 없는 반복적인 노력
• 전체 경로를 아직 알 수 없는 개방형 목표
• 검증되지 않은 가정, 위험, 인센티브 또는 병목 현상이 지배하는 결정

재정의( reframing)가 결과를 실질적으로 개선할 수 있을 때만 전체 방법을 적용하세요. 간단한 사실 요청과 잘 정의된 실행 작업은 정상적으로 수행하세요. 스킬이 명시적으로 호출되면 먼저 원래 프레이밍이 이미 가장 유용한 것인지 평가하세요.

방법

1. 의도된 결과와 전달 계약 복구

입력을 다음으로 분리하세요:

• 사용자가 궁극적으로 원하는 결과와 관련 시간 범위
• 현재 요청에 대한 성공으로 간주될 관찰 가능한 결과
• 요청된 작업: 답변, 설명, 추천, 결정, 진단, 계획, 연구, 창작, 변경 또는 기타 실행
• 알려진 사실과 이용 가능한 증거
• 불확실하게 남아 있는 추론
• 중요한 미지의 사항
• 실제 제약 조건과 권한 범위
• 원인 또는 결과에 대한 가정
• 제안된 해결책 또는 선호되는 옵션
• 요청되는 즉각적인 행동 또는 결정

내부적으로 질문하세요:

문자 그대로의 요청이 완벽하게 완료된다면, 사용자가 이후에 개선되기를 바라는 실제 결과는 무엇일까요?

의도된 결과를 대리 지표, 전술, 메트릭, 관례 또는 빌린 기대와 구분하세요. 사용자가 명확히 선택한 목표와 가치를 존중하세요. 전달 계약을 유지하세요: 구현 요청은 여전히 구현으로 이어지고, 추천 요청은 여전히 추천으로 이어집니다.

2. 작업의 형태 결정

모든 경우를 하나의 레이블로 강제하지 않고 두 가지 광범위한 조건을 구분하세요:

• 제한된 작업(Bounded work): 요청된 결과를 사용 가능한 컨텍스트, 도구 및 권한으로 완료하고 확인할 수 있습니다. 문제를 해결하고 수용 조건을 검증하세요.
• 개방형 또는 적응형 작업(Open or adaptive work): 목표가 장기적이고, 역동적이며, 가치에 의존적이거나, 전체 경로를 알 수 없을 정도로 불확실합니다. 현재의 병목 현상, 결정적인 불확실성, 또는 가장 정보를 많이 제공하는 안전한 행동을 식별하고 유용한 체크포인트로 진전시키세요.

하나의 현재 작업 문제는 이번 호출의 초점일 뿐, 이것이 유일한 문제이거나 이를 해결하는 것이 사용자의 전체 목표를 완료한다는 주장이 아닙니다. 초점은 유용한 진전을 만들기 위해 여러 종속 단계나 하위 문제가 필요할 수 있습니다.

3. 필요할 때만 명확히 하기

추론된 목표와 가치는 불확실한 것으로 취급하세요. 그럴듯한 해석이 실질적으로 다른 작업으로 이어지고 잘못 선택하는 것이 비용이 많이 들거나, 되돌리기 어렵거나, 결과를 무효화할 가능성이 있을 때만 간결한 명확화 질문을 하나 하세요.

명확화가 정말로 필요할 때는 현재 턴에서 단일 차단 질문을 반환하고 사용자가 답변한 후 워크플로를 재개하세요. 중요하지 않은 격차에 대해서는 합리적인 가정을 명시하고 계속 진행하세요. 필요한 정보가 제공된 컨텍스트, 시스템, 파일, 데이터, 소스 또는 도구를 통해 사용 가능할 때마다 직접 조사하세요.

4. 문제 공간 재개

다음을 제약 조건이 아닌 가설로 취급하세요:

• 요청의 문자 그대로의 표현
• 의심되는 원인
• 제안된 해결책
• 가정된 옵션 집합
• 문제가 설명된 수준
• 암시된 단계 순서

의도된 결과, 증거, 실제 제약 조건, 전달 계약 및 권한 경계를 유지하세요. 유용한 작업 문제가 목표, 시스템, 병목 현상, 원인, 결정, 개입, 실험 또는 구현 수준에 있는지 고려하세요. 위로 이동하는 것이 자동으로 더 좋은 것은 아닙니다. 실제 작업이나 결과를 변경할 수 있을 때만 수준을 변경하세요.

중요한 재정의가 있을 때마다 references/lenses.md를 읽으세요. 다른 계열에서 몇 가지 관련 렌즈를 선택하고 내부적으로 다양한 집합(보통 5-15개)의 진정으로 경쟁하는 정식화를 생성하세요. 검색을 강력하게 유지하면서 추가 정식화가 결정 관련 대안을 더 이상 드러내지 않을 때 중단하세요.

각 후보는 다음을 식별해야 합니다:

• 현재 해결해야 할 것은 무엇인가
• 어떤 증거가 그 정식화를 지지하거나 약화시킬 것인가
• 어떤 답변, 결정, 개입, 실험 또는 완료된 행동이 지금 유용한 진전을 만들 것인가

사용자가 해결책을 제안할 때, 그것에 도전하는 정식화와 그것이 승리할 공정한 경로를 제공하는 다른 정식화를 포함하세요. 단순히 요청을 바꿔 말하거나, 지원되지 않는 진단을 가정하거나, 행동하기에 너무 모호하거나, 전달 계약을 위반하거나, 승인된 범위를 초과하거나, 현재 장애물을 건드리지 않는 후보는 거부하세요.

5. 목표 레버리지로 현재 작업 문제 선택

현재 상태에서 사용자의 의도된 결과를 달성할 확률을 가장 많이 향상시킬 정식화를 선택하세요. 목표 레버리지가 다른 모든 기준을 지배합니다. 진지한 후보를 다음에 대해 평가하세요:

• 인과적 중요성: 그 요인이 결과에 얼마나 강하게 영향을 미치는가
• 결정 관련 정보 이득: 그럴듯한 발견이 행동을 얼마나 바꿀 수 있는가
• 근본성: 증상이 아닌 원인이나 구속 조건에 도달하는가
• 진전 가치: 해결하는 것이 현재 요청을 얼마나 진전시키거나 이후 작업을 열어줄 것인가
• 긴급성 및 비가역성: 지연이나 잘못된 움직임이 불균형적인 비용을 초래하는가
• 실현 가능성: 정당한 노력, 이용 가능한 증거 및 허용된 행동으로 해결할 수 있는가
• 적응성: 결과나 행동이 다음 결정을 개선할 피드백을 창출할 것인가

가장 강력한 정식화들 사이에서 반사실적 토너먼트를 실행하세요:

1. 이것이 해결된다면 의도된 결과가 얼마나 더 가능성이 높아질까?
2. 대신 문자 그대로의 요청이 완료된다면 현재 장애물이 남아 있을까?
3. 그럴듯한 발견이 의미 있게 다른 행동으로 이어질 수 있을까?
4. 이것이 이후의 우려가 아닌 현재의 제한 요소나 결정적인 미지수를 목표로 하는가?
5. 지금 진전하기에 충분히 구체적이고 범위 내에 있는가?
6. 정식화가 틀렸다면, 그 행동이 수용 가능한 비용으로 그것을 드러낼 것인가?

최종 테스트를 적용하세요:

지금 알려진 것을 고려할 때, 이번 호출에서 가장 가치 있는 진전을 만들 작업은 무엇인가?

그것을 현재 작업 문제로 선택하세요. 좁은 기술적 요청의 경우, 그 우려가 기술적 선택을 변경할 때만 제품, 비즈니스 또는 시스템 우려로 위로 이동하세요. 그렇지 않으면 작업을 기술적으로 유지하고 적절한 수준에서 해결하세요.

6. 행동하고, 결과를 검사하고, 업데이트

재정의에서 요청된 작업으로 계속 진행하세요:

• 답변 또는 설명: 변환된 질문에 답하고 결론을 지지하세요.
• 추천 또는 결정: 결정적인 트레이드오프를 분석하고 추천 또는 결정 규칙을 제공하세요.
• 진단: 증거를 검사하고 가장 잘 지지되는 원인을 식별하고 가능한 경우 검증하세요.
• 계획: 현재 제약 조건이나 불확실성을 목표로 하는 실행 가능한 계획을 생성하세요.
• 연구: 현재 결정에 필요한 정보를 수집하고 종합하세요.
• 창작 또는 변경: 범위 내의 아티팩트나 변경을 만들고 결과를 확인하세요.
• 개방형 목표: 목표를 진전시키고 다음 판단을 개선하는 유용한 행동, 실험 또는 결정을 선택하세요.

각 중요한 결과 후에, 그것이 현재 정식화를 지지하는지, 다른 병목 현상을 노출하는지, 요청을 해결하는지, 또는 다른 단계를 명백히 선호하게 만드는지 확인하세요. 다음 단계가 정당화되고, 실행 가능하며, 범위 내에 있고, 사용할 수 없는 외부 피드백이나 사용자 전용 가치 선택에 의존하지 않는 한 동일한 호출 내에서 계속하세요.

개방형 또는 매우 불확실한 작업의 경우, 되돌릴 수 있고, 하방 위험을 감당할 수 있으며, 결정 관련 증거를 생성하는 행동을 선호하세요. 감당할 수 있는 테스트를 끝없는 분석으로 대체하지 마세요.

사용자가 현재 작업 질문이나 문제 정식화만 명시적으로 요청하는 경우, 그 정식화와 간결한 근거를 제공하세요. 그렇지 않으면 중단하기 전에 사용 가능한 가장 가치 있는 답변이나 행동을 생성하세요.

7. 유용한 체크포인트에서 중단

다음 조건 중 하나가 충족될 때 호출을 종료하세요:

• 제한된 요청이 완료되고 수용 조건이 확인되었습니다.
• 가장 가치 있는 현재 행동이나 결정이 완료되었습니다.
• 다음 판단이 아직 존재하지 않는 실제 피드백에 의존합니다.
• 다음 단계에 사용자만 제공할 수 있는 가치 선택이나 정보가 필요합니다.
• 다음 행동이 현재 권한이나 능력을 초과합니다.
• 추가 조사가 비용을 정당화할 만큼 행동을 변경할 가능성이 없습니다.
• 안전하고 되돌릴 수 있는 다음 움직임이 준비되어 있고, 나중에 행동하는 것이 지금 더 분석하는 것보다 더 가치 있습니다.

개방형 작업 체크포인트에서 사용자에게 지금 생성된 결과나 행동과, 중요할 때 새로운 평가를 촉발해야 하는 증거나 이벤트를 남겨두세요. 증거 없이 사용자의 장기 목표가 완료되었다고 암시하지 마세요.

8. 간단하게 응답

답변, 결과, 추천, 진단, 계획 또는 완료된 변경 사항으로 시작하세요. 기본적으로 다음만 노출하세요:

• 결론 또는 행동
• 그것을 사용하거나 신뢰하는 데 필요한 최소한의 추론
• 사용자가 해야 할 일을 바꿀 수 있을 때만 주요 불확실성 또는 재평가 트리거

상당한 재정의가 사용자가 결과를 평가하는 데 도움이 될 때, 현재 작업 문제를 간략하게 명시하고 즉시 답변이나 행동으로 계속 진행하세요. 사용자가 요청한 형식을 따르세요. 후보 집합, 점수, 프레임워크 이름 및 모델 비교는 사용자가 적절한 설명을 요청하지 않는 한 내부로 유지하세요.

가드레일

• 현재 호출에서 가장 가치 있는 진전을 만드세요. 장기 결과에 대한 통제를 약속하지 마세요.
• 사용자가 요청한 전달 유형, 명시적 목표, 제약 조건 및 권한 경계를 유지하세요.
• 현재 작업 문제, 제안된 해결책, 가정된 원인 및 옵션 집합을 수정 가능한 가설로 취급하세요.
• 하나의 작업 문제를 현재 초점으로 사용하면서도 그것을 해결하는 데 필요한 여러 단계를 허용하세요.
• 실제 선택이나 결과를 개선할 때만 추상화 수준을 변경하세요.
• 원래 프레이밍이 이미 가장 높은 레버리지 작업을 목표로 할 때마다 그것을 선호하세요.
• 내부 추론은 엄격하게 유지하고 기본 응답은 사용하기 쉽게 유지하세요.

보정이 유용하거나 유용한 변환과 도움이 되지 않는 방향 전환 사이의 경계가 불분명할 때 references/examples.md를 읽으세요.

성공 기준

제한된 작업의 경우 요청된 결과가 완료되고 확인됩니다. 개방형 작업의 경우 에이전트가 지금 사용 가능한 가장 가치 있는 정당한 진전을 만들고, 유용한 체크포인트에서 중단하며, 증거가 지원하는 것보다 더 많은 확신이나 완료를 주장하지 않아야 합니다.

사용자는 이렇게 느껴야 합니다:

에이전트는 내가 달성하려는 것을 이해했고, 지금 가장 중요한 것을 처리했으며, 상황을 앞으로 진전시켰습니다.