이해하기

OPSX 워크플로우

Discord에서 피드백을 환영합니다.

그것이 무엇인가요?

OPSX는 이제 rasen의 표준 워크플로우입니다.

rasen 변경을 위한 유연하고 반복적인 워크플로우입니다. 더 이상 엄격한 단계는 없습니다. 언제든 수행할 수 있는 작업만 있습니다.

이것이 존재하는 이유

이전 워크플로우는 작동하지만, 매우 제한적입니다:

명령이 하드코딩되어 있습니다 — TypeScript에 묻혀 있어서 변경할 수 없습니다
전부 아니면 무라는 방식입니다 — 하나의 큰 명령이 모든 것을 생성하고, 개별 부분을 테스트할 수 없습니다
고정된 구조 — 모두를 위한 동일한 워크플로우, 커스터마이징이 불가능합니다
블랙박스 — AI 출력이 좋지 않을 때, 프롬프트를 수정할 수 없습니다

OPSX가 이를 개방합니다. 이제 누구든:

명령을 실험할 수 있습니다 — 템플릿을 편집하고, AI가 더 잘하는지 확인합니다
세부적으로 테스트할 수 있습니다 — 각 산출물의 명령을 독립적으로 검증합니다
워크플로우를 커스터마이징할 수 있습니다 — 자신만의 산출물과 의존성을 정의합니다
빠르게 반복할 수 있습니다 — 템플릿을 변경하고, 즉시 테스트하고, 다시 빌드할 필요가 없습니다

