Community코딩 & 개발github.com

batch-features

붙여넣은 대략적인 기능 아이디어 목록을 각 항목에 대한 논의 후에 정형화된 트래커 이슈로 변환합니다. 아이디어 배치, 백로그 덤프, 수정 목록을 받거나 "이것들을 이슈로 등록해줘", "이 목록에서 티켓을 만들어줘", "이슈로 만들어줘", "기능들을 배치로 등록해줘", "백로그를 만들어줘", "할 일 목록이 있어"라고 말할 때 사용하세요.

batch-features란 무엇인가요?

이 스킬은 사용자가 제공한 대략적인 기능 아이디어 목록을 체계적으로 분석하고 정제하여 GitLab 또는 GitHub 이슈로 변환합니다. 각 아이디어에 대해 스킬이 먼저 재진술하고, 최대 두 가지 질문을 통해 구체적인 해석을 제안하며, 명확한 수용 기준과 유형을 확정하는 논의 과정을 거칩니다. 모든 항목에 대한 논의가 완료되면 전체 배치를 하나의 검토 테이블로 보여주고 사용자의 승인을 받은 후에만 이슈를 생성합니다. 이를 통해 불명확하거나 추측에 기반한 이슈가 생성되는 것을 방지하고, 에이전트가 추가적인 발견 작업 없이 바로 계획을 수립할 수 있도록 합니다.

지원 대상✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/hbardet/agent-skills/tree/main/skills/batch-features

Installed? Explore more 코딩 & 개발 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

Batch features

워크플로우의 전반부입니다. 후반부는 work-issue입니다.

백로그 덤프를 등록하는 것이 아닙니다. 대략적인 아이디어를 에이전트가 별도의 발견 작업 없이 계획을 세울 수 있는 이슈로 만드는 것입니다. 즉, 항목별 논의 후 승인을 한 번 받은 다음 등록합니다.

시작 시 공지: "저는 batch-features 스킬을 사용하여 이 목록을 이슈로 변환하고 있습니다."

설정

shared/는 이 스킬 옆에 있는 디렉토리입니다 — 설치 시 ~/.agents/skills/shared/ 또는 체크아웃 시 ../shared/에 있습니다. shared/... 경로가 확인되지 않으면 다른 경로를 사용하세요.

  1. 저장소의 AGENTS.md (또는 CLAUDE.md)를 읽으세요. 이는 규칙에 대한 바인딩입니다.
  2. .agent-skills/config.json이 있으면 읽고, 없으면 shared/config.md를 읽고 첫 실행 질문에 답한 후 파일을 작성하세요.
  3. shared/tracker-adapter.md, shared/labels.md, shared/issue-template.md를 읽으세요.
  4. 트래커를 감지하세요. 기존 레이블과 이슈를 확인하여 새 이슈가 적합하도록 하세요.
  5. 템플릿. 프로젝트에 이미 이슈 템플릿(.gitlab/issue_templates/*.md, .github/ISSUE_TEMPLATE/*.md)이 있는지 확인하세요. 있으면 사용하고 해당 경로를 issueTemplate으로 config에 기록하세요. 없으면 마지막에 shared/issue-template.md를 프로젝트에 커밋할 것을 한 번 제안하고, 무음으로 생성하지는 않습니다.

논의

목록을 항목별로 하나씩 처리합니다. 각 항목에 대해:

  1. 재진술하세요: 자신의 말로 무엇인지, 누구를 위한 것인지, 왜 지금인지 설명하세요. 이슈 본문의 의도 아래에 원문을 그대로 인용문으로 유지하세요 — 나머지가 영어인 경우에도 마찬가지입니다.
  2. 구체적인 해석을 제안하세요: "여기서 원하는 게 뭐예요?"가 아니라 "Y이기 때문에 이것을 X로 읽었습니다. Z를 의도했다면 말씀해주세요."라고 하세요.
  3. 최대 두 가지 질문을 하세요. 각 질문은 구체적이어야 하며, 사용자가 한 단어로 수락할 수 있는 기본값을 제시해야 합니다. 어떤 질문의 답이 무엇을 구축할지 가장 크게 바꿀 수 있는 질문을 하세요. 사용자가 완전한 검토를 요청했다면 더 많이 질문하고, 그렇지 않으면 두 개만 하세요.
  4. 두 가지를 확정하세요: 수용 기준(각각 관찰 가능하고 확인 가능해야 함)과 종류(feature / fix / refactor / chore)입니다. 크기, 영역, 종속성 등 다른 것은 확정하지 마세요.

논의 후에도 항목을 확정할 수 없으면 추측하지 말고 needs spec 메모와 함께 status::blocked로 표시하세요. 모호한 이슈를 등록하는 것은 등록하지 않는 것보다 나쁩니다.

모든 항목이 논의될 때까지 등록으로 넘어가지 마세요.

검토 테이블

마지막 항목 후에 전체 배치에 대한 하나의 테이블을 제시하세요:

| # | 제목 | 종류 |
|---|------|------|
| 1 | ...   | feature |

그런 다음 승인을 요청하세요. 사용자는 제목을 수정하거나, 항목을 삭제하거나, 종류를 변경할 수 있습니다. 이 승인 전에는 아무것도 등록되지 않습니다.

이슈 등록

승인된 각 항목에 대해 사용자가 선호하는 순서로(기본적으로 생성 순서):

  1. 트래커 CLI를 사용하여 이슈를 생성합니다. 본문은 프로젝트에 템플릿이 있으면 해당 템플릿을, 없으면 shared/issue-template.md를 사용합니다. 제목과 본문은 설정의 language(기본값 en)를 따릅니다.
  2. status::ready와 kind::<kind> 레이블을 적용합니다. 이슈 번호를 기록합니다.
  3. 이슈 URL을 보고합니다.

사용자의 목록에 순서가 암시된 경우("X puis Y"), 이슈 본문의 참고 아래에 기록하세요 — 종속성 관계나 레이블을 생성하지 마세요.

프로젝트에 이슈 템플릿이 없고 사용자가 제안을 수락한 경우, shared/issue-template.md를 트래커의 예상 경로에 한 번 커밋한 다음 등록하세요. 무음으로 생성하지 마세요.

보고

마지막에 다음을 출력하세요:

  • 이슈 URL, 각각 한 줄씩.
  • 배치 요약: N개 등록됨, M개 차단됨.
  • 한 줄: "작업을 시작하려면 work-issue <n>이라고 말씀해주세요."

하드 게이트

  • 검토 테이블 승인 없이는 이슈가 생성되지 않습니다.
  • 수용 기준 또는 검증 섹션이 비어 있는 이슈는 생성되지 않습니다.
  • 추측된 범위의 이슈는 생성되지 않습니다: 논의 후에도 모호하면 status::blocked입니다.
  • 이 스킬에서 이슈를 담당하거나 구현을 시작하지 마세요. 그것은 work-issue의 역할입니다.

관련 스킬