Community코딩 & 개발github.com

steve-swanson/execute-work

사용자가 승인된 구현 계획이나 정의된 코딩 작업을 하위 에이전트, 분리된 Git 워크트리, fast-forward 통합을 통해 실행하도록 요청할 때 사용합니다. execute-work 스킬 사용 요청을 포함합니다.

execute-work란 무엇인가요?

이 스킬은 개발자가 승인된 구현 계획을 자동으로 실행할 수 있도록 설계된 오케스트레이션 도구입니다. `develop` 브랜치에서 하나의 의미 있는 조정(coordination) 브랜치를 생성하고, 하위 에이전트(subagent)에게 작업을 위임하며, 각 하위 에이전트는 별도의 Git 워크트리(worktree)에서 독립적으로 작업합니다. 작업이 완료되면 모든 브랜치를 fast-forward 방식으로 조정 브랜치에 통합하고, 최종적으로 `develop` 브랜치를 대상으로 풀 리퀘스트(PR)를 생성합니다. 이 스킬은 Claude Code, Codex 등 Git 워크트리 기반 작업을 지원하는 AI 에이전트 플랫폼에서 사용할 수 있으며, 브랜치 생성, 리베이스, 워크트리 정리, PR 생성까지의 전체 워크플로우를 자동화합니다. 주요 장점은 복잡한 협업 작업을 일관된 프로세스로 관리하고, 하위 에이전트의 병렬 실행, 충돌 해결, 자동 정리, 최종 결과 보고를 포함하여 개발자의 수동 개입을 최소화한다는 점입니다.

지원 대상~Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/steve-swanson/work-skills/tree/HEAD/skills/execute-work

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

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

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

문서

작업 실행(Execute Work)

develop 브랜치에서 하나의 의미 있는 브랜치로 승인된 작업을 자동으로 실행합니다. 구현을 별도 워크트리의 하위 에이전트에게 위임한 후, 완료된 브랜치를 fast-forward 방식으로 해당 조정 브랜치에 통합하고, 정리한 뒤 develop 브랜치로의 리뷰 준비 완료 풀 리퀘스트를 생성합니다.

호출 시 로컬 태스크 브랜치, 워크트리, 커밋, 자신의 미게시 태스크 브랜치 리베이스, 조정 브랜치로의 fast-forward 병합, 정리된 완전 통합 태스크 워크트리 및 브랜치 제거, 완료된 조정 브랜치 푸시, develop 브랜치로의 PR 생성을 승인합니다. 해당 작업에 대해 추가 확인 없이 진행합니다. 사용자의 범위 및 저장소 지침을 따르며, 명시적인 로컬 전용 또는 PR 미생성 재정의를 포함합니다. PR 병합 및 배포는 이 스킬의 권한 밖입니다. 기존 금지 사항은 계속 유지합니다.

1. 조정 브랜치 준비

승인된 계획, 해당 AGENTS.md 및 필요한 프로젝트 지침을 읽습니다. 작업이 이미 정의된 경우 추가 설계나 승인 없이 실행합니다. 누락된 필수 요구사항에 대해서만 하나의 집중된 질문을 합니다.

상태, refs, 기존 워크트리를 검사합니다. 관련 없는 편집 및 체크아웃은 보존하며, 리셋, 스태시, 용도 변경하지 않습니다. 설정된 원격에서 develop 브랜치를 가져와(fetch) 사용 가능하면 그 가져온 tip을 사용합니다. 가져오기가 불가능한 경우 제한 사항을 공개하고 기존 로컬 develop ref를 사용하며, 둘 다 없으면 기준 브랜치를 묻습니다. 다른 브랜치를 조용히 대체하지 마십시오.

브랜치나 워크트리를 생성하기 전에 git worktree list --porcelain, 로컬 브랜치 이름, 관리형 워크트리 첨부 정보(가능한 경우)를 캡처합니다. 태스크 체크리스트에 실행 소유 인벤토리를 유지합니다: 브랜치, 절대 경로, 소유자/에이전트, 관리 유형 및 ID, 최종 커밋, 정리 상태. 이 실행을 위해 생성된 모든 태스크, 헬퍼, 리뷰어, 재시도, 하위 에이전트 체크아웃을 포함하며, 폐기되었거나 변경 사항이 없는 경우도 포함합니다. 코디네이터는 이 전체 인벤토리의 정리를 담당합니다. 기존 및 관련 없는 브랜치/워크트리는 보존하며, 일치하는 이름 접두사가 소유권 증거가 되지 않습니다.

