analyse

analyse 기술 개요

analyse가 하는 일

analyse 기술은 Kaizen 스타일 분석을 위한 자동 선택기입니다. 대상에 따라 어떤 관점이 가장 맞는지 골라주며, 코드의 실제 상태를 볼 때는 Gemba Walk, 워크플로를 볼 때는 Value Stream Mapping, 낭비와 비효율을 볼 때는 Muda를 선택하도록 돕습니다. 어떤 방법을 먼저 써야 할지 감으로 정하지 않고도 시스템을 더 빠르게 점검하고 싶어서 analyse 기술을 찾는다면, 이 기술이 잘 맞습니다.

이 기술에 가장 잘 맞는 경우

코드베이스의 특정 영역, 프로세스, 또는 비효율에 대한 설명이 있고, 막연한 “이거 좀 봐줘”가 아니라 구조화된 조사를 원할 때 analyse를 사용하세요. 특히 Skill Authoring, repo 감사, 아키텍처 리뷰, 워크플로 병목 분석에 유용합니다.

설치할 가치가 있는 이유

analyse의 핵심 가치는 방법 선택에 있습니다. 모든 문제에 하나의 분석 방식을 억지로 들이대는 대신, 대상에 더 적합한 기법으로 매핑해 주기 때문에 시행착오를 줄이고 첫 번째 시도의 품질을 높여 줍니다.

analyse 기술 사용법

설치와 진입점

npx skills add NeoLabHQ/context-engineering-kit --skill analyse로 기술을 설치하세요. 기본 진입점은 /analyse [target_description]이며, 대상은 기능, 워크플로, 서브시스템, 또는 문제 영역이 될 수 있습니다.

analyse 입력을 어떻게 구성할지

기술이 다룰 구체적인 대상과 함께, 어떤 점이 걱정되는지까지 알려주세요. 더 좋은 예: /analyse deployment workflow for slow approvals and failed rollbacks. 덜 좋은 예: /analyse my project. 이 기술은 코드 탐색이 필요한지, 프로세스 매핑이 필요한지, 낭비 분석이 필요한지를 추론할 수 있을 때 가장 잘 작동합니다.

먼저 읽어야 할 파일

먼저 SKILL.md를 읽고, 이 생태계에서 동작을 좌우할 수 있는 repo 수준의 안내가 있으면 함께 확인하세요. 특히 README.md, AGENTS.md, 그리고 존재한다면 metadata.json을 보세요. 이 repo에서는 실무상 핵심 정보가 SKILL.md에 있으며, 워크플로를 더 깊게 파고들 수 있는 helper scripts나 support folders는 없습니다.

실무 팁

이미 어떤 방법을 써야 할지 알고 있다면 METHOD 값을 gemba, vsm, muda처럼 지정해 자동 선택을 덮어쓸 수 있습니다. 대상은 애매하지만 목적은 분명할 때 특히 유용합니다. 가장 좋은 결과를 내려면 대상, 원하는 결과, 그리고 가장 중요하게 보는 제약을 함께 적으세요.

analyse 기술 FAQ

analyse는 코드에만 쓰는 건가요?

아니요. analyse는 코드 구현, 워크플로, 낭비 분석을 모두 다룹니다. 기준은 입력이 repo인지 프로세스인지가 아니라, 대상이 무엇인지와 무엇을 알고 싶은지입니다.

언제 analyse를 쓰지 말아야 하나요?

이미 방법 선택이 필요 없는 좁고 분명한 작업이 있거나, 프롬프트가 너무 모호해서 기술이 코드의 실제 상태와 프로세스 문제를 구분할 수 없을 때는 사용하지 마세요. 그런 경우에는 먼저 맥락을 보강하거나 더 구체적인 기술을 고르는 편이 낫습니다.

analyse는 일반 프롬프트와 어떻게 다른가요?

일반 프롬프트는 보통 하나의 분석 방식을 전제로 합니다. 반면 analyse 기술은 먼저 가장 적절한 Kaizen 방법을 고르기 때문에, 구조화된 시작점이 필요하거나 엉뚱한 가정으로 막히고 싶지 않을 때 유용합니다.

analyse는 초보자에게도 적합한가요?

네, 사용자가 대상을 평이한 말로 설명할 수 있다면 적합합니다. 초보자는 워크플로의 어느 지점이 느린지, 또는 코드 동작이 문서와 어디서 어긋나는지처럼 구체적인 영역과 질문을 함께 줄 때 가장 큰 가치를 얻습니다.

analyse 기술을 더 좋게 만드는 방법

더 강한 대상을 제시하세요

품질을 가장 크게 높이는 방법은 분석 대상이 정확히 무엇인지, 그리고 어떤 실패 모드를 신경 쓰는지 이름 붙여 주는 것입니다. 예를 들어 “analyze the auth flow for mismatch between docs and implementation”은 “analyze auth”보다 훨씬 좋은 안내를 만들어 냅니다.

원하는 결과를 분명히 하세요

analyse에게 코드 워크스루가 필요한지, 프로세스 맵이 필요한지, 아니면 낭비 식별이 필요한지 알려주세요. 이 기술은 자동으로 방법을 고르지만, 결과를 명확히 적어 주면 더 적은 모호함으로 방법을 선택하고 설명할 수 있습니다.

제약과 예시를 함께 넣으세요

느린 단계, 헷갈리는 함수, 반복되는 인계, 이미 알고 있는 비효율처럼 실제 신호를 한두 개 포함하세요. 이런 세부 정보는 analyse 기술이 넓게 훑기보다 증거에 집중하도록 도와줍니다.

첫 시도 이후에는 다시 좁히세요

첫 분석이 너무 넓다면 대상을 더 좁히고, 더 구체적인 방법 힌트와 함께 다시 실행하세요. analyse 기술에서는 한 번에 크게 던지는 요청보다, 방법 선택은 유지하되 범위를 조이는 반복 프롬프트가 보통 더 좋은 결과를 냅니다.