moyu-strict

moyu-strict 기술 개요

moyu-strict란 무엇인가

moyu-strict는 코드 편집용 가드레일 스킬로, 과도한 설계를 강하게 억제하도록 만들어졌습니다. 다듬어진 리디자인이 아니라, 가장 작은 안전한 변경이 필요한 상황을 위한 도구입니다. 핵심 역할은 에이전트가 요청 범위를 벗어나 다른 파일을 건드리거나, 추상화를 덧붙이거나, 관련 없는 코드를 “개선”하지 않도록 막으면서도 요청 자체는 충족하게 하는 데 있습니다.

누가 사용하면 좋은가

이 moyu-strict 스킬은 기존 코드베이스에서 범위가 좁게 정해진 수정 작업을 하는 리뷰어, 유지보수 담당자, 에이전트에게 가장 잘 맞습니다. 최소 diff, 예측 가능한 리뷰, 실수로 인한 부작용 회피가 중요하다면 moyu-strict for Code Editing은 매우 적합합니다. 반대로 탐색적 리팩터링, 아키텍처 작업, 대규모 정리 작업에는 효용이 떨어집니다.

무엇이 다른가

실질적인 차이는 강제력에 있습니다. moyu-strict는 단순한 “더 좋은 코드를 써라” 프롬프트가 아니라, 범위 통제와 편집 절제, 그리고 자제에 초점을 맞춥니다. 가장 강한 신호는 명시적인 규칙들입니다. 편집 전에 범위를 확인하고, 새 추상화 계층을 만들지 말고, 요청받지 않은 문서/테스트/의존성을 추가하지 말며, 변경이 요청보다 너무 커지기 시작하면 멈추라는 식입니다.

moyu-strict 스킬 사용 방법

설치하고 활성화하기

리포지토리의 moyu-strict install 스킬 설치 흐름을 사용한 뒤, 코드 변경이 반드시 좁게 유지되어야 할 때 불러오세요. 환경이 명령 기반 설치기를 쓴다면, 핵심은 모델이 편집을 시작하기 전에 moyu-strict를 붙여 두는 것입니다. 그래야 제약이 리뷰 단계가 아니라 초안 단계부터 반영됩니다. moyu-strict usage 기준으로는, 작업이 설계 세션이 아니라 목표가 좁은 수정일 때마다 활성화하는 것이 좋습니다.

먼저 읽어야 할 파일

가장 먼저 skills/moyu-strict/SKILL.md를 보세요. 여기에는 엄격한 규칙과 활성화 동작이 들어 있습니다. 이 리포지토리는 단일 스킬 파일만 있고, 보조 스크립트나 참조 파일, 규칙 폴더가 없기 때문에 따라가야 할 숨은 워크플로우 트리가 없습니다. 사용자가 알아야 할 핵심은 확장된 리포지토리 투어가 아니라 규칙 텍스트 자체입니다.

거친 작업을 엄격한 프롬프트로 바꾸기

이 스킬은 요청이 정확한 대상과 정확한 경계를 이미 이름으로 제시할 때 가장 잘 작동합니다. 좋은 입력은 이런 식입니다. “src/parser.ts의 null 크래시를 고치되, 그 파일만 수정하고 테스트, 주석, 리팩터링은 추가하지 마세요.” 약한 입력은 이런 식입니다. “이 모듈을 개선해 주세요.” 첫 번째는 moyu-strict가 제약할 대상을 주지만, 두 번째는 범위 이탈을 부릅니다.

편집 확인 워크플로우에서 사용하기

좋은 moyu-strict guide는 이렇습니다. 영향을 받는 파일이나 함수를 특정하고, 의도한 변경을 명시한 뒤, 다른 파일은 건드리지 않아도 되는지 확인하고, 그다음 편집합니다. 작업에 더 넓은 변경이 필요해 보인다면, 멈추고 더 작은 버전이 가능한지 물어보세요. 이것이 이 스킬의 가장 엄격한 가치와 맞닿아 있습니다. diff가 커지기 전에 과잉 진행을 드러내는 것입니다.

