lee-spec-kit 0.4.13 → 0.4.14

package/README.en.md

@@ -169,6 +169,7 @@ Running `init` creates `.lee-spec-kit.json` in your docs root (default: `docs/`)
   "lang": "en",
   "createdAt": "YYYY-MM-DD",
   "docsRepo": "embedded",
+  "pr": { "screenshots": { "upload": false } },
   "approval": { "mode": "builtin" }
 }
 ```
@@ -183,6 +184,7 @@ Running `init` creates `.lee-spec-kit.json` in your docs root (default: `docs/`)
 | `pushDocs`    | (standalone only) whether to manage/push docs repo as a separate git repo |
 | `docsRemote`  | (standalone + pushDocs) docs repo remote URL |
 | `projectRoot` | (standalone only) project repo path (single: string, fullstack: {fe, be}) |
+| `pr`          | (optional) PR artifacts policy (e.g. screenshot upload) |
 | `approval`    | (optional) Override CHECK-required policy in `context` output (for automation/semi-auto) |
 
 > In standalone mode, `init` can add `pushDocs`, `docsRemote`, and `projectRoot` to this config.
@@ -233,6 +235,10 @@ Running `init` creates `.lee-spec-kit.json` in your docs root (default: `docs/`)
 
 > To discover available `category` values, check `actions[].category` in `context --json`.
 
+### pr (PR artifacts policy)
+
+- `pr.screenshots.upload` (default: `false`): When `true`, agents may upload screenshots (e.g. GitHub Release assets) and include URLs in PR body. When `false`, agents should not upload/include URLs and should omit screenshot sections from the PR body.
+
 ## Generated Structure
 
 See the Korean README for the full tree examples and workflow details: `README.md`.

package/README.md

@@ -214,6 +214,7 @@ npx lee-spec-kit update --force
   "lang": "ko",
   "createdAt": "YYYY-MM-DD",
   "docsRepo": "embedded",
+  "pr": { "screenshots": { "upload": false } },
   "approval": { "mode": "builtin" }
 }
 ```
@@ -228,6 +229,7 @@ npx lee-spec-kit update --force
 | `pushDocs`    | (standalone만) docs 레포를 별도 Git으로 관리/푸시할지 여부 |
 | `docsRemote`  | (standalone+pushDocs) docs 레포 remote URL |
 | `projectRoot` | (standalone만) 프로젝트 레포지토리 경로 (single: string, fullstack: {fe, be}) |
+| `pr`          | (선택) PR 결과물 정책 (예: 스크린샷 업로드 여부) |
 | `approval`    | (선택) `context` 출력의 `[확인 필요]`/`requiresUserCheck` 정책 오버라이드 (자동화/반자동용) |
 
 > `docsRepo: "standalone"`을 선택하면 `pushDocs`, `docsRemote`, `projectRoot`가 추가됩니다.
@@ -280,6 +282,10 @@ npx lee-spec-kit update --force
 
 > 사용 가능한 `category` 값은 `context --json`의 `actions[].category`로 확인하는 것을 권장합니다.
 
+### pr (PR 결과물 정책)
+
+- `pr.screenshots.upload` (기본: `false`): `true`면 스크린샷을 업로드(예: GitHub Release assets)하고 PR 본문에 URL을 포함할 수 있습니다. `false`면 업로드/URL 포함을 하지 않으며 PR 본문에서도 스크린샷 섹션을 만들지 않는 것을 권장합니다.
+
 ### Standalone 프로젝트 설정 예시
 
 **Single 프로젝트:**

package/dist/index.js

