---
name: automate-me
description: "\"automate me\", \"create/update/refresh my -mode skill\", \"내 선호도나 작업 스타일을 스킬로 전환/캡처\"에 사용하거나, 에이전트가 사용자의 작업 방식을 따르도록 하고 싶을 때 사용하세요. create-skill + unslop을 통해 개인 -mode 스킬을 작성하거나 수정하며, 선택적으로 최근 트랜스크립트에서 새로운 증거를 가져옵니다."
disable-model-invocation: true
---

# Automate me

사용자의 작업 관습을 에이전트가 따를 스킬로 전환하기 위한 가이드 플로우. 출력은 사용자에게 맞춤화된 하나의 `-mode` 스킬입니다 (예: `jay-mode`, `priya-mode`).

이 스킬은 세 가지 다른 스킬을 조율합니다: 인라인 마이닝 패스 (1단계 참조), Cursor의 내장 `create-skill` (작성), 그리고 **unslop** 스킬 (산문 규율). 이것들을 시퀀싱합니다. 대체하지 않습니다.

## 플로우

### 0. 기존 스킬 확인

사용자의 핸들과 일치하는 `.cursor/skills/**/*-mode/SKILL.md` 및 `~/.cursor/skills/*-mode/SKILL.md`를 재귀적으로 찾으세요. 모드 스킬은 최상위 수준뿐만 아니라 개인 카테고리 디렉토리 (`.cursor/skills/<handle>/`)에 있을 수 있습니다. 하나가 존재하면 `AskQuestion`으로 의도를 확인하세요 (이미 "내 스킬 업데이트" 또는 유사한 말을 하지 않은 경우):

- 기존 스킬 업데이트 (반복 실행의 기본값)
- 새로 시작 (드물며, 수행하기 전에 이유를 물어보세요)

업데이트 모드는 나머지 플로우를 변경합니다:
- 1단계는 스킬이 마지막으로 편집된 이후의 기록만 마이닝합니다 (`git log -1 --format=%cI <path>`).
- 2단계는 무엇이 변경되었거나 누락되었는지 물어보지, 제로에서 무엇을 캡처할지 물어보지 않습니다.
- 4단계는 기존 파일을 제자리에서 편집합니다. 사용자가 반박하지 않은 섹션을 보존하세요. 새로운 증거가 있는 섹션을 수정하세요. 진정으로 새로운 규칙에 대해서만 새 섹션을 추가하세요.

### 1. 기록 마이닝

팬 아웃하기 전에 활성 워크스페이스의 트랜스크립트를 찾으세요. 시스템 프롬프트는 워크스페이스의 `agent-transcripts/` 디렉토리를 명명합니다. 해당 경로만 사용하세요. `~/.cursor/projects/*/` 전체에 glob하지 마세요. 그것은 워크스페이스 경계를 넘고 관련 없는 프로젝트에서 비공개 채팅을 읽습니다.

해당 범위 내에서 반복되는 패턴에 대한 최근 에이전트 대화를 조사하세요. 기록 슬라이스 전체에 여러 병렬 서브에이전트를 실행하세요 (예: 지난 2-4주, 3개 슬라이스로 분할하여 각각 충분한 자료를 갖도록). **poteto-mode** 스킬의 Subagents 섹션에 따라 작업에 대한 각 서브에이전트의 추론 수준과 빠른 또는 표준 속도를 선택하세요. 각 슬라이스 마이닝 서브에이전트는 부모가 제공한 워크스페이스 범위 경로에서 트랜스크립트를 읽고, 아래 신호를 찾고, 증거 포인터와 함께 본 패턴의 짧은 구조화된 목록을 반환합니다. 찾을 가치가 있는 기본 신호:

- 응답 선호도 (길이, 톤, 형식, "더 쉽게 설명해" 수정)
- 위임 습관 (서브에이전트, 모델, 특수화된 워크플로우, 병렬성)
- 검증 자세 ("완료"의 의미, 단위 테스트 대 라이브 재현, 리뷰어)
- 코드 및 산문 규율 (스타일, 인용된 원칙, 린트/포맷 도구)
- 프로세스 관습 (워크트리, 커밋, PR, 리뷰/병합 도구)
- 메타 선호도 (작업 중 스킬 수정, 새로운 스킬 제안)

슬라이스 간에 교차 확인한 후 신호를 상승시키세요. 2개 이상의 슬라이스에서 본 패턴은 높은 신뢰도입니다. 외로운 신호는 약하며 일반적으로 삭제됩니다.

### 2. 사용자에게 직접 물어보기

마이닝은 아직 나타나지 않은 의도를 놓칩니다. 사용자가 처음부터 타이핑하도록 요청하기보다는 `AskQuestion` 도구 (구조화된 다중 선택)를 사용하세요.

형태: 각각 4-6개 옵션이 있는 한두 개의 질문, 카테고리 질문에 대해 `allow_multiple: true`. 넓게 시작하세요 ("어떤 영역이 가장 중요합니까?"), 그런 다음 선택한 영역에 대해 구체적인 옵션으로 후속 조치하세요. 구조화된 라운드 후, 하나의 자유 형식 채팅 질문이 옵션이 놓친 것을 포착합니다.

20개의 질문을 던지지 마세요.

### 3. 발견 사항 클러스터링

