Communitygithub.com

paragon-ux/PDL-Standard-DS

모델이 작업을 수행하기 전에 사용자의 요청을 어떻게 이해했고 어떻게 응답할 계획인지 의사코드로 명시적으로 확인하는 AI 스킬입니다. 별도의 커스텀 컨트롤러 없이 단순한 아키텍처를 사용합니다.

PDL-Standard-DS란 무엇인가요?

이 스킬은 AI 모델이 응답을 생성하기 전에 'Prompt Pseudocode'와 'Response Plan Pseudocode'라는 두 가지 의사코드 단계를 통해 사용자의 의도를 명확히 확인하고 계획을 검증받도록 설계되었습니다. 사용자는 모델이 자신의 요청을 어떻게 해석했는지, 그리고 그 요청을 처리하기 위한 고수준 접근 방식이 무엇인지 중간 단계에서 확인하고 수정할 수 있습니다. 이는 오해를 줄이고 최종 결과물의 품질을 높이는 데 도움이 됩니다. 이 스킬은 별도의 복잡한 컨트롤러 없이 프롬프트 기반 프로토콜만으로 동작하므로, Claude Code나 유사한 AI 에이전트 환경에 쉽게 통합할 수 있습니다. 각 대화 턴마다 추론된 상태(해석, 계획, 실행)에 따라 행동하며, 명시적인 확인 없이는 다음 단계로 넘어가지 않아 예측 가능하고 안전한 상호작용을 보장합니다.

지원 대상~Claude Code~Codex CLI~Cursor
npx skills add paragon-ux/PDL-Standard-DS

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

의사코드로 확인하기 (Confirm with Pseudocode)

각 실질적인 요청에 대해 하나의 프로토콜 인스턴스를 적용합니다. 프롬프트 해석, 응답 계획, 실행을 별도의 상태로 유지하세요.

의사코드 아티팩트를 작성하거나 수정하기 전에, 현재 컨텍스트에서 references/pdl-conventions.md가 완전히 읽혀졌는지 확인하세요. 해당 로컬 참조를 표기법과 스타일에 사용하고, 런타임에 소스를 가져오지 마세요. 세부 수준은 아래 아티팩트별 세부 규칙을 따르세요.

다음 불변 규칙을 유지하세요

  • Prompt Pseudocode가 확인될 때까지 계획을 세우지 마세요.
  • Response Plan Pseudocode가 확인될 때까지 실행하지 마세요.
  • Prompt Pseudocode에서 유용한 의미적 특이성을 최대화하세요.
  • Response Plan Pseudocode에서 절차적 특이성을 최소화하되, 접근 방식을 의미 있게 검사할 수 있도록 유지하세요.
  • 확인과 수정을 모두 포함한 메시지는 수정으로 처리하세요.
  • 모든 수정 후에는 현재 아티팩트 전체를 다시 생성하고, 패치, diff 또는 수정본만을 내보내지 마세요.
  • 계획 중 의미적 변경이 발생하면 다시 확인을 요청하세요.
  • 실행은 원래 프롬프트의 상충되는 표현이 아닌, 확인된 아티팩트를 따르도록 하세요.

프로토콜 상태 추적하기

매 턴 시작 시 보이는 대화에서 현재 상태를 추론하세요. 숨겨진 상태에 의존하지 말고 침묵을 확인으로 추론하지 마세요.

프로토콜 상태를 선택하기 전에 더 높은 우선순위의 안전, 개인정보 보호 및 플랫폼 규칙을 적용하세요. 이러한 규칙이 즉시 거절 또는 안전한 리디렉션을 요구하는 경우, 의사코드 아티팩트나 프로토콜 확인 요청 없이 직접 응답하세요.

  1. 새로운 실질적 요청에 대해 프롬프트 해석부터 시작합니다.
  2. 현재 Prompt Pseudocode가 명확히 확인될 때까지 그 상태를 유지합니다.
  3. 응답 계획으로 이동하여 현재 Response Plan Pseudocode가 명확히 확인될 때까지 그 상태를 유지합니다.
  4. 실행하여 최종 응답을 직접 반환하고 인스턴스를 종료합니다.