이전 워크플로우:                      OPSX:
┌────────────────────────┐           ┌────────────────────────┐
│  패키지에 하드코딩됨    │           │  schema.yaml           │◄── 이것을 편집합니다
│  (변경 불가)          │           │  templates/*.md        │◄── 또는 이것을
│        ↓               │           │        ↓               │
│  새 릴리스 대기        │           │  즉각적인 효과         │
│        ↓               │           │        ↓               │
│  더 나은지 바랍니다    │           │  직접 테스트합니다    │
└────────────────────────┘           └────────────────────────┘

모든 사람을 위한 것입니다:

팀 — 실제 작업 방식에 맞는 워크플로우를 생성합니다
고급 사용자 — 프롬프트를 수정하여 코드베이스에 맞는 더 나은 AI 출력을 얻습니다
Rasen 기여자 — 릴리스 없이 새로운 접근 방식을 실험합니다

우리 모두는 여전히 무엇이 가장 잘 작동하는지 배우고 있습니다. OPSX를 사용하면 함께 배울 수 있습니다.

사용자 경험

선형 워크플로우의 문제점: "기획 단계", "구현 단계", "완료"에 있습니다. 하지만 실제 작업은 그렇게 작동하지 않습니다. 뭔가를 구현하고, 설계가 잘못되었다는 것을 깨닫고, 스펙을 업데이트해야 하고, 계속 구현해야 합니다. 선형 단계는 실제 작업 방식에 맞서갑니다.

OPSX 접근 방식:

단계가 아닌 작업 — 생성, 구현, 업데이트, 보관 — 언제든 수행할 수 있습니다
의존성은 가능성의 활성화자입니다 — 필수 사항이 아니라 가능한 것을 보여줍니다

  제안서 ──→ 스펙 ──→ 설계 ──→ 작업 ──→ 구현

설정

# rasen이 설치되어 있는지 확인하세요 — 스킬은 자동으로 생성됩니다
rasen init

이렇게 하면 AI 코딩 어시스턴트가 자동 감지하는 .claude/skills/ (또는 해당 위치)에 스킬이 생성됩니다.

기본적으로 rasen은 full 워크플로우 프로파일을 사용합니다 — 모든 워크플로우, 확장된 명령 포함 (new, continue, ff, verify, bulk-archive, onboard). 일상적인 core 집합(propose, explore, apply, sync, archive)으로 축소하려면 rasen config profile core로 전환하고 rasen update를 적용합니다.

설정 중에 프로젝트 설정 (rasen/config.yaml)을 생성하도록 요청받습니다. 이는 선택 사항이지만 권장됩니다.

프로젝트 설정

프로젝트 설정을 사용하면 기본값을 설정하고 모든 산출물에 프로젝트별 컨텍스트를 주입할 수 있습니다.

설정 생성

설정은 rasen init 중에 생성되거나 수동으로 생성됩니다:

# rasen/config.yaml
schema: spec-driven

context: |
  Tech stack: TypeScript, React, Node.js
  API conventions: RESTful, JSON responses
  Testing: Vitest for unit tests, Playwright for e2e
  Style: ESLint with Prettier, strict TypeScript

rules:
  proposal:
    - Include rollback plan
    - Identify affected teams
  specs:
    - Use Given/When/Then format for scenarios
  design:
    - Include sequence diagrams for complex flows

설정 필드

필드	타입	설명
`schema`	string	새로운 변경을 위한 기본 스키마 (예: `spec-driven`)
`context`	string	모든 산출물 명령에 주입되는 프로젝트 컨텍스트
`rules`	object	산출물 ID로 키가 지정된 산출물별 규칙

작동 방식

스키마 우선순위 (가장 높음에서 낮음):

CLI 플래그 (--schema <name>)
변경 메타데이터 (변경 디렉터리의 .openspec.yaml)
프로젝트 설정 (rasen/config.yaml)
기본값 (spec-driven)

컨텍스트 주입:

컨텍스트는 모든 산출물의 명령 앞에 추가됩니다
<context>...</context> 태그로 래핑됩니다
AI가 프로젝트의 규칙을 이해하는 데 도움이 됩니다

규칙 주입:

규칙은 일치하는 산출물에만 주입됩니다
<rules>...</rules> 태그로 래핑됩니다
컨텍스트 후, 템플릿 전에 나타납니다

스키마별 산출물 ID

spec-driven (기본):

proposal — 변경 제안서
specs — 스펙
design — 기술 설계
tasks — 구현 작업

설정 검증

rules의 알려지지 않은 산출물 ID는 경고를 생성합니다
스키마 이름은 사용 가능한 스키마에 대해 검증됩니다
컨텍스트의 크기 제한은 50KB입니다
잘못된 YAML은 줄 번호와 함께 보고됩니다

문제 해결

"규칙에서 알 수 없는 산출물 ID: X"

산출물 ID가 스키마와 일치하는지 확인합니다 (위의 목록 참조)
rasen schemas --json을 실행하여 각 스키마의 산출물 ID를 확인합니다

설정이 적용되지 않습니다:

파일이 rasen/config.yaml에 있는지 확인합니다 (.yml 아님)
YAML 구문을 검증기로 확인합니다
설정 변경은 즉시 적용됩니다 (재시작 필요 없음)

컨텍스트가 너무 큽니다:

컨텍스트는 50KB로 제한됩니다
대신 요약하거나 외부 문서로 연결합니다

명령

명령	수행 내용
`/rasen:propose`	변경을 생성하고 한 단계로 기획 산출물 생성 (기본 빠른 경로)
`/rasen:explore`	아이디어를 생각하고, 문제를 조사하고, 요구사항을 명확히 합니다
`/rasen:new`	새로운 변경 스캐폴드 시작 (확장 워크플로우)
`/rasen:continue`	다음 산출물 생성 (확장 워크플로우)
`/rasen:ff`	기획 산출물 빠르게 전진 (확장 워크플로우)
`/rasen:apply`	작업을 구현하고, 산출물 업데이트
`/rasen:verify`	구현을 산출물에 대해 검증 (확장 워크플로우)
`/rasen:sync`	증량 스펙을 main으로 동기화 (기본 워크플로우, 선택)
`/rasen:archive`	완료되면 보관
`/rasen:bulk-archive`	완료된 여러 변경 보관 (확장 워크플로우)
`/rasen:onboard`	전체 변경에 대한 가이드 안내 (확장 워크플로우)

사용법

아이디어 탐색

/rasen:explore

아이디어를 생각하고, 문제를 조사하고, 옵션을 비교합니다. 구조가 필요하지 않습니다 — 단지 생각 파트너입니다. 인사이트가 결정화되면 /rasen:propose (기본) 또는 /rasen:new//rasen:ff (확장)로 전환합니다.

새로운 변경 시작

/rasen:propose

변경을 생성하고 구현 전에 필요한 기획 산출물을 생성합니다.

확장 워크플로우를 활성화했다면 대신 다음을 사용할 수 있습니다:

/rasen:new        # 스캐폴드만
/rasen:continue   # 한 번에 하나의 산출물 생성
/rasen:ff         # 모든 기획 산출물을 한 번에 생성

산출물 생성

/rasen:continue

의존성을 기반으로 생성 준비가 된 것을 표시한 다음 하나의 산출물을 생성합니다. 변경을 점진적으로 구성하려면 반복해서 사용합니다.

/rasen:ff add-dark-mode

모든 기획 산출물을 한 번에 생성합니다. 무엇을 구축할지 명확할 때 사용합니다.

구현 (유연한 부분)

/rasen:apply

작업을 진행하면서 완료하면서 체크합니다. 여러 변경을 처리하는 경우 /rasen:apply <name>을 실행할 수 있습니다. 그렇지 않으면 대화에서 추론하고 알 수 없으면 선택하도록 요청합니다.

마무리

/rasen:archive   # 완료되면 보관으로 이동 (필요시 스펙 동기화 프롬프트)

목표 주도 반복 (`/rasen:goal`)

/rasen:auto는 제품이 코드 변경 문서라고 가정합니다 (제안서 → 구현 → 배포). 일부 작업은 그 형태에 맞지 않습니다 — 그들의 "완료"는 조건입니다: Lighthouse 점수를 90으로 높이거나, 모듈을 루브릭 정리 상태로 만들거나, 조사하고 간단한 보고서를 작성합니다. /rasen:goal이 이러한 항목의 진입점입니다. 수정 → 판단을 반복합니다. 게이트가 만족되거나 반복 한계에 도달할 때까지.

하나의 명령을 봅니다. LEAD는 작업을 분류하고 하나의 백엔드 파이프라인을 선택합니다 (명시적 재정의가 항상 우선):

선택기 / 키워드	백엔드 파이프라인	게이트	종료
`measure` — `score` `latency` `lighthouse` `benchmark` `p99` `memory`	goal-loop-measure	결정론적 명령이 `{score, passed}`를 내보냅니다	배포 → 보관
`evaluate` — `rubric` `quality` `clean` `standard`	goal-loop-evaluate	새 리뷰어 워커가 `{satisfied, gaps}`를 판단합니다	배포 → 보관
`research` — `research` `investigate` `write brief` `autoresearch`	goal-loop-research	새 리뷰어 워커	보고서 (배포 없음)

흐름은 목표 정의 → 반복 → 종료입니다: 기획자가 goal-plan.md (목표, 게이트, 작업 제품, maxRounds)를 작성하고, 구현자는 반복 전체에서 따뜻하게 재사용되고, 각 반복의 판단은 goal-run.json에 추가됩니다 (권한 있는 반복 위치), 반복은 maxRounds (기본값 5) + loopStallLimit (기본값 2)로 제한됩니다. /rasen:goal은 /rasen:auto와 동일한 조율 재생을 공유합니다 — 두 번째 시스템이 아닌 형제 진입점입니다. 작업 예제, 재개 의미론, 정체 계단을 포함한 전체 장은 저장소 docs/ 디렉터리의 opsx-workflow-guide.md §9 (목표 주도 반복)를 참조하세요.

업데이트 vs 새로 시작하기

구현 전에 항상 제안서나 스펙을 편집할 수 있습니다. 하지만 정제가 "다른 작업"이 되는 때는 언제일까요?

제안서가 캡처하는 것

제안서는 세 가지를 정의합니다:

의도 — 어떤 문제를 해결하고 있습니까?
범위 — 무엇이 범위 내/외인가요?
접근 방식 — 어떻게 해결할 것입니까?

질문은: 어느 것이 변경되었고, 얼마나 많이?

기존 변경을 업데이트하는 경우:

동일한 의도, 정제된 실행

미처 고려하지 못한 엣지 케이스를 발견합니다
접근 방식을 수정해야 하지만 목표는 변하지 않습니다
구현에서 설계가 약간 잘못되었음을 알 수 있습니다

범위 축소

전체 범위가 너무 크다는 것을 깨닫고, 먼저 MVP를 배포하고 싶습니다
"다크 모드 추가" → "다크 모드 토글 추가 (v2의 시스템 환경설정)"

학습 기반 정정

코드베이스가 생각했던 것처럼 구조화되지 않았습니다
의존성이 예상과 다르게 작동합니다
"CSS 변수 사용" → "대신 Tailwind의 dark: 접두사 사용"

새로운 변경을 시작하는 경우:

근본적으로 변경된 의도

문제 자체가 지금은 다릅니다
"다크 모드 추가" → "커스텀 색상, 글꼴, 간격을 포함한 포괄적인 테마 시스템 추가"

범위가 폭발

변경이 너무 많이 커서 본질적으로 다른 작업입니다
원래 제안서는 업데이트 후 인식할 수 없습니다
"로그인 버그 수정" → "인증 시스템 재작성"

원래 완료 가능

원래 변경을 "완료"로 표시할 수 있습니다
새로운 작업은 독립적이며, 정제가 아닙니다
"다크 모드 MVP 추가" 완료 → 보관 → 새로운 변경 "다크 모드 향상"

휴리스틱

                        ┌─────────────────────────────────────┐
                        │     이것이 같은 작업인가요?          │
                        └──────────────┬──────────────────────┘
                                       │
                    ┌──────────────────┼──────────────────┐
                    │                  │                  │
                    ▼                  ▼                  ▼
             동일한 의도?      >50% 겹침?      원래를 이
             같은 문제?        같은 범위?      변경 없이
                    │                  │      "완료"할 수?
                    │                  │                  │
          ┌────────┴────────┐  ┌──────┴──────┐   ┌───────┴───────┐
          │                 │  │             │   │               │
         YES               NO YES           NO  NO              YES
          │                 │  │             │   │               │
          ▼                 ▼  ▼             ▼   ▼               ▼
       업데이트          새로움  업데이트       새로움  업데이트       새로움

테스트	업데이트	새로운 변경
정체성	"같은 것, 정제됨"	"다른 작업"
범위 겹침	>50% 겹침	<50% 겹침
완료	변경 없이 "완료"할 수 없음	원래를 완료할 수 있고, 새 작업은 독립적
스토리	업데이트 체인이 일관된 스토리를 전합니다	패치가 명확하기보다 혼란을 줍니다

원칙

업데이트는 컨텍스트를 보존합니다. 새로운 변경은 명확성을 제공합니다.

생각의 역사가 가치있을 때 업데이트를 선택합니다. 패칭하는 것보다 새로 시작하는 것이 더 명확할 때 새로운 것을 선택합니다.

git 분기처럼 생각하세요:

같은 기능을 작업하는 동안 계속 커밋합니다
진정한 새로운 작업일 때 새로운 분기를 시작합니다
때때로 부분 기능을 병합하고 2단계를 위해 새로 시작합니다

무엇이 다른가요?

	이전 (`/openspec:proposal`)	OPSX (`/rasen:*`)
구조	하나의 큰 제안서 문서	의존성이 있는 개별 산출물
워크플로우	선형 단계: 기획 → 구현 → 보관	유연한 작업 — 언제든 뭐든 수행
반복	돌아가기가 어렵습니다	배우면서 산출물 업데이트
커스터마이징	고정된 구조	스키마 기반 (자신만의 산출물 정의)

핵심 인사이트: 작업은 선형이 아닙니다. OPSX가 그렇게 가장합니다.

아키텍처 심화 탐구

이 섹션은 OPSX가 내부적으로 어떻게 작동하는지와 이전 워크플로우와 어떻게 비교되는지 설명합니다. 이 섹션의 예제는 확장된 명령 집합(new, continue 등)을 사용합니다. core 프로파일 사용자는 동일한 흐름을 propose → apply → sync → archive로 매핑할 수 있습니다.

철학: 단계 vs 작업

┌─────────────────────────────────────────────────────────────────────────────┐
│                         이전 워크플로우                                      │
│                    (단계 잠금, 전부 아니면 무)                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌──────────────┐      ┌──────────────┐      ┌──────────────┐             │
│   │   기획       │ ───► │ 구현         │ ───► │   보관       │             │
│   │    단계      │      │    단계      │      │    단계      │             │
│   └──────────────┘      └──────────────┘      └──────────────┘             │
│         │                     │                     │                       │
│         ▼                     ▼                     ▼                       │
│   /openspec:proposal   /openspec:apply      /openspec:archive              │
│                                                                             │
│   • 모든 산출물을 한 번에 생성합니다                                          │
│   • 구현 중 스펙으로 돌아가기가 불가능합니다                                    │
│   • 단계 게이트는 선형 진행을 강제합니다                                        │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘


┌─────────────────────────────────────────────────────────────────────────────┐
│                            OPSX 워크플로우                                     │
│                      (유연한 작업, 반복적)                             │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│              ┌────────────────────────────────────────────┐                 │
│              │           작업 (단계 아님)             │
│              │                                            │                 │
│              │   new ◄──► continue ◄──► apply ◄──► archive │                 │
│              │    │          │           │           │    │                 │
│              │    └──────────┴───────────┴───────────┘    │                 │
│              │              어떤 순서든                     │
│              └────────────────────────────────────────────┘                 │
│                                                                             │
│   • 한 번에 하나씩 또는 빠르게 전진 산출물 생성                           │
│   • 구현 중 스펙/설계/작업 업데이트                                      │
│   • 의존성은 진행을 활성화하고, 단계는 없습니다                              │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

컴포넌트 아키텍처

이전 워크플로우는 TypeScript의 하드코딩된 템플릿을 사용합니다:

┌─────────────────────────────────────────────────────────────────────────────┐
│                      이전 워크플로우 컴포넌트                              │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   하드코딩된 템플릿 (TypeScript 문자열)                                      │
│                    │                                                        │
│                    ▼                                                        │
│   도구별 구성기/어댑터                                      │
│                    │                                                        │
│                    ▼                                                        │
│   생성된 명령 파일 (.claude/commands/openspec/*.md)                  │
│                                                                             │
│   • 고정 구조, 산출물 인식 없음                                  │
│   • 변경하려면 코드 수정 + 다시 빌드 필요                             │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

OPSX는 외부 스키마와 의존성 그래프 엔진을 사용합니다:

┌─────────────────────────────────────────────────────────────────────────────┐
│                         OPSX 컴포넌트                                      │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   스키마 정의 (YAML)                                                 │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │  name: spec-driven                                                  │   │
│   │  artifacts:                                                         │   │
│   │    - id: proposal                                                   │   │
│   │      generates: proposal.md                                         │   │
│   │      requires: []              ◄── 의존성                     │   │
│   │    - id: specs                                                      │   │
│   │      generates: specs/**/*.md  ◄── 글롭 패턴                    │   │
│   │      requires: [proposal]      ◄── 제안서 후 활성화           │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   산출물 그래프 엔진                                                     │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │  • 위상 정렬 (의존성 순서)                           │
│   │  • 상태 감지 (파일 시스템 존재)                           │
│   │  • 풍부한 명령 생성 (템플릿 + 컨텍스트)                │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   스킬 파일 (.claude/skills/rasen-*/SKILL.md)                             │
│                                                                             │
│   • 크로스 에디터 호환 (Claude Code, Cursor, Windsurf)                 │
│   • 구조화된 데이터를 위한 스킬 조회 CLI                                     │
│   • 스키마 파일을 통해 완전히 커스터마이징 가능                              │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

