Stats
Actions
Tags
How this command is triggered — by the user, by Claude, or both
Slash command
/devoks-feature:devoks-new-feature-github-issueThe summary Claude sees in its command listing — used to decide when to auto-load this command
# GitHub Issue 기반 기능 구현 ## Overview GitHub에 등록된 **태스크 이슈 본문**을 SSOT로 삼아, 프로젝트 패턴에 맞게 기능을 설계·구현한다. [`devoks-new-feature-draft.md`](devoks-new-feature-draft.md)와 동일하게 **요구 정리 → 설계·승인 → 로컬 브랜치 생성 → 구현 → 마무리** 순서를 따른다. 본 Command에는 **제품·도메인 전용 용어·스택**을 넣지 않는다. ## 입력 실행 시 아래 중 하나를 제공받는다. | 입력 | 설명 | |------|------| | **이슈 URL** | `https://github.com/<owner>/<repo>/issues/<n>` | | **owner/repo#번호** | 예: `my-org/my-app#42` | | **이슈 본문 전체** | API·CLI 없이 붙여넣기만 가능한 경우 | `owner` / `repo`는 `git remote get-url origin`으로 파싱한다. 실패 시 사용자에게 직접 묻는다. ([`devoks-git-create-issue.md`](devoks-git-create-issu...
GitHub에 등록된 태스크 이슈 본문을 SSOT로 삼아, 프로젝트 패턴에 맞게 기능을 설계·구현한다. devoks-new-feature-draft.md와 동일하게 요구 정리 → 설계·승인 → 로컬 브랜치 생성 → 구현 → 마무리 순서를 따른다. 본 Command에는 제품·도메인 전용 용어·스택을 넣지 않는다.
실행 시 아래 중 하나를 제공받는다.
| 입력 | 설명 |
|---|---|
| 이슈 URL | https://github.com/<owner>/<repo>/issues/<n> |
| owner/repo#번호 | 예: my-org/my-app#42 |
| 이슈 본문 전체 | API·CLI 없이 붙여넣기만 가능한 경우 |
owner / repo는 git remote get-url origin으로 파싱한다. 실패 시 사용자에게 직접 묻는다. (devoks-git-create-issue.md의 저장소 식별과 동일한 패턴)
gh issue view — MCP 불가 시..github/ISSUE_TEMPLATE/feature_task.md의 최상위 섹션 제목을 그대로 키로 사용한다.
### Description### Objectives### Definition of Done### Additional Context### Decisions (With Agents)--- … ---)가 있으면 제거한 뒤 파싱한다.^### 로 시작하는 줄로 분할해 섹션 맵을 만든다.### Additional Context 안에 devoks-git-create-issue.md에서 정의한 선택 소제목이 있으면 하위 필드로 매핑한다: #### 배경 및 문제 정의, #### 범위, #### 범위 밖, #### 영향 파일, #### 미결정 사항. 없으면 “미사용”으로 두고 상위 섹션 전체만 사용한다.Additional Context 등에 > 로 시작하는 줄이 있으면, 파싱용으로 선행 >\s? 를 제거한 정규화 복사본을 만들어 요약·갭 분석에 쓴다(원문 보존이 필요하면 별도 유지)..github/ISSUE_TEMPLATE/feature_request.md처럼 ### Definition of Done 대신 ### Sub Tasks 만 있는 경우:
Sub Tasks를 구현·검증 체크리스트의 근거로 삼는다.Definition of Done 이 비어 있으면 완료 조건 갭 분석에 Sub Tasks를 반영한다.본문에 Related: #123, Closes #456 형태의 이슈 번호가 있으면, 디자인·스펙이 다른 이슈에 있을 수 있다. 해당 번호 이슈를 추가로 조회할지 사용자에게 확인하거나, 한 줄로 제안한다.
레이아웃·시각 스펙은 이슈 본문에 링크·식별자로 고정하거나, 연결 이슈·문서 한 곳에 모은다.
### Additional Context 안에 다음을 두면 파싱·갭 검사가 쉽다.
#### UI / Design — 디자인 도구 파일 URL + node-id(해당 시), 기획/스토리보드 링크, 핵심 화면 캡처(이슈 첨부) 등.Definition of Done(또는 Sub Tasks)에 UI 변경·화면 작업이 분명히 포함되는데, 위 소제목·링크·이미지·연결 이슈 중 어느 것도 없어 구현 근거가 없을 때 → 구현 착수 전 갭으로 차단하고, 링크·캡처·스펙·연결 이슈 중 최소 하나를 요청한다.저장소에 UI 구현 전용 절차 파일이 있으면(예: devoks-new-ui-draft.md), 이슈에 그 절차와 병행한다고 적거나, Agent 실행 시 해당 파일을 @로 함께 첨부하도록 안내한다. 본 파일에는 도구명·스택을 나열하지 않는다.
Description이 비었거나 플레이스홀더만 있다.Definition of Done 또는 Sub Tasks에 측정 가능한 완료 조건·검증이 없다.Decisions (With Agents) 가 비어 있고 스코프·기술 선택이 모호하다.섹션 | 상태(비어 있음/모호함/TBD) | 리스크계약·스코프에 큰 영향이 있는 내용은 추측으로 채우지 않는다. 프로젝트의 Fail-Fast·계약 검증 규칙은 .claude/CLAUDE.md, .claude/rules/, .claude/refs/를 따른다.
Grep, Glob).다음을 정리해 승인을 받은 뒤 코드 생성에 들어간다.
디자인 링크가 이슈에만 있고 채팅에 없으면, 승인 직전에 한 번 더 붙여 재확인하도록 요청할 수 있다.
사용자 규칙에 "승인 후 코드 생성"이 있으면 이 단계를 생략하지 않는다.
구현(코드 작성)에 들어가기 직전에, 이슈 목적과 devoks-git-commit-msg.md의 Conventional Commits 타입에 맞는 로컬 브랜치를 만든다.
feat, fix, docs, style, refactor, perf, test, build, ci, chore 중 이슈 성격에 가장 가까운 것을 고른다(상세는 devoks-git-commit-msg.md의 Rules).타입/이슈번호-간단-슬러그 — 이슈 번호는 GitHub 이슈 n을 사용하고, 슬러그는 kebab-case·짧게(예: feat/42-partner-etc-page).main) 최신을 기준으로 분기한다(git fetch 후 git checkout -b … 등 저장소 관례에 맞게).npm run lint(Bash)로 린트 확인.구현 시 규칙 본문을 이 파일에 복사하지 않고, 아래를 원본 그대로 읽어 적용한다.
| 참조 | 역할 |
|---|---|
.claude/CLAUDE.md | 저장소 프로젝트 구조 및 원칙 |
.claude/rules/agent-principles.md | 에이전트 행동 원칙 |
.claude/commands/README.md의 참조 규칙 파일 표 | .claude/rules/ 및 .claude/refs/ 인덱스 |
git commit / git push 하지 않는다.devoks-git-commit-msg.md 타입에 맞는 로컬 브랜치 생성(타입/이슈번호-슬러그).claude/CLAUDE.md / .claude/rules/ / .claude/refs/ 원본 참조npx claudepluginhub ridsync/devoks-team-harness --plugin devoks-feature