영역 저술은(는) 무엇을 하나요?
영역은 에이전트가 언제 임무 중인지, 다음에 무엇을 해야 하는지, 어떻게 완료되었는지 알려줍니다. 그 규율에 기억에 남는 하우스 분위기를 부여하세요.
작성 전
대상 가이드와 헌장의 트리거 테이블을 읽으세요. 합의된 하우스 할당을 유지하고 이웃 영역과 구별하세요. 사용자가 처리하고자 하는 실제 개발 상황에서 작업하세요. 인식 가능한 기술 이름을 사용하세요: "모의, 스텁, 페이크"는 "제어된 이중"만 사용하는 것보다 발견에 도움이 됩니다.
선택을 메인 스킬에 배치
메인 realms-of-code SKILL.md는 각 영역을 사용할 시기를 소유합니다. 해당 테이블은 에이전트가 가이드를 로드하기 전에 선택할 수 있도록 해야 합니다. 구체적인 상황을 사용하세요: 파일 삭제 테스트, API 표준 선택, 또는 쿼리 횟수 개선 보호. 각 가이드에서 반복하지 않고 트리거를 한 번만 유지하세요.
모범 사례를 영역 가이드에 배치
- 이름, 규율, 모토: 제목, 하나의 구체적인 범위 줄 및 모토.
- 전승: 파벌을 엔지니어링 역할에 연결하는 짧고 생생한 단락. 은유가 작업을 설명하게 하세요.
- 공리: 결정을 안내하는 몇 가지 간결한 원칙. 기존 영역을 수정할 때는 확립된 약속을 보존하세요.
- 해야 할 일: 동사로 시작하는 실용적인 단계. 검사하거나 변경할 사항, 접근 방식을 선택하는 방법, 확인할 사항을 식별하세요. 명시적인 기술 이름을 사용하고 프로젝트의 도구를 재사용하세요. 의미 있는 대안과 함정을 설명하세요.
- 증거: 완료를 뒷받침하는 관찰 가능한 결과 또는 산출물, 그리고 그 증거가 증명하는 중요한 한계.
공리는 판단을 설명하고, 단계는 실행 가능하게 만듭니다. 둘 다에서 동일한 조언을 반복하지 마세요. 각 섹션을 작업이 허용하는 만큼 짧게 유지하세요. 영역 참조 파일은 일반 Markdown입니다: ID, 중복 YAML 필드, 모토-출처 레이블 또는 귀속 잡음이 없습니다. 발견 가능한 SKILL.md만 스킬 프론트매터가 필요합니다.
수정 예시
Faceless Men의 경우 "의존성 제어"는 너무 추상적입니다. 유용한 트리거는 "파일을 삭제하거나 외부 결제 서비스를 호출하는 작업 테스트"입니다. 다음 행동은 해당 경계를 격리하고, 모의/스텁/페이크를 선택한 후, 의도하지 않은 실제 효과 없이 성공, 실패 및 재시도 동작을 실행하는 것입니다. 증거에는 의도된 대상과 결과 상태, 그리고 실제 계약이 중요한 경우 통합 증명이 포함됩니다. 여전히 실제 서비스를 호출하는 스파이는 이름을 붙일 가치가 있는 함정입니다.
동반 realms-of-code 스킬을 사용할 수 있는 경우, references/realms/faceless-men.md가 전체 작업 예시입니다.
Arryn의 경우 "프로토콜 선택"은 메인 트리거 테이블에 속합니다. 해당 가이드는 기존 표준과 기술을 찾고, 현재 유지 관리 및 폐기 상태를 확인하고, 실행 가능성을 평가하고, 지원되는 구현을 재사용하고, 상호 운용성을 테스트하도록 해야 합니다.
구현 중 보호를 가르치세요: 중요한 규칙을 가드레일로 인코딩하고, 검증된 개선 사항을 래칫으로 기록하세요. 래칫은 재현 가능한 기준선을 기록하고, 회귀를 거부하며, 개선 후 조여집니다. Citadel이 보호를 구축하고, Iron Bank가 이를 시행합니다. 실패하는 검사를 조용히 약화시켜 해결하지 마세요.
출판 전 검토
두 가지 현실적인 매칭 작업과 다른 영역에 속하는 하나의 근접 작업을 시도하세요. 메인 테이블에서 영역을 선택한 후, 해당 가이드에서 첫 번째 구체적인 행동과 필요한 증거를 식별하세요. 어느 단계가 여전히 모호하다면, 책임 파일을 수정하세요. 작업과 관련 없는 포괄적인 게이트는 피하세요.
분위기를 모토, 전승 및 가끔씩의 작업 문구(예: "버그에게 뭐라고 하지? 오늘은 안 돼.")로 살려두세요. 유용한 엔지니어링 지침과 함께 사용하세요. 결정이나 성격을 추가하지 않는 단어는 제거하세요. 저장소의 출판 워크플로우를 따르고, 영향을 받는 경우 상대 링크 및 스킬 발견 가능성을 확인하세요.