lee-spec-kit 0.6.33 → 0.6.35

package/package.json

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

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

@@ -22,12 +22,13 @@ Always run this checklist in Pre-PR review. Treat it as the minimum baseline, th
 2. Inspect regression, exception handling, critical/security risks, side effects, user flow impact, and release readiness.
 3. Check maintainability: split oversized functions/files when needed, reuse/integrate existing code where appropriate, and remove obsolete code.
 4. Run related test/verification commands (or explicitly record why they were not run).
-5. Run `npx lee-spec-kit pre-pr-review <feature-ref>` to record review notes in `decisions.md` and sync `Pre-PR Evidence/Decision`.
+5. Run the review agent first and generate `review-trace.json` with non-empty `commandsExecuted`, then run `npx lee-spec-kit pre-pr-review <feature-ref> --evidence review-trace.json`.
 6. `Pre-PR Evidence` should point to a real existing path. (default: `workflow.prePrReview.evidenceMode=path_required`)
-7. In `decisions.md`, include a `Pre-PR Review Log` section with non-placeholder `Summary` and `Decision` entries.
-8. In code-review stage, keep `PR Review Evidence/Decision` aligned with `decisions.md` by adding a `PR Review Log` section with `Summary` and `Decision`.
-9. `Pre-PR Decision` must use `decision: approve|changes_requested|blocked ...` (or `결정: ...`).
-10. Ensure the final decision is `approve` before moving to PR creation.
+7. With `workflow.prePrReview.enforceExecutionEvidence=true` (default), `commandsExecuted` is required and cannot be empty.
+8. In `decisions.md`, include a `Pre-PR Review Log` section with non-placeholder `Summary` and `Decision` entries.
+9. In code-review stage, keep `PR Review Evidence/Decision` aligned with `decisions.md` by adding a `PR Review Log` section with `Summary` and `Decision`.
+10. `Pre-PR Decision` must use `decision: approve|changes_requested|blocked ...` (or `결정: ...`).
+11. Ensure the final decision is `approve` before moving to PR creation.
 
 ---
 

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

@@ -0,0 +1,95 @@
+# Feature Scope Split Guide (Issue Unit Preserved)
+
+Use this guide when one Feature/Issue becomes too large to review safely.
+
+---
+
+## Threshold policy
+
+- Split suggestion starts when:
+  - `tasks.md` task count is `>= 40`, or
+  - `decisions.md` line count is `>= 1200`.
+- Strong 4-way split recommendation when:
+  - task count is `>= 80`, or
+  - decisions line count is `>= 2500`.
+
+Notes:
+
+- Keep one issue only for small, tightly coupled work.
+- Preserve "Feature = Issue" by creating multiple linked child issues/features.
+
+---
+
+## How to decide split boundaries
+
+Evaluate each candidate group with these four criteria:
+
+1. Coupling
+   - Can this group change without forcing edits in the others?
+2. Changed-file overlap
+   - Do PRs mostly touch separate files/modules?
+3. Test boundary
+   - Can tests be run and reviewed per group?
+4. Deployment independence
+   - Can each group merge safely with flags/compatibility guards?
+
+Prefer boundaries that maximize independence and minimize rebase conflicts.
+
+---
+
+## Required per-issue template
+
+For every split issue/feature, fill all fields below:
+
+```md
+## Split Issue: <name>
+- Goal:
+- Included Scope:
+- Excluded Scope:
+- Depends On:
+- PR Done Criteria:
+```
+
+Minimum quality bar:
+
+- `Included Scope` and `Excluded Scope` must be explicit.
+- `Depends On` must list predecessor issue(s) or `None`.
+- `PR Done Criteria` must be checkable in review.
+
+---
+
+## Recommended split shapes
+
+- 2-way split (typical for medium-large):
+  - Base/refactor lane
+  - Product behavior lane
+- 4-way split (typical for very large):
+  - Foundation (types/contracts/data)
+  - Core flow
+  - Edge cases/integrations
+  - Cleanup/docs/final hardening
+
+---
+
+## Merge sequencing
+
+When dependencies exist, use a linear merge order:
+
+1. Merge foundation PR
+2. Rebase/merge core flow PR
+3. Rebase/merge integration PR
+4. Rebase/merge cleanup PR
+
+Keep every PR independently reviewable and releasable.
+
+---
+
+## Split execution checklist
+
+1. Freeze new TODO inflow in the current oversized feature.
+2. Define split boundaries with the 4 criteria.
+3. Create linked child issues/features.
+4. Move TODO tasks to the correct child feature.
+5. Record dependencies and merge order.
+6. Continue implementation per child feature.
+

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

@@ -22,12 +22,13 @@ Pre-PR 리뷰에서 항상 수행하는 최소 기준입니다. 가능한 경우
 2. 회귀/예외 처리, 크리티컬·보안 리스크, 사이드 이펙트, 사용자 흐름 영향, 배포 준비도를 점검합니다.
 3. 유지보수성을 점검합니다: 큰 함수/파일은 필요 시 분리하고, 기존 코드 재사용·통합 가능성을 확인하며, 불필요해진 코드를 정리합니다.
 4. 관련 테스트/검증 명령을 실행합니다. 실행하지 못했다면 사유를 명시합니다.
