task-pipeliner 0.3.3 → 0.3.5

package/README.ko.md

@@ -2,17 +2,31 @@
 
 > 조건 기반 실행과 아름다운 CLI 출력을 제공하는 강력한 워크플로우 오케스트레이션 도구
 
-**버전:** 0.3.3
+**버전:** 0.3.5
 
 ![fox2](https://github.com/user-attachments/assets/fdf8d786-6a91-4d2d-9dc1-72be6f3ccd98)
 
 [![npm version](https://img.shields.io/npm/v/task-pipeliner)](https://www.npmjs.com/package/task-pipeliner)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
 
-**task-pipeliner**는 간단한 YAML 또는 JSON 파일로 복잡한 워크플로우를 정의, 조율, 실행할 수 있는 현대적인 워크플로우 오케스트레이션 도구입니다. 조건부 실행, 병렬 작업, 대화형 프롬프트, 그리고 아름다운 터미널 출력을 제공하여 빌드 스크립트, 배포 워크플로우, CI/CD 파이프라인에 완벽합니다.
+**task-pipeliner**는 간단한 YAML 또는 JSON 파일로 복잡한 워크플로우를 정의, 조율, 실행할 수 있는 현대적인 워크플로우 오케스트레이션 도구입니다. 조건부 실행, 병렬 작업, 대화형 프롬프트, 그리고 아름다운 터미널 출력을 제공하여 빌드 스크립트, 배포 워크플로우, CI/CD 파이프라인에 완벽합니다. *아직 베타 버전이라 인터페이스가 조금씩 수정될 수 있습니다.*
 
 **README-Language-Map** [KR [한국어 버전]](https://github.com/racgoo/task-pipeliner/blob/main/README.ko.md) / [EN [English Version]](https://github.com/racgoo/task-pipeliner)
 
+## 리소스
+
+### 문서 및 도구
+
+- 📚 **[문서](https://task-pipeliner.racgoo.com/)** - 완전한 DSL 참조 및 가이드
+- 🎨 **[워크플로우 생성기](https://task-pipeliner-generator.racgoo.com/)** - 브라우저에서 시각적으로 워크플로우 생성
+
+### 저장소 및 패키지 관리자
+
+- 💻 **[GitHub](https://github.com/racgoo/task-pipeliner)** - 소스 코드 및 이슈 추적
+- 📦 **[npm](https://www.npmjs.com/package/task-pipeliner)** - npm 레지스트리 패키지
+- 🍺 **[Homebrew](https://github.com/racgoo/homebrew-task-pipeliner)** - macOS/Linux용 Homebrew 탭
+- 🪟 **[Scoop](https://github.com/racgoo/scoop-task-pipeliner)** - Windows용 Scoop 버킷
+
 ## ✨ 주요 기능
 
 -  **조건 기반 실행** - 파일 존재 여부, 사용자 선택, 환경 변수 등을 기반으로 단계 실행
@@ -31,26 +45,18 @@
 
 - **워크플로우 스케줄링** - cron 표현식을 사용하여 지정된 시간에 워크플로우 자동 실행
 
-## 리소스
-
-### 문서 및 도구
-
-- 📚 **[문서](https://task-pipeliner.racgoo.com/)** - 완전한 DSL 참조 및 가이드
-- 🎨 **[워크플로우 생성기](https://task-pipeliner-generator.racgoo.com/)** - 브라우저에서 시각적으로 워크플로우 생성
-
-### 저장소 및 패키지 관리자
-
-- 💻 **[GitHub](https://github.com/racgoo/task-pipeliner)** - 소스 코드 및 이슈 추적
-- 📦 **[npm](https://www.npmjs.com/package/task-pipeliner)** - npm 레지스트리 패키지
-- 🍺 **[Homebrew](https://github.com/racgoo/homebrew-task-pipeliner)** - macOS/Linux용 Homebrew 탭
-- 🪟 **[Scoop](https://github.com/racgoo/scoop-task-pipeliner)** - Windows용 Scoop 버킷
-
 ### CLI 명령어
 
+**프로젝트 셋업 (신규 프로젝트 권장):**
+```bash
+tp setup   # tp/, tp/workflows, tp/schedules 생성 및 예시 워크플로우 2개·예시 스케줄 2개 추가 (echo 기반; choose, when, profiles, prompt 포함)
+```
+프로젝트 루트에서 실행. `tp/workflows/`, `tp/schedules/`를 만들고, choose·when·profiles·prompt를 쓴 예시 워크플로우와 cron·프로필을 쓴 예시 스케줄을 넣습니다. 이미 있는 파일은 덮어쓰지 않습니다.
+
 **워크플로우 실행:**
 ```bash
 tp run workflow.yaml        # 워크플로우 실행
-tp run                      # 가장 가까운 tp 디렉토리에서 워크플로우 선택하여 실행
+tp run                      # 가장 가까운 tp/workflows 디렉토리에서 워크플로우 선택하여 실행
 tp run workflow.yaml --profile Test   # 프로필로 실행 (프로필에 설정된 변수는 choose/prompt 생략)
 tp run workflow.yaml -p Test         # 프로필 짧은 형식
 tp run workflow.yaml --silent  # 사일런트 모드로 실행 (모든 콘솔 출력 억제)
@@ -74,16 +80,18 @@ tp history remove-all # 모든 히스토리 삭제
 **워크플로우 스케줄링:**
 ```bash
 tp schedule        # 모든 스케줄 보기 (tp schedule list와 동일)
-tp schedule list   # 스케줄 목록 및 데몬 상태 보기
-tp schedule add schedules.yaml  # 스케줄 파일에서 스케줄 추가
-tp schedule remove # 스케줄 삭제
+tp schedule list   # 스케줄 목록 및 데몬 상태 (각 스케줄을 카드로 표시: cron, 언제 실행되는지 설명, 다음 실행 시각 등)
+tp schedule add schedules.yaml  # 스케줄 파일에서 추가; 파일 경로 생략 시 가장 가까운 tp/schedules에서 선택
+tp schedule add    # 가장 가까운 tp/schedules 디렉토리에서 스케줄 파일 선택
+tp schedule remove # 스케줄 삭제; 삭제 후 삭제된 스케줄을 list와 동일한 카드 형식으로 표시
 tp schedule remove-all # 모든 스케줄 삭제
-tp schedule toggle # 스케줄 활성화/비활성화
+tp schedule toggle # 스케줄 활성화/비활성화; 토글 후 ENABLED/DISABLED를 굵게·색상으로 강조하고 스케줄 카드 표시
 tp schedule start  # 포그라운드 모드로 스케줄러 시작
 tp schedule start -d  # 백그라운드 데몬 모드로 스케줄러 시작
 tp schedule stop   # 스케줄러 데몬 종료
 tp schedule status # 데몬·스케줄 상태 확인 (실시간 모드; Ctrl+C는 화면만 종료, 데몬은 계속 실행)
 ```
+`tp schedule add`, `toggle`, `remove` 후에는 해당 스케줄이 `tp schedule list`와 같은 카드 레이아웃(크론, 언제 실행되는지 설명, 다음 실행, 활성 여부)으로 표시됩니다. 토글 후에는 ENABLED/DISABLED가 강조되어 새 상태를 한눈에 알 수 있습니다.
 
 **데이터 및 업그레이드:**
 ```bash
@@ -114,6 +122,13 @@ task-pipeliner run workflow.yaml
 tp run workflow.yaml
 ```
 
+설치 확인:
+```bash
+task-pipeliner --version
+# 또는
+tp --version
+```
+
 **업데이트:**
 ```bash
 # 먼저 Homebrew의 패키지 레지스트리를 업데이트합니다
@@ -144,6 +159,13 @@ task-pipeliner run workflow.yaml
 tp run workflow.yaml
 ```
 
+설치 확인:
+```bash
+task-pipeliner --version
+# 또는
+tp --version
+```
+
 **업데이트:**
 ```bash
 scoop update task-pipeliner
@@ -168,6 +190,13 @@ task-pipeliner run workflow.yaml
 tp run workflow.yaml
 ```
 
+설치 확인:
+```bash
+task-pipeliner --version
+# 또는
+tp --version
+```
+
 #### 프로젝트 설치 (개발 모드)
 
 프로젝트에 devDependency로 설치하면 `npx`로 사용할 수 있습니다:
@@ -195,7 +224,7 @@ npx tp run workflow.yaml
 name: My Workflow
 
 steps:
-  - run: echo "Hello, World!"
+  - run: 'echo "Hello, World!"'
   
   - choose:
       message: "무엇을 하시겠습니까?"
@@ -209,12 +238,12 @@ steps:
   - when:
       var:
         action: build
-    run: npm run build
+    run: 'npm run build'
   
   - when:
       var:
         action: test
-    run: npm test
+    run: 'npm test'
 ```
 
 **JSON 형식 (`workflow.json`):**
@@ -280,26 +309,31 @@ tp run workflow.yaml -s
 
 **`tp` 디렉토리 사용하기 (권장):**
 
-더 나은 조직화를 위해 프로젝트에 `tp` 디렉토리를 만들고 모든 워크플로우 파일을 그곳에 배치할 수 있습니다. 파일을 지정하지 않고 `tp run`을 실행하면 task-pipeliner가 자동으로 가장 가까운 `tp` 디렉토리(현재 디렉토리부터 시작하여 상위로 탐색)를 찾아 대화형으로 워크플로우를 선택할 수 있게 해줍니다.
+권장 프로젝트 구조는 `tp` 디렉토리 아래에 두 개의 하위 디렉토리를 두는 방식입니다.
+
+- **`tp/workflows/`** – 워크플로우 파일(YAML 또는 JSON). 파일 없이 `tp run`을 실행하면 task-pipeliner가 가장 가까운 `tp` 디렉토리를 찾고, **`tp/workflows/`** 안에서 실행할 워크플로우를 선택할 수 있게 합니다.
+- **`tp/schedules/`** – 스케줄 파일(YAML 또는 JSON). `tp schedule add` 실행 시 파일 경로를 주지 않으면 가장 가까운 **`tp/schedules/`** 안에서 스케줄 파일을 선택할 수 있습니다.
+
+**빠른 셋업:** 프로젝트 루트에서 `tp setup`을 실행하면 `tp/`, `tp/workflows/`, `tp/schedules/`가 생성되고, 예시 워크플로우 2개와 예시 스케줄 파일 2개(echo 기반, choose·when·profiles·prompt 및 스케줄 프로필 사용 예시 포함)가 추가됩니다. 이미 있는 파일은 덮어쓰지 않습니다.
 
 ```bash
-# tp 디렉토리를 만들고 워크플로우 파일 추가
-mkdir tp
-mv workflow.yaml tp/
+# 방법 1: tp setup 사용 (tp/workflows, tp/schedules + 예시 생성)
+tp setup
 
-# 파일을 지정하지 않고 실행 - 대화형 선택
+# 방법 2: 수동으로 구조 만들기
+mkdir -p tp/workflows tp/schedules
+mv workflow.yaml tp/workflows/
+
+# 파일 없이 실행 - tp/workflows에서 대화형 선택
 tp run
 ```
 
-이 기능은:
-1. 가장 가까운 `tp` 디렉토리를 찾습니다 (현재 디렉토리 또는 상위 디렉토리)
-2. 해당 디렉토리의 모든 워크플로우 파일 (`.yaml`, `.yml`, `.json`)을 나열합니다
-3. 다음 기능을 제공하는 대화형 검색 가능한 메뉴를 표시합니다:
-   - 타이핑하여 실시간으로 워크플로우 필터링
-   - 화살표 키 (↑↓)로 탐색
-   - Enter를 눌러 선택하고 실행
+파일을 지정하지 않고 `tp run`을 실행하면:
+1. 가장 가까운 `tp` 디렉토리를 찾습니다 (현재 디렉토리 또는 상위).
+2. **`tp/workflows/`** 안의 모든 워크플로우 파일 (`.yaml`, `.yml`, `.json`)을 나열합니다.
+3. 타이핑으로 필터, 화살표(↑↓)로 이동, Enter로 선택·실행하는 대화형 검색 메뉴를 띄웁니다.
 
-대화형 메뉴는 파일 이름과 워크플로우의 `name` (YAML/JSON 내용에서)을 모두 표시하여 쉽게 식별할 수 있습니다.
+메뉴에는 파일 이름과 워크플로우의 `name`(YAML/JSON)이 함께 표시되어 구분하기 쉽습니다.
 
 **사일런트 모드:**
 `--silent` (또는 `-s`) 플래그는 워크플로우 실행 중 모든 콘솔 출력을 억제합니다. 다음 경우에 유용합니다:
@@ -371,14 +405,13 @@ steps:                                 # 필수: 실행할 단계 배열
 - **타입**: `string` (상대 또는 절대 경로)
 - **설명**: 모든 명령 실행을 위한 기본 디렉토리
 - **해석**:
-  - **상대 경로** (예: `./`, `../frontend`): 워크플로우 파일의 디렉토리를 기준으로 해석
+  - **상대 경로** (예: `./`, `../frontend`): YAML 파일의 디렉토리를 기준으로 해석
   - **절대 경로** (예: `/home/user/project`): 그대로 사용
-  - **생략 시**: 워크플로우 파일의 디렉토리 사용 (스케줄 파일과 동일)
+  - **생략 시**: `process.cwd()` (현재 작업 디렉토리) 사용
 - **예제**:
   ```yaml
-  baseDir: ./frontend        # 워크플로우 파일 기준 상대 경로
+  baseDir: ./frontend        # YAML 파일 기준 상대 경로
   baseDir: /app/frontend     # 절대 경로
-  # 생략 시, 명령은 워크플로우 파일의 디렉토리에서 실행됨
   ```
 
 #### `shell` (선택)
@@ -476,12 +509,12 @@ steps:                                 # 필수: 실행할 단계 배열
 ```yaml
 # 간단한 명령
 steps:
-  - run: npm install
+  - run: 'npm install'
 
   # 조건이 있는 명령
   - when:
       file: ./package.json
-    run: npm install
+    run: 'npm install'
 
   # 변수 입력
   - choose:
@@ -496,55 +529,55 @@ steps:
       as: version
 
   # 변수 치환이 있는 명령
-  - run: echo "Building {{version}}"
+  - run: 'echo "Building {{version}}"'
 
   # 타임아웃이 있는 명령 (30초)
-  - run: npm install
+  - run: 'npm install'
     timeout: 30
 
   # 재시도가 있는 명령 (최대 3번 재시도)
-  - run: npm install
+  - run: 'npm install'
     retry: 3
 
   # 무한 재시도 명령 (성공할 때까지 재시도)
-  - run: npm install
+  - run: 'npm install'
     retry: Infinity
 
   # PM2처럼 프로세스 관리: 서버가 죽으면 자동 재시작
-  - run: node server.js
+  - run: 'node server.js'
     retry: Infinity
 
   # 타임아웃과 재시도 모두 사용
-  - run: npm install
+  - run: 'npm install'
     timeout: 60
     retry: 2
 
   # 실패 시 fallback 명령 실행
-  - run: pnpm lint
+  - run: 'pnpm lint'
     onError:
-      run: pnpm lint:fix
+      run: 'pnpm lint:fix'
 
   # 여러 단계로 이어지는 fallback 체인
-  - run: step1
+  - run: 'step1'
     onError:
-      run: step2
+      run: 'step2'
       onError:
-        run: step3
+        run: 'step3'
 
   # 실패를 기록만 하고 워크플로우는 계속 진행
-  - run: pnpm typecheck
+  - run: 'pnpm typecheck'
     continue: true
     onError:
-      run: echo "Type check failed, but continuing..."
+      run: 'echo "Type check failed, but continuing..."'
 
   # 커스텀 쉘 사용 (스텝별)
-  - run: echo $SHELL
+  - run: 'echo $SHELL'
     shell:
       - zsh
       - -c
 
   # bash 로그인 쉘 사용
-  - run: source ~/.bashrc && echo "프로필 로드됨"
+  - run: 'source ~/.bashrc && echo "프로필 로드됨"'
     shell:
       - bash
       - -lc
@@ -646,7 +679,7 @@ steps:
 - when:
     var:         # 변수를 사용한다는 정의
       env: prod  # 'env' 변수가 'prod'와 같은지 확인
-  run: echo "프로덕션에 배포 중"
+  run: 'echo "프로덕션에 배포 중"'
 ```
 
 ---
@@ -700,13 +733,13 @@ steps:
 **사용:**
 ```yaml
 # 명령에서 사용
-- run: echo "Building version {{version}}"
+- run: 'echo "Building version {{version}}"'
 
 # 조건에서 확인
 - when:
     var:
       version: "1.0.0"
-  run: echo "안정 버전 배포 중"
+  run: 'echo "안정 버전 배포 중"'
 ```
 
 ---
@@ -735,19 +768,19 @@ steps:
 # 기본 병렬 실행
 # parallel 내부의 각 step은 `-`로 시작하며, `steps`와 동일한 형식
 - parallel:
-    - run: npm run test:unit
-    - run: npm run test:integration
-    - run: npm run lint
+    - run: 'npm run test:unit'
+    - run: 'npm run test:integration'
+    - run: 'npm run lint'
 
 # 조건이 있는 병렬
 # 각 step은 자신만의 `when` 조건을 가질 수 있습니다
 - parallel:
     - when:
           file: ./src
-        run: echo "프론트엔드 빌드 중..."
+        run: 'echo "프론트엔드 빌드 중..."'
     - when:
           file: ./api
-        run: echo "백엔드 빌드 중..."
+        run: 'echo "백엔드 빌드 중..."'
 
 # 조건부 병렬 블록
 # 전체 parallel 블록에 `when` 조건을 적용할 수 있습니다
@@ -755,15 +788,15 @@ steps:
     var:
       env: staging
   parallel:
-    - run: npm run test
-    - run: npm run lint
+    - run: 'npm run test'
+    - run: 'npm run lint'
 
 # 중첩 parallel (허용); parallel 내부에는 run / parallel / fail만 사용
 - parallel:
-    - run: npm run test
+    - run: 'npm run test'
     - parallel:
-        - run: npm run lint
-        - run: npm run typecheck
+        - run: 'npm run lint'
+        - run: 'npm run typecheck'
 ```
 
 **동작:**
@@ -837,16 +870,16 @@ when:
 ```yaml
 - when:
     file: ./dist
-  run: echo "빌드가 존재합니다"
+  run: 'echo "빌드가 존재합니다"'
 
 - when:
     file: ./package.json
-  run: npm install
+  run: 'npm install'
 
 - when:
     not:
       file: ./node_modules
-  run: npm install
+  run: 'npm install'
 ```
 
 **동작:**
@@ -877,20 +910,20 @@ when:
 - when:
     var:
       env: prod
-  run: echo "프로덕션에 배포 중"
+  run: 'echo "프로덕션에 배포 중"'
 
 # version이 특정 값과 같은지 확인
 - when:
     var:
       version: "1.0.0"
-  run: echo "안정 버전 배포 중"
+  run: 'echo "안정 버전 배포 중"'
 
 # 여러 변수 확인 (모두 일치해야 함)
 - when:
     var:
       env: staging
       version: "2.0.0"
-  run: echo "스테이징에 v2.0.0 배포 중"
+  run: 'echo "스테이징에 v2.0.0 배포 중"'
 ```
 
 **동작:**
@@ -922,12 +955,12 @@ when:
 # 변수가 존재하는지 확인
 - when:
     var: version
-  run: echo "Version: {{version}}"
+  run: 'echo "Version: {{version}}"'
 
 # 'has' 별칭 사용
 - when:
     has: projectName
-  run: echo "Project: {{projectName}}"
+  run: 'echo "Project: {{projectName}}"'
 ```
 
 **동작:**
@@ -961,7 +994,7 @@ when:
       - file: ./dist
       - var:
           env: production
-  run: echo "프로덕션 빌드 준비 완료"
+  run: 'echo "프로덕션 빌드 준비 완료"'
 
 - when:
     all:
@@ -970,7 +1003,7 @@ when:
       - var:
           version: "2.0.0"
       - file: ./dist
-  run: echo "스테이징에 v2.0.0 배포 중"
+  run: 'echo "스테이징에 v2.0.0 배포 중"'
 ```
 
 **동작:**
@@ -1001,13 +1034,13 @@ when:
           env: staging
       - var:
           env: production
-  run: echo "서버에 배포 중"
+  run: 'echo "서버에 배포 중"'
 
 - when:
     any:
       - file: ./dist
       - file: ./build
-  run: echo "빌드 출력을 찾았습니다"
+  run: 'echo "빌드 출력을 찾았습니다"'
 ```
 
 **동작:**
@@ -1042,7 +1075,7 @@ when:
     not:
       var:
         env: prod
-  run: echo "프로덕션 환경이 아닙니다"
+  run: 'echo "프로덕션 환경이 아닙니다"'
 
 # 복잡한 부정
 - when:
@@ -1051,7 +1084,7 @@ when:
         - file: ./dist
         - var:
             env: prod
-  run: echo "프로덕션 준비가 되지 않았습니다"
+  run: 'echo "프로덕션 준비가 되지 않았습니다"'
 ```
 
 **동작:**
@@ -1079,7 +1112,7 @@ when:
       - not:
           var:
             version: "0.0.0"
-  run: echo "배포 준비 완료"
+  run: 'echo "배포 준비 완료"'
 
 # 여러 수준의 중첩
 - when:
@@ -1093,7 +1126,7 @@ when:
               env: staging
           - not:
               file: ./test-results
-  run: echo "조건부 배포"
+  run: 'echo "조건부 배포"'
 ```
 
 ---
@@ -1104,9 +1137,9 @@ when:
 
 **문법:**
 ```yaml
-run: echo "{{variableName}}"
+run: 'echo "{{variableName}}"'
 # 또는 선택적으로 공백 사용
-run: echo "{{ variableName }}"
+run: 'echo "{{ variableName }}"'
 ```
 
 **⚠️ 중요: YAML 문법 규칙**
@@ -1115,9 +1148,9 @@ run: echo "{{ variableName }}"
 
 ✅ **안전한 패턴:**
 ```yaml
-# 단어로 시작 (따옴표 불필요)
-- run: echo "Building {{version}}..."
-- run: npm run build --version={{version}}
+# 작은따옴표로 감싸기 (권장)
+- run: 'echo "Building {{version}}..."'
+- run: 'npm run build --version={{version}}'
 
 # 전체 명령어를 작은따옴표로 감싸기
 - run: 'echo "Selected: {{mode}}"'
@@ -1138,7 +1171,7 @@ run: echo "{{ variableName }}"
 - prompt:
     message: "프로젝트 이름을 입력하세요:"
     as: projectName
-- run: echo "Building {{projectName}}..."
+- run: 'echo "Building {{projectName}}..."'
 
 # 선택 변수 사용
 - choose:
@@ -1147,10 +1180,10 @@ run: echo "{{ variableName }}"
       - id: dev
         label: "개발"
     as: env
-- run: echo "Deploying to {{env}}"
+- run: 'echo "Deploying to {{env}}"'
 
 # 여러 변수
-- run: echo "Building {{projectName}} version {{version}} for {{env}}"
+- run: 'echo "Building {{projectName}} version {{version}} for {{env}}"'
 ```
 
 **동작:**
@@ -1170,7 +1203,7 @@ baseDir: ./
 
 steps:
   # 1. 간단한 명령
-  - run: echo "워크플로우 시작 중..."
+  - run: 'echo "워크플로우 시작 중..."'
 
   # 2. 변수 저장이 있는 사용자 선택
   - choose:
@@ -1196,12 +1229,12 @@ steps:
   - when:
       var:
         env: dev
-    run: echo "개발 환경에 배포 중..."
+    run: 'echo "개발 환경에 배포 중..."'
 
   - when:
       var:
         env: staging
-    run: echo "스테이징에 배포 중..."
+    run: 'echo "스테이징에 배포 중..."'
 
   # 5. 복잡한 조건 (all)
   - when:
@@ -1210,22 +1243,22 @@ steps:
             env: prod
         - var: deployReason
         - file: ./dist
-    run: echo "프로덕션 배포 승인됨"
+    run: 'echo "프로덕션 배포 승인됨"'
 
   # 6. 병렬 실행
   - parallel:
-      - run: npm run test:unit
-      - run: npm run test:integration
-      - run: npm run lint
+      - run: 'npm run test:unit'
+      - run: 'npm run test:integration'
+      - run: 'npm run lint'
 
   # 6.5. 스텝별 쉘 오버라이드
-  - run: echo "zsh로 실행"
+  - run: 'echo "zsh로 실행"'
     shell: [zsh, -c]  # 이 스텝만 워크플로우 쉘 오버라이드
 
   # 7. 파일 존재 확인
   - when:
       file: ./test-results
-    run: echo "테스트 완료"
+    run: 'echo "테스트 완료"'
 
   # 8. 결합된 조건 (any)
   - when:
@@ -1234,7 +1267,7 @@ steps:
             env: staging
         - var:
             env: prod
-    run: echo "서버에 배포 중..."
+    run: 'echo "서버에 배포 중..."'
 
   # 9. 부정
   - when:
@@ -1244,7 +1277,7 @@ steps:
       message: "빌드 출력을 찾을 수 없습니다"
 
   # 10. 변수 치환
-  - run: echo "Deploying {{projectName}} version {{version}} to {{env}}"
+  - run: 'echo "Deploying {{projectName}} version {{version}} to {{env}}"'
 ```
 
 ---
@@ -1430,9 +1463,11 @@ schedules:
 
 ```bash
 tp schedule add schedules.yaml
+# 또는 경로 없이: 가장 가까운 tp/schedules/에서 파일 선택
+tp schedule add
 ```
 
-각 스케줄에 대해 별칭을 확인하거나 변경할 수 있습니다
+각 스케줄에 대해 별칭을 확인하거나 변경할 수 있습니다. 추가 후에는 추가된 스케줄이 `tp schedule list`와 같은 카드 형식(크론, 언제 실행되는지 설명, 다음 실행, 활성 여부)으로 표시됩니다.
 
 **Cron 표현식 형식:**
 
@@ -1465,19 +1500,21 @@ tp schedule add schedules.yaml
 ### 스케줄 관리
 
 ```bash
-# 모든 스케줄 목록 보기
+# 모든 스케줄 목록 보기 (카드 레이아웃: cron, "언제" 설명, 다음 실행 등)
 tp schedule list
 
-# 스케줄 삭제
+# 스케줄 삭제 (삭제 후 삭제된 스케줄을 동일한 카드 형식으로 표시)
 tp schedule remove
 
 # 모든 스케줄 삭제
 tp schedule remove-all
 
-# 스케줄 활성화/비활성화
+# 스케줄 활성화/비활성화 (토글 후 ENABLED/DISABLED를 굵게·색상으로 강조하고 스케줄 카드 표시)
 tp schedule toggle
 ```
 
+**통일된 스케줄 UI:** list, add, toggle, remove 모두 동일한 스케줄 카드 레이아웃을 사용합니다. 각 카드에는 크론 표현식, 언제 실행되는지 사람이 읽기 쉬운 설명(예: "매분"), 타임존, 워크플로우 경로, 프로필(설정 시), 마지막 실행, 다음 실행이 표시됩니다. `tp schedule toggle` 후에는 새 상태(ENABLED는 초록, DISABLED는 회색)가 강조되어 한눈에 구분할 수 있습니다.
+
 ### 스케줄러 실행
 
 예약된 시간에 워크플로우를 실행하려면 스케줄러를 시작하세요. 두 가지 모드로 실행할 수 있습니다:
@@ -1532,6 +1569,7 @@ tp schedule status -n   # 한 번만 표시 후 종료 (갱신 없음)
 
 완전한 프로젝트 예제는 `examples/` 디렉토리를 확인하세요:
 
+- **`tp setup`** – 프로젝트 루트에서 `tp setup`을 실행하면 `tp/workflows/`, `tp/schedules/`와 예시 워크플로우 2개(choose, when, profiles, prompt), 예시 스케줄 파일 2개(프로필 사용 포함)가 생성됩니다. 모든 단계는 `echo`로 되어 있어 안전하게 실행한 뒤 실제 명령으로 바꿀 수 있습니다.
 - **`monorepo-example/`** - 여러 프로젝트가 있는 모노레포 워크플로우
 - **`simple-project/`** - 간단한 단일 프로젝트 워크플로우
 - **`react-app/`** - React 애플리케이션 빌드 및 배포