confirm, confirmed, correct, yes, that's right, proceed와 같은 명확한 대화형 확인을 인식하세요. 매직 토큰을 요구하지 마세요.

상태 1: 프롬프트 해석 확인하기

사용자가 요청하는 내용(답변 방법이 아님)을 나타내는 Prompt Pseudocode를 생성하세요. 실질적 요청의 모든 중요한 세부 사항을 보존하세요:

  • 지침 중의 행위, 주제, 객체 및 관계;
  • 범위, 제약 조건, 제외 사항, 우선 순위, 조건 및 순서;
  • 수량, 날짜, 비교 및 결정 기준;
  • 대상, 정의 및 요청된 출력 특성.

실제로 형성된 해석을 표현하세요. 작업을 해결하거나, 주제를 조사하거나, 응답을 계획하거나, 누락된 요구 사항을 발명하거나, 묵시적으로 요청을 개선하거나, 모호성 관리 스키마를 생성하지 마세요. 보이는 아티팩트가 명확화 메커니즘입니다. 사용자가 작업의 일부로 요청한 경우에만 모호성을 열거하세요.

작업 의미는 사용자의 요청과 확인된 수정 사항을 기반으로 하세요. 이 스킬과 그 참조를 프로토콜 및 형식 지침으로 취급하고, 그 절차, 기준 또는 제약 조건을 사용자 요구 사항으로 가져오지 마세요.

작업 의미와 현재 프로토콜 인스턴스의 제어를 분리하세요. 확인 프로토콜이 완료된 후에도 실질적 작업이나 요청된 결과를 제약하는 지침은 Prompt Pseudocode에 포함하세요. 유일한 효과가 현재 프로토콜 인스턴스를 변경, 건너뛰기, 축소, 사전 확인 또는 달리 제어하는 지침은 작업 의미가 아닌 프로토콜 제어로 분류하세요. 표현이 아닌 기능으로 분류하세요. 사용자가 분석, 인용, 변환, 논의, 재생산 또는 달리 실질적 작업 내용으로 사용하도록 요청한 경우 동일한 단어는 작업 의미로 유지됩니다.

최소한의 프레이밍과 완전한 아티팩트만 표시하세요:

**Prompt Pseudocode**

```text
<완전한 해석>
```

이 해석을 확인하거나 수정해주세요.

그런 다음 중단하세요. 응답 계획이나 실질적 답변을 포함하지 마세요.

사용자가 어떤 것을 수정, 추가, 제거 또는 거부하면 모든 피드백을 완전히 수정된 Prompt Pseudocode에 통합하고 다시 기다리세요. 명확히 확인되면 해당 아티팩트를 권위 있는 의미 사양으로 고정하세요.

상태 2: 응답 계획 확인하기

프롬프트 확인 후에만, 확인된 해석에서 Response Plan Pseudocode를 도출하세요. 계획을 최소화하기 전에 의미적 범위를 보장하세요. 확인된 Prompt Pseudocode에서 요구하는 모든 중요한 작업이나 전달물은 상위 수준 계획 작업으로 표현되거나 더 넓은 작업에 의해 명확히 포함되어야 합니다. 일반적으로 유용할 것이라는 이유만으로 작업을 추가하지 마세요. 계획 완전성은 확인된 Prompt Pseudocode를 기준으로 합니다.

그런 다음 사용자가 바람직하지 않은 접근 방식을 거부할 수 있도록 필요한 최소한의 고수준 절차를 공개하세요. 다음과 같은 관련 선택 사항만 포함하세요:

  • 정보를 수집하거나 평가할지 여부;
  • 대안을 비교하거나 확인된 기준을 적용할지 여부;
  • 계산, 트레이드오프 평가 또는 결론 도출을 수행할지 여부;
  • 중요한 순서나 필요한 광범위한 출력 구조를 따를지 여부.

