[ contents ]
가이드

예제 & 레시피

처음부터 끝까지 실제 변경. 각 레시피는 입력할 명령과 돌아오는 것을 보여주므로, 상황을 패턴과 일치시키고 복사할 수 있습니다. 이것들은 일일 core 명령 (propose, explore, apply, sync, archive는 기본 full 프로파일에서 즉시 사용 가능)을 사용합니다. 확장 집합이 도움이 되는 경우 주석을 달았습니다.

시작하기 전에 상기: /rasen:propose 같은 슬래시 명령은 AI 어시스턴트의 채팅에 가고, rasen 명령은 터미널에 갑니다. 이것이 새로우면 먼저 명령이 어떻게 작동하는지를 읽으세요. 아래 성적표에서 You:AI:는 채팅이며, $로 시작하는 줄은 터미널입니다.

아직 뭘 구축할지 확실하지 않나요? 이 레시피 대부분은 먼저 /rasen:explore로 생각을 정리하면 더 명확합니다. 레시피 3은 그것을 보여주고, 먼저 탐색 가이드가 전체 경우를 만듭니다.

레시피 1: 작은 기능, 빠른 경로

사용 시점: 당신이 원하는 것을 알고, 포함된 작업이라면. 이것이 가장 일반적인 레시피입니다.

전체 것은 세 명령입니다. 제안서, 구축, 보관.

당신: /rasen:propose add-logout-button

AI:   rasen/changes/add-logout-button/ 생성
      ✓ proposal.md — 이유와 무엇
      ✓ specs/      — 새로운 요구사항과 시나리오
      ✓ design.md   — 기술적 접근 방식
      ✓ tasks.md    — 구현 체크리스트
      구현 준비 완료. /rasen:apply를 실행하세요.

이제 계획을 읽으세요. 제안서와 증량 스펙을 엽니다. 이것이 rasen이 구축된 순간입니다: 잘못된 가정을 400줄의 코드가 아닌 한 단락일 때 포착하세요. 뭔가 잘못되면 산출물을 직접 편집하고 계속하세요.

당신: /rasen:apply

AI:   작업을 진행 중...
      ✓ 1.1 헤더에 로그아웃 버튼 추가
      ✓ 1.2 클릭 시 세션 지우기
      ✓ 1.3 확인 대화 추가
      모든 작업 완료!

당신: /rasen:archive

AI:   add-logout-button 보관 중...
      ✓ rasen/specs/auth/spec.md에 스펙 병합
      ✓ rasen/changes/archive/2026-06-22-add-logout-button/으로 이동
      완료. 다음 변경 준비.

그것뿐입니다. 로그아웃 동작이 이제 스펙의 일부이며, 변경은 전체 컨텍스트와 함께 보관되어 있습니다.

레시피 2: 버그 수정

사용 시점: 뭔가가 깨져있고 수정을 신비 커밋이 아닌 동작에 대한 의도적인 변경으로 기록하고 싶을 때.

버그 수정은 기능과 정확히 같이 작동합니다. 차이는 제안서 프레이밍 방식입니다: 단지 "버그 수정"이 아닌 올바른 동작을 설명합니다.

당신: /rasen:propose fix-login-redirect-loop

AI:   rasen/changes/fix-login-redirect-loop/ 생성
      제안서는 현재 깨진 동작과 의도된 동작을 캡처합니다.
      증량 스펙은 리다이렉트 요구사항을 MODIFIED하므로 이제
      정확하고 테스트 가능합니다.
      구현 준비 완료.

수정이 신선한 시나리오와 함께 MODIFIED 요구사항으로 방문하면, 다음 사람 (또는 다음 AI 세션)은 고친 것만 아니라 "올바른"이 의미하는 것을 봅니다. 그런 다음 /rasen:apply/rasen:archive를 정상으로 합니다.

팁: 수정의 경우, 좋은 시나리오는 산문의 회귀 테스트입니다. "GIVEN 로그아웃한 사용자, WHEN 유효한 자격증명 제출, THEN 대시보드에 방문하고 다시 리다이렉트되지 않음." 그것을 작성하고, 구현은 명확한 대상을 가집니다.

레시피 3: 커밋하기 전에 탐색

사용 시점: 당신은 문제가 있지만 아직 계획이 아닙니다. 구축할 것이 확실하지 않거나 어느 접근 방식이 올바른지.

/rasen:explore로 시작하세요. 구조와 생성된 산출물이 없는 생각 파트너입니다. 코드베이스를 읽고 결정을 내리는 데 도움이 됩니다.

당신: /rasen:explore

AI:   뭘 탐색하고 싶으세요?

당신: 페이지 로드가 느린데 시간이 어디로 가는지 모르겠어요.

AI:   살펴봤어요... 가능성이 있는 것 세 가지를 찾았어요:
      1. 상품 목록의 큰 최적화되지 않은 이미지
      2. 렌더링을 차단하는 동기 데이터 페칭
      3. 컨텍스트 변경에 의해 트리거되는 리렌더
      어느 것을 먼저 해야 할까요?

당신: 데이터 페칭 하나.

당신: /rasen:propose optimize-product-list-fetching

AI:   변경을 생성했어요. 우리가 방금 찾은 것으로 정보를 얻은
      제안서와 함께. 구현 준비 완료.

탐색은 변경에 시간을 쓰기 전에 생각을 명확히 합니다. 인사이트가 결정화되면 제안하고, AI는 컨텍스트를 앞으로 이동시킵니다.

레시피 4: 한 번에 두 가지 변경 처리

