스킬 슬림화: 스캐폴딩 시 중복되던 assets 제거 → SKILL.md만. 템플릿은 루트/스타터 레포가 단일 소스

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.claude/skills/yakcloud-deploy/SKILL.md

@@ -8,12 +8,13 @@ description: Scaffold and wire up YakCloud declarative CI/CD for a project — G
 VS Code로 개발 → 커밋 → **`v*` 태그 push** 하면, Gitea Actions가 이미지를 빌드/푸시하고
 YakCloud 콘솔 API로 **데이터소스 리컨실 + 워크로드 배포 + 바인딩**을 자동 처리한다.
 
-이 스킬은 **아무 프로젝트에나 이 파이프라인을 심는다.** 번들된 자산(`assets/`)을 프로젝트에 복사하고
-매니페스트를 채운 뒤, 1회 시크릿만 설정하면 끝. 빈 프로젝트면 프레임워크 중립 **스타터**로 바로 시작.
+이 스킬은 **아무 프로젝트에나 이 파이프라인을 심는다.** `yakcloud` CLI(권장) 또는 스타터 레포로
+스캐폴딩하고, 매니페스트를 채운 뒤 1회 시크릿만 설정하면 끝. 빈 프로젝트면 프레임워크 중립 **스타터**로 바로 시작.
+> 이 스킬은 **번들 파일을 두지 않는다**(SKILL.md 하나). 실제 템플릿은 CLI 또는 스타터 레포(`yakenator/yakcloud-starter`)에서 온다.
 
 ## 언제 쓰나
 - "이 프로젝트를 YakCloud에 배포/자동화" / "Gitea CI/CD 붙여줘" / "yakcloud.yaml 만들어줘"
-- "새 프로젝트 시작해서 배포까지" (→ `assets/starter/` 로 스캐폴딩)
+- "새 프로젝트 시작해서 배포까지" (→ `yakcloud project init`)
 - "데이터소스(Postgres/Mongo/…) 연결/바인딩" / "커스텀 도메인으로 노출"
 
 ## CLI 가 있으면 우선 사용
@@ -39,24 +40,24 @@ CLI 가 없거나 세밀 조정이 필요하면 아래 수동 절차를 따른
 ## 에이전트 실행 절차
 
 ### 0) 상황 파악
-- git 레포인지, 앱 코드가 이미 있는지 확인. **빈/신규**면 §1-A(스타터), **기존 앱**이면 §1-B.
-- Gitea 원격이 있는지(`git remote -v`) 확인. 없으면 사용자에게 Gitea 레포 URL을 물어 추가하도록 안내.
+- 이미 `yakcloud project init` 으로 스캐폴딩된 프로젝트면 루트에 `yakcloud.yaml`·`scripts/`·`.gitea/`·`app.py` 가 이미 있다 → 바로 §3 이후로.
+- 빈/신규면 §1, 기존 앱이면 §1-B. Gitea 원격 여부(`git remote -v`)도 확인(없으면 사용자에게 레포 URL 요청).
 
-### 1-A) 신규 — 스타터로 스캐폴딩
-1. `assets/starter/`(app.py·Dockerfile·README) 를 프로젝트 루트에 복사. (프레임워크 무의존 최소 HTTP 서버: `PORT` 리슨, `/healthz` 200, `/` 는 바인딩된 소스의 `<PREFIX>_URL` 키만 표시)
-2. 아래 §2 공통 파일 복사 + §3 매니페스트 작성.
+### 1) 스캐폴딩 (신규/빈 프로젝트)
+- **CLI 있으면(권장)**: `yakcloud project init [name]` — 앱·CI·매니페스트·이 스킬을 한 번에 생성.
+- **CLI 없으면**: `install.sh` 로 CLI 설치 후 init, 또는 스타터 레포에서 루트 파일을 복사:
+  ```sh
+  git clone --depth 1 https://gitea.yakenator.io/yakenator/yakcloud-starter .yc-tmp
+  cp -R .yc-tmp/app.py .yc-tmp/Dockerfile .yc-tmp/yakcloud.yaml .yc-tmp/scripts .yc-tmp/DATA-SOURCES.md .
+  cp -R .yc-tmp/.gitea . && rm -rf .yc-tmp
+  ```
+  스타터 앱 = 프레임워크 무의존 최소 HTTP 서버(`PORT` 리슨, `/healthz` 200). 이후 §3 매니페스트 작성.
 
 ### 1-B) 기존 앱에 부착
 1. 앱이 **`PORT` env로 리슨 + `/healthz`(또는 health 경로) 제공**하는지 확인. 없으면 추가 제안.
-2. 앱이 데이터소스 접속정보를 **하드코딩하지 말고 주입 env**(`<ALIAS>_URL` 등)로 읽도록 수정 제안. 키 규약: `reference/DATA-SOURCES.md`.
-3. 각 배포 단위마다 `Dockerfile` 필요(없으면 언어에 맞게 생성). 베이스 이미지는 Gitea 미러(`gitea.yakenator.io/yakenator/{node,python,...}`) 권장.
-
-### 2) 공통 파일 복사 (모든 경우)
-프로젝트 루트에 그대로 복사:
-- `assets/yakcloud.yaml`              → `./yakcloud.yaml`            (매니페스트 — §3에서 채움)
-- `assets/workflows/deploy.yml`       → `./.gitea/workflows/deploy.yml`  (매니페스트 구동형 CI — **수정 불필요**)
-- `assets/scripts/yakcloud_deploy.py` → `./scripts/yakcloud_deploy.py`   (리컨실 배포 CLI — 그대로)
-- `assets/reference/DATA-SOURCES.md`  → `./DATA-SOURCES.md`          (선택 — 소스별 주입 env 표)
+2. 데이터소스 접속정보를 **하드코딩하지 말고 주입 env**(`<ALIAS>_URL` 등)로 읽도록 수정 제안. 키 규약: 루트 `DATA-SOURCES.md`(스타터에서 복사).
+3. 각 배포 단위마다 `Dockerfile` 필요(없으면 언어에 맞게 생성). 베이스 이미지는 Gitea 미러(`gitea.yakenator.io/yakenator/{node,python,...}`).
+4. CI/배포 플러밍(`scripts/yakcloud_deploy.py`·`scripts/yakcloud_ctl.py`·`.gitea/workflows/deploy.yml`·`yakcloud.yaml`)은 §1 처럼 스타터 레포에서 복사(또는 `yakcloud project init` 이 대신 처리).
 
 ### 3) 매니페스트(`yakcloud.yaml`) 채우기 (핵심)
 사용자와 함께 값을 정한다: