spr-ai-native 0.7.0 → 0.8.0

package/README.md

@@ -2,7 +2,7 @@
 
 AI 코딩 에이전트(Claude Code / Codex CLI / Cursor)로 개발할 때 쓰는 **개발 규칙 문서와 서브에이전트 프리셋**을 현재 프로젝트에 생성하는 CLI입니다.
 
-생성되는 것은 `pm` → `planner` → `engineer` → `qa` 4개 역할로 구성된 개발 워크플로우입니다. 프로젝트 스택에 종속되지 않는 범용 프리셋이며, 스택·검증 항목·금지 사항은 생성된 프로젝트 지침 문서에 채웁니다.
+생성되는 것은 **계획서 승인 → 구현 → 검증 → 작업 보고서**로 이어지는 개발 워크플로우입니다. 사람이 개입하는 지점은 계획서 승인 1회이고, 산출 문서는 `plan.md`와 `work-report.md` 둘뿐입니다. 프로젝트 스택에 종속되지 않는 범용 프리셋이며, 스택·검증 항목·금지 사항은 생성된 프로젝트 지침 문서에 채웁니다.
 
 ## 사용법
 
@@ -51,7 +51,7 @@ spr-ai-native claude
 | Codex CLI | 멀티 에이전트(서브에이전트) + skills 지원 버전 | `codex --version`, `~/.codex/config.toml`의 `[agents]` 확인 |
 | Cursor | **2.4 이상** (서브에이전트 도입 버전) | Cursor > About |
 
-서브에이전트를 쓸 수 없는 환경이면 `pm` 없이 `/planner` → `/engineer` → `/qa` 커맨드를 순서대로 직접 실행하는 방식으로도 사용할 수 있습니다.
+서브에이전트를 쓸 수 없는 환경이면 `/pm` 없이 `/engineer` → `/qa` 커맨드를 직접 실행하는 방식으로도 사용할 수 있습니다.
 
 ## 생성되는 파일
 
@@ -59,12 +59,10 @@ spr-ai-native claude
 
 ```
 CLAUDE.md                      프로젝트 지침 (템플릿 — 직접 채워야 함)
-.claude/agents/planner.md      서브에이전트
-.claude/agents/engineer.md
+.claude/agents/engineer.md     서브에이전트
 .claude/agents/qa.md
 .claude/commands/pm.md         워크플로우 진입점 (/pm)
-.claude/commands/planner.md    단계별 진입점 (/planner, /engineer, /qa)
-.claude/commands/engineer.md
+.claude/commands/engineer.md   단계별 진입점 (/engineer, /qa)
 .claude/commands/qa.md
 ~/.claude/CLAUDE.md            --global 지정 시, 공통 행동 지침
 ```