의존성 그래프 모델

산출물은 방향 무환 그래프 (DAG)를 형성합니다. 의존성은 활성화자, 게이트가 아닙니다:

                              제안서
                             (루트 노드)
                                  │
                    ┌─────────────┴─────────────┐
                    │                           │
                    ▼                           ▼
                 스펙                       설계
              (requires:                  (requires:
               제안서)                    제안서)
                    │                           │
                    └─────────────┬─────────────┘
                                  │
                                  ▼
                               작업
                           (requires:
                           스펙, 설계)
                                  │
                                  ▼
                          ┌──────────────┐
                          │ 구현 단계  │
                          │ (requires:   │
                          │  작업)      │
                          └──────────────┘

상태 전환:

   차단됨 ────────────────► 준비됨 ────────────────► 완료됨
      │                        │                       │
   의존성              모든 종속성          파일이 파일
   누락됨             완료됨              시스템에 존재

정보 흐름

이전 워크플로우 — 에이전트는 정적 명령을 받습니다:

  사용자: "/openspec:proposal"
           │
           ▼
  ┌─────────────────────────────────────────┐
  │  정적 명령:                   │
  │  • proposal.md 생성                   │
  │  • tasks.md 생성                      │
  │  • design.md 생성                     │
  │  • specs/<capability>/spec.md 생성    │
  │                                         │
  │  무엇이 존재하는지 인식 없음 또는         │
  │  산출물 간 의존성                        │
  └─────────────────────────────────────────┘
           │
           ▼
  에이전트가 모든 산출물을 한 번에 생성합니다

