slack-review

Task Review - 작업 검증 및 완료 처리

Slack List 계획서의 미완료 항목을 확인하고, 코드 변경사항을 검증한 뒤 코드리뷰를 거쳐 Slack List 항목을 완료 상태로 업데이트한다.

사용자 입력 UI (v0.17+)

결정 지점은 AskUserQuestion 도구로 받는다. 옵션 2~4개 + description 구조화, preview로 미작업 목록·완료 대상 미리보기, multiSelect로 항목별 일괄 선택 지원.

사용법

/slack-review <SLACK_LIST_URL 또는 LIST_ID>

인자 없이 실행 시, .harness/config.env의 SLACK_LIST_URL을 사용한다. 설정이 없으면 docs/plans/에서 가장 최근 slack-list-*-plan.md 파일을 fallback으로 찾는다.

실행 흐름

Step 0: 설정 확인 및 URL 결정

.harness/config.env 파일에서 SLACK_BOT_TOKEN 또는 SLACK_USER_TOKEN이 있는지 확인한다.

없으면 안내 후 중단:

Slack 토큰이 설정되지 않았습니다.
먼저 /slack-setup 을 실행해 토큰을 저장하세요.

사용할 URL 결정 (우선순위 순):

1. 인자로 URL이 전달된 경우 → 해당 URL 사용 + .harness/config.env의 SLACK_LIST_URL을 업데이트
2. 인자 없음 + config.env에 SLACK_LIST_URL 존재 → 저장된 URL 사용
3. 인자 없음 + SLACK_LIST_URL 없음 → 사용자에게 URL 입력 요청 후 config.env에 저장

URL을 새로 저장/업데이트할 때:

grep -q "^SLACK_LIST_URL=" .harness/config.env \
  && sed -i '' "s|^SLACK_LIST_URL=.*|SLACK_LIST_URL=<URL>|" .harness/config.env \
  || echo "SLACK_LIST_URL=<URL>" >> .harness/config.env

Step 1: 미완료 요청사항 확인

Slack List에서 최신 데이터를 가져온다:

python3 skills/slack-plan/scripts/fetch_slack_list.py "<결정된 URL>"

가져온 아이템 중 상태가 완료가 아닌 항목을 필터링한다.

• 상태 컬럼 이름은 status, 상태, state 등 다양할 수 있으므로 유연하게 매칭한다.
• 완료로 간주하는 값: 완료, done, complete, completed, 백엔드 배포완료, 이슈아님
• 그 외 모든 값은 미완료로 간주한다.

미완료 항목이 없으면:

모든 요청사항이 완료 상태입니다. 처리할 항목이 없습니다.

라고 안내하고 종료한다.

미완료 항목 목록을 사용자에게 표로 보여준다:

## 미완료 요청사항 ({N}건)

| # | 요청 내용 | 현재 상태 | 담당자 |
|---|----------|----------|--------|
| 1 | ...      | ...      | ...    |

Step 2: 코드 변경 확인

각 미완료 항목에 대해 관련 코드 변경이 있는지 확인한다.

매칭 방법 (우선순위 순):

1. plan-execute 기록 우선 사용 — .harness/plans/에서 가장 최근 *-execute.json을 Read:

   • 각 TODO 결과의 slack_record_ids와 Slack 아이템 record_id를 직접 매칭
   • 해당 TODO의 files_changed 목록을 그대로 사용 (추측 불필요)
   • TODO status로 진행 상태 바로 판정:
     • completed → 작업됨
     • partial → 부분 작업
     • failed → 미작업
   • 매칭된 아이템은 fallback 대상에서 제외

