Plan Mode
사용자가 실행이 아닌 계획을 원할 때 이 스킬을 사용합니다.
핵심 동작
이번 턴에서는 계획만 수립합니다.
- 코드를 구현하지 마십시오.
- 계획 마크다운 파일 외에는 프로젝트 파일을 수정하지 마십시오.
- 변경을 일으키는 터미널 명령어, 커밋, 푸시 또는 외부 작업을 수행하지 마십시오.
- 필요시 읽기 전용 명령어/도구를 사용하여 저장소나 다른 컨텍스트를 검사할 수 있습니다.
- 작업 결과물은 활성 워크스페이스 내
.hermes/plans/에 저장된 마크다운 계획입니다.
출력 요구사항
구체적이고 실행 가능한 마크다운 계획을 작성합니다.
해당되는 경우 다음을 포함합니다:
- 목표
- 현재 컨텍스트 / 가정
- 제안된 접근 방식
- 단계별 계획
- 변경될 가능성이 있는 파일
- 테스트 / 검증
- 위험, 트레이드오프 및 미해결 질문
작업이 코드 관련인 경우, 정확한 파일 경로, 예상 테스트 대상 및 검증 단계를 포함합니다.
저장 위치
write_file을 사용하여 다음 위치에 계획을 저장합니다:
.hermes/plans/YYYY-MM-DD_HHMMSS-<slug>.md
이는 활성 작업 디렉터리 / 백엔드 워크스페이스를 기준으로 처리합니다. Hermes 파일 도구는 백엔드를 인식하므로 이 상대 경로를 사용하면 로컬, Docker, SSH, Modal 및 Daytona 백엔드에서 계획이 워크스페이스에 유지됩니다.
런타임이 특정 대상 경로를 제공하는 경우 해당 경로를 정확히 사용합니다.
제공되지 않으면 .hermes/plans/ 아래에 적절한 타임스탬프 파일명을 직접 생성합니다.
상호작용 스타일
- 요청이 충분히 명확하면 계획을 바로 작성합니다.
/plan에 명시적인 지침이 없으면 현재 대화 컨텍스트에서 작업을 유추합니다.- 진정으로 불명확한 경우, 추측 대신 간단한 명확화 질문을 합니다.
- 계획을 저장한 후, 무엇을 계획했는지와 저장 경로를 간략히 답변합니다.
계획을 잘 작성하는 방법
이 스킬의 나머지 부분은 좋은 구현 계획을 작성하는 기술에 관한 것입니다. 위 마크다운 파일에 들어갈 내용입니다.
개요
구현자가 코드베이스에 대한 컨텍스트가 전혀 없고 안목이 의심스럽다고 가정하고 포괄적인 구현 계획을 작성합니다. 필요한 모든 것을 문서화합니다: 어떤 파일을 다룰지, 전체 코드, 테스트 명령어, 확인할 문서, 검증 방법. 작은 작업 단위로 제공하세요. DRY. YAGNI. TDD. 빈번한 커밋.
구현자가 숙련된 개발자이지만 도구 세트나 문제 도메인에 대해 거의 알지 못한다고 가정합니다. 좋은 테스트 설계를 잘 모른다고 가정합니다.
핵심 원칙: 좋은 계획은 구현을 명백하게 만듭니다. 누군가가 추측해야 한다면 계획은 불완전한 것입니다.
전체 구현 계획이 도움이 되는 경우
다음 작업 전에는 항상 사용합니다:
- 다단계 기능 구현
- 복잡한 요구사항 분석
- 하위 에이전트 개발을 통한 하위 에이전트 위임
다음 경우 건너뛰지 마십시오:
- 기능이 간단해 보일 때 (가정이 버그를 만듭니다)
- 직접 구현할 계획일 때 (미래의 당신이 지침이 필요합니다)
- 혼자 작업할 때 (문서화가 중요합니다)
작은 작업 단위 세분화
각 작업 = 2-5분의 집중 작업.
모든 단계는 하나의 행동입니다:
- "실패하는 테스트 작성" — 단계
- "실패하는지 확인하기 위해 실행" — 단계
- "테스트를 통과시키는 최소 코드 구현" — 단계
- "테스트를 실행하고 통과하는지 확인" — 단계
- "커밋" — 단계
너무 큼:
### 작업 1: 인증 시스템 구축
[5개 파일에 50줄 코드]
적절한 크기:
### 작업 1: 이메일 필드가 있는 User 모델 생성
[10줄, 1개 파일]
### 작업 2: User에 비밀번호 해시 필드 추가
[8줄, 1개 파일]
### 작업 3: 비밀번호 해싱 유틸리티 생성
[15줄, 1개 파일]
계획 문서 구조
헤더 (필수)
모든 계획은 다음으로 시작해야 합니다:
# [기능 이름] 구현 계획
> **Hermes용:** subagent-driven-development 스킬을 사용하여 이 계획을 작업별로 구현합니다.
**목표:** [이것이 무엇을 구축하는지 한 문장으로 설명]
**아키텍처:** [접근 방식에 대한 2-3문장]
**기술 스택:** [주요 기술/라이브러리]
---
작업 구조
각 작업은 다음 형식을 따릅니다:
### 작업 N: [설명적 이름]
**목표:** 이 작업이 달성하는 것 (한 문장)
**파일:**
- 생성: `exact/path/to/new_file.py`
- 수정: `exact/path/to/existing.py:45-67` (라인 번호를 알 경우)
- 테스트: `tests/path/to/test_file.py`
**단계 1: 실패하는 테스트 작성**
```python
def test_specific_behavior():
result = function(input)
assert result == expected
```
**단계 2: 테스트를 실행하여 실패 확인**
실행: `pytest tests/path/test.py::test_specific_behavior -v`
예상 결과: FAIL — "function not defined"
**단계 3: 최소 구현 작성**
```python
def function(input):
return expected
```
**단계 4: 테스트를 실행하여 통과 확인**
실행: `pytest tests/path/test.py::test_specific_behavior -v`
예상 결과: PASS
**단계 5: 커밋**
```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```
작성 과정
단계 1: 요구사항 이해
다음을 읽고 이해합니다:
- 기능 요구사항
- 설계 문서 또는 사용자 설명
- 승인 기준
- 제약 조건
단계 2: 코드베이스 탐색
Hermes 도구를 사용하여 프로젝트를 이해합니다:
# 프로젝트 구조 이해
search_files("*.py", target="files", path="src/")
# 유사한 기능 살펴보기
search_files("similar_pattern", path="src/", file_glob="*.py")
# 기존 테스트 확인
search_files("*.py", target="files", path="tests/")
# 주요 파일 읽기
read_file("src/app.py")
단계 3: 접근 방식 설계
결정:
- 아키텍처 패턴
- 파일 구성
- 필요한 종속성
- 테스트 전략
단계 4: 작업 작성
순서대로 작업 생성:
- 설정/인프라
- 핵심 기능 (각각 TDD)
- 엣지 케이스
- 통합
- 정리/문서화
단계 5: 완전한 세부사항 추가
각 작업에 대해 다음을 포함합니다:
- 정확한 파일 경로 ("설정 파일"이 아닌
src/config/settings.py) - 완전한 코드 예제 ("검증 추가"가 아닌 실제 코드)
- 예상 출력이 포함된 정확한 명령어
- 작업이 작동함을 증명하는 검증 단계
단계 6: 계획 검토
확인:
- 작업이 순차적이고 논리적인가
- 각 작업이 작은 단위인가 (2-5분)
- 파일 경로가 정확한가
- 코드 예제가 완전한가 (복사-붙여넣기 가능)
- 명령어가 정확하고 예상 출력이 있는가
- 누락된 컨텍스트가 없는가
- DRY, YAGNI, TDD 원칙이 적용되었는가
원칙
DRY (중복 방지)
나쁨: 3곳에서 유효성 검사 복사-붙여넣기 좋음: 유효성 검사 함수를 추출하여 모든 곳에서 사용
YAGNI (필요 없는 기능 금지)
나쁨: 미래 요구사항을 위한 "유연성" 추가 좋음: 지금 필요한 것만 구현
# 나쁨 — YAGNI 위반
class User:
def __init__(self, name, email):
self.name = name
self.email = email
self.preferences = {} # 아직 필요 없음!
self.metadata = {} # 아직 필요 없음!
# 좋음 — YAGNI
class User:
def __init__(self, name, email):
self.name = name
self.email = email
TDD (테스트 주도 개발)
코드를 생성하는 모든 작업은 전체 TDD 주기를 포함해야 합니다:
- 실패하는 테스트 작성
- 실행하여 실패 확인
- 최소 코드 작성
- 실행하여 통과 확인
자세한 내용은 test-driven-development 스킬을 참조하세요.
빈번한 커밋
모든 작업 후 커밋:
git add [files]
git commit -m "type: description"
일반적인 실수
모호한 작업
나쁨: "인증 추가" 좋음: "이메일 및 password_hash 필드가 있는 User 모델 생성"
불완전한 코드
나쁨: "단계 1: 유효성 검사 함수 추가" 좋음: "단계 1: 유효성 검사 함수 추가" 뒤에 완전한 함수 코드 포함
검증 누락
나쁨: "단계 3: 작동하는지 테스트"
좋음: "단계 3: pytest tests/test_auth.py -v 실행, 예상 결과: 3 passed"
파일 경로 누락
나쁨: "모델 파일 생성"
좋음: "생성: src/models/user.py"
실행 핸드오프
계획을 저장한 후, 실행 접근 방식을 제안합니다:
"계획이 완료되어 저장되었습니다. subagent-driven-development를 사용하여 실행할 준비가 되었습니다. 각 작업에 대해 새로운 하위 에이전트를 파견하고 2단계 검토(사양 준수, 코드 품질)를 수행합니다. 진행할까요?"
실행 시 subagent-driven-development 스킬을 사용합니다:
- 각 작업에 대해 전체 컨텍스트와 함께 새로운
delegate_task사용 - 각 작업 후 사양 준수 검토
- 사양 통과 후 코드 품질 검토
- 두 검토 모두 승인할 때만 진행
기억하세요
작은 작업 단위 (각 2-5분)
정확한 파일 경로
완전한 코드 (복사-붙여넣기 가능)
예상 출력이 포함된 정확한 명령어
검증 단계
DRY, YAGNI, TDD
빈번한 커밋
좋은 계획은 구현을 명백하게 만듭니다.