결합된 신호를 섹션으로 그룹화하세요. 일반적인 것들 (적용되는 것만 사용):

- **Response style** (응답 스타일): 길이, 톤, 형식.
- **Autonomy** (자율성): 물어보지 않고 얼마나 많이 할지, MCP 도구 사용.
- **Understand first** (먼저 이해하기): 변경 범위 지정 또는 조사 시 도달할 스킬.
- **Subagents** (서브에이전트): 기본값, 병렬성, 작업에 대한 모델, 특수화된 워크플로우.
- **Prose / code discipline** (산문 / 코드 규율): 원칙, 린트 도구, 스타일 가이드.
- **Review and verify** (리뷰 및 검증): 재현 자세, 검증 스킬, 라이브 테스팅 도구.
- **Process** (프로세스): git 워크트리, 커밋, PR, 리뷰/병합 도구.
- **Skills** (스킬): 스킬 작성 습관, fix-the-skill-first, 새로운 스킬 제안.

**poteto-mode** 스킬은 형태를 보여줍니다. 세분성을 위해 읽으세요. 내용을 복사하지 마세요. 사용자의 규칙은 poteto-mode의 규칙과 다릅니다.

### 4. 스킬 초안 작성

Cursor의 내장 `create-skill` 스킬을 사용하여 스킬을 작성하세요. 배치:

- Path (경로): 기존 모드 스킬의 카테고리를 보존하세요. 새 모드의 경우, 저장소에 해당 핸들에 대한 확립된 개인 카테고리가 있으면 `.cursor/skills/<handle>/<handle>-mode/SKILL.md`를 사용하세요. 그렇지 않으면 프로젝트의 `.cursor/skills/<handle>-mode/SKILL.md`로 기본 설정하거나 (사용자가 개인 스킬을 선호하면 `~/.cursor/skills/<handle>-mode/`).
- Handle (핸들): 사용자의 이름 또는 선택한 식별자.
- Frontmatter `description`: "write code"나 "review PR"와 같은 일반 키워드가 아니라 그들의 이름 + `/<handle>-mode` + "work in their style"로 트리거합니다.
- Frontmatter formatting (프론트매터 포맷팅): `create-skill`의 YAML 규칙을 따르세요. `description`을 하나의 YAML 스칼라로 유지하세요. 구두점이나 줄 바꿈이 필요할 때 인용하거나 들여쓰기 연속 줄과 함께 `description: >-`를 사용하세요.
- Frontmatter `disable-model-invocation: true`를 기본값으로 설정하세요. 사용자가 모든 턴에 자신의 모드를 적용하기를 명시적으로 원하는 경우에만 옵트아웃하세요.

### 5. 산문 반복

모든 줄에 **unslop** 스킬과 `create-skill`의 쓰기 가이드라인을 적용하세요.

사용자에게 초안을 보여주고 피드백을 받으세요. 여러 번의 반복을 예상하세요. 무자비하게 자르세요. 모드 스킬은 매뉴얼이 아닙니다.

### 6. 착륙

메인에서 워크트리에서 작업하세요. 커밋하고 PR을 여세요. 메인에 직접 푸시하지 마세요.

## 가드레일

- **하나의 대화에 과적합하지 마세요.** 한 번 언급되고 다른 시간에 반박된 선호도는 노이즈입니다. 성문화하기 전에 여러 인스턴스를 요구하세요.
- **영리하지 마세요.** 다른 스킬의 내용을 재진술하거나, 은유를 발명하거나, 에이전트 독자를 위해 "시적인" 산문을 작성하는 것은 혜택 없는 비용입니다. 운영적으로 유지하세요.
- **참조하되 인라인하지 마세요.** 사용자가 의존하는 다른 스킬은 붙여넣은 발췌가 아니라 경로 참조로 나타나야 합니다. 다른 곳에서 유지 관리하는 모든 원칙 문서도 마찬가지입니다.
- **섹션을 최소화하세요.** 사용자가 특정 비기본 규칙을 가지고 있을 때만 섹션을 추가하세요. "명확하게 의사소통하라"는 섹션이 아닙니다. "짧은 단락. 옵션을 비교할 때 표.  항목이 진정으로 병렬일 때만 글머리 기호."는 섹션입니다.
- **관습을 일반적으로 명명하세요.** 저자의 이름이 아니라 명령문에 "the user" 또는 "the human"을 사용하세요.
- **대칭을 강요하지 마세요.** 사용자에게 기록할 가치가 있는 프로세스 규칙이 없으면 Process 섹션을 완전히 건너뛰세요.

## 평가

`-mode` 스킬은 주관적 출력입니다. `create-skill` 스타일의 테스트/반복 벤치마크 루프는 여기서 유용하지 않습니다. 사용자와 바이브 체크하세요: 그들처럼 읽히나요? 뭔가 놓친 것이 있나요? 그런 다음 배송하세요.

스킬의 트리거 정확도가 실제로 문제가 되는 경우에만 설명 최적화 루프를 실행하세요.

## 언제 사용하지 않을까

- 사용자가 작업별 스킬을 원함 (작업 관습이 아님): `create-skill` 단독, 마이닝 불필요.
- 사용자가 하나의 좁은 워크플로우를 캡처하기를 원함 (예: "내가 커밋 메시지를 작성하는 방법"). 그것은 모드 스킬이 아니라 일반 스킬입니다.