Samuele95/prometheus

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

LLM 에이전트를 위한 프롬프트 제작을 위한 범용 메타 프롬프팅 프레임워크. 모든 에이전트 CLI(Claude Code, Gemini CLI, Cursor 등) 및 비CLI 환경에서 작동합니다. 에이전트 루프, 원샷 태스크, 워크플로우 체인, 서브 에이전트 프롬프트, 시스템 페르소나, LLM-as-Judge 평가자, 에이전트 팀 등 일곱 가지 프롬프트 형태를 모두 다룹니다.

이 프레임워크는 고전적인 컨텍스트 엔지니어링(Anthropic의 "적절한 추상화 수준", "최소한의 실행 가능한 토큰 집합", "규칙보다 예제")과 양자 의미론적 원리(프롬프트는 '키를 찾는 도구'가 아닌 '연산자'이며, 순서는 구조적이고, 모호성은 기능이며, 결합은 비가산적임)를 기반으로 구축되었습니다.

이 스킬을 사용해야 하는 경우

사용자가 LLM 에이전트를 위한 프롬프트 설계 작업을 시작할 때 트리거하십시오. 일반적인 표현은 다음과 같습니다:

• "[작업]을 위한 프롬프트 작성을 도와줘"
• "[목적]을 위한 시스템 프롬프트가 필요해"
• "[프로젝트]를 위한 [Claude Code / Gemini CLI / 등] 프롬프트를 설정해줘"
• "[평가]를 위한 LLM-as-Judge 프롬프트를 설계해줘"
• "[X]를 수행하는 서브 에이전트를 만들고 있어, 그 지침 작성을 도와줘"
• "[작업]을 위한 에이전트 루프를 부트스트래핑해줘"

다음 경우에는 트리거하지 마십시오: 간단한 Q&A, 코드 완성 요청, 또는 사용자가 답변 자체를 원하는 경우(나중에 답변을 얻기 위한 프롬프트가 아닌 경우).

핵심 입장: 프롬프트는 연산자입니다

이 프레임워크가 기반하는 가장 심오한 재구성, 양자 의미론 문헌에서 비롯: 프롬프트는 모델로부터 '올바른 답'을 '추출'하지 않습니다. 프롬프트는 모델의 의미 상태 변환을 통해 답을 구성하는 연산자입니다. 프롬프트의 각 섹션은 특정 해석을 증폭하고, 다른 해석을 억제하며, 기저 상태를 혼합하여 새로운 판독을 생성하는 행렬입니다.

이는 은유가 아닙니다. 설계 관행을 변경합니다:

• "올바른 키워드"를 찾지 않습니다. — 변환을 설계합니다.
• 순서는 구조적입니다. — 연산자는 교환 법칙이 성립하지 않습니다.
• 섹션 결합은 간섭을 생성하며, 덧셈이 아닙니다.
• 각 명령은 정보를 파괴합니다. 이에 따라 설계하십시오.
• 사용자 의도의 모호성은 결함이 아니라 중첩 상태입니다.

이 스킬은 이러한 원칙을 장식이 아닌 구체적으로 적용합니다. 작동 매핑은 references/quantum-principles.md를, 섹션-연산자 카탈로그는 operators/를 참조하십시오.

세 가지 작동 모드

프레임워크는 사용자가 가져오는 내용에 따라 세 가지 모드 중 하나로 작동합니다:

처음부터 모드(기본값): 사용자가 작업을 설명하면 프레임워크가 프롬프트를 생성합니다. 6단계: 형태 추론 → 적응형 인터뷰 → 연산자 설계 초안 작성 → 감사 → 솔직한 평가 → 전달.

리팩터 모드: 사용자에게 기존 프롬프트가 있으며 이를 감사, 수정 또는 재작성하려고 합니다. 6단계(1R~6R): 수신 및 구문 분석 → 의도 복구 인터뷰 → 모드 선택(감사 / 대상 지정 리팩터 / 전면 재작성) → 모드 적용 → 솔직한 평가 → 전달. 전체 절차는 references/refactor-mode.md에 문서화되어 있습니다.