-5. `npx lee-spec-kit pre-pr-review <feature-ref>`를 실행해 리뷰 내용을 `decisions.md`에 기록하고 `PR 전 리뷰 Evidence/Decision`을 동기화합니다.
+5. 리뷰 에이전트를 먼저 실행해 비어있지 않은 `commandsExecuted`를 포함한 `review-trace.json`을 만든 뒤 `npx lee-spec-kit pre-pr-review <feature-ref> --evidence review-trace.json`을 실행합니다.
 6. `PR 전 리뷰 Evidence`는 실제 존재하는 문서 경로를 사용합니다. (`workflow.prePrReview.evidenceMode=path_required` 기본)
-7. `decisions.md`에 `Pre-PR Review Log`(또는 `PR 전 리뷰 로그`) 섹션을 두고 `Summary`/`Decision`을 placeholder 없이 기록합니다.
-8. 코드리뷰 단계에서도 `PR 리뷰 Evidence/Decision`과 `decisions.md`를 동기화하고 `PR Review Log`(또는 `PR 리뷰 로그`)의 `Summary`/`Decision`을 기록합니다.
-9. `PR 전 리뷰 Decision`은 `결정: approve|changes_requested|blocked ...` (또는 `decision: ...`) 형식을 사용합니다.
-10. PR 생성 단계로 이동하기 전 최종 Decision이 `approve`인지 확인합니다.
+7. `workflow.prePrReview.enforceExecutionEvidence=true`(기본)일 때 `commandsExecuted`는 필수이며 비어있을 수 없습니다.
+8. `decisions.md`에 `Pre-PR Review Log`(또는 `PR 전 리뷰 로그`) 섹션을 두고 `Summary`/`Decision`을 placeholder 없이 기록합니다.
+9. 코드리뷰 단계에서도 `PR 리뷰 Evidence/Decision`과 `decisions.md`를 동기화하고 `PR Review Log`(또는 `PR 리뷰 로그`)의 `Summary`/`Decision`을 기록합니다.
+10. `PR 전 리뷰 Decision`은 `결정: approve|changes_requested|blocked ...` (또는 `decision: ...`) 형식을 사용합니다.
+11. PR 생성 단계로 이동하기 전 최종 Decision이 `approve`인지 확인합니다.
 
 ---
 

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

@@ -0,0 +1,95 @@
+# Feature 범위 분할 가이드 (Feature = Issue 유지)
+
+하나의 Feature/Issue가 리뷰 가능한 범위를 넘었을 때 사용하는 가이드입니다.
+
+---
+
+## 임계값 정책
+
+- 분할 제안 시작 기준:
+  - `tasks.md` 태스크 수 `>= 40`, 또는
+  - `decisions.md` 줄 수 `>= 1200`.
+- 4분할 강한 권장 기준:
+  - 태스크 수 `>= 80`, 또는
+  - decisions 줄 수 `>= 2500`.
+
+주의:
+
+- 작은 범위, 강결합 작업은 단일 이슈 유지가 가능합니다.
+- "Feature = Issue" 원칙을 유지하면서 연관 child 이슈/feature를 생성합니다.
+
+---
+
+## 분할 경계 판단 기준
+
+후보 묶음을 아래 4가지로 평가하세요.
+
+1. 결합도
+   - 다른 묶음 수정 없이 독립 변경 가능한가?
+2. 변경 파일 겹침
+   - PR 간 파일/모듈 겹침이 낮은가?
+3. 테스트 경계
+   - 묶음 단위로 테스트 실행/검토가 가능한가?
+4. 배포 독립성
+   - 플래그/호환성 보호 하에서 순차 머지가 안전한가?
+
+독립성이 높고 리베이스 충돌이 적은 경계를 우선합니다.
+
+---
+
+## 분할 이슈 필수 템플릿
+
+각 분할 이슈/feature마다 아래 항목을 모두 작성하세요.
+
+```md
+## 분할 이슈: <name>
+- 목표:
+- 포함 범위:
+- 제외 범위:
+- 선행 의존성:
+- PR 완료 기준:
+```
+
+최소 품질 기준:
+
+- `포함 범위`/`제외 범위`를 명확히 구분합니다.
+- `선행 의존성`은 선행 이슈 또는 `None`을 명시합니다.
+- `PR 완료 기준`은 리뷰에서 검증 가능해야 합니다.
+
+---
+
+## 권장 분할 형태
+
+- 2분할(중대형 기본):
+  - 기반 정비(리팩터/계약/토대)
+  - 사용자 동작(핵심 기능)
+- 4분할(초대형 기본):
+  - Foundation(타입/계약/데이터)
+  - Core flow
+  - Integration/edge cases
+  - Cleanup/docs/final hardening
+
+---
+
+## 머지 순서
+
+의존성이 있으면 선형 순서로 머지합니다.
+
+1. foundation PR 머지
+2. core flow PR 리베이스 후 머지
+3. integration PR 리베이스 후 머지
+4. cleanup PR 리베이스 후 머지
+
+각 PR은 독립 리뷰/릴리스가 가능해야 합니다.
+
+---
+
+## 분할 실행 체크리스트
+
+1. 현재 과대 feature의 신규 TODO 유입을 잠시 중지합니다.
+2. 4가지 기준으로 분할 경계를 확정합니다.
+3. 연관 child 이슈/feature를 생성합니다.
+4. TODO를 올바른 child feature로 이관합니다.
+5. 의존성/머지 순서를 문서화합니다.
+6. child feature 단위로 구현을 재개합니다.
+