lee-spec-kit 0.7.9 → 0.7.10

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.en.md CHANGED
@@ -7,7 +7,7 @@
7
7
  </div>
8
8
 
9
9
  <p align="center">
10
- <strong>Agent-guided development harness CLI for spec-driven projects</strong>
10
+ <strong>Orchestration harness CLI for AI agent-driven development</strong>
11
11
  </p>
12
12
 
13
13
  <p align="center">
@@ -48,24 +48,21 @@ npx lee-spec-kit flow
48
48
 
49
49
  ## Why It Exists
50
50
 
51
- This CLI was built to make spec-driven development more consistent when working with AI agents.
52
- The goal is not just to generate a docs folder, but to make it easier for both humans and agents to follow how a project moves from requirements, through ideas, into concrete implementation work.
51
+ This CLI was built to keep documents and actual execution flow together when working with an AI agent.
53
52
 
54
- To do that, `lee-spec-kit` structures work as `PRD idea feature`, and then connects that document flow to a git-centered issue/PR workflow.
55
- The focus is to keep planning artifacts and code workflow aligned, so the agent-readable state and the human-reviewable state stay in the same operating model.
53
+ It is not just a tool that creates a docs folder. The main agent can use it to understand which feature is active, what the next action is, and where user approval is required.
56
54
 
57
- In that flow, PRD lives in the top-level `docs/prd/` space created by `init`.
58
- Ideas capture candidates and experiments that come out of those requirements, and Features turn the approved work into executable units with `spec.md`, `plan.md`, and `tasks.md`.
55
+ The project structure follows `PRD idea feature`. PRD is where top-level requirements are written under `docs/prd/`, idea is for candidate approaches or experiments, and feature is the stage where actual work is managed through `spec.md`, `plan.md`, and `tasks.md`.
59
56
 
