amberpixels/ship

f10 · ship

이 스킬을 실행하는 것은 사용자가 PR을 푸시하고 열거나 새로고침(pr 단계)하는 것에 대한 명시적 승인이며, 이는 해당 PR에 한해 전역 "푸시/PR 열지 않음" 규칙을 충족시킵니다. 또한 resolve의 +reply 게시, resolve의 수정 사항을 해당 PR에 푸시, review의 f10 review ack 게시, 그리고 플로우 내 CI 리뷰의 f10 review trigger(리뷰 섹션이 수동 읽기 방법을 명시한 경우) 및 resolve의 f10 review settle 게시, pr 이후 판사 항목에 대해 캐치업 가드의 통합 및 자체 변경 사항을 해당 PR에 푸시하고 상태와 댓글을 게시, 그리고 작업에 대한 실행 결과 댓글과 상태를 게시(Report back)합니다. 배포는 자체 확인(deploy 단계)이 필요합니다.

인수

• --help: ${CLAUDE_PLUGIN_ROOT}/modes/help.md를 따르고 중지합니다. 아래 내용은 적용되지 않습니다.
• --dry-run: 실행 대신 ${CLAUDE_PLUGIN_ROOT}/modes/dry-run.md를 따르고 중지합니다. 나머지 인수가 실행할 단계를 보고합니다.
• --driven: ${CLAUDE_PLUGIN_ROOT}/modes/driven.md를 따릅니다. 아래 내용은 여전히 실행됩니다.
• 단어 형태의 플로우 이름(/f10:ship direct: fix typo …; f10 start --local은 /f10:ship local: <id>를 전송하고, --flow <name>은 <name>:을 전송함), 또는 사용자 자신의 말로 명명된 경우: 해당 플로우를 실행합니다. 그렇지 않으면 frontmatter의 flow_by_area가 작업의 영역을 매핑하는 플로우(가져오기 브리핑의 영역, 또는 계획의 Areas 라인), 그렇지 않으면 default를 사용합니다. 두 영역이 다른 플로우에 매핑되는 경우: 전달물의 영역이 우선합니다(Roles에서와 같이), 브리핑이 다른 영역을 명명합니다. 영역 맵은 프로젝트의 선택 사항이지 사용자의 것이 아닙니다: 다른 플로우를 선택하지 마십시오. 단, 아주 작은 작업에 대해 제안할 수 있습니다. 첫 번째 단계 전에 한 줄로 영역이 선택한 플로우와 영역을 명명합니다.
• --pace <name>: 이 실행에 한해 해당 속도로 플로우를 실행합니다(Paces, 아래). 없으면 브랜치가 기록한 속도, 또는 프로젝트나 사용자의 pace:를 사용합니다.
• <plan.md>: 계획 파일입니다. 이 계획과 함께 플로우를 실행합니다.
• <task-id> (프로젝트 ID 형식 / id / url), 또는 +로 결합된 번들(ABC-1+ABC-2, 리드를 기준으로 함): 먼저 ${CLAUDE_PLUGIN_ROOT}/modes/forward.md를 따릅니다. 로드하기 전에. 작업을 전달하면 중지합니다. 그렇지 않으면 fetch 단계를 실행한 다음 <storage root>/plans/<TASK-ID>.md (번들의 리드)를 찾습니다(정확한 이름이 없으면 plans 디렉토리를 글로브 검색). 찾은 경우: 재사용하며 절대 묻지 않습니다. 계획 파일이 있는 작업은 다시 계획을 세우지 않으며, 재계획은 수동으로 /f10:plan <id>를 통해 수행합니다. 없는 경우: stale_after에서, 가져오기가 먼저 오래된 작업을 판단하고 실행을 차단할 수 있습니다(steering의 anyway는 이를 건너뜀). 그런 다음 플로우가 plan으로 시작할 때 plan 단계를 실행합니다(flow_by_area의 경우, start와 drive는 계획 수립을 ship에 맡깁니다). planless 플로우(아래)는 절대 실행하지 않으며 가져오기 브리핑이 인라인 계획이 됩니다. 그런 다음 플로우.
• <description>: 자유 텍스트입니다. capture, fetch, plan 단계를 거친 다음 플로우.
• 인수 없음(플래그 또는 플로우 단어만 있는 경우는 인수 없음으로 간주, 설명은 자유 텍스트, 위 참조): 이미 이 대화에 있는 작업(방금 저장한 계획, 가져온 작업), 그렇지 않으면 브랜치의 작업, f10 task current가 출력하는 ID. 어떤 작업을 어디서 가져왔는지 한 줄로 말한 다음 <task-id>로 실행합니다(전달 모드 포함). 저장된 계획이 재사용됩니다. f10 task current가 0이 아닌 종료 코드를 반환하면: 한 줄로 작업을 요청하고 기다립니다(driven: modes/driven.md에 따라 요청).
• 주제 외의 추가 텍스트는 steering입니다. resume at <entry> (f10 drive가 catchup이 중지를 해결한 후 전송)는 해당 항목에서 플로우를 시작하고 이전 항목을 완료된 것으로 간주합니다. (entry <n>)은 배지의 파이프라인에서 플로우가 이름을 두 번 지정하는 항목의 n번째 항목을 선택합니다. 배지는 해당 위치로 이동합니다: pipeline 이후, 한 번의 호출로 이전 각 항목에 대해 순서대로 set ship running을 실행한 다음 항목 자체에 대해 실행합니다.

실행

1. 이 스킬을 호출할 때마다 먼저 f10-load-project.sh를 실행하고, 입력에 필요한 단계를 명명합니다: 설명의 경우 capture fetch plan, 작업 ID의 경우 fetch plan, 계획 파일의 경우 없음. 플로우는 출력되는 project.md에 선언되어 있습니다. planless 플로우는 plan을 로드하지만 절대 실행하지 않습니다.
2. 인수 항목이 제공하는 순서대로 해당 단계를 따릅니다.
3. 각 플로우 항목을 실행 직전에 배지와 함께 한 번의 호출로 로드합니다: f10-state.sh set ship running <entry>; f10-load-project.sh <step>, 해당 로드의 단계를 따릅니다. review 항목은 review resolve를 로드하고, pr 항목은 handoff off 다이얼이 설정되지 않은 경우 pr handoff를 로드합니다(pr 단계가 핸드오프를 실행하기 때문). 캐치업 가드(아래)는 보호하는 각 항목의 로드에 catchup을 추가합니다.

플로우는 frontmatter의 flows:로, 이름과 순서가 지정된 항목의 매핑, 리스트 또는 공백이나 화살표로 분할된 하나의 문자열입니다(plan judge implement cleanup:comments,prose pr review:ci deploy:staging). 선언되지 않은 경우 default: plan implement pr입니다. f10 flow는 플로우를 나열하고 각각을 선택하는 기준을 보여줍니다.

**속도(Paces)**는 선택된 플로우를 조정합니다(docs/project-setup.md → Paces). 플로우가 선택되면 f10 flow <name> [--pace <name>]을 실행하고, 인수가 제공한 경우에만 --pace를 전달합니다. 출력된 순서대로 항목을 실행하며 frontmatter의 목록을 사용하지 않습니다. 한 줄에 하나의 항목을 출력합니다. skipped로 표시된 항목은 실행되지 않습니다: 한 줄로 설명하고 배지의 pipeline에서 제외합니다. 항목 뒤의 다이얼은 해당 단계로 전달됩니다: rounds와 depth는 review로, marker와 handoff는 pr로. 판사의 effort는 판사가 에이전트를 생성하는 경우(--blind)에만 적용되며, 프로필은 f10 agents judge에서 가져오고, 인수가 제공한 경우 --pace <name>이 함께 전달됩니다. 인라인 판사는 작업 에이전트의 프로필에서 실행됩니다. 속도가 건너뛴 플로우 앞의 plan은 실행을 planless로 만듭니다(plan이 없는 플로우와 동일). finish 라인은 해당 속도로 병합되었을 열린 PR에서 실행이 종료됨을 의미합니다: ship은 절대 병합하지 않으며 보고서의 Next:는 드라이브가 작업을 완료하지 않는 한(modes/driven.md) /f10:finish <id> --merge를 명명합니다. 속도가 없으면 목록은 선언된 플로우이며, 선택적 CI 리뷰(ci?)는 이미 해결되었습니다. 이름을 받기에 너무 오래된 f10 flow는 실패합니다: 선언된 플로우를 실행하고 속도가 적용되지 않았음을 한 줄로 말합니다.

항목은 단계 또는 step:arg입니다: 일반 단계와 오버레이, 또는 프로젝트 정의 단계로, 인수가 전달됩니다(review:local 또는 review:ci는 리뷰의 by(리뷰어)를 설정, review:host는 호스트의 자체 코드 리뷰에서 로컬 리뷰를 실행, review:local+ci는 둘 다 한 라운드와 한 resolve로 실행, review:local+ci?는 CI 리뷰가 실행 가능한 경우에만 실행, f10 flow <name>은 ship이 항목을 보기 전에 ?를 해결, cleanup:<targets>는 정리 대상을 지정하며, 항상 전체 패스를 받습니다(bare cleanup은 200개 미만의 추가 라인 diff에서 가벼운 정리를 실행), deploy:<env>는 환경). 실행은 앞의 plan 이후 항목에서 시작하며, plan은 계획 파일이 없는 작업에 대해서만 실행됩니다. resolve는 절대 명명되지 않습니다: review 항목이 이를 실행합니다. judge 항목은 위치에 따라 판단합니다: implement 이전은 plan judge(주제 plan <id>), 노란색 판정은 계획 파일을 제자리에서 수정하고 코드를 작성하지 않습니다. 이후는 change judge로, 노란색 판정의 변경 사항을 직접 빌드합니다. pr 전후에 judge 단계가 말하는 대로 라우팅됩니다. pr 항목은 브랜치의 PR을 열거나(이미 열린 경우 새로고침) 리뷰나 judge 후 PR 설명을 업데이트하기 위해 플로우가 pr을 다시 명명할 수 있습니다. 앞에 plan이 없는 플로우는 planless입니다: 계획 파일을 작성하지 않으며, 저장된 계획이 없는 경우 채팅의 간단한 인라인 계획이 대신합니다. 이전 키(pipelines, planless, drive_chain)는 여전히 읽히며, f10 init --migrate를 명명하는 경고와 함께 플로우로 변환됩니다. 이전 항목 형식 review (local)도 마찬가지입니다. 자유 텍스트 입력은 capture와 fetch도 건너뛰므로 실행에 작업 ID가 없습니다. 작업 ID는 fetch를 실행하고 실행을 ID에 연결합니다(배지, 보고서, 브랜치, 리뷰 디렉토리), 가져온 후 f10-state.sh set plan skipped를 표시합니다. 저장된 계획을 재사용하는 경우는 제외합니다(prior, 아래). 인라인 계획은 fetch가 결정한 종류를 명시하며, 버그의 재현 및 근본 원인, 리팩터의 불변성 또는 스파이크의 질문을 각각 한 줄로, 기본값에 대한 격차를 나열합니다. 작업 ID가 있는 경우, 인라인 계획은 plan 단계가 하는 대로 변경의 의도를 기록합니다(f10 lore add intent --change <change> -m <what and why>, docs/lore.md). 기존 의도 또는 추가 실패는 보고서의 한 줄일 뿐이며 실패한 단계가 아닙니다. shipment은 마지막 전달 항목입니다(conventions/context.md → shipment): 해당 단계가 선언한 행이며, 프로젝트 정의 단계는 오버레이의 Shipment: 라인에서 가져옵니다. 이후의 judge, demo 또는 handoff는 행을 추가하며 교체하지 않습니다. 보여줄 것이 없는 demo 항목은 한 줄로 건너뜁니다(demo 단계). 이는 행을 추가하지 않는 정상 종료입니다.

스파이크는 implement 후 종료됩니다, 플로우와 관계없이: Kind: spike 계획은 질문에 답하며 코드는 절대 머신을 떠나지 않습니다. implement 이후의 단계는 실행되지 않습니다(cleanup, commit, push, pr, review, judge, deploy 없음). shipment는 스파이크 보고서입니다. 최종 보고서는 f10 finish <id>로 종료되며, 이는 계획과 보고서를 보관하고 실험 코드를 폐기하며 worktree, 브랜치 및 워크스페이스를 제거합니다. --keep은 실험을 유지하며 kept/ 브랜치에 커밋됩니다. 드리븐 스파이크는 보고서에 종료가 필요하지 않습니다: f10 drive가 ship 후 스파이크를 종료합니다. 메인 체크아웃에서 f10 finish 전에 보고서가 명명한 경로로 실험 코드를 폐기합니다. f10 finish는 더티 메인 체크아웃을 거부합니다. 리포트 백(아래)은 질문, 답변 및 권장 사항을 전달합니다. visibility: public에서만 스파이크 보고서 경로를 명명합니다(stealth는 .f10/ 경로를 트래커에서 제외하기 때문). 종류는 플로우 시작 전에 계획 또는 planless 실행의 인라인 계획에서 알 수 있으므로 배지는 f10-state.sh pipeline implement를 선언하고, dry run은 implement에서 잘린 경로를 출력합니다.

캐치업 가드는 세 가지 종류의 항목 전에 베이스를 가져옵니다. catchup 단계의 As a guard에서 말하는 대로입니다. catchup: off에서는 절대 통합하지 않으며 로드에 catchup을 제외하지만, 코드가 없는 베이스에 대한 아래 질문은 여전히 실행됩니다. 캐치업은 플로우 항목이 아닙니다.

• implement 전, f10 start --after 또는 f10 finish가 브랜치(f10-after-branch 또는 f10-landed)에 베이스를 기록한 경우에만; 그렇지 않으면 f10 pr catchup --guard implement가 method: skip을 출력합니다. 아직 코드가 없는 베이스는 가드의 code: none 라인입니다. 이 규칙은 f10 drive가 종속 작업을 해제하는 기준입니다. 베이스가 로컬 또는 origin에만 있는 경우. 통합 전에 한 번 묻습니다(AskUserQuestion) 기다리기 또는 계획의 가정에 따라 진행하기. 기다리기는 실행을 차단합니다(f10-state.sh set ship blocked implement, note에 베이스 작업 명명). 진행은 계획 파일에 기록된 베이스 작업의 계획을 기준으로 빌드하며, 계획이 없으면 대체가 없습니다. Driven에서는 묻지 않으며 ship은 절대 진행하지 않습니다: f10-state.sh set ship blocked implement; f10-state.sh wait <base-id>; f10-state.sh note "waiting on <base-id>: its branch has no code yet" "rerun ship once <base-id> commits; f10 drive does it by itself", 그런 다음 보고서. f10 drive는 작업을 waiting on <base-id>로 유지하고, 베이스가 커밋되면 resume at implement와 함께 ship을 다시 전송합니다. 다른 작업은 계속 진행됩니다.
• 모든 pr 항목 전, 첫 번째와 각 새로고침: 먼저 f10 pr catchup --guard pr을 실행하여 가져오고 계보를 확인합니다. method가 merge, rebase 또는 onto인 경우에만, 트리가 보유한 것을 pr 단계가 하는 대로 커밋하고(conventions/context.md → Commits, --step implement) 통합하여 푸시가 이를 전달합니다. skip 또는 none은 pr과 어댑터에 커밋을 맡깁니다.
• 변경 판사 전 (implement 이후의 judge; plan judge는 코드 없음): 트리에 커밋되지 않은 작업이 있는 경우(implement는 작업을 커밋되지 않은 상태로 둠, 따라서 implement judge pr은 항상 있음), 한 줄로 건너뜁니다: 해당 판사는 브랜치를 이전 베이스에서 보며, 플로우에 pr 항목이 있는 경우 나중 pr 항목의 가드가 코드가 나가기 전에 베이스를 가져옵니다. pr 항목 후에는 통합을 푸시하고 강제하지 않습니다. PR 헤드는 판단된 코드와 판사 상태가 있는 것입니다.

가드는 보호하는 항목 아래에서 실행되며, 해당 항목의 로드(catchup pr) 및 배지에 포함됩니다. 실패는 set ship failed <entry> 또는 실행이 내구성 있는 것을 남긴 경우 partial(가드 자체 커밋 또는 열린 PR, conventions/failure.md 규칙 7)이며, state 행은 해당 커밋을 명명하고 note는 catchup과 /f10:catchup을 명명합니다. 가드는 실패 전에 브랜치를 표시합니다(catchup 단계). f10 drive는 표시된 브랜치를 자체적으로 캐치업하며, 베이스가 이동할 때마다 다시, 그런 다음 이 항목에서 ship을 다시 프롬프트합니다. 캐치업이 변경되지 않았거나, 베이스가 이동하지 않았거나, 동일한 파일이 연속으로 두 번 충돌하는 경우 파일을 명명하며 중단합니다. 드리븐 실행의 next는 worktree에서 /f10:catchup --driven을 실행한 다음 드라이브를 다시 실행입니다. 다시 실행은 이 항목에서 ship을 다시 프롬프트합니다.

플로우의 항목을 선언된 순서대로 실행하며, 각각 자체 로드에서 실행합니다. 이번 실행에 작성된 계획은 재확인이 필요하지 않습니다. judge 항목은 판정에 따라 실행을 라우팅합니다: plan judge는 judge 단계의 pr 전 경로가 말하는 대로, 변경 사항은 implement가 빌드할 계획 파일에 접힙니다. change judge는 pr 항목 전후에 다릅니다(judge 단계). change judge의 변경 사항은 pr 전후에 계획에 접히고 judge 단계 자체 경로(Building the changes)에 의해 빌드되며, implement의 재실행으로 빌드되지 않습니다.