전용 조정 워크트리와 브랜치를 생성합니다. 관례적 브랜치 스타일(Conventional Branch style)로 이름을 지정합니다. <type>/<short-description>, 소문자 및 하이픈 사용, 예: feat/store-invitation-recovery. 작업에 맞는 타입을 선택합니다: feat (새 동작), fix (버그 수정), refactor, perf, docs, test, chore (도구 또는 유지보수), 또는 ci. 사용자나 저장소가 다른 규칙을 지정하는 경우(예: AGENTS.md에서) 그 규칙을 따릅니다. 이름에 integration을 포함하지 마십시오. 조정 기준 커밋을 기록합니다. 재개된 호출에서는 이 실행의 조정 브랜치/워크트리와 인벤토리를 재사용하고, 처음부터 다시 시작하는 대신 상태를 검사합니다.

2. 분할 및 위임

인도물과 파일 소유권에 따라 분할합니다. 사용 가능한 에이전트 용량 내에서 독립적인 태스크를 동시에 실행하고, 의존성과 중복 편집을 순차적으로 처리합니다. 각 태스크 브랜치/워크트리를 조정 브랜치의 현재 tip에서 생성합니다. 의존성이 통합된 후에는 업데이트된 tip에서 의존 태스크를 시작합니다.

실제 하위 에이전트를 생성하며, 태스크 요구사항, 관련 계획 섹션, 절대 워크트리 경로, 브랜치, 소유 파일, 의존성 계약, 승인 기준, 필요한 검사를 전달합니다. 각 에이전트는 할당된 체크아웃에서만 작업하고, 변경 사항을 커밋하며, 커밋, 검사, 남은 우려 사항, 생성한 추가 브랜치/워크트리를 보고합니다. 이를 실행 소유 인벤토리에 즉시 등록합니다. 코디네이터만 워크트리를 통합하고 제거합니다. 하위 에이전트는 이 오케스트레이션 스킬을 재귀적으로 호출하거나 자신의 브랜치를 푸시해서는 안 됩니다. 명시적 작업 디렉토리 또는 git -C를 사용합니다. 에이전트가 기본 디렉토리를 공유할 수 있습니다. 위임이 불가능한 경우 조용히 단독 실행을 대체하지 않고 해당 제한 사항을 보고합니다.

3. 완료된 태스크 검토

각 태스크의 실제 diff와 커밋을 승인 기준과 비교 검사합니다. 실패 사항은 소유 에이전트와 논의합니다. 통합 전에 깨끗한 태스크 체크아웃, 완료된 커밋, 관련 통과 검사를 요구합니다. 기존 또는 환경적 장애물을 정확히 보고합니다. 에이전트가 완료를 보고했다는 이유만으로 작업을 병합하지 마십시오.

4. Fast-forward 병합으로 직렬 통합

완료된 태스크 브랜치에 쓰기를 중단한 후 리베이스합니다. 각 태스크에 대해 조정 브랜치의 현재 tip과의 계보(ancestry)를 검사합니다. 병렬 형제 브랜치는 첫 번째 병합 후 분기됩니다. 미게시된 각 태스크 브랜치를 업데이트된 조정 브랜치 위로 리베이스한 후 병합합니다. 이미 통합된 동작을 보존하면서 승인된 요구사항에 따라 충돌을 해결하고, 리베이스 또는 충돌 해결 후 영향을 받는 검사를 다시 실행합니다.

기록된 절대 경로 및 브랜치 이름을 사용한 예시:

git -C "$task_path" rebase "$work_branch"
git -C "$task_path" status --short
# 태스크 경로에서 필요한 검사를 실행한 다음 계보를 확인합니다.
git -C "$work_path" merge-base --is-ancestor HEAD "$task_branch"
git -C "$work_path" merge --ff-only "$task_branch"

계속하기 전에 각 명령의 결과를 검사합니다. fast-forward가 실패하면 계보를 다시 검사하고 필요에 따라 다시 리베이스합니다. 병합 커밋, 스쿼시, 체리픽, 강제 푸시, 조정 브랜치 리셋을 대체하지 마십시오. 안전한 해결을 위해 제품 결정이 필요한 경우 두 브랜치를 모두 유지하고 질문합니다. 각 태스크 통합 및 필요한 검사가 성공한 후, 해당 태스크에 대해 아래 필요한 정리를 즉시 수행합니다. 조정 체크아웃에서 통합된 작업을 검토합니다. 병합된 태스크 체크아웃은 PR 리뷰에 필요하지 않습니다. 폐기되거나 대체된 실행 소유 헬퍼에도 작업이 처리된 후 동일한 정리를 적용합니다.

5. 확인, 정리, PR 열기

최종 조정 브랜치에서 관련 결합 검사를 실행하고 결과를 전체 계획과 비교합니다. 완료 전에 통합 회귀를 수정합니다.

필요한 정리: 실행 및 확인