사용 시점: 당신은 기능 중간이지만, 긴급 수정이 대기열을 점프합니다.

변경은 독립 폴더이므로 병렬 작업은 충돌하지 않습니다. 수정을 시작하고, 배포하고, 정확히 멈춘 곳으로 기능으로 돌아가세요.

당신: add-dark-mode 중간이지만 로그인 버그를 지금 수정해야 해요.

당신: /rasen:propose fix-login-redirect

AI:   rasen/changes/fix-login-redirect/ 생성. 구현 준비 완료.

당신: /rasen:apply

AI:   수정을 구현했어요. 모든 작업 완료.

당신: /rasen:archive

AI:   ✓ fix-login-redirect 보관.

당신: 다크 모드로 돌아가기.

당신: /rasen:apply add-dark-mode

AI:   add-dark-mode 재개. 작업 2.3에서 선택: Header 업데이트...

/rasen:apply add-dark-mode에서 변경을 명명하는 것이 AI가 한 개 이상이 활성일 때 특정 변경을 지정하는 방법입니다. 작업이 tasks.md의 완료를 추적하므로, AI는 정확히 어디서 멈췄는지 압니다.

여러 변경이 한 번에 완료되면, 확장 /rasen:bulk-archive가 함께 보관하고 실제로 구현된 것을 확인하여 스펙 충돌을 해결합니다. 워크플로우를 참조하세요.

레시피 5: 동작 변경 없는 리팩토

사용 시점: 코드를 재구성하고 있으며 외부적으로 보이는 동작은 동일해야 할 때.

이것은 흥미로운 경우입니다. 순수 리팩토는 스펙에 추가할 것이 없기 때문입니다. 동작 계약은 변경되지 않습니다. 구현만 변경됩니다. 따라서 작업은 설계와 작업에 있고, 스펙 증량은 비어있거나 없습니다.

당신: /rasen:propose refactor-payment-module

AI:   변경을 생성했어요. 제안서가 목표 (결제 모듈 분할,
      동작 변경 없음)를 명시하고, 설계가 새로운 구조를
      캡처합니다. 동작이 동일하므로 스펙 변경 없음.
      구현 준비 완료.

스펙을 만지지 않는 변경을 보관할 때, 스펙 단계를 건너뛰도록 터미널 명령에 지시할 수 있습니다:

$ rasen archive refactor-payment-module --skip-specs

동일한 플래그는 도구, CI 및 문서만 변경할 때 편합니다. 원칙: 스펙은 동작을 설명하므로, 동작이 변경되지 않으면 스펙도 변경되지 않아야 합니다. 개념을 참조하세요.

레시피 6: 단계별 제어 (확장 명령)

사용 시점: 각 산출물을 이동하기 전에 검토하려는 복잡하거나 위험한 변경.

core /rasen:propose는 모든 것을 한 번에 초안합니다. 한 번에 한 단계씩 진행하려면 확장 명령을 켜세요:

$ rasen config profile      # 확장 워크플로우 선택
$ rasen update              # 이 프로젝트에 적용

이제 증분적으로 스캐폴드하고 구축할 수 있습니다:

당신: /rasen:new add-2fa

AI:   rasen/changes/add-2fa/ 생성. 생성 준비: 제안서.

당신: /rasen:continue

AI:   proposal.md 생성. 이제 가능: 스펙, 설계.

당신: /rasen:continue

AI:   specs/auth/spec.md 생성. 이제 가능: 설계.

각 산출물이 도착하면서 검토하고 자유롭게 편집하고, 만족하면 계속하세요. 나머지를 한 번에 초안 작성하려면 /rasen:ff가 남은 계획 산출물을 빠르게 전진시킵니다. 보관 전에 /rasen:verify가 구현이 실제로 스펙과 일치하는지 확인합니다. 워크플로우를 참조하세요.

레시피 7: 전체 루프를 실제로 배우기

사용 시점: rasen을 설치했고 장난감 예제가 아닌 자신의 코드에서 워크플로우를 느끼고 싶을 때.

확장 명령을 켜세요 (레시피 6 참조), 그 후:

당신: /rasen:onboard

AI:   rasen에 오신 것을 환영합니다! 나는 당신의 실제 코드베이스를
      사용하여 완전한 변경을 안내하겠습니다. 함께 안전하게 할 수
      있는 작은 개선을 찾기 위해 스캔해봅시다...

/rasen:onboard는 실제 (작은) 개선을 찾고, 변경을 생성하고, 구현하고, 모든 단계를 설명하면서 보관합니다. 15~30분이 걸리고 유지하거나 삭제할 수 있는 실제 변경으로 남습니다. 배우는 가장 부드러운 방법입니다. 명령을 참조하세요.

터미널에서 작업 확인

언제든지, 터미널에서 상태를 검사할 수 있습니다:

$ rasen list                      # 활성 변경
$ rasen show add-dark-mode        # 하나의 변경 상세히
$ rasen validate add-dark-mode    # 구조 확인
$ rasen view                      # 대화형 대시보드

이것들은 읽기 및 검사 도구입니다. 제안과 구축은 여전히 채팅의 슬래시 명령을 통해 발생합니다. 전체 세부사항은 CLI 참조에 있습니다.

다음은 어디로?

  • 먼저 탐색: 확실하지 않을 때 시작하는 권장 방법
  • 워크플로우: 위의 패턴, 각각을 언제 사용할지에 대한 결정 지침
  • 명령: 모든 슬래시 명령 상세히
  • 시작하기: 표준 첫 번째 변경 안내
  • 개념: 부품이 함께 작동하는 방식의 이유