promote

promote skill 개요

promote가 하는 일

promote skill은 Claude가 auto-memory에서 반복적으로 학습하고 검증한 행동을 명시적인 프로젝트 규칙으로 바꿔 줍니다. 유용한 패턴을 MEMORY.md 안에 묻어 두는 대신, promote는 그 내용을 CLAUDE.md, .claude/rules/<topic>.md, 또는 전역 Claude instruction 파일로 옮겨 이후 세션에서도 일관되게 적용되도록 돕습니다.

스스로 개선되는 Claude 워크플로에 잘 맞는 경우

팀에서 이미 Claude가 수정 사항, 선호도, 반복되는 프로젝트 관례를 학습하도록 두고 있고, 이제 그중 하나를 오래 유지되는 규칙으로 만들 필요가 있을 때 promote를 사용하세요. 특히 MEMORY.md가 관찰 내용을 담고, rule 파일이 에이전트가 반드시 따라야 할 내용을 정의하는 Context Engineering 구성에서 유용합니다.

좋은 예로는 “이 repo에서는 항상 pnpm을 사용한다”, “API handlers는 입력값을 검증해야 한다”, “billing code 테스트에는 이 fixtures가 필요하다” 같은 규칙이 있습니다. 반대로 일회성 선호, 아직 결론 나지 않은 논의, 실제로 효과가 검증되지 않은 규칙은 적합하지 않습니다.

이 promote skill이 유용한 이유

이 skill은 단순한 복사-붙여넣기 알림이 아닙니다. 패턴을 명확히 하고, 근거가 되는 memory 항목을 찾고, 알맞은 대상 파일을 고르고, 실행 가능한 규칙으로 작성한 뒤, 원래 memory에는 promotion note를 남기는 의사결정 흐름을 제공합니다. 중요한 이유는 markdown을 편집하는 것 자체가 어려운 일이 아니기 때문입니다. 진짜 어려운 부분은 어떤 memory가 영구적인 규칙이 될 만한지, 그리고 그 규칙이 어디에 있어야 하는지를 판단하는 일입니다.

promote skill 사용 방법

promote 설치와 repository 확인 경로

GitHub skill collection에서 다음 명령으로 skill을 설치합니다.

npx skills add alirezarezvani/claude-skills --skill promote

그다음 SKILL.md를 먼저 읽으세요. 현재 이 repository path에서는 promote 워크플로가 단일 파일로 제공되므로, 별도로 살펴볼 helper scripts, references, rule templates는 없습니다. 도입은 간단하지만, 중요한 repo에 적용하기 전에는 command examples와 target-selection table을 꼼꼼히 확인해야 합니다.

실제로 promote를 호출하는 방법

의도된 trigger는 /si:promote이며, 뒤에 영구 규칙으로 만들고 싶은 패턴을 붙입니다.

• /si:promote use pnpm instead of npm
• /si:promote API handlers need validation --target rules/api.md
• /si:promote tests for auth changes must include session expiry cases --target rules/testing.md --paths "src/auth/**/*.ts"

skill은 먼저 사용자가 말하는 행동이 무엇인지 확인합니다. 요청이 모호하면, 예를 들어 이 규칙이 전역으로 적용되는지 특정 경로에만 적용되는지처럼 하나의 확인 질문을 해야 합니다. 그런 다음 ~/.claude/projects/.../memory/MEMORY.md 아래에 있는 프로젝트의 Claude auto-memory 파일에서 관련 항목을 검색하고, 매칭된 내용을 보여 준 뒤, 해당 memory가 promotion을 뒷받침하는지 확인합니다.

거친 목표를 좋은 prompt로 바꾸기

약한 prompt는 “promote our testing preference”처럼 말합니다. 더 좋은 promote 사용 prompt는 행동, 근거, 범위, 알고 있다면 대상까지 함께 제공합니다.

/si:promote "When changing billing code, add regression tests for failed payment and retry paths" --target rules/testing.md --paths "src/billing/**/*.ts"

이렇게 쓰면 skill이 막연한 선호가 아니라 실행 가능한 규칙을 작성할 수 있어 더 잘 작동합니다. 다음을 포함하세요.

• Claude가 따라야 할 정확한 행동
• 전체 프로젝트에 적용되는지, 특정 파일 유형에 적용되는지, 모든 프로젝트에 적용되는지
• 규칙이 범위 제한을 갖는 경우 예시 경로
• 그 패턴이 유용하다는 점을 입증한 memory 문구나 incident

규칙을 merge하기 전에 권장되는 워크플로