정리는 인도물의 일부이며 사용자가 나중에 수행하라는 제안이 아닙니다. 호출은 이미 이 실행의 깨끗하고 완전히 통합된 태스크/헬퍼 워크트리 및 브랜치 제거를 승인했습니다. 해당 제거에 대해 다시 묻지 마십시오.

  1. 소유 에이전트 및 체크아웃에 쓰는 백그라운드 프로세스를 중지합니다. 리베이스 후 브랜치의 최종 커밋을 기록하고, 현재 조정 tip의 조상(ancestor)인지 확인하며, 추적, 미추적, 무시된 파일을 검사합니다. 커밋이 없는 헬퍼의 경우 해당 tip이 이미 포함되어 있는지 확인합니다. 소유자와 미완료 작업을 처리합니다: 필요한 변경 사항을 통합하고 보존할 위치에 귀중한 로컬 아티팩트를 보존한 후 진행합니다. 폐기 가능한 실행 생성 캐시 또는 로그는 정확한 경로로 제거할 수 있습니다. 그렇지 않으면 완료된 체크아웃을 무기한으로 남겨두는 이유가 되지 않습니다.

  2. 일반 Git 워크트리의 경우, 기록된 정확한 경로와 이름을 사용하여 다음 작업을 실행하고 각 결과를 확인한 후 진행합니다:

    git -C "$work_path" merge-base --is-ancestor "$task_tip" "$work_branch"
    git -C "$task_path" status --porcelain --untracked-files=all
    git -C "$work_path" worktree remove "$task_path"
    git -C "$work_path" branch -d "$task_branch"
    

    워크트리 제거는 브랜치를 삭제하지 않습니다. 두 작업 모두 필요합니다. 남은 워크트리가 없는 실행 소유 브랜치도 삭제합니다. 강제 제거, git branch -D, 광범위한 디렉토리 삭제, 알 수 없는 편집 폐기를 절대 사용하지 마십시오. 실패한 명령을 진단하고 조용히 건너뛰지 않고 범위 내에서 일반적인 정리 문제를 수정합니다.

  3. 앱 관리형 워크트리의 경우, 디렉토리를 직접 삭제하는 대신 관리 API를 사용합니다. Codex에서는 list_artifacts를 사용하여 정확한 소유 워크트리 ID를 확인한 다음 archive_worktree를 사용합니다. 결과를 검사하고 다시 나열하여 더 이상 활성 상태가 아님을 확인합니다. 그 후 git branch -d로 실행 소유 로컬 브랜치가 남아 있으면 삭제합니다. 아카이브 스냅샷 또는 앱 첨부는 Git 등록 및 브랜치 제거 확인을 대체하지 않습니다.

  4. 정확한 경로가 없고, git worktree list --porcelain에 더 이상 등록되지 않으며, 로컬 refs에 브랜치가 없고, 관리형 첨부가 더 이상 활성 상태가 아님을 확인한 후에만 인벤토리 항목을 정리된 것으로 표시합니다. Git에서 브랜치가 여전히 체크아웃되었다고 말하는 경우 다른 체크아웃을 검사합니다. 성공적인 제거 요청이나 에이전트의 보고를 증거로 취급하지 마십시오.

  5. 최종 응답 직전, PR 생성 또는 늦은 리뷰 작업 후, Git 브랜치/워크트리 및 관리형 첨부 인벤토리를 다시 확인합니다. 이를 기준선 및 실행 소유 인벤토리와 비교합니다. 관련 없는 동시 작업을 삭제하지 않고 에이전트 보고서에서 누락된 새 항목을 설명합니다. 조정 브랜치/워크트리가 유일하게 남은 실행 소유 브랜치/워크트리여야 합니다. PR 및 테스트를 위해 보존하며, 기존 또는 관련 없는 체크아웃과 함께 보존합니다. 이 최종 감사는 PR 생성이 차단되거나 건너뛰어진 경우에도 필요하며, 안전할 때 양보하기 전에 실패/중단 시에도 필요합니다.

정리를 안전하게 완료할 수 없으면 다른 적격 항목을 계속 정리하고 정리 차단됨을 보고하며, 각 유지된 브랜치/경로, 정확히 실패한 작업 또는 가치 있는/병합되지 않은 작업, 이를 해결하는 데 필요한 최소 조치를 보고합니다. 실행 소유 임시 브랜치/워크트리가 남아 있는 동안 전체 워크플로우가 완료되었다고 보고하지 마십시오. 성공적인 병합, 테스트 통과 또는 PR 생성에서 종료하지 않고 일상적인 정리를 계속합니다.

푸시 및 PR 열기

조정 브랜치/워크트리를 모든 커밋된 작업과 함께 리뷰 준비 상태로 유지합니다. 통합 및 필수 검증이 성공한 후 최종 diff를 검사하고 조정 브랜치만 의도된 저장소 원격에 푸시합니다. develop을 기준 브랜치로, 조정 브랜치를 헤드로 하는 리뷰 준비 완료 PR을 생성합니다. 사용자가 명시적으로 요청하는 경우에만 초안을 사용합니다. 이 헤드/기준에 대해 기존 열린 PR이 있는지 생성 전에 확인하고, 불확실한 생성 결과 이후에도 확인하며, 중복을 생성하는 대신 재사용하거나 업데이트합니다.

저장소 PR 템플릿, 제목 규칙, 티켓 링크 요구사항을 따릅니다. 최종 동작, 검사 및 그 결과, 구체적인 수동 테스트 단계를 설명합니다. 해당 단계는 제품을 실행하거나 유지된 상태를 검사하는 방법을 설명해야 하며, 저장소 테스트 명령의 또 다른 목록이 아니어야 합니다. 푸시에는 로컬 Git을 선호하고 PR 생성에는 사용 가능한 저장소 커넥터를 사용합니다. 적절한 경우 인증된 CLI를 사용합니다. PR의 실제 기준, 헤드, 게시된 커밋을 완료된 조정 브랜치와 확인합니다. 아티팩트 첨부 도구를 사용할 수 있는 경우 생성된 모든 PR을 현재 채팅에 첨부합니다. PR을 리뷰를 위해 열어 둡니다.

푸시 또는 PR 생성이 차단된 경우 완료된 조정 브랜치/워크트리를 보존하고 정확한 차단 요인과 남은 작업을 보고합니다. 확인된 URL 없이 PR이 존재한다고 주장하거나 거부를 우회하기 위해 강제 푸시하지 마십시오.

완료 보고서

최종 응답은 정확한 조정 브랜치 이름과 절대 워크트리 경로로 시작해야 합니다. 확인된 PR에 대한 마크다운 링크를 포함하거나 PR 생성이 차단되거나 명시적으로 건너뛰어진 이유를 명시한 후 다음을 포함합니다:

  • 이제 작동하는 것: 완료된 동작과 남은 범위.
  • 이미 실행된 검사: 정확한 명령과 실제 결과, 건너뛰거나 차단된 검사를 식별.
  • 테스트 방법: 조정 워크트리에서 사용자가 실행할 수 있는 짧은 번호가 매겨진 검증 절차. 이는 자동화된 검사와 별개이며 pnpm test, lint, 빌드 또는 유사한 명령을 반복하여 충족되어서는 안 됩니다. 해당하는 경우 다음을 포함:
    • 설정: 환경/앱 URL, 로그인 및 역할, 서비스, 시드 또는 픽스처 데이터, 레코드 ID, 작업 디렉토리;
    • 주요 제품 흐름: 정확한 화면 또는 엔드포인트, 현실적인 입력 및 UI 작업, 트리거할 동작, 예상되는 가시적 결과;
    • 관련 에지 또는 회귀 흐름: 해당 사항이 있는 경우 유효하지 않음, 빈, 중복, 제한됨 또는 이전에 완료된 데이터;
    • 데이터를 쓰거나 전환하는 변경 사항에 대한 유지된 상태 확인: 테이블 또는 리소스, 필터 또는 식별자, 확인할 필드/상태, 예상 결과와 함께 읽기 전용 DB/API 검사를 제공합니다. 사용자 작업을 저장된 레코드에 연결하고 단순히 "DB를 확인"이라고 말하지 마십시오. 예를 들어, 프로스펙팅 변경은 명명된 영역 및 반경에 대한 영토 스캔을 생성하고, 특정 장소를 찾고, 필요한 속성을 확인하고, 리뷰/아웃리치 작업을 완료하고, 앱 및 관련 레코드에서 결과 리뷰 또는 아웃리치 상태를 확인하도록 말해야 합니다. 다른 제품 워크플로우에도 동일한 수준의 구체성을 사용합니다. 자동화된 명령은 이미 실행된 검사 아래에 둡니다. 각 수동 단계를 수행됨 또는 제안됨으로 표시합니다. 앱 또는 데이터베이스를 사용할 수 없는 경우 정확한 차단 요인과 실행에 필요한 최소 설정을 명시합니다. 데이터베이스 검사는 승인된 작업이 명시적으로 테스트 데이터 변경을 승인하지 않는 한 읽기 전용입니다.
  • 정리 및 차단 요인: 제거 또는 보관된 임시 워크트리와 삭제된 로컬 브랜치의 확인된 개수; 최종 감사에서 남은 실행 소유 브랜치/워크트리(일반적으로 코디네이터만). 차단된 모든 임시 브랜치/경로와 정확한 이유를 나열합니다. 불완전한 푸시 또는 PR 단계를 포함합니다.

진행 업데이트를 간결하게 유지하고 2분 미만으로 수행할 수 있는 하나의 구체적인 다음 조치로 마무리합니다.

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

관련 스킬