OPSX — 에이전트는 풍부한 컨텍스트를 조회합니다:

  사용자: "/rasen:continue"
           │
           ▼
  ┌──────────────────────────────────────────────────────────────────────────┐
  │  단계 1: 현재 상태 조회                                             │
  │  ┌────────────────────────────────────────────────────────────────┐  │
  │  │  $ rasen status --change "add-auth" --json                      │  │
  │  │                                                                    │  │
  │  │  {                                                                 │  │
  │  │    "artifacts": [                                                  │  │
  │  │      {"id": "proposal", "status": "done"},                         │  │
  │  │      {"id": "specs", "status": "ready"},      ◄── 첫 준비      │  │
  │  │      {"id": "design", "status": "ready"},                          │  │
  │  │      {"id": "tasks", "status": "blocked", "missingDeps": ["specs"]}│  │
  │  │    ]                                                               │  │
  │  │  }                                                                 │  │
  │  └────────────────────────────────────────────────────────────────┘  │
  │                                                                          │
  │  단계 2: 준비된 산출물에 대한 풍부한 명령 받기                        │
  │  ┌────────────────────────────────────────────────────────────────┐  │
  │  │  $ rasen instructions specs --change "add-auth" --json          │  │
  │  │                                                                    │  │
  │  │  {                                                                 │  │
  │  │    "template": "# 스펙\n\n## ADDED 요구사항...",      │
  │  │    "dependencies": [{"id": "proposal", "path": "...", "done": true}│  │
  │  │    "unlocks": ["tasks"]                                            │  │
  │  │  }                                                                 │  │
  │  └────────────────────────────────────────────────────────────────┘  │
  │                                                                          │
  │  단계 3: 의존성 읽기 → 한 산출물 생성 → 활성화된 것을 표시        │
  └──────────────────────────────────────────────────────────────────────────┘

반복 모델

이전 워크플로우 — 반복하기 어렵습니다:

  ┌─────────┐     ┌─────────┐     ┌─────────┐
  │/proposal│ ──► │ /apply  │ ──► │/archive │
  └─────────┘     └─────────┘     └─────────┘
       │               │
       │               ├── "잠깐, 설계가 잘못됐어"
       │               │
       │               ├── 옵션:
       │               │   • 수동으로 파일 편집 (컨텍스트 깨짐)
       │               │   • 포기하고 처음부터 시작
       │               │   • 계속 진행하고 나중에 수정
       │               │
       │               └── "돌아가기" 메커니즘 없음
       │
       └── 모든 산출물을 한 번에 생성합니다

OPSX — 자연스러운 반복:

  /rasen:new ───► /rasen:continue ───► /rasen:apply ───► /rasen:archive
      │                │                  │
      │                │                  ├── "설계가 잘못됐어"
      │                │                  │
      │                │                  ▼
      │                │            설계.md 편집하면 됩니다
      │                │                  │
      │                │                  ▼
      │                │         /rasen:apply가
      │                │         중단한 곳에서 선택
      │                │
      │                └── 한 산출물 생성, 활성화된 것 표시
      │
      └── 변경을 스캐폴드, 방향 대기

커스텀 스키마

스키마 관리 명령을 사용하여 커스텀 워크플로우를 생성합니다:

# 처음부터 새로운 스키마 생성 (대화형)
rasen schema init my-workflow

# 또는 기존 스키마를 시작점으로 포크
rasen schema fork spec-driven my-workflow

# 스키마 구조 검증
rasen schema validate my-workflow

# 스키마 해결 위치 확인 (디버깅에 유용)
rasen schema which my-workflow

스키마는 rasen/schemas/ (프로젝트 로컬, 버전 제어) 또는 ~/.rasen/schemas/ (사용자 글로벌, RASEN_HOME으로 위치 재정의)에 저장됩니다.

스키마 구조:

rasen/schemas/research-first/
├── schema.yaml
└── templates/
    ├── research.md
    ├── proposal.md
    └── tasks.md

schema.yaml 예제:

name: research-first
artifacts:
  - id: research        # 제안서 전에 추가됨
    generates: research.md
    requires: []

  - id: proposal
    generates: proposal.md
    requires: [research]  # 이제 research에 의존

  - id: tasks
    generates: tasks.md
    requires: [proposal]

의존성 그래프:

   research ──► proposal ──► tasks

요약

측면	이전	OPSX
템플릿	하드코딩된 TypeScript	외부 YAML + Markdown
의존성	없음 (전부)	위상 정렬이 있는 DAG
상태	단계 기반 정신 모델	파일 시스템 존재
커스터마이징	소스 편집, 재빌드	schema.yaml 생성
반복	단계 잠금	유연, 뭐든 편집
에디터 지원	도구별 구성기/어댑터	단일 스킬 디렉터리

스키마

스키마는 어떤 산출물이 존재하고 그들의 의존성을 정의합니다. 현재 사용 가능:

spec-driven (기본): 제안서 → 스펙 → 설계 → 작업

# 사용 가능한 스키마 나열
rasen schemas

# 해결 소스가 있는 모든 스키마 확인
rasen schema which --all

# 새로운 스키마를 대화형으로 생성
rasen schema init my-workflow

# 커스터마이징할 기존 스키마 포크
rasen schema fork spec-driven my-workflow

# 사용 전에 스키마 구조 검증
rasen schema validate my-workflow

팁

변경에 커밋하기 전에 아이디어를 생각하려면 /rasen:explore 사용
명확할 때는 /rasen:ff, 탐색할 때는 /rasen:continue 사용
/rasen:apply 중에 뭔가 잘못되면 — 산출물을 수정한 후 계속
작업은 tasks.md의 체크박스를 통해 진행을 추적합니다
언제든 상태 확인: rasen status --change "name"

피드백

이것은 거친 상태입니다. 이것은 의도적입니다 — 우리는 무엇이 가장 잘 작동하는지 배우고 있습니다.

버그를 찾았습니까? 아이디어가 있습니까? Discord에 참여하거나 GitHub에서 이슈를 열어주세요.