moyu-ko

moyu-ko skill 개요

moyu-ko는 무엇을 위한 도구인가

moyu-ko는 과도한 설계를 시작하기 전에 멈추게 해주는 코드 편집 skill입니다. AI가 가장 작고 올바른 변경만 하도록 돕고, 사용자가 요청한 범위 안에 머물며, 별도 요청이 없는 한 추가 추상화, 테스트, 문서, 의존성을 덧붙이지 않도록 합니다.

누가 설치하면 좋은가

AI에게 기존 코드를 패치하게 하거나, 좁은 범위의 버그를 고치게 하거나, 리라이트 없이 최소 변경만 원한다면 moyu-ko skill을 설치하세요. 정밀한 diff, 빠른 리뷰, 낮은 구현 변경량을 중시하는 팀에 특히 잘 맞습니다.

무엇이 다른가

“간결하게”라고만 말하는 일반적인 프롬프트와 달리, moyu-ko는 명시적인 가드레일을 담고 있습니다. 요청된 파일만 수정하고, 가장 단순한 구현을 우선하며, 요청이 불분명하면 멈춰서 확인합니다. 그래서 범위 통제가 광범위한 리팩터링보다 더 중요한 moyu-ko for Code Editing에 특히 유용합니다.

moyu-ko skill 사용법

설치하고 활성화하기

디렉터리의 표준 설치 흐름에 따라 moyu-ko install 단계를 진행한 뒤, 명확하게 코드 편집 요청인 작업에 이 skill을 호출하세요. 좋은 트리거 예시는 다음과 같습니다. “src/auth.ts의 이 버그를 고치는 데 필요한 최소 변경만 하도록 moyu-ko를 사용해줘.”

범위가 제한된 작업을 주기

moyu-ko usage 패턴은 아래를 구체적으로 지정할 때 가장 잘 동작합니다.

• 수정할 정확한 파일 또는 경로
• 원하는 동작 변화
• 바뀌면 안 되는 것
• “새 의존성 추가 금지”, “테스트 추가 금지” 같은 알려진 제약

더 좋은 입력:

src/cart.ts를 업데이트해서 할인은 로그인한 사용자에게만 적용되게 해줘. 다른 가격 계산 로직은 바꾸지 말고 새 파일도 만들지 마.

덜 좋은 입력:

결제 흐름을 개선해줘.

먼저 관련 파일부터 읽기

가장 빠른 moyu-ko guide 작업 흐름은 SKILL.md부터 읽고, 이어서 저장소에서 변경 범위를 정의하는 파일들을 살펴보는 것입니다. 이 skill 저장소는 의도적으로 작기 때문에, 핵심은 추가 지원 폴더를 뒤지는 것이 아니라 동작 규칙을 이해하는 데 있습니다.

최소 diff를 요청하기

skill이 제대로 작동하게 하려면, 가장 작은 수정만 하라고 명시적으로 요청하고 필요한 하드 리밋도 함께 적으세요. 예를 들면:

api.ts를 패치해줘. 검증 분기만 바꾸고, 새 helper는 만들지 말고, 다른 파일을 건드리기 전에 먼저 물어봐.

moyu-ko skill FAQ

moyu-ko는 코드 편집에만 쓰는 도구인가?

네, 그것이 의도된 용도입니다. moyu-ko skill은 폭넓은 기획, 아키텍처 작업, 새 프로젝트용 스캐폴딩이 아니라 절제된 편집을 위한 도구입니다. 재설계가 필요하다면 일반 프롬프트가 더 잘 맞을 수 있습니다.

언제 moyu-ko를 쓰지 말아야 하나?

AI가 여러 접근법을 탐색하거나, 보조 테스트를 추가하거나, 작업의 일부로 인접 코드를 함께 정리하길 원할 때는 moyu-ko를 쓰지 마세요. 이 skill의 가치는 범위 통제에 있으므로, 열린 형태의 리팩터링에는 오히려 맞지 않을 수 있습니다.

초보자도 쓰기 쉬운가?

변경 내용을 분명하게 설명할 수 있다면 그렇습니다. 이 skill의 규칙은 단순하지만, 요청 자체에 경계가 잡혀 있을 때 가장 잘 동작합니다. 초보자라면 파일명, 동작, 그리고 “건드리지 말 것” 목록을 함께 적는 것이 가장 좋은 결과로 이어집니다.

일반 프롬프트와 무엇이 다른가?

일반 프롬프트도 최소 변경을 요청할 수 있지만, moyu-ko는 그것을 기본 동작 방식으로 만듭니다. 덕분에 집중된 편집만 원했는데도 실수로 다시 작성하거나, 추상화가 늘어나거나, 파일이 추가되는 위험이 줄어듭니다.

moyu-ko skill 개선 방법

범위 지시를 더 좁히기

품질을 가장 크게 끌어올리는 방법은 수정 범위를 좁히는 것입니다. 정확한 파일, 바꿔야 할 가장 작은 구간, 기대하는 결과를 분명히 적으세요. 요청이 구체적일수록 moyu-ko가 확인을 위해 멈추거나 과하게 수정할 가능성이 낮아집니다.

명시적인 경계 추가하기

건드리면 안 되는 것이 있다면 분명히 말하세요. 유용한 경계 예시는 다음과 같습니다.

• “새 helper function 추가 금지”
• “새 의존성 추가 금지”
• “public API는 바꾸지 말 것”
• “가능하면 diff를 10줄 이내로 유지할 것”

이런 제약은 moyu-ko for Code Editing이 리뷰하기 쉬운 결과를 내는 데 도움이 됩니다.

작업이 모호하면 질문이 나올 것을 예상하기

흔한 실패 패턴은 대상 범위를 충분히 설명하지 않은 채 나머지는 모델이 알아서 추론하길 기대하는 것입니다. 요청이 다른 파일에 영향을 줄 수 있거나 새 추상화가 필요한 경우, moyu-ko는 멈추고 확인해야 합니다. 그것은 버그가 아니라 의도된 동작입니다.

전체 계획이 아니라 첫 패치를 기준으로 반복하기

첫 결과가 너무 넓다면, 작업 전체를 키우기보다 다음 지시를 더 좁히세요. 예를 들어 “모듈을 정리해줘” 대신 “입력을 파싱하는 그 줄만 바꿔줘”라고 요청하는 식입니다. 이렇게 해야 moyu-ko usage가 최소 변경 설계와 계속 맞물립니다.