60
- Structurally, it draws inspiration from [spec-kit](https://github.com/github/spec-kit) and [OpenSpec](https://github.com/Fission-AI/OpenSpec),
61
- but it is adapted toward a more practical project workflow with explicit document stages, feature-level execution units, and tighter git workflow integration for agent orchestration.
57
+ The overall approach is influenced by [spec-kit](https://github.com/github/spec-kit) and [OpenSpec](https://github.com/Fission-AI/OpenSpec). The difference is that this project is less about inventing a new standard and more about keeping my own document flow and execution flow in one CLI.
62
58
 
63
59
  ## What This CLI Does
64
60
 
65
- `lee-spec-kit` is less a power-user operator console and more a development harness that helps the main agent read project state and choose the next action.
61
+ `lee-spec-kit` is less a power-user console and more an opinionated harness that helps the main agent read project state and choose the next action.
66
62
 
67
63
  - Humans usually ask in natural language.
68
- - The main agent translates those requests into commands like `detect`, `context`, `flow`, `idea`, and `feature`.
64
+ - The human-facing surface stays small: `init`, `idea`, `feature`, `context`, `flow`.
65
+ - In practice, the main agent runs `detect`, `context`, and `flow` first.
69
66
  - Deeper operational commands still exist, but they are no longer front-loaded in the default help output.
70
67
 
71
68
  ## How It Works
@@ -85,14 +82,18 @@ but it is adapted toward a more practical project workflow with explicit documen
85
82
  - "What is the next action right now?"
86
83
  - "Check the overall project state."
87
84
 
88
- ## Commands The Agent Usually Runs
89
-
90
- - `init`: initialize docs/workflow scaffolding
91
- - `idea`: create a pre-feature idea document
92
- - `feature`: create a concrete execution unit
93
- - `detect`: detect whether the workspace uses lee-spec-kit
94
- - `context`: read current feature state and next actions
95
- - `flow`: summarize workflow state
85
+ ## Commands
86
+
87
+ - The core agent-facing commands are the three commands below.
88
+ - `detect`: detect whether the workspace uses lee-spec-kit
89
+ - `context`: read the current feature state and next actions
90
+ - `flow`: summarize workflow state and auto-run progress
91
+ - The public human-facing commands are the five commands below.
92
+ - `init`: initialize docs/workflow scaffolding
93
+ - `idea`: create a pre-feature idea document
94
+ - `feature`: create a concrete execution unit
95
+ - `context`: show the current state and next action
96
+ - `flow`: summarize workflow health
96
97
 
97
98
  ## Agent Kickoff Prompt
98
99
 
package/README.md CHANGED
@@ -48,27 +48,21 @@ npx lee-spec-kit flow
48
48
 
49
49
  ## 왜 만들었나
50
50
 
51
- 이 CLI는 AI 에이전트와 함께 프로젝트를 진행할 spec-driven development 기반의 흐름을 일관되게 만들기 위해 만들어졌습니다.
52
- 목표는 단순히 문서 폴더를 생성하는 것이 아니라, 프로젝트가 어떤 요구사항에서 출발했고 어떤 아이디어를 거쳐 어떤 구현 단위로 내려왔는지를
53
- 에이전트와 사람이 함께 추적할 수 있게 만드는 것입니다.
51
+ 이 CLI는 AI 에이전트와 함께 프로젝트를 진행할 때, 문서와 실제 작업 흐름이 따로 놀지 않게 하려고 만들었습니다.
54
52
 
55
- 이를 위해 `lee-spec-kit`는 `PRD idea feature` 단계로 작업을 구조화하고, 실제 구현과 협업 흐름에서는 git 기반의 issue/PR 구조를 자연스럽게 연결하도록 설계되었습니다.
56
- 즉, 문서 작성 단계와 코드 변경 단계가 따로 놀지 않도록, 에이전트가 읽을 수 있는 상태와 사람이 리뷰할 수 있는 상태를 같은 흐름 안에 두는 데 초점을 둡니다.
53
+ 단순히 문서 폴더만 만드는 것이 아니라, 메인 에이전트가 지금 어떤 feature 보고 있는지, 다음에 무엇을 해야 하는지, 어디서 사용자 확인이 필요한지를 같이 다룰 있게 하는 쪽에 더 가깝습니다.
57
54
 
58
- 여기서 PRD `init`이 만들어 주는 `docs/prd/`에서 직접 관리하는 상위 요구사항 공간입니다.
59
- Idea는 그 요구사항에서 나온 후보와 실험을 정리하는 단계이고, Feature는 그중 실제로 실행하기로 한 단위를
60
- `spec.md`, `plan.md`, `tasks.md`로 내려서 관리하는 단계입니다.
55
+ 작업 구조는 `PRD → idea → feature` 흐름을 따릅니다. PRD는 `docs/prd/`에서 상위 요구사항을 정리하는 공간이고, idea는 후보나 실험을 적어두는 단계이며, feature는 실제로 실행할 단위를 `spec.md`, `plan.md`, `tasks.md`로 내려 관리하는 단계입니다.
61
56
 
62
- 구조적으로는 [spec-kit](https://github.com/github/spec-kit)과 [OpenSpec](https://github.com/Fission-AI/OpenSpec)의 접근을 참고했지만,
63
- `lee-spec-kit`는 실제 프로젝트 진행 방식과 에이전트 오케스트레이션에 맞게 더 실무적인 문서 단계, feature 단위, 그리고 git workflow 연결을 강조하도록 재구성되었습니다.
57
+ 구조적으로는 [spec-kit](https://github.com/github/spec-kit)과 [OpenSpec](https://github.com/Fission-AI/OpenSpec)의 접근을 참고했습니다. 다만 이 프로젝트는 새 표준을 만들려는 쪽보다는, 내가 실제로 쓰는 작업 흐름을 더 잘 굴리기 위해 문서 구조와 실행 흐름을 한 CLI에 묶는 쪽에 가깝습니다.
64
58
 
65
59
  ## 이 CLI가 하는 일
66
60
 
67
- `lee-spec-kit`는 사람이 매번 세부 명령을 직접 치는 도구라기보다,
68
- 메인 에이전트가 현재 상태를 읽고 다음 액션을 고르도록 돕는 개발 하네스입니다.
61
+ `lee-spec-kit`는 사람이 세부 운영 명령을 외우는 도구라기보다, 메인 에이전트가 현재 상태를 읽고 다음 액션을 고르도록 돕는 개인용 하네스에 가깝습니다.
69
62
 
70
63
  - 사람은 보통 자연어로 요청합니다.
71
- - 메인 에이전트는 그 요청을 `detect`, `context`, `flow`, `idea`, `feature` 같은 명령으로 번역해 실행합니다.
64
+ - 사람용으로는 `init`, `idea`, `feature`, `context`, `flow` 정도의 작은 표면을 제공합니다.
65
+ - 실제 에이전트 실행은 `detect`, `context`, `flow` 3개 명령을 기준으로 움직입니다.
72
66
  - 더 깊은 운영 명령은 여전히 지원되지만 기본 help에는 전면 노출하지 않습니다.
73
67
 
74
68
  ## 어떻게 동작하나
@@ -90,12 +84,16 @@ Idea는 그 요구사항에서 나온 후보와 실험을 정리하는 단계이
90
84
 
91
85
  ## 에이전트가 주로 실행하는 명령
92
86
 
93
- - `init`: docs/workflow 구조를 초기화합니다.
94
- - `idea`: 구현 아이디어 문서를 생성합니다.
95
- - `feature`: 실제 작업 단위를 생성합니다.
96
- - `detect`: 현재 워크스페이스가 lee-spec-kit 프로젝트인지 감지합니다.
97
- - `context`: 현재 feature 상태와 다음 액션을 읽습니다.
98
- - `flow`: 전체 워크플로우 상태를 요약합니다.
87
+ - 실제 에이전트 실행 기준 명령은 아래 3개입니다.
88
+ - `detect`: 현재 워크스페이스가 lee-spec-kit 프로젝트인지 감지합니다.
89
+ - `context`: 현재 feature 상태와 다음 액션을 읽습니다.
90
+ - `flow`: 전체 workflow 상태와 auto-run 진행 상태를 읽습니다.
91
+ - 사람용 public 명령은 아래 다섯 개입니다.
92
+ - `init`: docs/workflow 구조를 초기화합니다.
93
+ - `idea`: 구현 전 아이디어 문서를 생성합니다.
94
+ - `feature`: 실제 작업 단위를 생성합니다.
95
+ - `context`: 현재 feature 상태와 다음 액션을 읽습니다.
96
+ - `flow`: 전체 워크플로우 상태를 요약합니다.
99
97
 
100
98
  ## 에이전트 킥오프 프롬프트
101
99