promote가 규칙을 초안 작성하거나 수정한 뒤에는 production configuration을 검토하듯 확인하세요. 지시문이 짧고, 검증 가능하며, 근거가 뒷받침하는 범위를 넘지 않는지 살펴봐야 합니다. 프로젝트 전체에 적용되는 행동이라면 보통 CLAUDE.md가 적절합니다. 좁은 범위의 행동이라면 path scope가 있는 .claude/rules/<topic>.md를 우선 고려하세요. 여러 repository에 걸친 개인 관례라면 그 패턴이 정말 보편적인 경우에만 전역 Claude instruction 파일을 사용하세요.

promote skill FAQ

promote는 Context Engineering용인가요, 일반 prompting용인가요?

promote는 관찰된 행동을 지속적인 instruction으로 정식화하는 경로를 만들어 주기 때문에 Context Engineering에서 가장 가치가 큽니다. 일반 prompt로도 Claude에게 한 세션 동안 무언가를 기억해 달라고 할 수는 있습니다. promote는 그 학습이 repo의 운영 context 일부가 되어야 하는지 판단하도록 돕습니다.

promote를 쓰지 말아야 할 때는 언제인가요?

검증되지 않은 아이디어, 임시 workaround, 팀 규범과 충돌하는 개인 취향, 또는 application code, tests, linters, CI에 들어가야 할 instruction에는 promote를 사용하지 마세요. 규칙은 agent 행동을 안내할 때 유용합니다. 반대로 실행 가능한 enforcement를 대체하는 수단이 되면 위험합니다.

CLAUDE.md를 직접 편집하는 것과 무엇이 다른가요?

직접 편집해도 동작할 수는 있지만, 근거와 범위를 건너뛰는 경우가 많습니다. promote skill은 memory를 찾고, 의도한 행동을 확인하고, 올바른 목적지를 선택하고, 해당 memory가 promotion되었다는 흔적을 남기는 반복 가능한 프로세스를 더합니다. 이를 통해 rule sprawl을 줄이고, 이후 유지보수자가 왜 이 instruction이 존재하는지 이해하기 쉬워집니다.

promote는 초보자에게도 쉬운가요?

네, 사용자가 자신의 Claude project memory와 rule files가 어디에 있는지 이미 이해하고 있다면 쉽습니다. 초보자는 명확한 프로젝트 전체 패턴 하나로 시작하고, --target claude.md를 사용하며, .claude/rules/ 관례에 익숙해질 때까지는 scoped path rules를 피하는 것이 좋습니다.

promote skill 개선 방법

더 좋은 근거로 promote 결과 개선하기

promote skill은 source memory가 구체적일 때 가장 잘 작동합니다. 실행하기 전에 해당 규칙이 필요하다는 점을 입증하는 정확한 memory entry, correction, 또는 반복된 failure를 모아 두세요. “Claude keeps using npm”은 “In three sessions Claude ran npm commands, but this repo uses pnpm and has no package-lock.json.”보다 약한 근거입니다.

흔한 promotion 실패 피하기

가장 흔한 실패는 over-promoting입니다. 좁은 관찰을 전역 명령으로 바꿔 버리는 경우입니다. 또 다른 실패는 “write better tests”처럼 좋아 보이지만 실행 가능하지 않은 규칙을 작성하는 것입니다. 더 나은 규칙은 trigger, required action, scope를 명확히 말합니다. 예: “For src/api/**/*.ts, validate request bodies before calling service functions.”

첫 번째 생성 규칙 이후 반복 개선하기

첫 promote output이 나온 뒤에는 규칙이 너무 넓은지, 너무 모호한지, 다른 곳에 중복되어 있는지 물어보세요. 그런 다음 다듬으면 됩니다. 유용한 follow-up prompts는 다음과 같습니다.

• “Make this rule enforceable in one paragraph.”
• “Narrow this to only API route files.”
• “Add one example and one non-example.”
• “Check whether this belongs in CLAUDE.md or .claude/rules/testing.md.”

규칙 시스템을 건강하게 유지하기

좋은 promote guide는 rule layer가 시끄러워지는 것을 막아야 합니다. promotion된 rules를 주기적으로 검토해 충돌, 오래된 관례, tooling으로 옮겨야 할 instruction이 있는지 확인하세요. 가장 좋은 promote 결과는 markdown이 늘어나는 것이 아닙니다. Claude가 올바른 durable context를 알맞은 scope에서 받게 되어 반복적인 수정이 줄어드는 것입니다.