관리 모드: 사용자가 기존 관리형 에이전트 패키지를 가리키며 실행 모니터링, 목표 위반 분석, 적응, 내부 상태를 유지한 정지 및 재시작 등 수명 주기 전반에 걸쳐 실행하기를 원합니다. 이는 프레임워크를 단순한 설계자가 아닌 에이전트 관리자로 사용하는 것입니다: 에이전트 프롬프트에 대한 MAPE-K 루프(모니터링/분석/계획/실행)를 연산자 대수를 통해 표현합니다. 전체 절차는 references/manage-mode.md에, 패키지 레이아웃, 수명 주기 및 원장은 references/agent-state.md에 있습니다.

모드 감지. 사용자의 시작 메시지에 프롬프트 붙여넣기와 감사, 개선, 수정 또는 리팩터 요청이 포함된 경우 리팩터 모드를 자동 감지합니다. "이 프롬프트 리팩터", "이 프롬프트 감사", "이 프롬프트 문제점"과 같은 직접 호출은 즉시 리팩터 모드를 트리거합니다. 사용자가 기존 에이전트 패키지 경로를 가리키거나 "이 에이전트 관리", "적응 주기 실행", "내 에이전트가 왜 퇴보했을까", "내 에이전트 다시 시작"과 같은 수명 주기 동사를 호출하면 관리 모드를 자동 감지합니다. 감지가 모호한 경우(프롬프트가 붙여넣어졌지만 요청이 불명확한 경우), 한 번 질문하십시오: "프롬프트가 보입니다. 리팩터를 원하시나요, 아니면 다른 작업을 위한 컨텍스트로 사용하시는 건가요?" 리팩터 또는 관리 신호가 명확하지 않은 한 기본값은 처음부터 모드입니다.

세 가지 모드는 인프라(형태 카탈로그, 연산자 카탈로그, 감사 체크리스트, 검증기 사양)를 공유하지만 다른 절차를 실행합니다. 특히 관리 모드는 새로운 분석 메커니즘을 추가하기보다는 처음부터 모드 및 리팩터 모드의 하위 루틴(감사 체크리스트, 리팩터 하위 모드, 교차 실행 검증기)을 재사용합니다. 처음부터 모드 절차는 아래에 이어집니다. 리팩터 절차는 references/refactor-mode.md에, 관리 절차는 references/manage-mode.md에 있습니다.

처음부터 모드 절차(6단계)

1단계 — 라우팅이 아닌 형태 추론

사용자의 작업 설명은 중첩 상태의 의미 상태로 도착합니다. 라우팅 질문을 하지 마십시오. 이미 존재하는 신호로부터 형태를 추론하십시오. §2.4 베이지안 샘플링의 정신에 따라.

1. 사용자의 요청을 주의 깊게 읽으십시오. 신호 추출: 동사(빌드 / 초안 / 분류 / 등급 / 평가 / 추출 / 요약), 명사(시스템 / 문서 / 파이프라인 / 루프 / 에이전트 / 페르소나 / 판사), 규모 표시자(원샷 대 지속적, 다중 턴 대 단일 호출), 및 도구 언급(Claude Code, Gemini CLI 등).

2. 가능한 형태에 대한 내부 사후 분포를 생성하십시오. 형태 카탈로그는 templates/shape-catalog.md에 있습니다. 아직 결정하지 말고 가중치를 유지하십시오.

3. 두 번째 형태가 명확히 뒤쳐져 있는 경우에만 가장 높은 사후 확률을 가진 형태를 선택하십시오. 두 개 이상의 형태가 서로 ~30% 이내에 있으면 추론이 모호하므로 하나의 대상 지정 명료화 질문을 통해 명확히 해야 합니다. 개방형 라우팅 질문이 아닌 상위 두 형태 간의 강제 선택으로 표현하십시오.

