응답 스타일·규칙 동기화 — 스킬 프로젝트 소개

한국어 답변과 개발 실행은 다른 규칙입니다

응답 스타일·규칙 동기화 스킬에서 제가 먼저 나눈 것은 말하는 방식과 일하는 방식입니다. 한국어로 짧게 답하는 선호는 문체에 가깝습니다. 구현 전에 계획을 만들거나 범위를 넓힐 때 확인하는 규칙은 실행 정책입니다. 유료 모델 호출을 어떤 조건에서 허용하는지도 별도의 판단입니다.

세 가지를 한 프로필에 섞으면 어떤 항목을 바꿨는지 설명하기 어려워집니다. 답변을 간결하게 만들려다 개발 절차까지 줄이거나, 모델 경로를 바꾸면서 문체 규칙까지 다시 작성할 필요는 없습니다. 저는 문체, 에이전트 실행, 모델·프록시 사용 정책을 세 JSON 프로필로 분리했습니다.

이 프로젝트의 대표 산출물은 규칙을 읽을 수 있는 문서와 그 문서를 만드는 프로필입니다. 새로운 에이전트 실행기를 만드는 대신, 서로 다른 개발 도구가 참고할 규칙의 입력을 한곳에서 관리하는 구조로 잡았습니다.

예제 프로필에 실제 판단 조건을 남기기

함께 만든 문체 예제에는 한국어 우선, 답부터 말하기, 짧은 문단, 불필요한 반복 줄이기를 넣었습니다. 단순 질문에는 필요 없는 제목을 늘리지 않고, 프로젝트 변경 보고에서는 바꾼 곳과 실제 검증 결과를 알리도록 했습니다. “전문적으로 답한다”보다 다른 작업자가 적용할 수 있는 행동을 적은 것입니다.

실행 정책 예제에는 개발 계획을 먼저 만드는 흐름과 작업 경계를 넣었습니다. 명확한 읽기 작업은 진행할 수 있고, 불분명한 요구나 범위 확대는 확인하도록 구분했습니다. 병렬 작업을 선호하는 설정에도 쓰기 경계를 먼저 정하고 공유 파일 통합은 조율 담당이 맡는 조건을 연결했습니다.

모델 정책은 또 다른 프로필입니다. 비용이 드는 클라우드 사용을 기본 선택으로 두지 않고, 필요한 이유와 승인 조건을 적었습니다. 프록시를 고를 때는 스트리밍, 도구 호출 이력, 인증, 로그처럼 실제 호환에 영향을 주는 항목을 살피게 했습니다. 프록시 주소가 목록에 있다는 사실만으로 그 경로가 모든 도구에서 동작한다고 보장하지 않습니다.

같은 기준을 두 규칙 문서로 보내기

동기화 스크립트는 세 프로필을 읽고 개발 도구별 규칙 문서에 같은 기준을 렌더링합니다. 기본 대상은 AGENT.md와 CLAUDE.md입니다. 문서별로 같은 규칙을 손으로 복사하는 대신 입력 프로필과 출력 템플릿을 나눠 뒀습니다.

프로필에는 짧은 키 이름을 사용했습니다. 프로필 식별자, 언어 모드, 설명 수준, 계획 규칙, 클라우드 사용 규칙처럼 무엇을 뜻하는지 직접 드러내도록 했습니다. 문서에 드러나는 표현은 템플릿에서 정하고, 적용할 값은 프로필에서 관리합니다.

두 파일의 글자가 모두 같을 필요는 없습니다. 제목과 주변 설명은 달라도 한국어 우선, 실행 경계, 모델 사용 조건이 같은 프로필에서 전달됐는지 확인합니다. 규칙을 바꿀 때 돌아가 볼 입력이 분명해야 합니다.

프로젝트별 예외는 관리 영역 밖에 두었습니다

기존 규칙 문서 전체를 새 출력으로 덮어쓰면 그 프로젝트에서 따로 정한 내용까지 잃을 수 있습니다. 저는 동기화 대상 구간에 시작과 끝 표시를 두고, 그 구간만 바꾸도록 구현했습니다. 프로젝트만의 예외는 바깥에 남길 수 있습니다.

두 표시가 있으면 그 사이를 새 규칙으로 교체하고 앞뒤 내용은 유지합니다. 관리 영역이 없는 문서에는 기존 내용 뒤에 새 구간을 붙이는 방식입니다. 이 경계는 스크립트가 관리하는 내용과 사람이 프로젝트에 맞춰 남긴 내용을 구분하기 위한 선택입니다.

따라서 예외를 적을 때도 위치가 중요합니다. 동기화 구간 안에 직접 고친 문장은 다음 실행에서 바뀔 수 있습니다. 여러 저장소에 공통으로 적용할 규칙은 프로필에, 해당 프로젝트에만 필요한 조건은 관리 구간 밖에 두는 것이 이 구조에 맞습니다. 동기화가 곧 모든 규칙의 일괄 통일이라는 뜻은 아닙니다.

키 이름을 바꿔도 이전 입력은 읽을 수 있게

새 프로필을 만들면서 기존 키를 바로 없애지는 않았습니다. 이전 프로필 이름과 언어 정책, 계획 정책에 해당하는 이름도 읽기 호환으로 남겼습니다. 새 문서와 템플릿은 짧은 키를 기본으로 설명하되, 이미 만들어진 입력을 가져오는 경로를 유지한 것입니다.

문체만 다루던 호출도 별도 래퍼로 이어지도록 했습니다. 세 프로필을 사용하는 새 구조를 추가했다고 기존 문체 동기화 요청까지 모두 다시 구성해야 하지는 않도록 한 선택입니다. 새 기준을 소개하는 것과 기존 사용 경로를 지우는 것은 다른 작업으로 봤습니다.

이 호환을 확인할 때는 새 번들 초기화와 세 프로필 렌더링만 보는 데서 끝내지 않습니다. 이전 호출 경로로도 출력이 이어지는지, 관리 구간 밖에 남긴 내용이 유지되는지, 대상 문서에 필요한 정책이 빠지지 않았는지 각각 살펴야 합니다. 스크립트를 실행했다는 사실만으로 정책이 제대로 전달됐다고 판단하지 않도록 검수 지점을 나눴습니다.

규칙의 우선순위까지 함께 적기

예제 프로필에는 더 높은 우선순위의 지시와 현재 대화의 직접 요청을 존중하는 조건을 넣었습니다. 프로젝트 기본값을 재사용하는 것이 현재 요청을 덮어쓰는 이유가 되지 않도록 했습니다. 문체의 기본 설정과 이번 작업의 요구는 함께 읽어야 합니다.

다른 프로젝트에 이 구조를 가져갈 때는 먼저 기존 규칙을 읽고 안정적인 기본값만 프로필로 옮깁니다. 한 번의 작업에서만 필요한 요청을 모든 프로젝트의 공통 정책으로 만들지 않습니다. 모델 후보나 실행 방식도 환경에 맞게 검토하고 선택 이유를 남깁니다.

공통 규칙을 바꾸려면 해당 프로필을 고치고, 프로젝트만의 예외는 관리 구간 밖에 남깁니다. 문체·실행·모델 정책을 따로 둔 이유도 필요한 규칙만 수정할 수 있게 하기 위해서입니다.