에이전틱 엔지니어링

• 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에게 결과를 어떻게 반환할지도 알려주어야 합니다.

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

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

  • 표

  • 글머리표 목록

  • 다시 작성된 요구사항

  • 구조화된 보고서

  • 체크리스트

  • 요약

  • 제안된 변경 사항 목록

  • 질문 또는 미해결 이슈 집합

  출력 형식은 스킬의 목적과 일치해야 합니다. 예를 들어, 검토 중심 스킬은 문제, 설명, 권장 사항 열이 있는 표 형식이 적합한 경우가 많습니다. 다시 작성 중심 스킬은 원문 텍스트, 제안 출력, 근거를 함께 보여줄 때 적합한 경우가 많습니다.