4. 도메인(엔지니어링 / 연구 / 글쓰기 / 운영 / 일반)은 보조 축이며, 형태와 직교합니다. 같은 방식으로 추론하십시오. 원샷 글쓰기 프롬프트와 에이전트 엔지니어링 프롬프트 모두 이 프레임워크를 적용하며, 단지 섹션 내용이 다를 뿐입니다.

5. 동일한 패스 중에 하드 추론 신호를 감지하십시오. 수학/논리 작업, 다단계 계획, 코드 분석 또는 디버깅, 다중 제약 조건 문제, 또는 사용자가 모델이 첫 번째 시도에 실패했다고 언급하는 작업은 references/reasoning-patterns.md(인지 도구 비계)를 구조적 기본값(선택적 확장이 아님)으로 포함해야 한다는 신호입니다. 두 개 이상의 신호 + 도구 호출 런타임 → 인용된 실증 결과가 적용되는 레거시 및 강력 등급에 비계를 포함하십시오. 최첨단 등급에서 비계는 M5 트리거 옵션이며 기본값이 아닙니다 — references/reasoning-patterns.md §등급 게이팅 참조.

6. 기판 역량 등급 추론 — 형태 및 도메인과 직교하는 세 번째 축으로, 런타임 답변에서 읽습니다: 최첨단(런타임의 가장 최신 고지시 따르기 모델), 강력(현재 주류 모델), 레거시(구형 또는 소형 모델). 알 수 없음 → 강력으로 가정. 등급 조건: 3단계의 기본 연산자 강도(references/quantum-principles.md의 원칙 9 — 규범적 연산자는 고지시 따르기 기판에서 과도하게 투영됨), 비계 트리거 임계값(위 5번), 프리필 가용성, 및 6단계의 추론 제어 매개변수 안내.

2단계 — 적응형 인터뷰(연산자 인식)

인터뷰 자체는 사용자 의도에 적용되는 일련의 연산자입니다. §5.6에 따라, 모든 질문은 모호성을 비가역적으로 붕괴시킵니다. 너무 빨리 붕괴시키지 마십시오.

수행 규칙:

• 총 6개의 평면 질문으로 제한하십시오. 여기에는 1단계의 명료화 질문이 포함됩니다(3개의 보편적 질문 — 배포 컨텍스트가 명백한 경우 생략 가능 — 더하기 2~3개의 형태별 질문). 엄격한 상한. 공동 작성 패스(형태 3, 6, 7)는 templates/interview-branches.md의 수행 규칙에 따라 면제됩니다.
• 턴당 하나의 질문. 여러 질문이 있는 턴은 더 얕은 답변을 생성합니다.
• 사용자의 요청에 이미 답변이 있는 질문은 건너뛰십시오. 재질문은 정보를 파괴하는 반복입니다.
• 질문 순서가 중요합니다(§2.3, §5.1). 가장 광범위한 프레이밍 질문을 먼저 하고, 제약 조건을 좁히고, 형식을 마지막에 지정하십시오. 첫 번째 질문은 이후 모든 질문이 작동할 하위 공간을 설정합니다.
• 질문 비용이 낮고 잘못될 비용이 높은 경우 중첩 상태를 유지하십시오(§4.1). 아키텍처 수준 선택(형태, 대상, 도구)의 경우 유지하십시오. 전술적 선택(파일 이름, 대문자 표기)의 경우 기본값을 정하고 진행하십시오.

형태별 질문 은행은 templates/interview-branches.md에 있습니다. 모든 형태에 공통되는 두 가지 질문이 있습니다:

1. 도구 / 런타임. "이 프롬프트는 어디서 실행됩니까? (Claude Code, Gemini CLI, OpenAI API, 일반 LLM, 기타?)" 메모리 파일 이름 지정 및 도구별 기능에 영향을 미칩니다.
2. 완료 정의 / 성공 기준. "프롬프트가 작동했는지 어떻게 알 수 있습니까? 직감이 아닌 확인 가능하게." 5단계의 자기 평가를 위한 루브릭을 제공합니다.

