에이전틱 엔지니어링

• Break Down Complex Requirements – 선택한 요구사항을 분석하고 원래 의도를 유지하면서 더 작고 독립적으로 테스트 가능한 요구사항으로 분할합니다.

  예시 프롬프트:

  Break down these requirements.

• Apply Requirement Writing Standards – 요구사항을 검토하고 조직의 요구사항 작성 가이드라인에 따라 다시 작성합니다. 일반적인 점검 항목에는 모호성, 검증 불가능한 표현, 누락된 행위자, 불명확한 승인 기준이 포함됩니다.

  예시 프롬프트:

  Rewrite these requirements according to our requirement quality standard.

• Translate Requirements – 기술적 의미, 용어, ID 및 추적성 참조를 유지하면서 요구사항을 한 언어에서 다른 언어로 번역합니다.

  예시 프롬프트:

  Translate these requirements to German.

• Classify Requirements – Electronics, Mechanical, Software, Safety, Security 또는 기타 회사별 분류 체계와 같은 조직의 분류 체계를 요구사항에 적용합니다.

  예시 프롬프트:

  Classify these requirements according to our applicability model.

• Generate Verification Criteria – 요구사항을 분석하고, 항상 동일한 방식으로 준수를 입증하는 데 사용할 수 있는 검증 방법, 승인 기준 또는 테스트 조건을 제안합니다.

  예시 프롬프트:

  Generate verification criteria for these requirements.

• Summarize a Specification/Section/Group of Requirements – 명세서, 요구사항 섹션 또는 요구사항 집합에 대한 간결하고 구조화된 요약을 생성합니다.

  예시 프롬프트:

  Summarize the selected requirements.

좋은 스킬은 AI가 두 가지를 이해하도록 도와줍니다:

• 스킬을 언제 사용해야 하는지

• 스킬이 실행될 때 AI가 무엇을 해야 하는지

스킬을 정의할 때, 

이는 서로 다른 목적을 가진 세 가지 필드를 통해 표현됩니다:

• Name – 스킬을 식별하는 데 도움이 됩니다.

• Short Description – AI가 해당 스킬이 관련 있는지 판단하는 데 도움이 됩니다.

• Instructions – 스킬이 선택된 후 AI가 따라야 할 동작을 정의합니다.

각 필드에 대한 자세한 내용은 아래 섹션을 참조하세요.

이름

Name은(는) 짧고, 명확하며, 행동 지향적이어야 합니다. 이름만 보고도 해당 스킬이 어떤 용도인지 빠르게 이해할 수 있어야 합니다. 좋은 이름은 일반적으로 스킬이 수행하는 작업과 그 대상이 되는 엔지니어링 데이터 유형을 설명합니다.

좋은 스킬 이름은 다음과 같아야 합니다:

• 다른 스킬과 구분될 만큼 충분히 구체적이어야 함

• 스킬 목록에서 쉽게 훑어볼 수 있을 만큼 짧아야 함

• 스킬이 수행하는 핵심 작업에 초점이 맞춰져 있어야 함

• 사용자가 자연스럽게 이해할 수 있는 언어로 작성되어야 함

너무 광범위하거나 일반적인 이름은 피하세요. 이름이 여러 다른 작업에 모두 적용될 수 있다면, 충분히 구체적이지 않을 가능성이 큽니다.

짧은 설명

Short Description은(는) AI가 스킬의 주제와 언제 트리거되어야 하는지를 이해하는 데 도움이 됩니다. 이 필드가 중요한 이유는 스킬을 수동으로 선택할 필요가 없기 때문입니다. 어시스턴트는 사용자의 프롬프트를 분석하고, 사용 가능한 스킬과 비교한 뒤, 해당 스킬이 관련 있는지 판단합니다.

좋은 짧은 설명에는 다음이 포함되어야 합니다:

• 스킬이 수행하는 작업

• 적용되는 엔지니어링 데이터 유형

• 스킬을 사용해야 하는 시점

• 스킬이 생성해야 하는 예상 결과

짧은 설명은 간결해야 하지만 모호해서는 안 됩니다. AI가 이 스킬을 유사한 다른 스킬과 구분할 수 있도록 충분한 맥락을 포함해야 합니다.

약한 짧은 설명은 스킬이 속한 영역만 말합니다. 강한 짧은 설명은 구체적인 작업, 예상되는 맥락, 그리고 트리거 상황을 설명합니다. 예를 들어, 어떤 스킬을 단순히 "요구사항을 도와주는" 것으로 설명하는 대신, 해당 스킬이 요구사항 품질을 검토하는지, 복잡한 요구사항을 분해하는지, 요구사항 텍스트를 번역하는지, 충돌을 감지하는지, 검증 기준을 생성하는지, 또는 다른 특정 작업을 수행하는지를 설명해야 합니다.

짧은 설명이 스킬의 목적과 사용 맥락을 더 잘 설명할수록, 어시스턴트는 이를 언제 적용해야 하는지 더 안정적으로 판단할 수 있습니다.

지침