moyu-strict 스킬 FAQ

moyu-strict는 그냥 일반 프롬프트인가?

아닙니다. 일반 프롬프트는 간결한 코드를 요청할 수는 있지만, moyu-strict는 편집 경계를 강제하는 데 초점이 있습니다. 주된 위험이 잘못된 로직이 아니라 불필요한 추가 변경일 때 가장 유용합니다.

언제는 쓰지 말아야 하나?

정말로 조정된 전면 개편, 새 추상화, 문서 갱신, 테스트 하네스 생성이 필요한 작업에는 moyu-strict를 쓰지 마세요. 결과물에 더 넓은 정리가 포함되어야 한다면, 이 스킬의 “최소 PR” 성향이 실제 목표와 충돌할 수 있습니다.

초보자도 쓰기 쉬운가?

네, 규칙이 단순하고 구체적이기 때문입니다. 초보자가 자주 하는 실수는 모호한 요청을 던져 놓고 스킬이 경계를 알아서 추론하리라 기대하는 것입니다. moyu-strict는 무엇을 바꿔야 하는지뿐 아니라, 무엇을 바꾸면 안 되는지도 사용자가 분명히 말할수록 더 잘 작동합니다.

일반적인 코드 편집 프롬프트와는 어떻게 다른가?

일반적인 프롬프트는 대체로 완료를 최적화합니다. moyu-strict는 절제를 최적화합니다. 에이전트에게 범위 확장을 의심하고, 장식적인 변경을 피하며, 빠르게 검토할 수 있을 만큼 작은 diff를 유지하라고 지시합니다. 그래서 기능 확장보다 유지보수 작업에 더 잘 맞습니다.

moyu-strict 스킬 개선 방법

정확한 편집 경계를 지정하기

가장 큰 품질 향상은 파일, 함수, 의도한 결과를 처음부터 명시하는 데서 나옵니다. “정리해 주세요” 대신 “src/auth.ts만 수정해서 빈 토큰을 처리하고, 나머지는 그대로 두세요”처럼 말하세요. 이렇게 해야 moyu-strict가 가능한 한 가장 좁은 응답을 강제하기 쉬워집니다.

금지할 항목을 분명히 하기

moyu-strict는 배제 규칙을 중심으로 만들어졌기 때문에, 무엇을 추가하지 말아야 하는지도 함께 적어야 합니다. 새 helper 금지, 주석 금지, 테스트 금지, 의존성 변경 금지, 포맷만 바꾸는 수정 금지처럼요. 이 스킬의 가치는 불필요한 추가를 거절하는 데 있지, 더 큰 해법을 상상해 내는 데 있지 않습니다.

흔한 실패 패턴을 주의하기

가장 흔한 실패는 작게 시작한 요청이 조용히 설계 변경으로 번지는 경우입니다. 그럴 때 필요한 개선은 “더 나은 코드 품질”이 아니라, 작업 자체를 줄이는 것입니다. 허용 가능한 최소 패치를 요청한 뒤, 필요하면 그다음에 반복하세요. 그래야 moyu-strict 스킬이 엄격한 diff 한계와 최소 변경 철학에 맞게 유지됩니다.

아주 작은 첫 패치부터 반복하기

첫 결과가 너무 넓다면, 하나의 증상, 하나의 파일, 하나의 결과에 맞춰 프롬프트를 더 좁히세요. 첫 결과가 너무 얕다면, 가장 중요한 빠진 제약만 추가하세요. 예를 들어 “시그니처를 바꾸지 마세요” 또는 “call site를 수정하지 마세요”처럼요. moyu-strict skill 사용자는 대체로 더 긴 지시문보다 더 선명한 경계에서 더 좋은 결과를 얻습니다.