개발자 확인 게이트 공통 패턴 스킬. AskUserQuestion 기반으로 개발자의 의사결정을 받는 표준 패턴을 제공합니다. /specify, /develop, /fix-review 커맨드에서 공통으로 활용됩니다.
How this skill is triggered — by the user, by Claude, or both
Slash command
/go-clean-arch-toolkit:developer-gateThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
모든 워크플로우에서 **개발자 확인이 필요한 시점**에 `AskUserQuestion` 도구를 사용하여 표준화된 의사결정 게이트를 제공합니다.
모든 워크플로우에서 개발자 확인이 필요한 시점에 AskUserQuestion 도구를 사용하여 표준화된 의사결정 게이트를 제공합니다.
핵심 원칙:
| 항목 | 설명 |
|---|---|
| Q&A 이슈 구체화 | /specify에서 순차 질문으로 요구사항 도출 |
| 기술 설계 확인 | /specify에서 파일 목록, 마이그레이션, DI 확인 |
| 구현 승인 게이트 | /develop에서 구현 계획을 개발자가 승인 |
| 리뷰 반영 확인 | /fix-review에서 수정 사항 목록 확인 |
이슈의 핵심 기능을 확인하는 첫 번째 질문입니다.
AskUserQuestion:
questions:
- question: |
이슈 'PD-210: 알림 설정 기능'에 대해 구체화하겠습니다.
현재 이슈 내용: "사용자별 알림 설정 CRUD"
이 기능의 핵심 동작을 설명해주세요.
header: "기능 확인"
options:
- label: "알림 유형별 ON/OFF"
description: "이메일, 푸시 등 알림 유형별로 활성화/비활성화 설정"
- label: "알림 스케줄 설정"
description: "알림을 받을 시간대와 빈도를 설정"
multiSelect: false
새로운 데이터 구조가 필요한 경우 필드를 확인합니다.
AskUserQuestion:
questions:
- question: |
알림 설정 엔티티에 추가할 필드를 확인합니다.
| 필드 | Go 타입 | GORM 태그 | Nullable | 설명 |
|------|---------|-----------|----------|------|
| UserID | uint | not null;uniqueIndex | N | 사용자 ID |
| EmailEnabled | bool | not null;default:true | N | 이메일 알림 |
| PushEnabled | bool | not null;default:true | N | 푸시 알림 |
| SlackEnabled | bool | not null;default:false | N | Slack 알림 |
이 필드 정의가 맞나요?
header: "필드 확인"
options:
- label: "이대로 진행"
description: "위 필드 정의로 구현합니다"
- label: "수정 필요"
description: "필드를 추가하거나 수정합니다"
multiSelect: false
AskUserQuestion:
questions:
- question: |
API 엔드포인트를 확인합니다.
| 메서드 | 경로 | 권한 | 설명 |
|--------|------|------|------|
| GET | /api/v1/notification-settings | 인증 | 내 설정 조회 |
| PUT | /api/v1/notification-settings | 인증 | 설정 수정 |
이 엔드포인트 정의가 맞나요?
header: "API 확인"
options:
- label: "이대로 진행"
description: "위 엔드포인트로 구현합니다"
- label: "수정 필요"
description: "엔드포인트를 추가하거나 수정합니다"
multiSelect: false
구체화된 스펙 + 기술 설계를 최종 확인합니다.
AskUserQuestion:
questions:
- question: |
PD-210 구체화 결과입니다.
[요구사항]
- 사용자별 알림 설정 CRUD
- 알림 유형별 ON/OFF
- 기본값 모두 ON
[기술 설계]
변경 파일:
- internal/domain/notification_setting.go (신규)
- internal/repository/.../notification_setting_pg.go (신규)
- internal/api/domain/notification_setting.go (신규)
- internal/api/usecase/.../notification_setting_ucase.go (신규)
- internal/api/delivery/.../notification_setting_http.go (신규)
- cmd/api/main.go (수정)
마이그레이션: 있음 (notification_settings 테이블)
DI 변경: 있음
테스트: Usecase table-driven
이 내용으로 이슈를 업데이트할까요?
header: "스펙 확인"
options:
- label: "승인, 이슈 업데이트"
description: "이 내용으로 Linear 이슈 description을 업데이트합니다"
- label: "수정 필요"
description: "내용을 수정합니다"
multiSelect: false
AskUserQuestion:
questions:
- question: |
PD-210 구현 계획입니다.
[태스크 목록]
1. migrations/20260218_notification_settings.sql - 테이블 생성
2. internal/domain/notification_setting.go - 엔티티 + Repository
3. internal/repository/.../notification_setting_pg.go - Repository 구현
4. internal/api/domain/notification_setting.go - Usecase + DTO
5. internal/api/usecase/.../notification_setting_ucase.go - CRUD
6. internal/api/delivery/.../notification_setting_http.go - HTTP 핸들러
7. cmd/api/main.go - DI 등록
8. notification_setting_ucase_test.go - 테스트
[마이그레이션] 있음
[테스트] Usecase table-driven 테스트
[DI 변경] 있음
이 계획으로 진행해도 될까요?
header: "구현 승인"
options:
- label: "승인, 구현 시작"
description: "이 계획대로 구현을 시작합니다"
- label: "태스크 수정 필요"
description: "태스크 목록을 수정합니다"
- label: "테스트 범위 조정"
description: "테스트 범위를 변경합니다"
multiSelect: false
AskUserQuestion:
questions:
- question: |
PR #45에 3건의 리뷰 코멘트가 있습니다.
1. `notification_setting_http.go:25` - Swagger 주석 보강 필요
2. `notification_setting_ucase.go:42` - 에러 메시지 한국어로 통일
3. `notification_setting.go:15` - 한국어 주석 추가
어떻게 반영할까요?
header: "리뷰 반영"
options:
- label: "전부 반영"
description: "3건 모두 수정합니다"
- label: "선택적 반영"
description: "반영할 항목을 선택합니다"
- label: "확인만 하고 직접 수정"
description: "수정 사항을 확인만 합니다"
multiSelect: false
| ID | 안티패턴 | 올바른 패턴 |
|---|---|---|
| G-001 | 개발자 확인 없이 Linear 이슈 업데이트 | 반드시 확인 후 업데이트 |
| G-002 | 개발자 확인 없이 구현 시작 | 구현 계획 승인 필수 |
| G-003 | 5개 이상 선택지 제시 | 2-4개로 제한 (Other 자동 제공) |
| G-004 | 질문에 현재 상황 요약 누락 | 컨텍스트 포함 필수 |
| 게이트 | 반드시 포함할 정보 |
|---|---|
| 기능 확인 | 이슈 제목, 현재 description, 추정 동작 |
| 필드 확인 | 필드명, Go 타입, GORM 태그, Nullable 여부 |
| API 확인 | HTTP 메서드, 경로, 권한, 설명 |
| 스펙 확인 | 요구사항 요약 + 기술 설계 전체 |
| 구현 승인 | 태스크 목록, 마이그레이션 유무, 테스트 범위, DI 변경 |
| 리뷰 반영 | 리뷰 코멘트 목록 (파일:줄 + 내용) |
게이트 자체는 AskUserQuestion 도구 호출이므로 자동 테스트 대상이 아닙니다.
검증 방법: 각 커맨드를 실행하여 적절한 시점에 질문이 나오는지 수동 확인합니다.
| 연계 대상 | 활용 방식 |
|---|---|
/specify | Q&A 구체화 게이트 (패턴 1, 2, 3, 4) |
/develop | 구현 승인 게이트 (패턴 5) |
/fix-review | 리뷰 반영 확인 게이트 (패턴 6) |
linear-workflow | 게이트 승인 후 Linear 연동 |
| 메트릭 | 설명 |
|---|---|
게이트 스킵 수 | 개발자 확인 없이 진행된 횟수 (0이어야 함) |
게이트 응답 시간 | 개발자가 응답하는 데 걸린 평균 시간 |
수정 요청 비율 | "수정 필요" 선택 비율 (구체화/구현 품질 지표) |
npx claudepluginhub yangtaeyoung/go-clean-arch-toolkit --plugin go-clean-arch-toolkitImplements Linear issues via full TDD workflow, automated planning, parallel code reviews for security and Rails best practices, feedback fixes, and PR creation with Linear integration. Use on issue IDs like TRA-9 or DEV-123.
Generates structured GitHub issues with TDD plans, acceptance criteria, and agent instructions for autonomous PR lifecycle management.
Opens a problem-statement conversation that explores a topic and files a GitHub issue with What/Why/Acceptance Criteria. Use to clarify scope before planning implementation.