Instructions은(는) 스킬이 선택된 후 AI가 무엇을 해야 하는지를 정의합니다. 이는 스킬의 동작을 제어하는 가장 중요한 필드입니다. 짧은 설명이 AI가 스킬 사용 시점을 결정하도록 돕는다면, 지침은 스킬이 어떻게 실행되어야 하는지를 정의합니다.

좋은 지침은 명확한 단계별 안내로 작성되어야 합니다. 최종 출력만 설명하는 것이 아니라, 그 출력을 생성하는 동안 AI가 따라야 하는 추론과 제약 조건도 함께 설명해야 합니다.

지침에는 다음이 설명되어야 합니다:

• What the AI should analyze first – 변경하거나 생성하기 전에 어시스턴트가 일반적으로 엔지니어링 의도, 맥락, 구조 또는 관계를 이해해야 함

• What steps the AI should perform – 출력이 반복 가능하고 예측 가능하도록 동작을 명시적인 단계로 나누어야 함

• What the AI should preserve – 여기에는 원래 의도, 요구사항 ID, 기술 용어, 단위, 값, 제약 조건, 참조, 적용 범위, 계층 구조 또는 추적성 맥락이 포함될 수 있음

• What the AI must not do – 좋은 스킬은 AI가 누락된 엔지니어링 세부 정보를 만들어내거나, 의도를 변경하거나, 새로운 가정을 도입하거나, 사용자 검토 없이 변경을 적용하는 일을 명시적으로 방지함

• How the AI should handle uncertainty – 정보가 누락되었거나, 모호하거나, 충분하지 않은 경우, 스킬은 AI가 추측하는 대신 문제를 명확히 밝히도록 지시해야 함

• What output format is expected – 결과를 표, 글머리 기호 목록, 재작성된 텍스트, 요약, 체크리스트 또는 구조화된 보고서 중 어떤 형식으로 반환해야 하는지 스킬이 정의해야 함

좋은 지침은 엔지니어링 작업에서 특히 중요합니다. 어시스턴트가 사양, 검증, 설계 결정 또는 후속 구현에 영향을 미치는 데이터를 다룰 수 있기 때문입니다. 따라서 스킬은 AI가 과도한 확신 없이도 유용하게 동작하도록 안내해야 합니다.

기타 참고 사항

• 목표는 긴 프롬프트를 작성하는 것이 아닙니다. 목표는 AI를 위한 명확한 운영 절차를 정의하는 것입니다.

• Keep Skills Focused

  스킬은 반복 가능한 하나의 작업을 잘 수행해야 합니다.

  스킬이 너무 많은 일을 하려고 하면, 어시스턴트가 언제 이를 사용해야 하는지 판단하기가 더 어려워지고, 사용자가 출력 결과를 신뢰하기도 어려워집니다. 예를 들어, 하나의 스킬이 요구사항 분해, 번역, 품질 검토, 추적성 분석, 검증 생성까지 모두 결합해서는 안 됩니다. 단, 이러한 작업들이 의도적으로 하나의 긴밀하게 정의된 워크플로의 일부인 경우는 예외입니다.

  스킬의 목적상 여러 관련 없는 작업이 필요하다면, 이를 별도의 스킬로 나누세요.

• Define Boundaries Clearly

  좋은 스킬은 경계를 명확히 합니다.

  이는 요구사항, 사양, 엔지니어링 데이터를 다룰 때 특히 중요합니다. 어시스턴트는 무엇을 변경해도 되는지, 무엇은 제안만 해야 하는지, 무엇은 절대 가정해서는 안 되는지를 알아야 합니다.

  유용한 경계의 예시는 다음과 같습니다:

  • 원래의 엔지니어링 의도를 변경하지 말 것

  • 값, 제약 조건 또는 설계 결정을 지어내지 말 것

  • ID 또는 참조를 제거하지 말 것

  • 누락된 검증 방법을 임의로 가정하지 말 것

  • 사용자 검토 없이 자동으로 변경을 적용하지 말 것

  • 불명확한 정보를 사실로 취급하지 말 것

  명확한 경계는 그럴듯하지만 잘못된 엔지니어링 출력의 위험을 줄여줍니다.

• Define the Output Format

  스킬은 AI에 결과를 어떻게 반환할지도 알려줘야 합니다.

  일관된 출력 형식은 스킬을 검토하고, 비교하고, 재사용하기 쉽게 만듭니다.

  스킬에 따라 출력은 다음과 같을 수 있습니다:

  • 표

  • 글머리 기호 목록

  • 재작성된 요구사항

  • 구조화된 보고서

  • 체크리스트

  • 요약

  • 제안된 변경 사항 목록

  • 질문 또는 미해결 이슈 세트

  출력 형식은 스킬의 목적에 맞아야 합니다. 예를 들어, 검토 중심 스킬은 이슈, 설명, 권장 사항 열이 있는 표 형식이 잘 맞는 경우가 많습니다. 재작성 중심 스킬은 원문, 제안 출력, 근거를 함께 보여줄 때 효과적인 경우가 많습니다.