@@ -836,6 +836,9 @@ async function runInit(options) {
     lang,
     createdAt: (/* @__PURE__ */ new Date()).toISOString().split("T")[0],
     docsRepo,
+    pr: {
+      screenshots: { upload: false }
+    },
     // Approval policy for "requiresUserCheck" actions shown by `context`.
     // - builtin (default): Use requiresUserCheck embedded in steps/actions.
     // - category: Override by action category (recommended for automation).
@@ -965,6 +968,7 @@ async function getConfig(cwd) {
             pushDocs: configFile.pushDocs,
             docsRemote: configFile.docsRemote,
             projectRoot: configFile.projectRoot,
+            pr: configFile.pr,
             approval: configFile.approval
           };
         } catch {
@@ -2761,6 +2765,11 @@ async function runContext(featureName, options) {
         token: "OK",
         config: config.approval ?? { mode: "builtin" }
       },
+      prPolicy: {
+        screenshots: {
+          upload: config.pr?.screenshots?.upload ?? false
+        }
+      },
       recommendation: ""
     };
     if (result.status === "multiple_active") {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lee-spec-kit",
-  "version": "0.4.13",
+  "version": "0.4.14",
   "description": "Project documentation structure generator for AI-assisted development",
   "type": "module",
   "bin": {

package/templates/en/common/agents/pr-template.md

@@ -25,6 +25,11 @@ For file links within the repo in PR body, **always use current branch name**:
 > ⚠️ `main` branch links will return 404 until merged!
 > Always use the **current feature branch name** (e.g., `feat/5-feature-name`).
 
+### Labels (Required)
+
+- PRs must have **at least 1 label**. (cannot be empty)
+- If you're unsure which label to use, confirm with the user before creating the PR.
+
 ---
 
 ## PR Body Template
@@ -59,6 +64,7 @@ For file links within the repo in PR body, **always use current branch name**:
 
 ## Screenshots (Frontend / UI changes)
 
+<!-- If there are no UI changes, or if screenshot upload is disabled (e.g. `.lee-spec-kit.json` has `pr.screenshots.upload: false`), remove this section. -->
 > If you follow the Release assets upload flow in `skills/create-pr.md`, you can include images in the PR body without committing files to your branch.
 
 {Screenshot markdown (e.g. ![](URL))}
@@ -66,12 +72,18 @@ For file links within the repo in PR body, **always use current branch name**:
 ## Architecture Diagram (Backend / core structure changes)
 
 ```mermaid
-flowchart TD
+sequenceDiagram
   %% Guidelines:
-  %% - Focus on components/modules/data flow (structure/flow)
-  %% - Keep it small (≤ 12 nodes recommended); summarize/split if needed
-  A[Client] --> B[API]
-  B --> C[DB]
+  %% - Express the key "request → processing → storage/response" flow in time order
+  %% - Keep participants ≤ 6
+  %% - Keep messages ≤ 12; summarize/split if needed
+  participant Client as Client
+  participant API as API
+  participant DB as DB
+  Client->>API: Request
+  API->>DB: Query/Command
+  DB-->>API: Result
+  API-->>Client: Response
 ```
 
 ## Related Documents

package/templates/en/common/agents/skills/create-feature.md

@@ -37,22 +37,8 @@ After completing the action, go back to Step 1 and run `context` again.
 2. **Do not skip**: Do not fake issue numbers/statuses to advance steps.
 3. **No self-judgment**: If unsure, run `context` again.
 
----
-
-## Reference: the 10-step workflow (reference only)
-
-> ⚠️ Do NOT execute these from memory. Always follow the CLI.
-
-1. Feature folder created
-2. Write `spec.md`
-3. Get `spec.md` approved
-4. Create GitHub Issue and record `#`
-5. Create feature branch
-6. Write `plan.md`
-7. Get `plan.md` approved
-8. Write/approve/execute `tasks.md` (Doc Status: Review → Approved)
-9. Pre-commit verification
-10. Commit docs
+> Note: the workflow steps may change over time. Do not memorize step numbers.
+> Treat `context` output as the SSOT.
 
 ---
 

package/templates/en/common/agents/skills/create-pr.md

@@ -23,16 +23,18 @@ Guide for creating Pull Requests.
 | -------- | ---------------------------------- |
 | Title    | `feat(#{issue-number}): {feature} ({short description})` |
 | Body     | Overview, Changes, Tests, Docs     |
-| Labels   | Appropriate labels                 |
+| Labels   | **At least 1 required** (cannot be empty) |
 | Assignee | `@me` (default)                    |
 
+> ⚠️ Labels cannot be empty. If you’re unsure which label to use, ask/confirm with the user before creating the PR.
+
 ### 2. Test Verification
 
 > 🚨 **PR cannot be created if tests fail**
 
 1. Run relevant test commands (e.g., `npm test`, `pnpm test`); if no tests exist, request them from the user
 2. Check results (PASS/FAIL)
-3. In the PR body "Tests" section, add **only the tests you actually ran** as checklist items and ensure they are **all checked ([x])** (do not include unexecuted tests)
+3. In the PR body "Tests" section, follow `pr-template.md` rules as-is. (add/check only what you actually ran)
 4. If you didn’t run any tests, request/confirm with the user before creating the PR
 
 ### 3. Prepare Screenshots / Diagrams (Include in PR Body)
@@ -44,6 +46,8 @@ Include the artifacts in the PR body.
 
 #### UI changes (Frontend PR)
 
+- Default is `pr.screenshots.upload: false`. If you need upload/URL inclusion, enable it in `.lee-spec-kit.json`.
+- If `.lee-spec-kit.json` has `pr.screenshots.upload: false`, **do not upload/include URLs**, and **do not include a "Screenshots" section** in the PR body.
 - Use `agent-browser` to generate screenshots.
 - Save files under a local temp folder (`/tmp/lee-spec-kit/pr-assets/`).
 - Upload them as Release assets, then put the image URLs into the "Screenshots" section of the PR body.
@@ -87,6 +91,7 @@ kill \"$DEV_PID\" >/dev/null 2>&1 || true
 
 ```bash
 # Upload to Release assets and generate the URL to paste into the PR body
+# - If `.lee-spec-kit.json` has `pr.screenshots.upload: false`, skip this section.
 REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
 SAFE_BRANCH=$(git branch --show-current | tr '/' '-')
 TAG="pr-assets/${SAFE_BRANCH}"
@@ -101,10 +106,7 @@ echo \"![](https://github.com/${REPO}/releases/download/${TAG}/ui-1.png)\"
 
 #### Logic/structure changes (Backend PR)
 
-- Write a Mermaid diagram in the PR body (see the "Architecture Diagram" section in `pr-template.md`).
-- Default to **`flowchart TD`** (CodeRabbit-style).
-- Focus on components/modules/data flow (structure/flow over implementation detail).
-- Keep it small: **≤ 12 nodes** recommended (summarize or split if it gets too big).
+- Write a Mermaid **`sequenceDiagram`** in the PR body (follow the "Architecture Diagram" rules in `pr-template.md` as-is).
 
 ### 4. Request User Approval
 
@@ -114,7 +116,7 @@ Before creating PR, share the following **in a code block** and wait for **expli
 
 - Title
 - Full body (`pr-template.md` format)
-- Labels
+- Labels (at least 1; cannot be empty)
 
 ### 5. Create PR
 
@@ -122,6 +124,7 @@ Before creating PR, share the following **in a code block** and wait for **expli
 gh pr create \
   --title "feat(#{issue-number}): {feature} ({short description})" \
   --body-file /tmp/pr-body.md \
+  --label "{label1,label2}" \
   --assignee @me \
   --base main
 ```

package/templates/en/common/agents/skills/execute-task.md

@@ -20,8 +20,7 @@ npx lee-spec-kit context
 Execute the `👉 Next Action` exactly as printed by the CLI.
 
 - If the CLI points to an active task, focus on that task only.
-- If there is no active task, **share the task title and get user approval (OK)**, then switch the next `[TODO]` task to `[DOING]` and start.
-- For **[DOING] → [DONE]**: before marking it `[DONE]`, **share the outcome/changes/verification (including tests)** and get user approval (OK). (Do not mark DONE first.)
+- Treat the task state/approval rules in `tasks.md` **"Task Rules"** as SSOT (e.g. when OK is required for `[TODO]→[DOING]`, `[DOING]→[DONE]`).
 - If the CLI prints commands, copy/paste them. (In standalone setups commands may include `git -C ...` and scopes like `project`/`docs`.)
 
 ### Step 3: Update tasks.md (only what you did)

package/templates/ko/common/agents/pr-template.md

@@ -25,6 +25,11 @@ PR 본문에서 레포 내 파일 링크는 **반드시 현재 브랜치명을
 > ⚠️ `main` 브랜치 링크는 머지 전까지 404가 발생합니다!
 > 반드시 **현재 피처 브랜치명** (예: `feat/5-feature-name`)을 사용하세요.
 
+### 라벨 (필수)
+
+- PR에는 **최소 1개 라벨이 반드시 필요**합니다. (비워둘 수 없음)
+- 어떤 라벨을 써야 할지 확신이 없으면 PR 생성 전에 사용자에게 확인하세요.
+
 ## PR 본문 템플릿
 
 ```markdown
@@ -57,6 +62,7 @@ PR 본문에서 레포 내 파일 링크는 **반드시 현재 브랜치명을
 
 ## 스크린샷 (프론트엔드 / UI 변경 시)
 
+<!-- UI 변경이 아니거나, 스크린샷을 업로드하지 않았다면(예: `.lee-spec-kit.json`의 `pr.screenshots.upload: false`) 이 섹션은 제거하세요. -->
 > `skills/create-pr.md`의 Release assets 업로드 절차를 사용하면 브랜치에 파일을 커밋하지 않고도 이미지를 본문에 포함할 수 있습니다.
 
 {스크린샷 마크다운 (예: ![](URL))}
@@ -64,12 +70,18 @@ PR 본문에서 레포 내 파일 링크는 **반드시 현재 브랜치명을
 ## 아키텍처 다이어그램 (백엔드 / 핵심 구조 변경 시)
 
 ```mermaid
-flowchart TD
+sequenceDiagram
   %% 가이드:
-  %% - 컴포넌트/모듈/데이터 흐름 중심 (구조/흐름)
-  %% - 노드 수 12개 이내 권장 (너무 크면 핵심만 남기고 요약/분리)
-  A[Client] --> B[API]
-  B --> C[DB]
+  %% - 핵심 "요청→처리→저장/응답" 흐름을 시간 순서로 표현
+  %% - 참여자(participant)는 6개 이내 권장
+  %% - 메시지는 12개 이내 권장 (너무 길면 핵심만 남기고 요약/분리)
+  participant Client as Client
+  participant API as API
+  participant DB as DB
+  Client->>API: Request
+  API->>DB: Query/Command
+  DB-->>API: Result
+  API-->>Client: Response
 ```
 
 ## 관련 문서

package/templates/ko/common/agents/skills/create-feature.md

@@ -38,22 +38,8 @@ CLI가 출력하는 **`👉 Next Action` 메시지를 읽고, 그 지시만 정
 2. **건너뛰지 않기**: "이슈 생성" 단계를 귀찮아서 생략하거나 가짜 번호를 넣지 마세요.
 3. **스스로 판단 금지**: "이 정도면 됐겠지?"라고 생각하지 말고 CLI에게 물어보세요.
 
----
-
-## 참조: CLI가 안내하는 10단계 (참조용)
-
-> ⚠️ 이 단계를 외워서 실행하지 마세요. **참조용**일 뿐입니다. 항상 CLI를 믿으세요.
-
-1. **Feature 폴더 생성**: `npx lee-spec-kit feature ...`
-2. **spec.md 작성**: 기능 정의 (작성 후 Status: Review로 설정)
-3. **spec.md 승인**: 사용자 검토 및 승인 (Status: Approved)
-4. **GitHub Issue 생성**: 이슈 번호 발급
-5. **브랜치 생성**: `git checkout -b feat/...`
-6. **plan.md 작성**: 구현 계획 (작성 후 Status: Review로 설정)
-7. **plan.md 승인**: 사용자 검토 및 승인 (Status: Approved)
-8. **tasks.md 작성/승인**: 태스크 분해 및 진행 (문서 상태: Review → Approved)
-9. **문서 커밋 전 확인**: 최종 점검
-10. **문서 커밋**: Docs Sync
+> 참고: 워크플로우 단계는 변경될 수 있으므로, “단계 번호”를 외우지 마세요.
+> **항상 `context` 출력만**을 SSOT로 따르세요.
 
 ---
 

package/templates/ko/common/agents/skills/create-pr.md

@@ -23,16 +23,18 @@ Pull Request를 생성할 때 따르는 가이드입니다.
 | ------ | ---------------------------------- |
 | 제목   | `feat(#{이슈번호}): {기능명} ({짧은 설명})` |
 | 본문   | 개요, 변경 사항, 테스트, 관련 문서 |
-| 라벨   | 적절한 라벨 지정                   |
+| 라벨   | **최소 1개 필수** (비워둘 수 없음) |
 | 담당자 | `@me` (기본값)                     |
 
+> ⚠️ 라벨을 비워둘 수 없습니다. 적절한 라벨이 없거나 확신이 없다면, PR 생성 전에 사용자에게 라벨을 요청/확인하세요.
+
 ### 2. 테스트 검증
 
 > 🚨 **테스트 미통과 시 PR 생성 불가**
 
 1. 작업과 관련된 테스트 명령어 실행 (예: `npm test`, `pnpm test`), 테스트가 없는 경우 사용자에게 요청
 2. 결과 확인 (PASS/FAIL)
-3. PR 본문 "테스트" 섹션에 **실행한 테스트만** 체크리스트로 추가하고, **모두 체크([x])** 합니다. (미실행 항목은 작성하지 않기)
+3. PR 본문 "테스트" 섹션은 `pr-template.md`의 규칙을 그대로 따릅니다. (실행한 테스트만 추가/체크)
 4. 테스트를 실행하지 않았다면, PR 생성 전에 사용자에게 요청/확인합니다.
 
 ### 3. 스크린샷/다이어그램 작성 (PR 본문에 포함)
@@ -44,6 +46,8 @@ PR 본문에 결과물을 포함합니다.
 
 #### UI 변경 (프론트엔드 PR)
 
+- 기본값은 `pr.screenshots.upload: false`입니다. 업로드/URL 포함이 필요하다면 `.lee-spec-kit.json`에서 `true`로 켜세요.
+- `.lee-spec-kit.json`에서 `pr.screenshots.upload: false`라면 **업로드/URL 포함을 하지 않으며**, PR 본문에서도 **"스크린샷" 섹션을 만들지 않습니다.**
 - `agent-browser`로 스크린샷을 생성합니다.
 - 스크린샷 파일은 로컬 임시 폴더(`/tmp/lee-spec-kit/pr-assets/`)에 저장합니다.
 - 릴리스 자산(Release assets)으로 업로드한 뒤, 생성된 이미지 URL을 PR 본문 "스크린샷" 섹션에 넣습니다.
@@ -87,6 +91,7 @@ kill \"$DEV_PID\" >/dev/null 2>&1 || true
 
 ```bash
 # 스크린샷을 Release assets로 업로드하고, PR 본문에 넣을 URL 만들기
+# - `.lee-spec-kit.json`에서 `pr.screenshots.upload: false`라면 이 단계는 생략합니다.
 REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
 SAFE_BRANCH=$(git branch --show-current | tr '/' '-')
 TAG="pr-assets/${SAFE_BRANCH}"
@@ -101,10 +106,7 @@ echo \"![](https://github.com/${REPO}/releases/download/${TAG}/ui-1.png)\"
 
 #### 로직/구조 변경 (백엔드 PR)
 
-- PR 본문에 Mermaid 다이어그램을 작성합니다. (`pr-template.md`의 "아키텍처 다이어그램" 섹션 참고)
-- 기본은 **`flowchart TD`** 를 사용합니다. (코드래빗 스타일)
-- 컴포넌트/모듈/데이터 흐름 중심으로 그립니다. (구현 디테일보다 “구조/흐름”)
-- 노드 수는 **12개 이내**를 권장합니다. (너무 크면 핵심만 남기고 분리/요약)
+- PR 본문에 Mermaid **`sequenceDiagram`**을 작성합니다. (`pr-template.md`의 "아키텍처 다이어그램" 섹션 규칙을 그대로 따르세요)
 
 ### 4. 사용자 확인 요청
 
@@ -114,7 +116,7 @@ PR 생성 전 다음 내용을 **코드블록으로** 사용자에게 공유하
 
 - 제목
 - 본문 전체 (`pr-template.md` 형식)
-- 라벨
+- 라벨(최소 1개, 비워둘 수 없음)
 
 ### 5. PR 생성
 
@@ -122,6 +124,7 @@ PR 생성 전 다음 내용을 **코드블록으로** 사용자에게 공유하
 gh pr create \
   --title "feat(#{이슈번호}): {기능명} ({짧은 설명})" \
   --body-file /tmp/pr-body.md \
+  --label "{라벨1,라벨2}" \
   --assignee @me \
   --base main
 ```

package/templates/ko/common/agents/skills/execute-task.md

@@ -22,8 +22,7 @@ npx lee-spec-kit context
 CLI가 가리키는 **Active Task** 또는 **Next Action**을 수행합니다.
 
 - **[DOING] 상태인 태스크가 있다면**: 해당 태스크를 최우선으로 완료하세요.
-- **[DOING]이 없다면**: CLI가 추천하는 다음 태스크(`[TODO]`)를 시작하기 전에, **태스크 제목을 공유하고 사용자 승인(OK)을 받은 뒤** `[DOING]`으로 변경하세요.
-- **[DOING] → [DONE]**: 완료 처리 전에 **결과물/변경 사항/검증(테스트 포함)을 공유**하고 사용자 승인(OK)을 받은 뒤 `[DONE]`으로 변경하세요. (DONE으로 “먼저” 바꾸지 않기)
+- 태스크 상태 전환/승인 규칙은 `tasks.md`의 **"태스크 규칙"** 섹션을 SSOT로 따릅니다. (예: `[TODO]→[DOING]`, `[DOING]→[DONE]` 시점의 OK)
 - CLI가 명령어를 출력하면 **그대로 복사해 실행**합니다. (standalone 환경에서도 레포 경로가 포함될 수 있습니다)
 
 ### 3단계: 기록 및 반복 (Record & Loop)
@@ -68,14 +67,7 @@ CLI가 가리키는 **Active Task** 또는 **Next Action**을 수행합니다.
 
 > ⚠️ 직접 판단하지 말고 CLI가 시키는 대로 하세요.
 
-1. **[TODO] → [DOING]**: 작업 시작 시 표시
-2. **[DOING] → [DONE]**: 결과/검증 공유 + 사용자 승인(OK) 후 표시 (테스트 통과 포함)
-
-```markdown
-- [DONE] T-01: 로그인 UI (완료됨)
-- [DOING] T-02: API 연동 (현재 작업 중)
-- [TODO] T-03: 에러 처리 (대기 중)
-```
+태스크 상태 전환/승인 규칙은 `tasks.md`의 **"태스크 규칙"** 섹션을 따르세요.
 
 ## 비상시 대처 (Emergency)