2. Fallback: plan 파일 + git log — 실행 기록에서 매칭되지 않은 아이템에 한해:

   • docs/plans/slack-list-*-plan.md의 "원문 요청 요약" 테이블에서 record_id 컬럼 확인
   • 해당 아이템과 연결된 TODO의 예상 작업 범위 파일 목록 파악
   • .harness/reviews/*/ 폴더의 최근 리뷰 이후 git log --since + git diff로 실제 변경 수집
   • 파일 목록이 겹치거나 커밋 메시지에 item 키워드가 나타나면 작업됨으로 판정

각 항목별 작업 진행 상태를 판정한다:

• 작업됨: plan-execute completed 또는 관련 코드 변경 확인
• 미작업: 실행 기록/관련 변경 모두 없음
• 부분 작업: plan-execute partial 또는 일부 파일만 변경됨

결과를 사용자에게 보여준다:

## 작업 진행 현황

| # | 요청 내용 | 진행 상태 | 관련 변경 |
|---|----------|----------|----------|
| 1 | ...      | 작업됨    | src/foo.ts (+23/-5), ... |
| 2 | ...      | 미작업    | -        |

미작업 항목이 있으면 사용자에게 진행 현황 표를 먼저 보여준 뒤, AskUserQuestion으로 계속 여부를 묻는다:

AskUserQuestion({
  questions: [{
    question: "미작업 항목이 있습니다. 작업됨/부분 작업 항목만 대상으로 계속 진행할까요?",
    header: "Proceed",
    options: [
      { label: "작업됨/부분만 진행 (Recommended)",
        description: "미작업 항목은 건너뛰고, 작업됨과 부분 작업 항목에 대해 코드리뷰·완료 처리 진행",
        preview: "```\n<진행 현황 표 전체>\n```" },
      { label: "미작업 항목 원인 먼저 확인",
        description: "중단하고 미작업 항목의 의도된 담당자/일정을 사용자가 확인한 뒤 다시 실행" },
      { label: "전체 중단",
        description: "이번 세션 종료. Slack List에는 변경 없음." }
    ],
    multiSelect: false
  }]
})

Step 3: 코드리뷰 진행

작업됨으로 판정된 항목 전체에 대해 /code-review 스킬을 호출하여 다중 에이전트 리뷰를 수행한다.

1. 관련 변경사항의 diff 범위를 /code-review에 전달 (Step 2에서 결정된 범위)
2. /code-review가 .harness/reviews/{TS}-{SUM}/{TS}-{SUM}-review.json을 생성할 때까지 대기
3. 생성된 리뷰 JSON의 findings를 항목별로 매핑하여 verdict를 판정한다:
   • APPROVE: 해당 항목 관련 파일에 critical/major severity 없음
   • REQUEST_CHANGES: critical 또는 major severity + scope: fix_now 존재
   • NEEDS_DISCUSSION: major severity + scope: followup 또는 판정 애매

결과를 사용자에게 보여준다:

## 코드리뷰 결과

### 항목 #1: <요청 내용 요약>
- **Verdict**: APPROVE
- **변경 파일**: src/foo.ts, src/bar.ts
- **소견**: 정상적으로 구현됨. 추가 이슈 없음.

### 항목 #2: <요청 내용 요약>
- **Verdict**: REQUEST_CHANGES
- **변경 파일**: src/baz.ts
- **Findings**:
  - 🔴 Critical: ...
  - 🟡 Suggestion: ...

REQUEST_CHANGES 또는 NEEDS_DISCUSSION verdict가 있으면 해당 항목은 완료 처리하지 않고 사용자에게 수정을 안내한다.

Step 4: 완료 항목 코멘트 표시

APPROVE를 받은 항목에 대해 작업 내용을 코멘트로 정리한다.

코멘트 작성을 위해 변경사항을 분석한다:

1. 변경된 API 스펙 파악: diff에서 라우트, 엔드포인트, request/response 스키마, 상태코드 변경을 추출한다.
   • 새로 추가된 엔드포인트
   • 변경된 request 파라미터 또는 response 필드
   • 삭제된 엔드포인트
2. 변경된 유저 플로우 파악: diff에서 비즈니스 로직, 조건 분기, 처리 순서 변경을 추출한다.
   • 새로 추가된 플로우 (예: 이메일 인증 단계 추가)
   • 변경된 플로우 (예: 결제 전 재고 확인 로직 추가)
   • 삭제된 플로우

Slack List 아이템에 코멘트를 추가한다:

[Task Review] 백엔드 작업 완료
- 처리일: YYYY-MM-DD
- 커밋: abc1234 - <커밋 메시지>
- 변경 파일: src/foo.ts, src/bar.ts
- 리뷰 결과: APPROVE

📡 변경된 API 스펙:
- [추가] POST /api/v1/orders - 주문 생성 엔드포인트
- [변경] GET /api/v1/users - response에 `role` 필드 추가
- [삭제] DELETE /api/v1/legacy/... - 레거시 엔드포인트 제거

🔀 변경된 유저 플로우:
- [추가] 주문 생성 시 재고 확인 → 결제 → 주문 확정 플로우
- [변경] 로그인 후 이메일 미인증 사용자는 인증 페이지로 리다이렉트

API 스펙 또는 유저 플로우 변경이 없는 경우 해당 섹션은 "변경 없음"으로 표기한다.

update_slack_list.py의 --field 옵션으로 코멘트를 작성한다:

# 레코드별 다른 코멘트 작성 (stdin JSON)
cat <<'EOF' | python3 skills/slack-plan/scripts/update_slack_list.py <LIST_ID> --field "백엔드 변경 사항"
[
  {"record_id": "Rec...", "value": "[Task Review] 백엔드 작업 완료\n- 처리일: YYYY-MM-DD\n- 커밋: abc1234\n- 변경 파일: src/foo.ts, src/bar.ts\n- 리뷰 결과: APPROVE\n\n📡 변경된 API 스펙:\n- ...\n\n🔀 변경된 유저 플로우:\n- ..."},
  {"record_id": "Rec...", "value": "[Task Review] 백엔드 작업 완료\n- 처리일: ..."}
]
EOF

Step 5: 백엔드 배포완료 상태로 변경

APPROVE된 항목의 Slack List 상태를 백엔드 배포완료로 변경한다.

update_slack_list.py의 --status 옵션으로 상태를 변경한다 (스키마 조회 및 select 옵션 매칭을 스크립트가 자동 처리):

python3 skills/slack-plan/scripts/update_slack_list.py <LIST_ID> \
  --record Rec... Rec... \
  --status "백엔드 배포완료"

Step 6: 최종 요약

전체 처리 결과를 요약한다:

## Task Review 완료

### 처리 결과
| # | 요청 내용 | 리뷰 결과 | Slack 상태 |
|---|----------|----------|-----------|
| 1 | ...      | APPROVE  | 백엔드 배포완료 ✅ |
| 2 | ...      | REQUEST_CHANGES | 미변경 ⚠️ |
| 3 | ...      | 미작업    | 미변경 ⏳ |

### 요약
- 전체 미완료 항목: {N}건
- 코드리뷰 통과: {X}건
- 완료 처리됨: {X}건
- 수정 필요: {Y}건
- 미작업: {Z}건

주의사항

1. 자동 완료 처리 전 반드시 사용자 확인 (AskUserQuestion + multiSelect): APPROVE 항목을 Slack에 반영하기 전에 항목별 개별 선택 UI로 확인:

   AskUserQuestion({
     questions: [{
       question: "다음 APPROVE 항목 중 어떤 것을 '백엔드 배포완료'로 변경할까요?",
       header: "Confirm items",
       multiSelect: true,
       options: [
         { label: "항목 #1: <요청 요약>",
           description: "파일: src/foo.ts, src/bar.ts · 리뷰 APPROVE · 코멘트 자동 작성" },
         { label: "항목 #2: <요청 요약>",
           description: "파일: src/baz.ts · 리뷰 APPROVE · 코멘트 자동 작성" },
         // 최대 4개. 항목이 더 많으면 "일괄 처리" vs "개별 선택" 질문을 먼저 추가
         { label: "전체 제외하고 중단",
           description: "어떤 항목도 Slack에 반영하지 않음" }
       ]
     }]
   })
   

   • 선택된 항목만 update_slack_list.py로 반영
   • 5개 이상인 경우: 먼저 "일괄/개별 선택" 선분기 질문 (2-option)을 띄워 일괄이면 그대로 진행, 개별이면 페이지네이션으로 4개씩 반복 질문
2. 코드리뷰는 보수적으로: 의심스러운 변경은 REQUEST_CHANGES로 판정한다.
3. Slack API 실패 시 graceful 처리: API 호출 실패 시 에러를 표시하되 나머지 항목은 계속 처리한다.
4. 계획서가 없는 경우: docs/plans/에 관련 계획서가 없으면 커밋 메시지와 diff만으로 판단하되, 매칭 정확도가 낮을 수 있음을 사용자에게 알린다.