인터뷰를 요약 붕괴로 종료하십시오: 추론한 형태, 수집한 주요 제약 조건, 지정되지 않은 모든 항목에 할당하는 기본값을 명시하십시오. 초안 작성 전에 사용자에게 한 번 재정의할 기회를 주십시오. 이것은 의도적인 측정 단계입니다(§1.2). 사용자가 붕괴에 이의를 제기할 수 있도록 명시적으로 만드십시오.

3단계 — 연산자 설계 초안 작성

초안 작성은 연산자 설계(§5.3)이지 섹션 채우기가 아닙니다. 포함하는 각 섹션에 대해:

1. 기저 상태 식별 — 어떤 해석이 증폭, 억제 또는 혼합되어야 합니까?
2. 강도 선택 — 강한 연산자(페르소나, 하드 제약 조건)는 적극적으로 투영하고, 약한 연산자(스타일 선호도, 형식)는 대부분의 다른 연산자와 교환됩니다. 기판 등급에 기본 강도 보정(원칙 9): 최첨단 등급에서는 열거보다 간결한 일반 명령을 선호하고, 입증된 실패 모드가 있는 제약 조건에 대해 강도 언어("CRITICAL", "MUST", 반복 금지)를 사용하십시오. 레거시 등급에서는 더 강한 투영이 종종 정당화됩니다. 파괴적 역량 역할에 대한 역량 잠금은 모든 등급에서 계층화되고 명확하게 유지하십시오 — 그 근거는 기판 약점이 아니라 위험입니다.
3. 연산자 시퀀스에 배치 §5.1에 따라: 가장 광범위한 프레이밍을 먼저, 좁히기, 형식을 마지막으로.
4. 인접 섹션과의 간섭 확인(§5.4) — 조합이 의도했거나 의도하지 않은 긴급 행동을 생성합니까?

형태별 템플릿은 templates/shape-catalog.md를 사용하십시오. 섹션별 연산자 설명(각 섹션이 증폭/억제/혼합하는 것, 강도, 교환 속성)은 operators/를 사용하십시오. 전체 형태 선택이 필요하지 않은 작업(작고, 잘 정의되며, 단일 목적)의 경우 templates/minimum-viable-prompt.yaml이 대체 비계입니다 — 6개의 슬롯(시스템 / 지침 / 예제 / 제약 조건 / 상태 / 질문)과 그 이상은 없습니다.

구조화된 분해가 단일체 사고 사슬보다 성능이 뛰어난 추론 중심 작업의 경우 references/reasoning-patterns.md를 참조하십시오 — 인지 도구 하위 패턴(IBM Zurich, AIME2024에서 +16.6%)과 선택된 형태 내에서 이를 호출해야 하는 시기를 문서화합니다.

프롬프트의 출력이 사람이 아닌 다른 LLM 에이전트가 사용하는 경우(형태 4 서브 에이전트/도구 프롬프트 및 형태 6 LLM-as-Judge에서 가장 일반적), references/agent-consumability.md를 참조하십시오. 출력 설계는 소비자가 에이전트일 때 변경됩니다: 검색 가능한 실패 마커, 집계 우선 구조, 상세 로그가 포함된 간결한 표준 출력, 결정론적이지만 다른 샘플링, 및 가시적인 상태 전환.

형태 7(에이전트 팀)의 경우 토폴로지 선택이 기본적이며 역할별 초안 작성보다 선행되어야 합니다. references/agent-team-topologies.md를 참조하여 네 가지 표준 토폴로지(오케스트레이터-작업자, 병렬화-분할, 병렬화-투표, 평가자-최적화자)와 각각의 연산자 프로필, 역할 정의 및 일반적인 실패 모드를 확인하십시오. 먼저 토폴로지를 선택한 다음 각 역할의 프롬프트를 개별 형태 템플릿을 사용하여 초안을 작성하고, 역할 간 일관성을 감사하십시오.

보편적인 초안 작성 규칙이 모든 형태에 적용됩니다:

• 적절한 추상화 수준. 행동할 수 있을 만큼 구체적이며, 모델이 적응할 수 있을 만큼 유연합니다. 깨지기 쉬운 하드코딩과 모호한 막연함은 이중 실패 모드입니다.
• 최소한의 실행 가능한 토큰 집합. 특정 실패 모드를 해결하거나 구체적인 동작을 가능하게 하지 않는 것은 제거하십시오. 각 토큰은 주의력을 소모합니다.
• 규칙보다 예제. 규칙이 중요할 때는 작업 예제를 작성하십시오. 예제는 추상적인 지침을 고정하는 중요한 연산자입니다. 그러나 예제는 고유한 모호성 표면이 있습니다. 예제 내의 모든 암묵적인 판단 호출은 모델이 역엔지니어링하는 규칙이 됩니다. 예제를 제공하기 전에 스스로에게 물어보십시오: 이 예제는 내 의도 외에 조용히 무엇을 가르치는가? 확실하지 않으면 더 깔끔한 경우로 교체하십시오.
• 연산자 강도별 섹션 순서. 가장 강한 연산자를 먼저.
• DO NOT으로서의 실패 모드. 각각은 구체적인 결과와 함께 알려진 특정 날카로운 모서리를 다룹니다. 일반적인 경고는 토큰을 낭비합니다.

4단계 — 감사(구조적 및 양자)

references/audit-checklist.md의 감사 체크리스트를 실행하십시오. 체크리스트는 고전적인 컨텍스트 엔지니어링 검사(적절한 추상화 수준, 최소 토큰 집합, 예제 존재, 장기 지원 내구성)와 양자 의미론적 검사를 결합합니다:

• 연산자 카탈로그 완전함. 각 섹션은 명확한 증폭/억제/혼합 프로필을 가지고 있습니다. "장식"인 섹션은 없습니다.
• 순서 최적화. 가장 강한 연산자를 먼저. 인접한 섹션을 정신적으로 교체하고 "이것이 동작을 변경하는가?"라고 자문해 보십시오. 그렇다면 비가환 쌍을 올바르게 식별한 것입니다.
• 간섭 확인. 두 섹션이 상호 작용할 가능성이 있는 경우(예: 페르소나 + 톤 + 형식), 결합이 의도된 긴급 행동을 생성하는지, 원치 않는 소거를 생성하는지 확인하십시오.
• 정보 보존. 중요한 컨텍스트는 가능한 한 일찍 로드됩니다(더 많은 투영에서 살아남습니다). 모호하게 유지되어야 하는 것은 미리 붕괴시키지 말고 그대로 표시하십시오.
• 측정 인식. 프롬프트가 LLM-as-Judge(형태 6) 또는 에이전트 평가자의 일부인 경우, 평가 기준이 프롬프트 자체 외부에 명시적으로 정의되어 있는지 확인하십시오(순환 평가 방지).
• 중첩 표시. 의도적으로 모호하게 남겨둔 것은(templates/interview-branches.md의 보존 규칙에 따라) 명시적으로 표시됩니다.

5단계 — 솔직한 평가

사용자를 속이고 스스로를 속이지 마십시오. 프롬프트의 약점을 객관적인 용어로 설명하십시오. 어조는 전문적이고 직접적이며, 지나치게 미안해하지도 않고 지나치게 공격적이지도 않아야 합니다.

각 약점에 대해 다음을 설명하십시오:

• 무엇이 위험에 처했는가. 지금의 프롬프트로, 어떤 실패 모드가 발생할 가능성이 높습니까?
• 확률적 심각도. 이것이 자주 발생합니까, 아니면 드뭅니까? 발생하면 심각한가, 사소한가? (높음/중간/낮음)
• 권장 완화. 한 문장으로, 4단계 감사보다 더 깊이 들어가지 않고.

평가 영역:

1. 모호성 관리. 의도하지 않은 중첩 붕괴가 있습니까? 보존되어야 할 모호성이 사전에 붕괴되었습니까?
2. 간섭 역학. 섹션 결합이 원치 않는 긴급 동작을 생성합니까?
3. 연산자 강도 정렬. 연산자 투영이 작업 및 기판에 적절합니까? 과도하게 투영적입니까, 아니면 충분히 투영적입니까?
4. 구체성 수준. 적절한 추상화 수준을 유지합니까? 구체적으로 할 수 있는 부분이 모호합니까, 아니면 유연해야 하는 부분이 너무 엄격합니까?
5. 러닝 보드. 프롬프트의 확장을 테스트하는 데 사용할 수 있는 진입 경계 조건이 있습니까? (예: "이 프롬프트로 테스트할 수 있는 엣지 케이스는 무엇입니까?")

평가 후 사용자에게 피드백을 통합할 기회를 한 번 주십시오. "이러한 약점을 해결하기 위해 초안을 수정하시겠습니까?" 이 시점 이후에는 3단계로 돌아갈 수 있습니다.

6단계 — 전달

최종 프롬프트를 제공할 때는 항상 다음을 포함하십시오:

• 지침 텍스트: 최종 프롬프트 텍스트 자체(사용자가 복사하여 붙여넣기 위해).
• 실행 컨텍스트: 프롬프트가 실행되도록 의도된 환경과 대상 모델(기판 등급 포함).
• 사용법 참고 사항: 프롬프트를 최대한 활용하는 방법에 대한 간결한 안내(예: "첫 번째 교체는 {task}를 구체적인 작업 설명으로 교체" 또는 "이 프롬프트는 Claude 3.5 Sonnet에서 개발되었습니다. 더 작은 모델에 사용하는 경우 섹션 [X]에 더 많은 예제를 추가하십시오").
• 기판 등급에 따른 조정: 프롬프트가 특정 등급(최첨단, 강력, 레거시)에 맞게 설계된 경우, 다른 등급에서의 동작에 대한 예측과 함께 알려진 조정 사항을 명시하십시오.

리팩터 모드

리팩터 절차는 references/refactor-mode.md에 문서화되어 있습니다. 사용자가 기존 프롬프트를 제공할 때 자동으로 트리거됩니다. 2단계(의도 복구 인터뷰)에서 프롬프트가 생성되거나 사용되는 컨텍스트를 재구성하는 데 집중하십시오. 3단계(모드 적용)는 사용자의 목표와 수집된 맥락에 따라 감사 체크리스트, 리팩터 템플릿 또는 전체 재작성을 실행합니다.

관리 모드

관리 절차는 references/manage-mode.md에 문서화되어 있습니다. 사용자가 기존 에이전트 패키지의 수명 주기를 관리하려고 할 때 트리거됩니다. 패키지의 디렉터리 구조, 원장 파일 및 수명 주기 신호를 읽고 MAPE-K 루프를 실행합니다. 사용자 작업이나 원장의 목표 위반에 응답할 수 있으며, 적응 주기를 실행하고, 동일한 내부 상태로 에이전트를 중지/재시작합니다.

참조

• templates/shape-catalog.md: 형태 카탈로그
• templates/interview-branches.md: 형태별 질문 은행
• templates/minimum-viable-prompt.yaml: 최소 실행 가능 프롬프트 비계
• operators/: 연산자 카탈로그
• references/refactor-mode.md: 리팩터 모드 절차
• references/manage-mode.md: 관리 모드 절차
• references/agent-state.md: 에이전트 상태 및 패키지 레이아웃
• references/quantum-principles.md: 양자 의미론 원칙
• references/reasoning-patterns.md: 하드 추론 패턴(인지 도구)
• references/agent-consumability.md: 에이전트 소비 가능 출력 설계
• references/agent-team-topologies.md: 에이전트 팀 토폴로지
• references/audit-checklist.md: 감사 체크리스트