@@ -73,11 +71,9 @@ CLAUDE.md                      프로젝트 지침 (템플릿 — 직접 채워
 
 ```
 AGENTS.md                      프로젝트 지침 (템플릿)
-.codex/agents/planner.toml     서브에이전트 (TOML)
-.codex/agents/engineer.toml
+.codex/agents/engineer.toml    서브에이전트 (TOML)
 .codex/agents/qa.toml
 .codex/skills/pm/SKILL.md      워크플로우 진입점 ($pm)
-.codex/skills/planner/SKILL.md
 .codex/skills/engineer/SKILL.md
 .codex/skills/qa/SKILL.md
 ~/.codex/AGENTS.md             --global 지정 시, 공통 행동 지침
@@ -90,11 +86,9 @@ AGENTS.md                      프로젝트 지침 (템플릿)
 ```
 .cursor/rules/00-base.mdc      공통 행동 지침 (alwaysApply: true)
 .cursor/rules/10-project.mdc   프로젝트 지침 (템플릿)
-.cursor/agents/planner.md      서브에이전트
-.cursor/agents/engineer.md
-.cursor/agents/qa.md           (readonly: true — 코드 수정 불가)
+.cursor/agents/engineer.md     서브에이전트
+.cursor/agents/qa.md           (readonly: true — 코드·문서 수정 불가)
 .cursor/commands/pm.md         워크플로우 진입점 (/pm)
-.cursor/commands/planner.md
 .cursor/commands/engineer.md
 .cursor/commands/qa.md
 ```
@@ -119,135 +113,122 @@ Cursor는 전역 규칙을 파일로 두지 않고 Settings > Rules > User Rules
 
 사람이 정하는 것은 **`실행`(필수 / 선택 / 안 함)** 뿐입니다. "이 프로젝트가 무엇을 검증해야 하는가"는 사람의 판단이고, "그 명령이 무엇인가"는 프로젝트 설정에 이미 적혀 있는 사실이기 때문입니다.
 
-명령 칸이 비어 있으면 `engineer`가 매니페스트·CI 설정·도구 설정에서 **근거를 찾아** 실행하고, 찾은 명령을 §4 표에 적어 넣습니다. 다음 회차부터는 다시 찾지 않습니다. `qa`는 표를 고치지 않고 찾은 명령을 `qa.md`에 기록만 합니다.
+명령 칸이 비어 있으면 `engineer`가 매니페스트·CI 설정·도구 설정에서 **근거를 찾아** 실행하고, 찾은 명령을 §4 표에 적어 넣습니다. 다음 회차부터는 다시 찾지 않습니다. `qa`는 표를 고치지 않고 찾은 명령을 보고에 남깁니다.
 
 **근거를 못 찾으면 실행하지 않고 N/A로 보고합니다.** "아마 이 명령일 것"은 발견이 아니라 추측이며, 검증이 조용히 생략되는 것보다 N/A로 드러나는 편이 안전하기 때문입니다. 감시(watch) 모드로 도는 명령과 코드를 자동 수정하는 옵션이 붙은 명령도 같은 이유로 실행하지 않습니다.
 
 ## 워크플로우
 
 ```
-[사용자] 논의하거나 스펙 파일 준비
+[사용자] 요구사항 대화
    │
-[사용자] /pm TECG-582 위 논의대로 진행
+[사용자] /pm 위 논의대로 진행
    │
-[PM]     task_id 확인 → works/TECG-582/pm-brief.md 작성
-   ⏸ 멈춤 ──────────────────────────────────── 게이트 1 (착수 브리프 확인)
+[PM]     task_id 발급(브랜치명) → works/<task_id>/plan.md 작성
+   ⏸ 멈춤 ─────────────────────────────────── 게이트 (계획서 승인, 유일)
    │
-[사용자] 진행                    (고칠 게 있으면 pm-brief.md를 직접 편집한 뒤 "진행")
+[사용자] 승인  또는  D1=A, D2=B      (고칠 게 있으면 plan.md를 직접 편집)
    │
-[PM]     planner Phase 1 → works/TECG-582/pending.md
-   ⏸ 멈춤 ──────────────────────────────────── 게이트 2 (미결정 0개면 스킵)
+[PM]     engineer(구현 + 테스트) → qa(계획 대비 검증) ─┐
+         │                                             │ 실패하면 재개발 1회
+         └── qa PASS ──────────────────────────────────┘
+         works/<task_id>/work-report.md 작성 + 채팅 보고
    │
-[사용자] D1=A, D2=B
-   │
-[PM]     planner Phase 2 → engineer → qa ─┐
-         │                                 │ FAIL이면 engineer fix (기본 최대 3회)
-         └── qa PASS ──────────────────────┘
-         works/TECG-582/pm-report.md 작성 + 채팅 보고
-   │
-[사용자] 코드 리뷰 → 직접 커밋
+[사용자] 작업 보고서 검토 → 코드 리뷰 → 직접 커밋
 ```
 
-### 사용자가 실제로 입력하는 것: 3~4번
+### 통제 지점은 두 곳입니다
 
-| 순서 | 입력 | 비고 |
+이 프리셋의 목적은 산출물을 남기는 것이 아니라, **한정된 사람의 주의력을 통제가 가장 많이 사는 곳에 배치하는 것**입니다.
+
+| 지점 | 문서 | 사람이 하는 일 |
 |---|---|---|
-| 1 | `/pm TECG-582 <지시>` | 논의 후면 "위 논의대로", 파일이면 "docs/spec.md 기준으로" |
-| 2 | `진행` | 착수 브리프 확인 후 |
-| 3 | `D1=A, D2=B` | 미결정 사항이 없으면 이 단계 없음 |
-| 4 | (커밋) | PM은 커밋하지 않습니다 |
+| 위임 **전** | `plan.md` | 범위를 자르고, AI가 대신 내린 판단을 뒤집는다 |
+| 위임 **후** | `work-report.md` | 계획 대비 결과와 증거를 확인하고, 검증되지 않은 것을 본다 |
 
-3번 이후 **engineer → qa → fix 루프 → 완료 보고까지는 개입 없이 자동**입니다.
+그 사이는 통제할 수 없으므로 규칙으로 막습니다 — **계획 범위 밖은 건드리지 않는다.**
 
-### 착수 브리프 게이트
+### 계획서 승인 게이트
 
-`/pm`은 곧바로 위임하지 않고 먼저 `works/<task_id>/pm-brief.md`를 씁니다. **PM은 이전 대화를 보지만 서브에이전트는 보지 못하므로, 이 문서가 planner에게 전달되는 유일한 입력입니다.** 논의 내용이 압축되는 유일한 병목을 파일로 만들어 사용자가 검토할 수 있게 한 것입니다.
+`/pm`은 곧바로 위임하지 않고 먼저 `works/<task_id>/plan.md`를 씁니다. **대화를 나눈 메인 세션이 직접 쓰므로** 논의 내용을 서브에이전트에게 압축해 넘기며 새는 구간이 없습니다.
 
-brief에 들어가는 것: 목표 / 배경 / 범위(**포함 · 명시적 제외**) / 참고 자료 / 확인 필요 항목.
-brief에 들어가지 않는 것: 구현 방법, 파일 목록, 작업 단위, 테스트 전략 — planner의 몫입니다.
+계획서에 쓰는 것: 목표·완료 조건 / 범위(포함 · **제외**) / **결정 사항** / 작업 단위 / 테스트 시나리오.
+쓰지 않는 것: 함수 시그니처, 클래스 설계, 알고리즘, 코드 조각. 판별 기준은 하나입니다 — **계획서에 코드 블록이 등장하면 선을 넘은 것입니다.**
 
-채팅으로 정정하는 대신 **`pm-brief.md`를 직접 편집**하는 것을 권합니다. planner는 사용자가 확인한 그 파일을 그대로 읽습니다. `범위: 제외` 항목은 planner가 계획에 넣지 않고 `followups.md`로만 넘깁니다.
+**결정 사항** 표에는 `되돌리는 비용` 칸이 있습니다. 항목이 여럿이어도 사용자는 `높음`부터 보면 되므로 이 칸이 검토 시간을 배분합니다. 스키마나 공개 인터페이스처럼 나중에 바꾸기 비싼 것은 본문이 아니라 여기로 올라와 승인을 받습니다.
 
-### README는 두 역할이 나눠 씁니다
+작업 단위가 **7개**를 넘거나 영향 파일이 **15개**를 넘으면 PM이 계획서를 내놓기 전에 **작업을 쪼개자고 먼저 제안**합니다. 게이트가 1회뿐이라 한 번에 위임하는 양이 크면 통제할 수 없기 때문입니다.
 
-`works/` 밖에서 에이전트가 손대는 파일은 `README.md` 하나뿐입니다.
+### 테스트 기준은 계획서입니다
 
-| 구간 | 작성자 | 내용 |
-|---|---|---|
-| 실행 방법 | engineer | 설치 / 실행 / 테스트 명령을 **실제로 실행해본 그대로**. 환경변수는 이름과 예시값만 |
-| 개요 · 범위 · 알려진 한계 | pm | `pm-brief.md`의 `범위: 제외`와 약점 표에서 사용자에게 영향이 가는 것만 |
+커버리지 수치나 함수 개수를 기준으로 삼지 않습니다. **숫자를 목표로 주면 통과하기 쉬운 테스트가 생기기 때문**입니다 — 구현을 그대로 옮긴 assertion은 커버리지만 올리고 검증력을 남기지 않습니다. 그래서 사용자가 승인한 완료 판정 기준에만 테스트를 매답니다.
 
-PM은 engineer가 쓴 실행 방법 섹션을 수정하지 않습니다. 실제로 실행해보고 쓴 쪽이 engineer이기 때문입니다.
+| 구분 | 실행 | 기준 |
+|---|---|---|
+| 완료 조건 테스트 | 필수 | 계획서 각 작업 단위의 완료 판정 기준마다 최소 1개 |
+| 실패 경로 테스트 | 필수 | 계획서에 적힌 경계 · 오류 시나리오 |
+| 단위 테스트 | 선택 | 로직이 복잡한 순수 함수에 한해 engineer 재량 |
 
-**사용자에게 보이는 변화가 있을 때만 갱신합니다.** 내부 리팩터링이나 테스트 추가만으로는 README를 건드리지 않으며, 기존 README에 사람이 써 둔 내용은 지우지 않고 해당 섹션만 갱신합니다.
+qa는 테스트가 통과했는지만이 아니라 **완료 판정 기준마다 대응 테스트가 실재하는지**를 확인합니다. 없으면 통과가 아니라 **미검증**입니다.
 
-### 알려진 약점은 산출물에 남습니다
+### 작업 보고서
 
-완료 보고(`pm-report.md`)는 **판정과 함께 알려진 약점을 반드시 적습니다.** 판정이 `완료`여도 생략하지 않습니다.
+`work-report.md`는 PM이 쓰지만 **PM은 코드를 읽지 않습니다.** 그래서 증거(실행한 명령, 출력, 파일:라인)는 engineer · qa 응답에서 **원문 그대로** 옮기고, 응답에 없는 것은 보고서에 적지 않습니다.
 
-재료는 구현한 쪽에서 나옵니다. engineer는 회차 보고에 자기가 작성한 코드 중 **재현 조건을 적을 수 있는** 취약 지점을 남기고, QA는 미커버리지(N/A)를 남깁니다. PM은 이 둘과 `범위: 제외`·`followups.md`에서 파급이 큰 순으로 3개 내외를 추려 `지점 / 왜 위험한가 / 다음에 검증할 것`으로 정리합니다.
+계획서의 작업 단위와 보고서의 결과 표가 `T` 기준으로 1:1이라 두 문서를 나란히 놓고 대조할 수 있습니다.
 
-**PM은 코드를 읽지 않으므로 이 표는 추측이 아니라 인용입니다.** 재현 조건을 못 적는 것은 약점이 아니라 추측이라고 보고 걸러냅니다. 통과 보고서만 남기면 다음 사람이 같은 지뢰를 다시 밟기 때문입니다.
+`검증하지 못한 것` 섹션이 비어 있고 근거도 없는 보고서는 검증이 아니라 통과 선언입니다. qa는 계획에 없는데 바뀐 파일도 `git diff`로 대조해 **계획 이탈**로 보고합니다.
 
 ### 세션이 끊겨도 이어집니다
 
-상태가 대화가 아니라 파일에 있으므로, 새 세션에서 `/pm <task_id>`만 다시 호출하면 재개 지점을 판단합니다.
+상태가 대화가 아니라 파일에 있으므로, 새 세션에서 `/pm`을 다시 호출하면 재개 지점을 판단합니다.
 
 | `works/<task_id>/`에 있는 파일 | 재개 지점 |
 |---|---|
-| 없음 | 착수 브리프 작성 |
-| `pm-brief.md` | planner Phase 1 |
-| `pm-brief.md` + `pending.md` | 결정 회신 대기 (회신과 함께 호출하면 Phase 2) |
-| `plan.md`가 있으면 (위 조건보다 우선) | engineer부터. planner를 다시 부르지 않습니다 |
+| 없음 | 계획서 작성 |
+| `plan.md` (승인 회신 없음) | 사용자 검토 대기 |
+| `plan.md` (승인 회신 있음) | engineer부터 |
+| `work-report.md` | 완료된 작업 |
 
 ### 산출물
 
 ```
 works/<task_id>/
-  pm-brief.md      pm       착수 브리프 (사용자 확인 대상)
-  pending.md       planner  미결정 사항 (있을 때만)
-  plan.md          planner  구현 계획
-  decisions.md     planner  결정 로그
-  engineer.md      engineer 회차별 구현 보고
-  qa.md            qa       검증 결과
-  followups.md     3개 역할 append
-  pm-report.md     pm       완료 보고 (판정 · 알려진 약점)
+  plan.md          pm   계획서 (사용자 승인 대상)
+  work-report.md   pm   작업 보고서 (판정 · 증거 · 미검증 항목)
 ```
 
+**engineer와 qa는 파일을 만들지 않습니다.** 보고는 응답으로만 하고 PM이 보고서로 옮깁니다. 저장소 문서(README 포함)는 어느 역할도 건드리지 않으며, 예외는 프로젝트 지침 §4의 명령 칸 기입 하나뿐입니다.
+
 `.gitignore`는 건드리지 않으므로 `works/`를 커밋할지는 직접 결정하세요.
 
 ### 역할별 권한
 
 | 역할 | 코드 수정 | 산출물 | 비고 |
 |---|---|---|---|
-| pm | ✗ | pm-brief.md, pm-report.md, README(개요·범위·한계) | 메인 세션 역할 |
-| planner | ✗ (`works/`만) | pending.md, plan.md, decisions.md, followups.md | |
-| engineer | ✓ | engineer.md (회차별 append), README(실행 방법) | git 커밋/푸시 금지 |
-| qa | ✗ | qa.md, followups.md | Cursor에서는 `readonly: true`로 강제 |
+| pm | ✗ | `plan.md`, `work-report.md` | 메인 세션의 역할 |
+| engineer | ✓ | 없음 (응답으로 보고) | git 커밋 / 푸시 금지 |
+| qa | ✗ | 없음 (응답으로 보고) | 쓰기 도구 없음. Cursor에서는 `readonly: true` |
 
-- **PM은 서브에이전트가 아니라 메인 세션의 역할**입니다. `/pm`으로 진입하면 그 세션이 PM이 되어 나머지 3개에게 위임합니다. 서브에이전트가 다시 서브에이전트를 호출하는 중첩 위임에 의존하지 않으므로 세 도구에서 동일하게 동작합니다. 다만 도구 권한으로 PM의 코드 수정을 차단할 수 없어 프롬프트 규율에만 의존합니다 — 중첩 위임 의존성을 없애기 위한 트레이드오프입니다.
-- **task_id는 사용자에게 확인받습니다.** PM이 git 브랜치명에서 후보를 제안하지만 확정은 사용자가 합니다. 디렉터리명이 되므로 `/`나 공백이 들어가면 되묻습니다.
-- **engineer fix 재호출은 최대 3회**입니다 (engineer 호출 최대 4회, qa 호출 최대 4회). 3회 fix 후에도 FAIL이면 임의로 통과시키지 않고, `pm-report.md`에 `판정: 미완료(에스컬레이션)`으로 기록한 뒤 사용자에게 넘깁니다. fix 루프 없이 검증만 받고 싶으면 `/engineer` → `/qa`를 쓰세요.
+- **PM은 서브에이전트가 아니라 메인 세션의 역할**입니다. `/pm`으로 진입하면 그 세션이 PM이 되어 둘에게 위임합니다. 중첩 위임에 의존하지 않으므로 세 도구에서 동일하게 동작합니다. 다만 계획서를 본인이 썼기 때문에 그대로 구현하고 싶어지는데, 도구 권한으로 이를 막을 수 없어 프롬프트 규율에 의존합니다. **그 선을 지키는 것이 이 워크플로우의 존재 이유입니다.**
+- **task_id는 브랜치명의 마지막 `/` 뒤 토큰에서 자동 발급**하고, 무엇으로 정했는지 밝히고 시작합니다. `main` / `develop`처럼 부적합하거나 git 저장소가 아니면 사용자에게 묻습니다.
+- **재개발은 1회까지**입니다. 같은 자리에서 두 번 실패했다면 계획이 틀렸다는 신호이고 계획 판단은 사용자의 몫이므로, 임의로 통과시키지 않고 `판정: 미완`으로 올립니다.
 
 ### 어느 진입점을 쓸까
 
-`/pm`은 게이트 2개와 서브에이전트 호출 4회 이상을 포함합니다. **모든 작업에 쓰라고 만든 것이 아닙니다.**
-
 | 작업 | 진입점 | 이유 |
 |---|---|---|
-| 스택·범위·설계에 갈림길이 있다 | `/pm` | 미결정 사항을 사용자 결정으로 확정하는 것이 이 워크플로우의 값어치입니다 |
-| 계획은 이미 섰고 구현만 남았다 | `/engineer` → `/qa` | brief·pending·plan을 만들 이유가 없습니다 |
-| 계획만 받아보고 싶다 | `/planner` | 구현은 나중에 판단합니다 |
+| 범위 · 설계에 갈림길이 있다 | `/pm` | 결정 사항을 사용자 승인으로 확정하는 것이 이 워크플로우의 값어치입니다 |
+| 계획은 이미 섰고 구현만 남았다 | `/engineer` → `/qa` | 계획서를 새로 만들 이유가 없습니다 |
 | 방금 고친 것만 검증하고 싶다 | `/qa` | |
 | 오타 수정, 한 줄 변경 | **아무것도 쓰지 않음** | 워크플로우 비용이 작업보다 큽니다 |
 
 ```
-/planner TECG-582 <작업 주제>
 /engineer TECG-582
 /qa TECG-582
 ```
 
-개별 커맨드는 해당 서브에이전트만 호출하는 얇은 래퍼입니다. 브리프 게이트도, QA fix 루프도 없습니다 — QA가 FAIL이면 fix를 제안만 하고 재호출은 직접 하셔야 합니다. 산출물 파일 규약은 `/pm`과 동일하므로, 개별 커맨드로 시작했다가 도중에 `/pm`으로 넘어가도 이어집니다.
+개별 커맨드는 해당 서브에이전트만 호출하는 얇은 래퍼입니다. 승인 게이트도, 재개발 루프도 없습니다 — qa가 FAIL이면 재개발을 제안만 하고 호출은 직접 하셔야 합니다. 산출물 규약은 `/pm`과 동일하므로 도중에 `/pm`으로 넘어가도 이어집니다.
 
 ## 모델 변경
 
@@ -259,7 +240,7 @@ works/<task_id>/
 | Cursor | `.cursor/agents/<role>.md` | `model: inherit` → 모델 ID |
 | Codex CLI | `.codex/agents/<role>.toml` | `model = "..."` 줄 추가 (필요 시 `model_reasoning_effort` 함께) |
 
-각 파일에 안내 주석이 들어 있습니다. 예를 들어 `qa`는 저렴한 모델로, `planner`는 추론이 강한 모델로 두는 구성이 일반적입니다.
+각 파일에 안내 주석이 들어 있습니다. 예를 들어 `qa`는 저렴한 모델로, `engineer`는 추론이 강한 모델로 두는 구성이 일반적입니다.
 
 ## 커스터마이징
 
@@ -269,8 +250,8 @@ works/<task_id>/
 preset/common/
   base-rules.md          공통 행동 지침
   project-doc.md         프로젝트 지침 템플릿
-  roles/{planner,engineer,qa}.md   서브에이전트 정의 (도구 중립)
-  commands/{pm,planner,engineer,qa}.md   진입점 정의 (도구 중립)
+  roles/{engineer,qa}.md         서브에이전트 정의 (도구 중립)
+  commands/{pm,engineer,qa}.md   진입점 정의 (도구 중립)
 ```
 
 역할 본문은 한 번만 작성하고, 도구별 메타데이터(`tools`, `model`, `readonly`, TOML 변환)는 `src/targets/*.js`가 처리합니다. `{{PROJECT_DOC}}` 같은 플레이스홀더는 대상별로 치환됩니다.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spr-ai-native",
-  "version": "0.7.0",
+  "version": "0.8.0",
   "description": "AI 코딩 에이전트(Claude Code / Codex CLI / Cursor)용 개발 규칙·서브에이전트 프리셋 생성기",
   "type": "module",
   "bin": {

package/preset/common/commands/engineer.md

@@ -1,6 +1,6 @@
 ---
 name: engineer
-description: engineer 서브에이전트에게 구현 또는 QA fix를 위임합니다. PM 워크플로우 없이 구현 단계만 실행할 때 사용합니다.
+description: engineer 서브에이전트에게 구현 또는 재개발을 위임합니다. pm 워크플로우 없이 구현 단계만 실행할 때 사용합니다.
 argument-hint: <task_id> [fix]
 ---
 
@@ -11,12 +11,11 @@ argument-hint: <task_id> [fix]
 ## 전달할 내용
 
 - `task_id` — 입력의 첫 토큰. **없으면 사용자에게 먼저 요청합니다.** 임의로 정하지 마세요.
-- 모드 판단:
-  - **신규 구현** — `works/<task_id>/plan.md` 경로와 `decisions.md` 경로를 전달합니다. `plan.md`가 없으면 위임하지 말고 planner를 먼저 실행하라고 사용자에게 안내합니다.
-  - **QA Fix** — 입력에 `fix`가 있거나 `works/<task_id>/qa.md`가 FAIL/PARTIAL이면, `qa.md` 경로와 회차(`<N>/3`)를 전달합니다. 회차는 `engineer.md`의 기존 회차 섹션 수를 보고 계산합니다.
-- 다음 지시를 함께 전달합니다: 구현 보고를 `works/<task_id>/engineer.md`에 회차별 append, **git 커밋/푸시 금지**.
+- `works/<task_id>/plan.md` 경로. **계획서가 없으면 위임하지 말고 `/pm`으로 계획부터 세우라고 안내합니다.**
+- 입력에 `fix`가 있으면 재개발 모드입니다. 직전 QA 결과를 원문으로 함께 전달하고, **상한이 1회임을 명시합니다.**
+- 다음 지시를 함께 전달합니다: 보고는 응답으로만 하고 `works/` 아래에 파일을 만들지 말 것, **git 커밋 / 푸시 금지**.
 
 ## 이후 처리
 
-- 서브에이전트의 자체 검증 결과(검증 명령별 PASS/FAIL/N/A)를 그대로 사용자에게 전달합니다. **실행되지 않은 검증을 통과로 적지 마세요.**
+- 서브에이전트의 자체 검증 결과(항목별 PASS / FAIL / N/A)를 **그대로** 사용자에게 전달합니다. 실행되지 않은 검증을 통과로 적지 마세요.
 - **직접 코드를 수정하지 마세요.**