배지 (conventions/report.md): f10-state.sh pipeline <entry>... 플로우가 선택되면, plan 이후의 모든 항목을 플로우가 명명하는 대로, 각각 인수 하나(pipeline judge implement cleanup pr review:local judge pr), 마지막을 최종으로 선언합니다. f10-state.sh set ship running <entry> 각 항목 전에, 플로우가 명명하는 대로, 로드하는 호출에서. f10-state.sh set ship done 마지막 후. 이전 실행의 계획(계획 파일 또는 재사용)은 단계를 반복하지 않습니다: plan은 해당 항목 이후로 건너뜁니다.

리포트 백 (conventions/report.md → Report back): pr 후, PR에 실행 결과 댓글을 게시하고, f10-state.sh set ship report-ran <badge>와 함께 배지를 방문하고, f10-state.sh set ship done 후 배지를 방문하고, 보고서를 <storage>/reports/<TASK-ID>.md에 쓰고, 프로젝트 체크아웃에 f10-summary.sh를 실행하여 reports/ 아래 요약 링크를 업데이트합니다. 보고서는 PR 댓글에 보이는 것과 동일한 텍스트를 포함하며 구조화된 형식으로: conventions/report.md가 있습니다. 프로젝트가 연결된 이슈 트래커(짧은 링크)가 있는 경우, return <short-link>가 최종 단계 후의 상태 메시지에서 반환됩니다.

선행 (conventions/report.md → Prior): 계획 파일이 재사용된 경우, 보고서는 동일한 실행 결과를 포함하며 차이점은 다음과 같습니다: 최초 실행 전의 단계(plan 및 이전)는 실행되지 않으며, pipeline은 해당 단계를 생략합니다. f10-state.sh set ship ran-on <head>를 기록하고, pr 단계가 이미 pr handoff를 완료하지 않은 경우(PR이 이미 열림) pr 단계를 실행하지 않습니다. 선행 실행의 보고서 링크는 prior 섹션에 포함됩니다.

핸드오프 (conventions/report.md → Handoff): 선택적 단계로, pr 전이나 후에 실행됩니다. handoff 항목이 플로우에 있는 경우(pr handoff), pr 단계가 핸드오프를 실행합니다. 핸드오프는 PR 설명, 댓글 및 레이블을 설정합니다. handoff off 다이얼이 설정된 경우 핸드오프는 건너뜁니다.

데모 (conventions/report.md → Demo): 선택적 단계로, 플로우에 demo 항목이 있는 경우 실행됩니다. 데모는 변경 사항을 보여주는 스크립트나 명령을 실행합니다. 보여줄 것이 없으면 한 줄로 건너뜁니다.

정리(Cleanup) (conventions/report.md → Cleanup): 선택적 단계로, 플로우에 cleanup 항목이 있는 경우 실행됩니다. 정리는 작업 파일, 임시 파일 및 디버그 출력을 제거합니다. cleanup:<targets>는 특정 대상을 지정합니다.

환경(Environment) (conventions/report.md → Environment): 선택적 단계로, 플로우에 deploy 항목이 있는 경우 실행됩니다. 배포는 빌드, 마이그레이션 실행, 서비스 재시작 등을 포함할 수 있습니다. deploy:<env>는 환경을 지정합니다.

오류 처리 (conventions/failure.md):

• 실패한 단계는 f10-state.sh set ship failed <entry>로 표시됩니다.
• 부분 실패(일부 내구성 있는 상태가 남은 경우)는 partial로 표시됩니다.
• 실패 후에도 PR이 열려 있고 조치가 가능한 경우 next는 /f10:catchup을 제안합니다.
• 사용자에게 항상 실패 이유와 다음 단계를 한 줄로 설명합니다.

보안 및 권한 (conventions/security.md):

• 이 스킬은 모든 작업에 대해 명시적 사용자 승인을 요구합니다.
• PR 푸시/열기는 사용자의 명시적 승인(스킬 호출)이 필요합니다.
• 비밀, 자격 증명 또는 민감한 정보가 코드에 포함되지 않도록 합니다.

제한 사항:

• 이 스킬은 f10 플러그인이 설치된 프로젝트에서만 작동합니다.
• 작업은 프로젝트의 flow_by_area 또는 flows 구성에 의해 정의된 플로우를 따라야 합니다.
• 스파이크는 implement 후 종료되며 코드를 폐기합니다.
• 캐치업 가드는 안전한 통합을 보장하기 위해 자체 메커니즘을 가지고 있습니다.

이 스킬을 사용하려면 /f10:ship [task-id | plan-file.md | description]을 입력하세요. 자세한 내용은 f10 문서를 참조하십시오.