@jjlabsio/claude-crew 0.1.41 → 0.1.43
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/.claude-plugin/marketplace.json +2 -2
- package/.claude-plugin/plugin.json +1 -1
- package/README.ko.md +173 -0
- package/README.md +101 -74
- package/agents/dev.md +40 -3
- package/data/agent-contracts.json +11 -1
- package/data/agent-instructions/dev.md +40 -3
- package/data/provider-catalog.json +4 -4
- package/package.json +1 -1
- package/skills/crew-do/SKILL.md +169 -0
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
"name": "claude-crew",
|
|
12
12
|
"source": "./",
|
|
13
13
|
"description": "오케스트레이터 + PM, 플래너, 개발, QA, 마케팅 에이전트 팀으로 단일 제품의 개발과 마케팅을 통합 관리",
|
|
14
|
-
"version": "0.1.
|
|
14
|
+
"version": "0.1.43",
|
|
15
15
|
"author": {
|
|
16
16
|
"name": "Jaejin Song",
|
|
17
17
|
"email": "wowlxx28@gmail.com"
|
|
@@ -28,5 +28,5 @@
|
|
|
28
28
|
"category": "workflow"
|
|
29
29
|
}
|
|
30
30
|
],
|
|
31
|
-
"version": "0.1.
|
|
31
|
+
"version": "0.1.43"
|
|
32
32
|
}
|
package/README.ko.md
ADDED
|
@@ -0,0 +1,173 @@
|
|
|
1
|
+
# Claude Crew
|
|
2
|
+
|
|
3
|
+
1인 SaaS 개발자를 위한 Claude Code 멀티 에이전트 오케스트레이션 플러그인.
|
|
4
|
+
|
|
5
|
+
[English](README.md)
|
|
6
|
+
|
|
7
|
+
## 파이프라인
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
crew-interview → crew-plan → crew-dev
|
|
11
|
+
WHAT HOW DO
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
| 단계 | 역할 | 산출물 |
|
|
15
|
+
|------|------|--------|
|
|
16
|
+
| **crew-interview** | 무엇을 만드는가 — 요구사항 인터뷰, 제품 설계 | spec.md |
|
|
17
|
+
| **crew-plan** | 어떻게 만드는가 — 기술 분석, 태스크 분해 | contract.md |
|
|
18
|
+
| **crew-dev** | 만든다 — 구현, 코드 리뷰, QA | 동작하는 코드 + PR |
|
|
19
|
+
|
|
20
|
+
## 설치
|
|
21
|
+
|
|
22
|
+
Claude Code에서:
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
/plugin marketplace add jjlabsio/claude-crew
|
|
26
|
+
/plugin install claude-crew
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
또는 로컬에서 직접:
|
|
30
|
+
|
|
31
|
+
```
|
|
32
|
+
/plugin install /path/to/claude-crew
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
## 초기 설정
|
|
36
|
+
|
|
37
|
+
설치 후 반드시 한 번 실행:
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
/crew-setup
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
- `.gitignore` / `.gitattributes` 마이그레이션 (`.crew/` git tracked 전환)
|
|
44
|
+
- HUD statusline 설치
|
|
45
|
+
- 에이전트별 provider/model 설정
|
|
46
|
+
|
|
47
|
+
## 사용
|
|
48
|
+
|
|
49
|
+
### 개발 파이프라인
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
/crew
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
오케스트레이터가 시작되고 현황을 브리핑합니다.
|
|
56
|
+
|
|
57
|
+
### 간단 작업 즉시 위임
|
|
58
|
+
|
|
59
|
+
```
|
|
60
|
+
/crew-do "로그인 에러 메시지 정리"
|
|
61
|
+
/crew-do # active task가 있으면 해당 task를 실행
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
`/crew-do`는 기존 Dev 에이전트를 `direct` 모드로 호출해 작은 수정, 버그픽스, 테스트 실패 수정처럼 범위가 명확한 작업을 바로 위임합니다. Dev 기본 provider가 Codex이면 실제 코드 탐색, 수정, 검증은 Codex runtime에서 수행되고 Claude는 결과 요약과 후속 조율만 담당합니다.
|
|
65
|
+
|
|
66
|
+
`/task`는 계속 기억/queue 관리 전용입니다. 저장된 태스크를 실행하려면 `/task work {id}`로 active 상태로 만든 뒤 `/crew-do`를 실행합니다.
|
|
67
|
+
|
|
68
|
+
### 태스크 관리
|
|
69
|
+
|
|
70
|
+
```
|
|
71
|
+
/task add "설명" # 태스크 추가 (대화 컨텍스트 자동 캡처)
|
|
72
|
+
/task add "설명" --next # 긴급 — queue 맨 위 삽입
|
|
73
|
+
/task work 3 # 태스크 #3 작업 시작 (관련 파일 Read + 브리핑)
|
|
74
|
+
/task start # queue 최상단 태스크 작업 시작
|
|
75
|
+
/task done # active 태스크 완료 처리
|
|
76
|
+
/task bump 4 # 우선순위 한 칸 올리기
|
|
77
|
+
/task top 7 # queue 맨 위로 이동
|
|
78
|
+
/task note 3 "메모" # 태스크에 메모 추가
|
|
79
|
+
/task drop 3 # 태스크 삭제
|
|
80
|
+
|
|
81
|
+
/tasks # 프로젝트 태스크 보드
|
|
82
|
+
/tasks stale # 30일+ 방치 태스크 리뷰
|
|
83
|
+
/tasks clean # 완료 후 7일 경과 태스크 정리
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
태스크는 `.crew/tasks/` 디렉토리에 개별 파일로 관리된다. 각 파일이 상태, 우선순위, 컨텍스트를 포함하여 세션 간 작업 재개 시 컨텍스트 재입력이 불필요하다.
|
|
87
|
+
|
|
88
|
+
## 에이전트 팀
|
|
89
|
+
|
|
90
|
+
| 에이전트 | 역할 | 소속 스킬 |
|
|
91
|
+
|---------|------|----------|
|
|
92
|
+
| **오케스트레이터** | 유저와 대화, 위임 판단, 파이프라인 진행 | 전체 |
|
|
93
|
+
| **Explorer** | 코드베이스 탐색 (read-only) | interview, plan |
|
|
94
|
+
| **Researcher** | 외부 리서치 (WebSearch) | interview, plan |
|
|
95
|
+
| **TechLead** | 기술 분석, 아키텍처 방향 판단 | plan |
|
|
96
|
+
| **Planner** | 태스크 분해, 구현 계획 | plan |
|
|
97
|
+
| **PlanEvaluator** | 계획 검증 (하드 임계값) | plan |
|
|
98
|
+
| **Dev** | 코드 구현 | dev |
|
|
99
|
+
| **CodeReviewer** | 코드 리뷰 | dev |
|
|
100
|
+
| **QA** | 실행 검증 | dev |
|
|
101
|
+
|
|
102
|
+
## 두 가지 사용 모드
|
|
103
|
+
|
|
104
|
+
claude-crew는 **다른 프로젝트에 설치되어 사용되는 플러그인**이다. 두 가지 모드로 구분된다.
|
|
105
|
+
|
|
106
|
+
### 사용자 모드
|
|
107
|
+
|
|
108
|
+
이 plugin을 자기 프로젝트에 설치해서 SaaS 개발에 활용하는 일반 사용자.
|
|
109
|
+
|
|
110
|
+
- 직접 호출하는 슬래시 명령: `/crew`, `/crew-setup`, `/crew-do`, `/task`, `/tasks`, `/crew-interview`, `/crew-plan`, `/crew-dev`.
|
|
111
|
+
- 디버그용 직접 호출 가능 명령: `node scripts/crew-agent-runner.mjs resolve --role <role> --json` (provider/model/contract 통합 표 확인).
|
|
112
|
+
- plugin이 설치된 위치(`~/.claude/plugins/...` 등)에 무관하게 동작 — plugin script가 자기 위치를 자동으로 인식.
|
|
113
|
+
|
|
114
|
+
### 개발자 모드
|
|
115
|
+
|
|
116
|
+
claude-crew 자체를 개발하는 사람 (이 repo 안에서 작업).
|
|
117
|
+
|
|
118
|
+
- `node scripts/crew-agent-runner.mjs build`: contracts/instructions에서 `agents/{role}.md` + `plugin.json` agents 배열 derive.
|
|
119
|
+
- `node scripts/crew-agent-runner.mjs validate`: build 결과와 현재 파일 정합성 검사 + sandbox 정합성 검증.
|
|
120
|
+
- `node scripts/crew-agent-runner.mjs install-hooks`: pre-commit hook 설치 (drift 차단).
|
|
121
|
+
|
|
122
|
+
위 세 명령은 **plugin source repo 안에서만 동작**한다. 사용자 환경에서 호출하면 가드로 차단된다 (`.claude-plugin/plugin.json` + `package.json.name === "@jjlabsio/claude-crew"` 감지). 사용자에게는 의미 없는 명령이므로 정상이다.
|
|
123
|
+
|
|
124
|
+
## 모델 설정
|
|
125
|
+
|
|
126
|
+
`/crew-setup`에서 에이전트별 provider/model을 설정합니다. 설정하지 않은 에이전트는 `data/provider-catalog.json`의 `agent_defaults`를 따릅니다.
|
|
127
|
+
|
|
128
|
+
권장 기본값은 에이전트 역할의 성격에 따라 세 그룹으로 구분됩니다.
|
|
129
|
+
|
|
130
|
+
| 에이전트 | provider | model | reasoning | 역할 성격 |
|
|
131
|
+
|----------|----------|-------|-----------|---------|
|
|
132
|
+
| `techlead` | codex | gpt-5.5 | high | 판단/평가 — 아키텍처 방향 결정 |
|
|
133
|
+
| `code-reviewer` | codex | gpt-5.5 | high | 판단/평가 — 코드 품질 판정 |
|
|
134
|
+
| `pm` | codex | gpt-5.5 | medium | 계획/분석 — 요구사항 수집 |
|
|
135
|
+
| `planner` | codex | gpt-5.5 | medium | 계획/분석 — 구현 계획 작성 |
|
|
136
|
+
| `dev` | codex | gpt-5.5 | medium | 계획/분석 — 코드 구현 |
|
|
137
|
+
| `plan-evaluator` | codex | gpt-5.4-mini | high | 실행/검증 — 계획 기준 충족 판정 |
|
|
138
|
+
| `qa` | codex | gpt-5.4-mini | high | 실행/검증 — 빌드/테스트 실행 |
|
|
139
|
+
| `researcher` | codex | gpt-5.4-mini | high | 실행/검증 — 외부 정보 조사 |
|
|
140
|
+
| `explorer` | codex | gpt-5.3-codex-spark | low | 탐색 전용 — 코드베이스 검색 |
|
|
141
|
+
|
|
142
|
+
Claude 모델은 `opus`, `sonnet`, `haiku` latest alias와 `claude-opus-4-7` 같은 버전 고정 ID를 모두 선택할 수 있습니다.
|
|
143
|
+
|
|
144
|
+
Claude provider는 Claude Code `Agent`로 실행하고, Codex provider는 플러그인에 내장된 `scripts/crew-codex-companion.mjs` app-server runtime으로 실행합니다. 에이전트가 유저 질문이나 다른 에이전트 호출이 필요하면 직접 처리하지 않고 오케스트레이터가 이어받아 실행합니다.
|
|
145
|
+
|
|
146
|
+
Provider와 무관하게 에이전트 결과는 `complete`, `blocked_on_user`, `needs_agent`, `needs_tool`, `failed` 상태 중 하나로 해석합니다. Claude Code 전용 도구가 필요한 경우에도 Codex provider는 요청 상태를 반환하고, 실제 도구 실행은 오케스트레이터가 담당합니다.
|
|
147
|
+
|
|
148
|
+
## 상태 파일
|
|
149
|
+
|
|
150
|
+
프로젝트 로컬 `.crew/` 디렉토리에 마크다운 파일로 상태를 관리합니다 (git tracked). 플러그인 업데이트 시에도 학습 내용과 상태는 보존됩니다.
|
|
151
|
+
|
|
152
|
+
```
|
|
153
|
+
.crew/
|
|
154
|
+
config.json # provider 설정 (gitignored)
|
|
155
|
+
tasks/ # 태스크 파일 (1개 = 1파일)
|
|
156
|
+
plans/ # 파이프라인 산출물 (spec, contract, dev-log, review)
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
## 설계 철학
|
|
160
|
+
|
|
161
|
+
**역할별 관점은 유지하되, 정보는 제한하지 않는다.**
|
|
162
|
+
|
|
163
|
+
각 에이전트는 특정 관점(기획/기술/구현)에서 사고하지만, 활용할 수 있는 정보(코드 포함)는 제한하지 않는다. 실제 회사의 역할 분리를 모방하는 것이 아니라, 빠뜨리는 관점이 없도록 구조화된 사고를 강제하는 것이 목적이다.
|
|
164
|
+
|
|
165
|
+
### 기타 원칙
|
|
166
|
+
|
|
167
|
+
- [Anthropic 하네스 설계 아티클](https://www.anthropic.com/engineering/harness-design)을 최우선 레퍼런스로 따름
|
|
168
|
+
- 가능한 단순하게 시작하고 필요할 때만 복잡성을 높임
|
|
169
|
+
- 모델이 발전하면 불필요해진 구성 요소를 제거
|
|
170
|
+
|
|
171
|
+
## License
|
|
172
|
+
|
|
173
|
+
MIT. This project also includes Apache-2.0 third-party components under `scripts/crew-codex/`; see `THIRD_PARTY_NOTICES.md`.
|
package/README.md
CHANGED
|
@@ -1,145 +1,172 @@
|
|
|
1
1
|
# Claude Crew
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
A Claude Code multi-agent orchestration plugin for solo SaaS developers.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
[한국어](README.ko.md)
|
|
6
|
+
|
|
7
|
+
## Pipeline
|
|
6
8
|
|
|
7
9
|
```
|
|
8
10
|
crew-interview → crew-plan → crew-dev
|
|
9
11
|
WHAT HOW DO
|
|
10
12
|
```
|
|
11
13
|
|
|
12
|
-
|
|
|
13
|
-
|
|
14
|
-
| **crew-interview** |
|
|
15
|
-
| **crew-plan** |
|
|
16
|
-
| **crew-dev** |
|
|
14
|
+
| Stage | Role | Output |
|
|
15
|
+
|-------|------|--------|
|
|
16
|
+
| **crew-interview** | What to build — requirements interview, product design | spec.md |
|
|
17
|
+
| **crew-plan** | How to build it — technical analysis, task decomposition | contract.md |
|
|
18
|
+
| **crew-dev** | Build it — implementation, code review, QA | working code + PR |
|
|
17
19
|
|
|
18
|
-
##
|
|
20
|
+
## Installation
|
|
19
21
|
|
|
20
|
-
Claude Code
|
|
22
|
+
In Claude Code:
|
|
21
23
|
|
|
22
24
|
```
|
|
23
25
|
/plugin marketplace add jjlabsio/claude-crew
|
|
24
26
|
/plugin install claude-crew
|
|
25
27
|
```
|
|
26
28
|
|
|
27
|
-
|
|
29
|
+
Or install locally:
|
|
28
30
|
|
|
29
31
|
```
|
|
30
32
|
/plugin install /path/to/claude-crew
|
|
31
33
|
```
|
|
32
34
|
|
|
33
|
-
##
|
|
35
|
+
## Initial Setup
|
|
34
36
|
|
|
35
|
-
|
|
37
|
+
Run once after installation:
|
|
36
38
|
|
|
37
39
|
```
|
|
38
40
|
/crew-setup
|
|
39
41
|
```
|
|
40
42
|
|
|
41
|
-
- `.gitignore` / `.gitattributes`
|
|
42
|
-
- HUD statusline
|
|
43
|
-
-
|
|
43
|
+
- `.gitignore` / `.gitattributes` migration (`.crew/` git tracked)
|
|
44
|
+
- HUD statusline installation
|
|
45
|
+
- Per-agent provider/model configuration
|
|
44
46
|
|
|
45
|
-
##
|
|
47
|
+
## Usage
|
|
46
48
|
|
|
47
|
-
###
|
|
49
|
+
### Development Pipeline
|
|
48
50
|
|
|
49
51
|
```
|
|
50
52
|
/crew
|
|
51
53
|
```
|
|
52
54
|
|
|
53
|
-
|
|
55
|
+
The orchestrator starts and briefs the current status.
|
|
54
56
|
|
|
55
|
-
###
|
|
57
|
+
### Quick Task Delegation
|
|
56
58
|
|
|
57
59
|
```
|
|
58
|
-
/
|
|
59
|
-
/
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
/task note 3 "메모" # 태스크에 메모 추가
|
|
66
|
-
/task drop 3 # 태스크 삭제
|
|
60
|
+
/crew-do "clean up login error messages"
|
|
61
|
+
/crew-do # runs the active task if one exists
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
`/crew-do` invokes the Dev agent in `direct` mode for small fixes, bug patches, and clearly scoped tasks. If Dev's default provider is Codex, code exploration, editing, and verification happen inside the Codex runtime; Claude handles only result summarization and follow-up coordination.
|
|
65
|
+
|
|
66
|
+
`/task` remains dedicated to memory/queue management. To execute a saved task, mark it active with `/task work {id}` then run `/crew-do`.
|
|
67
67
|
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
68
|
+
### Task Management
|
|
69
|
+
|
|
70
|
+
```
|
|
71
|
+
/task add "description" # add a task (captures conversation context)
|
|
72
|
+
/task add "description" --next # urgent — insert at top of queue
|
|
73
|
+
/task work 3 # start working on task #3 (reads related files + briefs)
|
|
74
|
+
/task start # start working on the top-priority task
|
|
75
|
+
/task done # mark active task complete
|
|
76
|
+
/task bump 4 # raise priority by one
|
|
77
|
+
/task top 7 # move to top of queue
|
|
78
|
+
/task note 3 "note" # add a note to a task
|
|
79
|
+
/task drop 3 # delete a task
|
|
80
|
+
|
|
81
|
+
/tasks # project task board
|
|
82
|
+
/tasks stale # review tasks untouched for 30+ days
|
|
83
|
+
/tasks clean # clean up tasks completed 7+ days ago
|
|
71
84
|
```
|
|
72
85
|
|
|
73
|
-
|
|
86
|
+
Tasks are managed as individual files in `.crew/tasks/`. Each file carries state, priority, and context so work can resume across sessions without re-entering context.
|
|
87
|
+
|
|
88
|
+
## Agent Team
|
|
89
|
+
|
|
90
|
+
| Agent | Role | Used in |
|
|
91
|
+
|-------|------|---------|
|
|
92
|
+
| **Orchestrator** | Talks with the user, decides delegation, drives the pipeline | all |
|
|
93
|
+
| **Explorer** | Codebase exploration (read-only) | interview, plan |
|
|
94
|
+
| **Researcher** | External research (WebSearch) | interview, plan |
|
|
95
|
+
| **TechLead** | Technical analysis, architecture direction | plan |
|
|
96
|
+
| **Planner** | Task decomposition, implementation planning | plan |
|
|
97
|
+
| **PlanEvaluator** | Plan validation (hard thresholds) | plan |
|
|
98
|
+
| **Dev** | Code implementation | dev |
|
|
99
|
+
| **CodeReviewer** | Code review | dev |
|
|
100
|
+
| **QA** | Execution verification | dev |
|
|
74
101
|
|
|
75
|
-
##
|
|
102
|
+
## Two Modes
|
|
76
103
|
|
|
77
|
-
|
|
78
|
-
|---------|------|----------|
|
|
79
|
-
| **오케스트레이터** | 유저와 대화, 위임 판단, 파이프라인 진행 | 전체 |
|
|
80
|
-
| **Explorer** | 코드베이스 탐색 (read-only) | interview, plan |
|
|
81
|
-
| **Researcher** | 외부 리서치 (WebSearch) | interview, plan |
|
|
82
|
-
| **TechLead** | 기술 분석, 아키텍처 방향 판단 | plan |
|
|
83
|
-
| **Planner** | 태스크 분해, 구현 계획 | plan |
|
|
84
|
-
| **PlanEvaluator** | 계획 검증 (하드 임계값) | plan |
|
|
85
|
-
| **Dev** | 코드 구현 | dev |
|
|
86
|
-
| **CodeReviewer** | 코드 리뷰 | dev |
|
|
87
|
-
| **QA** | 실행 검증 | dev |
|
|
104
|
+
claude-crew is a **plugin installed into other projects**. It operates in two distinct modes.
|
|
88
105
|
|
|
89
|
-
|
|
106
|
+
### User Mode
|
|
90
107
|
|
|
91
|
-
|
|
108
|
+
General users who install this plugin into their own project for SaaS development.
|
|
92
109
|
|
|
93
|
-
|
|
110
|
+
- Slash commands to invoke directly: `/crew`, `/crew-setup`, `/crew-do`, `/task`, `/tasks`, `/crew-interview`, `/crew-plan`, `/crew-dev`.
|
|
111
|
+
- Debug command: `node scripts/crew-agent-runner.mjs resolve --role <role> --json` (shows combined provider/model/contract table).
|
|
112
|
+
- Works regardless of where the plugin is installed (`~/.claude/plugins/...` etc.) — the plugin script auto-detects its own location.
|
|
94
113
|
|
|
95
|
-
|
|
114
|
+
### Developer Mode
|
|
96
115
|
|
|
97
|
-
|
|
98
|
-
- 디버그용 직접 호출 가능 명령: `node scripts/crew-agent-runner.mjs resolve --role <role> --json` (provider/model/contract 통합 표 확인).
|
|
99
|
-
- plugin이 설치된 위치(`~/.claude/plugins/...` 등)에 무관하게 동작 — plugin script가 자기 위치를 자동으로 인식.
|
|
116
|
+
People developing claude-crew itself (working inside this repo).
|
|
100
117
|
|
|
101
|
-
|
|
118
|
+
- `node scripts/crew-agent-runner.mjs build`: derives `agents/{role}.md` + `plugin.json` agents array from contracts/instructions.
|
|
119
|
+
- `node scripts/crew-agent-runner.mjs validate`: checks build output against source files + sandbox consistency.
|
|
120
|
+
- `node scripts/crew-agent-runner.mjs install-hooks`: installs pre-commit hook (prevents drift).
|
|
102
121
|
|
|
103
|
-
|
|
122
|
+
These commands **only work inside the plugin source repo**. They are blocked when called from a user environment (detected via `.claude-plugin/plugin.json` + `package.json.name === "@jjlabsio/claude-crew"`).
|
|
104
123
|
|
|
105
|
-
|
|
106
|
-
- `node scripts/crew-agent-runner.mjs validate`: build 결과와 현재 파일 정합성 검사 + sandbox 정합성 검증.
|
|
107
|
-
- `node scripts/crew-agent-runner.mjs install-hooks`: pre-commit hook 설치 (drift 차단).
|
|
124
|
+
## Model Configuration
|
|
108
125
|
|
|
109
|
-
|
|
126
|
+
Configure per-agent provider/model via `/crew-setup`. Agents without explicit configuration fall back to `agent_defaults` in `data/provider-catalog.json`.
|
|
110
127
|
|
|
111
|
-
|
|
128
|
+
Default recommendations are grouped by the nature of each agent's role:
|
|
112
129
|
|
|
113
|
-
|
|
130
|
+
| Agent | Provider | Model | Reasoning | Role type |
|
|
131
|
+
|-------|----------|-------|-----------|-----------|
|
|
132
|
+
| `techlead` | codex | gpt-5.5 | high | Judgment — architecture direction |
|
|
133
|
+
| `code-reviewer` | codex | gpt-5.5 | high | Judgment — code quality assessment |
|
|
134
|
+
| `pm` | codex | gpt-5.5 | medium | Planning — requirements gathering |
|
|
135
|
+
| `planner` | codex | gpt-5.5 | medium | Planning — implementation planning |
|
|
136
|
+
| `dev` | codex | gpt-5.5 | medium | Planning — code implementation |
|
|
137
|
+
| `plan-evaluator` | codex | gpt-5.4-mini | high | Execution — plan threshold checks |
|
|
138
|
+
| `qa` | codex | gpt-5.4-mini | high | Execution — build/test verification |
|
|
139
|
+
| `researcher` | codex | gpt-5.4-mini | high | Execution — external research |
|
|
140
|
+
| `explorer` | codex | gpt-5.3-codex-spark | low | Exploration — codebase search |
|
|
114
141
|
|
|
115
|
-
|
|
142
|
+
For Claude models, both latest aliases (`opus`, `sonnet`, `haiku`) and pinned version IDs like `claude-opus-4-7` are supported.
|
|
116
143
|
|
|
117
|
-
Claude provider
|
|
144
|
+
The Claude provider runs agents via Claude Code's `Agent` tool. The Codex provider runs via the bundled `scripts/crew-codex-companion.mjs` app-server runtime. When an agent needs to ask the user a question or invoke another agent, it does not handle this directly — the orchestrator takes over.
|
|
118
145
|
|
|
119
|
-
|
|
146
|
+
Regardless of provider, agent results are interpreted as one of: `complete`, `blocked_on_user`, `needs_agent`, `needs_tool`, or `failed`. Even when a Claude Code-specific tool is required, the Codex provider returns a request status and the orchestrator handles the actual tool execution.
|
|
120
147
|
|
|
121
|
-
##
|
|
148
|
+
## State Files
|
|
122
149
|
|
|
123
|
-
|
|
150
|
+
State is managed as Markdown files in the project-local `.crew/` directory (git tracked). Learning and state are preserved across plugin updates.
|
|
124
151
|
|
|
125
152
|
```
|
|
126
153
|
.crew/
|
|
127
|
-
config.json # provider
|
|
128
|
-
tasks/ #
|
|
129
|
-
plans/ #
|
|
154
|
+
config.json # provider configuration (gitignored)
|
|
155
|
+
tasks/ # task files (one file per task)
|
|
156
|
+
plans/ # pipeline artifacts (spec, contract, dev-log, review)
|
|
130
157
|
```
|
|
131
158
|
|
|
132
|
-
##
|
|
159
|
+
## Design Philosophy
|
|
133
160
|
|
|
134
|
-
|
|
161
|
+
**Preserve per-role perspective; do not restrict information.**
|
|
135
162
|
|
|
136
|
-
|
|
163
|
+
Each agent thinks from a specific viewpoint (product / technical / implementation), but the information it can use (including code) is not restricted. The goal is not to mimic real-world org chart separation, but to enforce structured thinking so no perspective is missed.
|
|
137
164
|
|
|
138
|
-
###
|
|
165
|
+
### Other Principles
|
|
139
166
|
|
|
140
|
-
- [Anthropic
|
|
141
|
-
-
|
|
142
|
-
-
|
|
167
|
+
- [Anthropic harness design article](https://www.anthropic.com/engineering/harness-design) is the primary reference
|
|
168
|
+
- Start as simple as possible; add complexity only when needed
|
|
169
|
+
- Remove components that become unnecessary as models improve
|
|
143
170
|
|
|
144
171
|
## License
|
|
145
172
|
|
package/agents/dev.md
CHANGED
|
@@ -14,13 +14,26 @@ canWriteCrewFiles: true
|
|
|
14
14
|
|
|
15
15
|
# Dev 에이전트
|
|
16
16
|
|
|
17
|
-
|
|
17
|
+
개발 실행자는 항상 이 Dev 에이전트 하나다.
|
|
18
|
+
요청의 `mode`에 따라 정식 파이프라인 구현과 간단 작업 direct 실행을 구분한다.
|
|
19
|
+
|
|
20
|
+
- `mode`가 없거나 `full`이면 `plan.md`의 유저 스토리를 순차 구현하고, 자체 검증(빌드/린트/타입/테스트/실행 검증) 5개를 모두 통과해야 완료를 선언한다.
|
|
21
|
+
- `mode: direct`이면 사용자 요청 또는 active task를 작은 작업 계약으로 보고 직접 탐색, 수정, 검증한다. 이때 `plan.md`와 `contract.md`가 없다는 이유로 실패하지 않는다.
|
|
18
22
|
|
|
19
23
|
## 입력
|
|
20
24
|
|
|
25
|
+
### full mode
|
|
26
|
+
|
|
21
27
|
- `plan.md` + `contract.md`
|
|
22
28
|
- retry 시: 위 + `review-report-{n}.md` + `qa-report-{n}.md`
|
|
23
29
|
|
|
30
|
+
### direct mode
|
|
31
|
+
|
|
32
|
+
- `request.mode`: `direct`
|
|
33
|
+
- `request.task` 또는 `.crew/runs/{run-id}/request.md`
|
|
34
|
+
- active task 기반이면 `.crew/tasks/{task-id}.md`
|
|
35
|
+
- 선택적으로 `request.context`, `request.files`
|
|
36
|
+
|
|
24
37
|
## 접근 금지
|
|
25
38
|
|
|
26
39
|
- `brief.md`, `spec.md`, `analysis.md` — 읽지 않는다.
|
|
@@ -28,7 +41,8 @@ plan.md의 유저 스토리를 순차 구현하고, 자체 검증(빌드/린트/
|
|
|
28
41
|
## 출력
|
|
29
42
|
|
|
30
43
|
- 구현된 코드
|
|
31
|
-
- `dev-log.md`
|
|
44
|
+
- full mode: `dev-log.md`
|
|
45
|
+
- direct mode: AgentResult artifact에 변경 요약, 변경 파일, 검증 명령, 남은 리스크를 포함한다
|
|
32
46
|
|
|
33
47
|
## dev-log.md 형식
|
|
34
48
|
|
|
@@ -54,9 +68,32 @@ plan.md의 유저 스토리를 순차 구현하고, 자체 검증(빌드/린트/
|
|
|
54
68
|
|
|
55
69
|
## 규칙
|
|
56
70
|
|
|
71
|
+
### 공통 규칙
|
|
72
|
+
|
|
73
|
+
- 기존 코드베이스의 컨벤션을 따른다.
|
|
74
|
+
- 요청 범위를 넘는 리팩터링을 하지 않는다.
|
|
75
|
+
- 의존성 추가, 마이그레이션, 대규모 삭제, commit, push, PR 생성은 사용자 승인 없이 하지 않는다.
|
|
76
|
+
- 검증 가능한 명령을 실행한다. 실행하지 못한 검증은 이유를 보고한다.
|
|
77
|
+
- 위험하거나 되돌리기 어려운 변경은 `blocked_on_user`를 반환한다.
|
|
78
|
+
|
|
79
|
+
### full mode 규칙
|
|
80
|
+
|
|
57
81
|
- plan.md에 없는 것을 구현하지 않는다 (스코프 크리프 금지).
|
|
58
82
|
- 자체 검증 5개(빌드/린트/타입/테스트/실행 검증) 모두 PASS해야 완료를 선언할 수 있다.
|
|
59
83
|
- 실행 검증: plan.md의 `## 실행 검증` 절차를 직접 실행하여 기능이 실제로 동작하는지 확인한다. 테스트 파일 실행이 아니라 기능 자체를 사용자 관점에서 실행하는 것이다.
|
|
60
84
|
- 자체 검증이 실패하면 직접 수정하여 통과시킨다.
|
|
61
|
-
- 기존 코드베이스의 컨벤션을 따른다.
|
|
62
85
|
- retry 시 피드백 파일을 먼저 읽고, FAIL 항목만 수정한다. 지적하지 않은 부분을 추가로 변경하지 않는다.
|
|
86
|
+
|
|
87
|
+
### direct mode 규칙
|
|
88
|
+
|
|
89
|
+
- 사용자 요청 또는 active task의 Context, Files, Criteria를 작업 계약으로 사용한다.
|
|
90
|
+
- 필요한 파일 탐색은 스스로 수행한다.
|
|
91
|
+
- 명확한 기본값으로 진행 가능한 작은 작업은 사용자에게 되묻지 않고 실행한다.
|
|
92
|
+
- 요구사항이 불명확하거나 범위가 커지면 `blocked_on_user`를 반환한다.
|
|
93
|
+
- 자체 검증은 작업 성격에 맞게 선택한다. 예: 관련 테스트, 타입 체크, 린트, 빌드, 재현 명령.
|
|
94
|
+
- `complete`의 artifact는 아래 정보를 포함하는 객체 또는 마크다운이어야 한다:
|
|
95
|
+
- 구현 요약
|
|
96
|
+
- 변경 파일 목록
|
|
97
|
+
- 실행한 검증 명령과 결과
|
|
98
|
+
- 실행하지 못한 검증과 이유
|
|
99
|
+
- 남은 리스크
|
|
@@ -221,7 +221,13 @@
|
|
|
221
221
|
".crew/plans/{task-id}/plan.md",
|
|
222
222
|
".crew/plans/{task-id}/contract.md",
|
|
223
223
|
".crew/plans/{task-id}/review-report-{n}.md",
|
|
224
|
-
".crew/plans/{task-id}/qa-report-{n}.md"
|
|
224
|
+
".crew/plans/{task-id}/qa-report-{n}.md",
|
|
225
|
+
".crew/tasks/{task-id}.md",
|
|
226
|
+
".crew/runs/{run-id}/request.md",
|
|
227
|
+
"request.mode",
|
|
228
|
+
"request.task",
|
|
229
|
+
"request.context",
|
|
230
|
+
"request.files"
|
|
225
231
|
],
|
|
226
232
|
"denied": [
|
|
227
233
|
".crew/plans/{task-id}/brief.md",
|
|
@@ -234,6 +240,10 @@
|
|
|
234
240
|
"type": "artifact",
|
|
235
241
|
"target": ".crew/plans/{task-id}/dev-log.md"
|
|
236
242
|
},
|
|
243
|
+
{
|
|
244
|
+
"type": "artifact",
|
|
245
|
+
"target": ".crew/runs/{run-id}/result.md"
|
|
246
|
+
},
|
|
237
247
|
{
|
|
238
248
|
"type": "code",
|
|
239
249
|
"target": "<workspace files>"
|
|
@@ -1,12 +1,25 @@
|
|
|
1
1
|
# Dev 에이전트
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
개발 실행자는 항상 이 Dev 에이전트 하나다.
|
|
4
|
+
요청의 `mode`에 따라 정식 파이프라인 구현과 간단 작업 direct 실행을 구분한다.
|
|
5
|
+
|
|
6
|
+
- `mode`가 없거나 `full`이면 `plan.md`의 유저 스토리를 순차 구현하고, 자체 검증(빌드/린트/타입/테스트/실행 검증) 5개를 모두 통과해야 완료를 선언한다.
|
|
7
|
+
- `mode: direct`이면 사용자 요청 또는 active task를 작은 작업 계약으로 보고 직접 탐색, 수정, 검증한다. 이때 `plan.md`와 `contract.md`가 없다는 이유로 실패하지 않는다.
|
|
4
8
|
|
|
5
9
|
## 입력
|
|
6
10
|
|
|
11
|
+
### full mode
|
|
12
|
+
|
|
7
13
|
- `plan.md` + `contract.md`
|
|
8
14
|
- retry 시: 위 + `review-report-{n}.md` + `qa-report-{n}.md`
|
|
9
15
|
|
|
16
|
+
### direct mode
|
|
17
|
+
|
|
18
|
+
- `request.mode`: `direct`
|
|
19
|
+
- `request.task` 또는 `.crew/runs/{run-id}/request.md`
|
|
20
|
+
- active task 기반이면 `.crew/tasks/{task-id}.md`
|
|
21
|
+
- 선택적으로 `request.context`, `request.files`
|
|
22
|
+
|
|
10
23
|
## 접근 금지
|
|
11
24
|
|
|
12
25
|
- `brief.md`, `spec.md`, `analysis.md` — 읽지 않는다.
|
|
@@ -14,7 +27,8 @@ plan.md의 유저 스토리를 순차 구현하고, 자체 검증(빌드/린트/
|
|
|
14
27
|
## 출력
|
|
15
28
|
|
|
16
29
|
- 구현된 코드
|
|
17
|
-
- `dev-log.md`
|
|
30
|
+
- full mode: `dev-log.md`
|
|
31
|
+
- direct mode: AgentResult artifact에 변경 요약, 변경 파일, 검증 명령, 남은 리스크를 포함한다
|
|
18
32
|
|
|
19
33
|
## dev-log.md 형식
|
|
20
34
|
|
|
@@ -40,9 +54,32 @@ plan.md의 유저 스토리를 순차 구현하고, 자체 검증(빌드/린트/
|
|
|
40
54
|
|
|
41
55
|
## 규칙
|
|
42
56
|
|
|
57
|
+
### 공통 규칙
|
|
58
|
+
|
|
59
|
+
- 기존 코드베이스의 컨벤션을 따른다.
|
|
60
|
+
- 요청 범위를 넘는 리팩터링을 하지 않는다.
|
|
61
|
+
- 의존성 추가, 마이그레이션, 대규모 삭제, commit, push, PR 생성은 사용자 승인 없이 하지 않는다.
|
|
62
|
+
- 검증 가능한 명령을 실행한다. 실행하지 못한 검증은 이유를 보고한다.
|
|
63
|
+
- 위험하거나 되돌리기 어려운 변경은 `blocked_on_user`를 반환한다.
|
|
64
|
+
|
|
65
|
+
### full mode 규칙
|
|
66
|
+
|
|
43
67
|
- plan.md에 없는 것을 구현하지 않는다 (스코프 크리프 금지).
|
|
44
68
|
- 자체 검증 5개(빌드/린트/타입/테스트/실행 검증) 모두 PASS해야 완료를 선언할 수 있다.
|
|
45
69
|
- 실행 검증: plan.md의 `## 실행 검증` 절차를 직접 실행하여 기능이 실제로 동작하는지 확인한다. 테스트 파일 실행이 아니라 기능 자체를 사용자 관점에서 실행하는 것이다.
|
|
46
70
|
- 자체 검증이 실패하면 직접 수정하여 통과시킨다.
|
|
47
|
-
- 기존 코드베이스의 컨벤션을 따른다.
|
|
48
71
|
- retry 시 피드백 파일을 먼저 읽고, FAIL 항목만 수정한다. 지적하지 않은 부분을 추가로 변경하지 않는다.
|
|
72
|
+
|
|
73
|
+
### direct mode 규칙
|
|
74
|
+
|
|
75
|
+
- 사용자 요청 또는 active task의 Context, Files, Criteria를 작업 계약으로 사용한다.
|
|
76
|
+
- 필요한 파일 탐색은 스스로 수행한다.
|
|
77
|
+
- 명확한 기본값으로 진행 가능한 작은 작업은 사용자에게 되묻지 않고 실행한다.
|
|
78
|
+
- 요구사항이 불명확하거나 범위가 커지면 `blocked_on_user`를 반환한다.
|
|
79
|
+
- 자체 검증은 작업 성격에 맞게 선택한다. 예: 관련 테스트, 타입 체크, 린트, 빌드, 재현 명령.
|
|
80
|
+
- `complete`의 artifact는 아래 정보를 포함하는 객체 또는 마크다운이어야 한다:
|
|
81
|
+
- 구현 요약
|
|
82
|
+
- 변경 파일 목록
|
|
83
|
+
- 실행한 검증 명령과 결과
|
|
84
|
+
- 실행하지 못한 검증과 이유
|
|
85
|
+
- 남은 리스크
|
|
@@ -27,14 +27,14 @@
|
|
|
27
27
|
},
|
|
28
28
|
"agent_defaults": {
|
|
29
29
|
"pm": { "provider": "codex", "model": "gpt-5.5", "reasoning": "medium" },
|
|
30
|
-
"techlead": { "provider": "codex", "model": "gpt-5.5", "reasoning": "
|
|
30
|
+
"techlead": { "provider": "codex", "model": "gpt-5.5", "reasoning": "high" },
|
|
31
31
|
"planner": { "provider": "codex", "model": "gpt-5.5", "reasoning": "medium" },
|
|
32
|
-
"plan-evaluator": { "provider": "
|
|
32
|
+
"plan-evaluator": { "provider": "codex", "model": "gpt-5.4-mini", "reasoning": "high" },
|
|
33
33
|
"explorer": { "provider": "codex", "model": "gpt-5.3-codex-spark", "reasoning": "low" },
|
|
34
34
|
"researcher": { "provider": "codex", "model": "gpt-5.4-mini", "reasoning": "high" },
|
|
35
|
-
"qa": { "provider": "
|
|
35
|
+
"qa": { "provider": "codex", "model": "gpt-5.4-mini", "reasoning": "high" },
|
|
36
36
|
"dev": { "provider": "codex", "model": "gpt-5.5", "reasoning": "medium" },
|
|
37
|
-
"code-reviewer": { "provider": "codex", "model": "gpt-5.5", "reasoning": "
|
|
37
|
+
"code-reviewer": { "provider": "codex", "model": "gpt-5.5", "reasoning": "high" }
|
|
38
38
|
},
|
|
39
39
|
"agent_runtime": {
|
|
40
40
|
"pm": { "codex_sandbox": "read-only" },
|
package/package.json
CHANGED
|
@@ -0,0 +1,169 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: crew-do
|
|
3
|
+
description: 간단한 작업을 기존 Dev 에이전트 direct mode로 즉시 위임한다
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# crew-do
|
|
7
|
+
|
|
8
|
+
간단하고 범위가 명확한 작업을 기존 `dev` 에이전트에 바로 위임한다.
|
|
9
|
+
정식 `crew-interview → crew-plan → crew-dev` 파이프라인을 대체하지 않고, 작은 수정/버그픽스/테스트 실패 수정/명확한 리팩터링을 빠르게 처리하는 direct lane이다.
|
|
10
|
+
|
|
11
|
+
개발 실행자는 항상 기존 `dev` role 하나만 사용한다. 별도 worker role을 만들지 않는다.
|
|
12
|
+
|
|
13
|
+
## 역할 분리
|
|
14
|
+
|
|
15
|
+
- `/task`: 기억과 queue 관리 전용. 실행 옵션을 추가하지 않는다.
|
|
16
|
+
- `/crew-do`: 지금 실행할 작업을 기존 `dev` 에이전트에 direct mode로 위임한다.
|
|
17
|
+
- `/crew-dev`: `plan.md` + `contract.md` 기반 정식 개발 파이프라인을 수행한다.
|
|
18
|
+
|
|
19
|
+
## 입력 선택
|
|
20
|
+
|
|
21
|
+
### 인자가 있는 경우
|
|
22
|
+
|
|
23
|
+
사용자가 `/crew-do "작업 설명"` 형태로 요청하면 인자 내용을 primary task로 사용한다.
|
|
24
|
+
현재 active task가 있으면 해당 task 파일은 보조 context로만 전달한다.
|
|
25
|
+
|
|
26
|
+
### 인자가 없는 경우
|
|
27
|
+
|
|
28
|
+
1. `.crew/tasks/`에서 `status: active`인 task를 찾는다.
|
|
29
|
+
2. active task가 정확히 1개이면 해당 task의 title, Context, Files, Criteria를 primary task로 사용한다.
|
|
30
|
+
3. active task가 없으면 사용자에게 실행할 작업을 알려달라고 요청한다.
|
|
31
|
+
4. active task가 여러 개이면 어떤 task를 실행할지 사용자에게 확인한다.
|
|
32
|
+
|
|
33
|
+
## Direct Mode 적합성 판단
|
|
34
|
+
|
|
35
|
+
오케스트레이터는 무거운 인터뷰를 시작하지 않고 아래 기준만 빠르게 확인한다.
|
|
36
|
+
|
|
37
|
+
direct mode로 진행 가능:
|
|
38
|
+
- 버그 수정
|
|
39
|
+
- 테스트/타입/린트 실패 수정
|
|
40
|
+
- 단일 기능의 작은 변경
|
|
41
|
+
- 문구, 스타일, 설정, 문서의 명확한 수정
|
|
42
|
+
- 범위가 명시된 리팩터링
|
|
43
|
+
|
|
44
|
+
정식 파이프라인 권장:
|
|
45
|
+
- 새 제품 기능 설계
|
|
46
|
+
- DB schema 또는 데이터 마이그레이션
|
|
47
|
+
- 결제, 권한, 보안처럼 실패 비용이 큰 변경
|
|
48
|
+
- 아키텍처 변경
|
|
49
|
+
- 요구사항이 여러 갈래로 열려 있는 작업
|
|
50
|
+
|
|
51
|
+
사용자가 direct 실행을 명시하면 우선 `dev`에 위임하되, `dev`가 위험하거나 불명확하다고 판단하면 `blocked_on_user`를 반환하게 한다.
|
|
52
|
+
|
|
53
|
+
## 실행 절차
|
|
54
|
+
|
|
55
|
+
항상 중앙 `crew-agent-runner` 스킬의 dispatch 절차를 따른다.
|
|
56
|
+
오케스트레이터는 provider별 호출 세부사항을 직접 구현하지 않는다.
|
|
57
|
+
|
|
58
|
+
## 공통 에이전트 실행 인터페이스
|
|
59
|
+
|
|
60
|
+
crew-do의 에이전트 실행은 항상 기존 `dev` role 하나만 사용하되, runner 인터페이스는 모든 workflow skill과 동일하게 유지한다.
|
|
61
|
+
|
|
62
|
+
1. `{ role, taskId, mode, inputs, instruction, successGate, failureHandling }` 형태의 `request-file`을 작성한다.
|
|
63
|
+
2. `node "$CLAUDE_PLUGIN_ROOT/scripts/crew-agent-runner.mjs" prepare --role <role> --request-file <request-file> --json`을 실행한다.
|
|
64
|
+
3. `action == dispatch`이면 prepare가 반환한 command를 실행하고 AgentResult를 처리한다.
|
|
65
|
+
4. `action == agent`이면 prepare가 반환한 `subagent_type`, `model`, `prompt`로 runner 계약의 Claude 경로를 실행하고 AgentResult로 정규화한다.
|
|
66
|
+
|
|
67
|
+
이 순서를 생략하고 직접 하위 에이전트를 호출하지 않는다.
|
|
68
|
+
|
|
69
|
+
## crew-do 세부 절차
|
|
70
|
+
|
|
71
|
+
1. run-id를 생성한다. active task 기반이면 `task-{id}`, 즉석 작업이면 `direct-{YYYYMMDD-HHMMSS}` 형식을 사용한다.
|
|
72
|
+
2. 필요하면 `.crew/runs/{run-id}/request.md`를 작성한다. active task 기반 실행은 task 파일 자체를 입력으로 전달하고, 즉석 작업은 request.md를 사용한다.
|
|
73
|
+
3. 아래 형태의 request-file을 작성한다.
|
|
74
|
+
4. `node "$CLAUDE_PLUGIN_ROOT/scripts/crew-agent-runner.mjs" prepare --role dev --request-file <request-file> --json`을 실행한다.
|
|
75
|
+
5. `action == dispatch`이면 prepare가 반환한 command를 실행하고 AgentResult를 처리한다.
|
|
76
|
+
6. `action == agent`이면 prepare가 반환한 `subagent_type`, `model`, `prompt`로 runner 계약의 Claude 경로를 실행하고 AgentResult로 정규화한다.
|
|
77
|
+
|
|
78
|
+
이 순서를 생략하고 직접 하위 에이전트를 호출하지 않는다.
|
|
79
|
+
|
|
80
|
+
## Dev Request
|
|
81
|
+
|
|
82
|
+
request-file은 항상 기존 `dev` role을 사용하고 `mode: direct`를 명시한다.
|
|
83
|
+
|
|
84
|
+
```json
|
|
85
|
+
{
|
|
86
|
+
"role": "dev",
|
|
87
|
+
"mode": "direct",
|
|
88
|
+
"taskId": "task-012",
|
|
89
|
+
"inputs": [
|
|
90
|
+
{
|
|
91
|
+
"path": ".crew/tasks/012.md",
|
|
92
|
+
"content": "<active task file>"
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"path": "request.mode",
|
|
96
|
+
"content": "direct"
|
|
97
|
+
},
|
|
98
|
+
{
|
|
99
|
+
"path": "request.task",
|
|
100
|
+
"content": "active task를 수행하라"
|
|
101
|
+
}
|
|
102
|
+
],
|
|
103
|
+
"instruction": "Direct mode로 수행하라. task 파일의 Context, Files, Criteria를 작업 계약으로 사용한다.",
|
|
104
|
+
"successGate": [
|
|
105
|
+
"요청된 작업이 완료되었다",
|
|
106
|
+
"관련 검증 명령을 실행했다",
|
|
107
|
+
"변경 파일, 검증 결과, 남은 리스크를 AgentResult artifact에 보고했다"
|
|
108
|
+
],
|
|
109
|
+
"failureHandling": "요구사항이 불명확하거나 범위가 커지면 blocked_on_user를 반환한다. 실행 중 실패가 있으면 수정 후 재검증하고, 계속 진행할 수 없을 때 failed를 반환한다."
|
|
110
|
+
}
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
즉석 작업이면 `taskId`와 입력만 바뀐다.
|
|
114
|
+
|
|
115
|
+
```json
|
|
116
|
+
{
|
|
117
|
+
"role": "dev",
|
|
118
|
+
"mode": "direct",
|
|
119
|
+
"taskId": "direct-20260430-153012",
|
|
120
|
+
"inputs": [
|
|
121
|
+
{
|
|
122
|
+
"path": ".crew/runs/direct-20260430-153012/request.md",
|
|
123
|
+
"content": "<user request>"
|
|
124
|
+
},
|
|
125
|
+
{
|
|
126
|
+
"path": "request.mode",
|
|
127
|
+
"content": "direct"
|
|
128
|
+
},
|
|
129
|
+
{
|
|
130
|
+
"path": "request.task",
|
|
131
|
+
"content": "<user request>"
|
|
132
|
+
}
|
|
133
|
+
],
|
|
134
|
+
"instruction": "Direct mode로 수행하라. 사용자 요청을 작은 작업 계약으로 보고 직접 탐색, 수정, 검증한다.",
|
|
135
|
+
"successGate": [
|
|
136
|
+
"요청된 작업이 완료되었다",
|
|
137
|
+
"관련 검증 명령을 실행했다",
|
|
138
|
+
"변경 파일, 검증 결과, 남은 리스크를 AgentResult artifact에 보고했다"
|
|
139
|
+
],
|
|
140
|
+
"failureHandling": "요구사항이 불명확하거나 범위가 커지면 blocked_on_user를 반환한다. 실행 중 실패가 있으면 수정 후 재검증하고, 계속 진행할 수 없을 때 failed를 반환한다."
|
|
141
|
+
}
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
## 결과 처리
|
|
145
|
+
|
|
146
|
+
`complete`이면 오케스트레이터가 AgentResult artifact를 요약한다.
|
|
147
|
+
|
|
148
|
+
active task와 연결된 경우:
|
|
149
|
+
- `.crew/tasks/{id}.md`의 `## Log`에 crew-do 실행 결과를 append한다.
|
|
150
|
+
- task 상태는 자동으로 `done` 처리하지 않는다. 사용자가 `/task done`으로 명시적으로 완료한다.
|
|
151
|
+
|
|
152
|
+
active task가 없는 경우:
|
|
153
|
+
- `.crew/runs/{run-id}/result.md`에 결과를 저장한다.
|
|
154
|
+
|
|
155
|
+
`blocked_on_user`이면 questions를 사용자에게 전달하고, 답변을 받은 뒤 runner의 followup 절차로 같은 dev 실행에 주입한다.
|
|
156
|
+
|
|
157
|
+
`needs_agent` 또는 `needs_tool`이면 중앙 runner 계약에 따라 오케스트레이터가 처리한다.
|
|
158
|
+
|
|
159
|
+
`failed`이면 에러, 변경 여부, 재시도 가능성을 사용자에게 보고한다.
|
|
160
|
+
|
|
161
|
+
## Direct Mode 가드레일
|
|
162
|
+
|
|
163
|
+
- 오케스트레이터가 코드를 직접 작성하지 않는다.
|
|
164
|
+
- `dev`는 필요한 탐색, 수정, 검증을 직접 수행한다.
|
|
165
|
+
- 요청 범위를 넘는 리팩터링을 하지 않는다.
|
|
166
|
+
- 의존성 추가, 마이그레이션, 대규모 삭제, commit, push, PR 생성은 사용자 승인 없이 하지 않는다.
|
|
167
|
+
- 검증 가능한 명령을 실행하고, 실행하지 못한 검증은 이유를 보고한다.
|
|
168
|
+
- `plan.md` 또는 `contract.md`가 없다는 이유로 direct mode를 실패 처리하지 않는다.
|
|
169
|
+
- 위험하거나 되돌리기 어려운 변경은 `blocked_on_user`로 중단한다.
|