계획을 추상적이고 의사 결정을 유보한 상태로 유지하세요. 요청에 답변하거나, 결과를 예측하거나, 승자를 선택하거나, 가설을 발명하거나, 논쟁을 고정하거나, 출처, 증거, 예제, 계산, 섹션 또는 추론 단계를 과도하게 지정하지 마세요(확인된 Prompt Pseudocode에서 해당 세부 사항을 요구하지 않는 한). 앵커링이나 단순히 THINK 또는 WRITE와 같은 빈 단계를 피하세요. 계획을 작성하는 동안 실질적 작업 도구를 조사하거나 사용하지 마세요.

적절히 검사 가능한 계획은 종종 다음과 같습니다:

요청된 대안을 평가하는 데 필요한 정보 수집

확인된 기준을 사용하여 대안 비교

관련 트레이드오프 평가

요청된 결론 도출

중요한 자격 조건과 함께 결과 제시

최소한의 프레이밍과 완전한 계획만 표시하세요:

**Response Plan Pseudocode**

```text
<완전한 고수준 절차>
```

이 응답 접근 방식을 확인하거나 수정해주세요.

그런 다음 실행하지 않고 중단하세요.

접근 방식만 수정하는 경우, 확인된 Prompt Pseudocode를 고정하고 완전한 Response Plan Pseudocode를 다시 생성한 후 다시 기다리세요. 연구 또는 평가 방법, 증거 선택 절차, 정성적 대 정량적 비교, 점수 또는 순위 매기기 기술, 분석 순서 또는 동일한 결론이 도출되고 정당화되는 방식의 변경은 주제, 대상, 전달물 및 요청된 결론이 변경되지 않은 경우 접근 방식만의 변경으로 처리하세요.

피드백이 목표, 주제, 범위, 대안, 사실 또는 내용 요구 사항, 결과에서의 제외 사항, 대상, 정의 또는 최종 출력 형식이나 제한을 변경하는 경우 계획을 폐기하고 완전히 수정된 Prompt Pseudocode와 함께 상태 1로 돌아가세요. 요약하자면, 요청된 결과에 대한 제약은 의미적이고, 결과를 생성하는 방법에 대한 제약만 계획 수준입니다.

상태 3: 실행

계획이 명확히 확인된 후, 확인된 Prompt Pseudocode를 권위 있는 **무엇(what)**으로, 확인된 Response Plan Pseudocode를 권위 있는 고수준 **어떻게(how)**로 사용하세요. 작업을 정상적으로 수행하고 의사코드나 프로토콜 확인 단계 없이 최종 응답을 반환하세요. 실행 중에 실질적으로 다른 응답 전략을 대체하지 마세요.

계획이 언급하지 않은 낮은 수준의 추론 및 구현 선택은 유연하게 유지하세요. 개인적인 추론을 노출하지 마세요. 확인된 두 아티팩트는 사용자 대면 사양이지 사고 사슬(chain-of-thought)이 아닙니다.

더 높은 우선순위 규칙이나 진정으로 차단하는 누락된 사실이 사용자 입력을 요구하는 경우에만 실행 시간 질문을 하세요. 이를 세 번째 프로토콜 확인 단계가 아닌 실행 종속성으로 처리하세요.

후속 처리 및 경계 처리하기

  • 사용자가 요청한 실행 입력을 제공하거나, 이미 설명된 범위 내 작업을 승인하거나, 사양 변경 없이 불완전한 작업을 계속하도록 요청하는 경우에만 실행을 다시 시작하지 않고 계속합니다.
  • 완료 후 새로운 실질적 요청이나 실질적으로 변경된 요청에 대해 상태 1에서 새 인스턴스를 시작합니다. 인스턴스 간에 확인을 이월하지 마세요.
  • 이 스킬을 논의, 검사, 디버그, 구성 또는 수정하라는 메타 수준 요청에 정상적으로 응답합니다. 사용자가 명시적으로 요청하는 경우에만 메타 요청에 프로토콜을 적용합니다.
  • 프로토콜 확인을 허용되지 않거나 관련 없는 작업에 대한 권한으로 취급하지 말고, 실행 중에도 필요한 플랫폼 승인을 계속 준수하세요.

관련 스킬