Bluetape Skills Part 2: bluetape-workflow로 작업을 시작하는 방법

하나의 요청을 먼저 분류하고, 승인과 검증 gate를 통과한 작업만 다음 단계로 보낸다.

2026-07-11 · Bluetape Skills Part 2

이 글은 「AI와 일하는 환경을 인프라로 만들기」에서 설명한 skill 계층과 Part 1의 공유·설치 구조를 실제 작업 절차로 연결한 글이다. 협업 환경을 구성하는 요소를 갖추는 데서 한 걸음 더 나아가, 요청 하나가 어떤 순서로 분류되고 승인·실행·검증되는지 살펴본다.

Skill을 설치했다고 모든 이름을 외울 필요는 없다. Bluetape 생태계 작업은 $bluetape-workflow 하나로 시작하면 된다. 이 skill은 코드를 대신 작성해 주는 만능 prompt가 아니다. 요청의 성격을 먼저 파악하고, 그에 맞는 세부 skill과 검증 수준을 고르는 router다.

지금의 router가 이런 구조를 갖게 된 데에는 이유가 있다. 이전에는 작업 절차가 있어도 일부 gate를 건너뛰고, 뒤 단계의 성공을 앞 단계의 증거로 갈음하거나, “작은 변경”이라는 이유로 확인 항목을 줄이는 일이 반복됐다. 반대로 안전한 로컬 작업인데도 단계마다 진행 여부를 다시 물어 workflow가 자주 끊기기도 했다.

그래서 첫 계획에서 범위와 결과물을 한 번 승인받고, 승인 뒤에는 안전하고 되돌릴 수 있는 작업을 끊지 않고 이어 가도록 했다. 대신 한 번 열린 gate는 완료 보고만으로 넘기지 않고, 새로 확인한 증거로 통과해야 한다.

$bluetape-workflow

bluetape4k-exposed의 README에 새 cache 사용 예제를 추가해 줘.

이 요청은 실제 동작을 바꾸지 않는 문서 작업이므로 Type E Maintenance로 분류한다. 반대로 재현 가능한 실패가 있으면 Type C Bug Fix, 새 모듈이나 넓은 API 설계가 필요하면 Type A Full Feature가 된다. 분류에 따라 첫 계획과 필요한 증거, 테스트 범위, PR을 열기 전에 통과해야 할 gate가 달라진다.

첫 단계는 구현이 아니라 분류다

사용자가 작업 유형을 명시했다면 bluetape-workflow는 그 분류를 우선한다. 별도 분류가 없다면 다음 표에서 가장 가벼우면서도 안전한 유형을 고른다.

Type	이런 작업에 사용한다	연결되는 실행 skill
A · Full Feature	새 모듈·서비스·의존성, 넓은 public API, multi-layer 변경	$bluetape-full-feature
B · Fast Track	영향 범위가 좁은 작은 기능이나 확장	$bluetape-fast-track
C · Bug Fix	재현 가능한 결함, regression, 잘못된 출력, 실패 테스트	$bluetape-bugfix
D · Code Review	구현 요청이 없는 review·audit·조사	code review와 언어별 pattern skill
E · Maintenance	README, KDoc, 문서, AGENTS, skill, config, CI hygiene	$bluetape-maintenance
P · Publish	snapshot, release, BOM/catalog train, tag, Maven Central	$bluetape-publish-jvm 또는 $bluetape-publish-go
F · Self Improve	baseline과 stop condition이 있는 benchmark 개선 반복	$bluetape-self-improve

사용자가 작은 작업이라고 불러도 곧바로 Type B가 되는 것은 아니다. 새 dependency나 새 모듈은 변경량이 작아도 Type A다. Review 요청은 사용자가 구현까지 명시하지 않는 한 Type D에서 멈춘다. Bug fix와 무관한 기능 추가가 섞였다면 workflow를 둘로 나눈다. 작업에 붙인 이름이 아니라 위험도와 검증 범위가 분류 기준이다.

변경의 위험과 필요한 증거를 기준으로 가장 가벼우면서도 안전한 실행 경로를 고른다.

첫 계획 승인 전에는 읽기만 한다

분류가 끝나면 바로 파일을 고치지 않는다. 먼저 구체적인 계획을 보여 주고 승인을 받는다.

Work type: Type E - Maintenance
Basis: README와 예제 문구만 변경하며 production behavior는 그대로다.

1. Action: 현재 README locale과 실제 API 사용법을 확인한다.
   Expected DoD: source와 문서의 identifier가 일치한다.
2. Action: README.md와 README.ko.md를 같은 범위로 수정한다.
   Expected DoD: 두 locale의 예제와 링크가 대응한다.
3. Action: diff check와 문서 build를 실행한다.
   Expected DoD: 변경 route와 링크가 정상 렌더링된다.

이 시점까지는 읽기 전용 조사만 한다. AGENTS.md, skill, source, git status, issue와 PR metadata, 과거 lessons는 읽을 수 있다. 하지만 파일 수정, 저장소에 남길 plan 작성, commit, PR 생성, workflow dispatch, merge는 첫 계획을 승인받은 뒤에 한다.

이 gate는 agent의 자율성을 줄이려고 만든 것이 아니다. 요청을 잘못 분류한 채 빠르게 구현하면 나중에 되돌려야 할 범위만 커진다. 사용자는 첫 계획에서 범위와 결과물을 확인하고, agent는 승인된 범위 안에서 중간 허가를 반복해서 묻지 않고 끝까지 진행한다.

반복된 실패를 겪으며 승인 경계를 다듬었다

과거에는 “자율적으로 진행”하라는 지침과 “계획을 먼저 승인”받으라는 지침이 서로 다른 문서에 흩어져 있었다. 어떤 작업에서는 agent가 계획을 보여 주지도 않고 수정부터 시작했고, 다른 작업에서는 이미 승인된 로컬 수정 하나하나에 다시 허가를 물었다.

이를 다음 경계로 정리했다.

상황	현재 동작
status, source, skill, issue/PR metadata 확인	승인 전에도 읽기 전용으로 조사한다
첫 번째 구체적인 plan	Action과 Expected DoD를 적어 사용자 승인을 받는다
승인된 로컬 수정·테스트·검증	중간 승인을 다시 묻지 않고 계속 진행한다
범위가 크게 달라지는 새 작업	변경된 plan을 다시 보여 주고 승인받는다
merge, tag, publish, release, 파괴적 정리	승인받은 외부 변경의 범위인지 다시 확인한다

승인 gate는 agent를 단계마다 멈춰 세우는 장치가 아니다. 사용자가 방향을 결정해야 하는 지점과 agent가 책임지고 실행해야 하는 지점을 분리하는 장치다.

체크리스트 한 줄에는 세 가지가 들어간다

승인을 받으면 router 체크리스트와 common gate, 선택한 세부 skill의 체크리스트를 만든다. 실행 항목은 다음 형식으로 적는다.

- [ ] **CG-07 — Lock behavior and run targeted proof**
  - **Action:** 변경 계약을 증명하는 가장 작은 테스트와 build를 실행한다.
  - **Evidence:** 실제 command, 결과, 대상 module 또는 route를 기록한다.
  - **Failure:** 실패하면 다음 단계로 가지 않고 구현으로 돌아간다.

Action은 지금 할 일, Evidence는 완료를 증명할 결과, Failure는 증거를 얻지 못했을 때 취할 조치다. 이 세 가지가 있어야 checkbox가 단순한 할 일 목록을 넘어 다음 단계를 통제하는 gate가 된다.

상태 규칙도 엄격하다.

• [ ]은 아직 증명되지 않았다는 뜻이며 뒤따르는 단계를 막는다.
• UNKNOWN, 오래된 결과, agent의 말뿐인 완료 보고는 FAIL로 취급한다.
• SKIPPED는 없다. 적용되지 않는 항목은 왜 N/A인지 구체적인 범위 증거를 남긴다.
• 뒤 단계가 성공해도 앞 단계의 누락을 대신 증명하지 못한다.

예를 들어 site build가 성공했다고 첫 계획 승인이나 locale parity 검토까지 자동으로 통과하는 것은 아니다. 반대로 README만 바꿨다면 Kotlin compiler 진단은 N/A가 될 수 있지만, “.kt 변경 0개”처럼 확인할 수 있는 근거가 필요하다.

이 규칙도 실제 누락을 겪으며 생겼다. 선택 항목을 확인하지 않은 채 N/A로 닫고, CI PASS를 보고 앞선 gate도 통과했다고 간주하거나, 도구의 출력을 읽기도 전에 checkbox부터 체크하는 문제가 있었다. 그래서 다음 제약을 추가했다.

• 체크리스트는 파일을 수정하기 전에 만든다.
• Required, conditional, N/A를 실행 전에 분류한다.
• Evidence를 읽은 직후 해당 항목에 기록한다.
• 실패한 항목은 체크하지 않은 상태로 두고 후속 작업을 막는다.
• 순서를 어겼다면 누락된 항목과 그 영향을 받은 후속 검증을 모두 다시 실행한다.
• 완료 전에는 Required checks: X/Y; N/A: N; Blocked: N 합계가 실제 체크리스트와 맞는지 센다.

그래야 “증거는 나중에 채우겠다”는 방식이 정상 workflow처럼 굳지 않는다. 뒤늦게 확보한 증거는 복구 내역으로 기록하고, 그 증거에 의존한 후속 검증이 여전히 유효한지도 다시 확인한다.

Router는 여섯 단계를 차례로 연다

bluetape-workflow의 핵심 흐름은 다음과 같다.

WF-01 Classify
  -> WF-02 Write the first concrete plan
  -> WF-03 Obtain first-plan approval
  -> WF-04 Load execution contracts
  -> WF-05 Execute gates in dependency order
  -> WF-06 Repair skipped or weak gates

WF-04에서는 모든 skill을 한꺼번에 읽지 않는다. Type E라면 $bluetape-maintenance, 공통 gate, 현재 작업에 필요한 reference만 읽는다. Kotlin 구현이면 $bluetape-kotlin-patterns, Go라면 $bluetape-go-patterns, 글이라면 $bluetape-writer를 추가한다. 필요한 지침만 골라 context를 아끼되, 한 번 선택한 지침은 끝까지 읽는다.

WF-05는 단계 사이의 의존 순서를 지킨다. 테스트보다 먼저 코드를 고쳤다는 이유만으로 test gate가 실패하는 것은 아니다. 하지만 bugfix에서 재현과 regression test를 건너뛰고 구현부터 했다면 순서가 깨진다. 이때 WF-06에서 누락된 gate를 복구하고, 그 영향을 받은 검증도 다시 실행한다.

WF-06을 별도 단계로 둔 이유도 “이미 여기까지 왔으니 계속하자”는 관성을 막기 위해서다. Gate 누락을 발견하면 후속 작업을 멈춘다. 빠진 단계의 Action과 DoD를 다시 세우고 PASS 증거를 얻은 뒤에만 작업을 잇는다.

Common gate는 작업 전후의 안전선을 맡는다

세부 skill이 유형별 실행 절차를 맡는다면 common gate는 저장소 전체에 공통으로 적용할 안전선을 맡는다. 항목은 모두 17개이며, 작업의 성격에 따라 적용 여부가 달라진다.

구간	확인하는 내용
CG-01~03	적용할 지침, 현재 status와 diff, 과거 증거, 사용자 작업과 worktree 경계
CG-04~05	대화·문서·KDoc 언어, public contract 문서화
CG-06~08	기존 ecosystem pattern 재사용, 범위를 좁힌 검증, 무거운 test의 직렬 실행
CG-09~12	issue/PR metadata, PR body와 review, side-effect 권한, merge 뒤 local sync
CG-13~15	chezmoi source-first 변경, Codex self-audit, global policy와 Claude scope 경계
CG-16~17	정보를 생략하지 않는 command 사용, 항목별 완료 증거

모든 작업에서 17개 항목을 똑같이 실행하는 것은 아니다. 블로그 글에서는 public API KDoc과 Testcontainers가 N/A다. 반면 locale parity, site build, PR body, merge 뒤 local sync는 적용된다. 사용자 범위의 skill을 수정할 때는 CG-13과 CG-14가 열리며, live 파일만 고쳐서는 통과하지 못한다. chezmoi source를 먼저 고친 뒤 apply, parity, self-audit, commit과 push까지 확인해야 한다.

Common gate도 작업을 마무리할 때 반복해서 생긴 문제를 흡수하며 보강됐다. Issue와 PR을 만들고도 assignee·milestone·label을 확인하지 않은 채 끝내고, CI가 green이 된 뒤 새 review comment를 다시 읽지 않거나, remote merge만 마친 채 local develop을 뒤처진 상태로 남기는 일이 있었다. 지금은 GitHub의 실제 metadata 확인과 merge 뒤 local sync가 각각 별도 gate다. PR body도 comment나 agent의 보고로 대신하지 않는다. 실제 body를 다시 읽고 마지막 ## heading이 ## DoD Status인지 확인한다.

코딩보다 먼저 내리는 결정이 훨씬 중요하다

개인적으로는 Superpowers의 brainstorming, spec, plan 단계를 실제 코딩보다 훨씬 중요하게 본다. 코딩은 이미 선택한 방향을 파일과 테스트로 옮기는 일이다. 목표와 경계, API contract, 실패 모드를 잘못 정했다면 코드를 빠르고 깔끔하게 작성할수록 엉뚱한 구현만 더 빨리 완성된다. 반대로 앞 단계가 충분히 구체적이면 구현은 검증 가능한 작은 작업의 연속으로 바뀐다.

그래서 Type A에서는 곧바로 editor부터 열지 않는다.

단계	코딩 전에 확정하는 내용	이 단계가 없을 때 생기는 문제
Brainstorming	실제 사용자 문제, 범위와 제외 항목, 2~3개 접근법, 선택 이유, architecture와 실패 처리	첫 아이디어를 요구사항으로 착각해 불필요한 기능이나 잘못된 경계를 구현한다
Design Spec	승인된 동작과 API contract, 대안과 기각 이유, 호환성, 실패 모드, acceptance criteria와 DoD	구현자마다 요구사항을 다르게 해석하고, 테스트가 무엇을 증명해야 하는지 정할 수 없다
Implementation Plan	spec-to-task mapping, dependency order, 정확한 파일, TDD 단계, 검증 command, 문서·rollback·hazard	구현 중에 설계를 다시 시작하고, 테스트·README·CI·Nightly·BOM 같은 후속 작업을 빠뜨린다
Coding	승인된 spec과 plan을 따라 failing test와 최소 구현을 반복한다	앞선 결정이 약하면 코드가 암묵적인 설계 문서가 되어 review 비용이 커진다

Brainstorming은 아이디어를 많이 쏟아내는 회의가 아니다. 선택할 수 있는 접근법을 비교하고, YAGNI 기준으로 범위를 덜어 낸 뒤, 사용자가 설계 방향을 승인하는 과정이다. 그 결과를 design spec으로 고정한다. Spec은 “대략 이런 기능”을 적은 메모가 아니라 구현과 테스트에서 같은 뜻으로 해석할 수 있는 contract다.

Plan도 작업 목록 몇 줄로 끝나지 않는다. Spec의 모든 acceptance criterion이 어느 파일과 테스트, command에서 증명되는지 연결해야 한다. 앞선 task가 뒤 task에서 만들 artifact에 의존한다면 순서를 바로잡는다. Public 동작이 바뀌면 README locale과 KDoc 작업을 배정하고, 새 module이면 CI, Nightly, coverage, BOM 등록까지 task로 고정한다. 구현 도중에 기억해 내기를 기대하지 않고, 빠뜨리기 쉬운 일을 코딩 전에 드러내는 것이다.

이 세 단계에 시간을 쓴다고 코드 작성량이 반드시 줄어드는 것은 아니다. 대신 잘못된 방향으로 코드를 만들었다가 버리는 비용, review에서 architecture를 다시 논의하는 비용, PR을 연 뒤 빠진 contract와 운영 항목을 찾는 비용이 줄어든다. 그래서 작업 속도는 code generation 속도가 아니라, 승인된 요구사항이 검증된 결과로 수렴하기까지 걸린 전체 시간으로 판단한다.

문서를 만들었다고 저절로 안전해지는 것도 아니다. Brainstorming 결과와 spec, plan은 서로 다른 관점에서 다시 읽어야 한다. 작성자는 자신이 의도한 맥락을 이미 알고 있어서 빠진 전제까지 무의식적으로 보완해 읽는다. 다관점 review는 이런 암묵적인 보완을 걷어 내고 performance, stability, security, 운영, API, caller 관점의 빈틈을 찾는다.

2-R, 3-R, 6-R은 P0/P1=0까지 반복하는 7-Tier review다

Type A Full Feature에서 특히 중요한 지점은 2-R, 3-R, 6-R이다. 검토하는 artifact만 다를 뿐 세 단계 모두 같은 7-Tier review와 수렴 조건을 적용한다. Review를 한 번 실행했다는 사실만으로는 통과할 수 없다. 최신 통합 결과가 P0=0, P1=0이 될 때까지 수정과 재검토를 반복한다.

Gate	검토 대상	다음 단계가 열리는 조건
2-R · Spec Review	승인된 design spec, research 근거, 경계, 실패 모드, 호환성, acceptance criteria	design의 최신 통합 review가 P0=0, P1=0
3-R · Plan Review	spec-to-task mapping, dependency order, 테스트·문서·rollback·repository hazard	plan의 최신 통합 review가 P0=0, P1=0
6-R · Pre-PR Review	현재 branch diff, 테스트와 진단 결과, 문서, module별 변경과 PR evidence	현재 diff의 최신 통합 review가 P0=0, P1=0

2-R, 3-R, 6-R은 같은 7-Tier engine을 사용한다. Main session의 최신 통합 결과가 P0=0, P1=0일 때만 다음 gate가 열린다.

여기서 7-Tier란 비슷한 code review를 일곱 번 한다는 뜻이 아니다. 여섯 개의 독립 관점과 main session의 통합 검토로 구성된다. 독립 검토 관점은 Performance, Stability, Security, Operator/Ops, Developer/API, User/Caller다.

앞의 여섯 관점은 서로 다른 실패를 찾는다. 마지막 통합 검토에서는 결과를 모아 중복과 충돌을 정리하고, 심각도를 P0/P1/P2/P3로 통일해 최종 gate를 판정한다. 이 단계는 별도의 일곱 번째 agent에게 넘기지 않는다. 현재 작업의 범위와 변경을 책임지는 main session이 최종 판단을 맡는다.

그림의 red loop는 이 수렴 조건을 나타낸다. Blocker를 수정하고 관련 검증을 다시 실행한 뒤, 전제가 바뀐 review 관점을 다시 열어 main session에서 재통합한다. Gate의 통과 기준은 review를 한 번 실행했는지가 아니라, 최신 artifact가 blocker 없는 상태로 수렴했는지다.

P0/P1은 발견 목록에 적어 두고 나중에 처리할 TODO가 아니라, 즉시 진행을 막는 blocker다. 2-R에 남아 있으면 plan을 작성하지 않고, 3-R에 남아 있으면 구현하지 않으며, 6-R에 남아 있으면 PR을 만들지 않는다. 수정 뒤에는 전체 review를 형식적으로 되풀이하지 않고 영향을 받은 관점과 통합 검토를 다시 실행한다. 수정이 여러 관점의 전제를 바꿨다면 관련 관점을 모두 다시 연다.

P2/P3도 조용히 버리지 않는다. 현재 범위에서 고치거나, 미루는 이유를 기록하거나, 후속 issue로 남긴다. 다만 gate의 절대 종료 조건은 최신 review table의 P0=0, P1=0이다. 이전 반복에서 blocker가 0이었다는 기록이나 이후의 CI 성공은 현재 artifact에 blocker가 없다는 증거가 될 수 없다.

세부 skill마다 실패를 다루는 방식이 다르다

Router가 작업 유형을 골랐다고 실행 방법까지 같아지는 것은 아니다.

같은 router에서 시작해도 유형마다 단계 순서, 강조하는 증거, 실패했을 때 되돌아가는 지점이 다르다.

Bug Fix

Type C는 결함 재현부터 시작한다. root cause를 찾고 같은 문제가 다시 생기면 실패할 regression test를 만든 뒤, 가장 작은 수정을 적용한다. 재현하지 못했다면 추측으로 파일부터 고치지 않는다.

Fast Track

Type B는 변경 범위를 좁히고 targeted test로 증명하는 데 집중한다. 영향 범위가 작다는 근거가 있어야 하며, review에서 P0/P1이 남아 있으면 다음 단계로 가지 않는다. 기능이 작다는 이유로 문서나 API contract 검증을 생략하지 않는다.

Full Feature

Type A는 spec, plan, advisor review, implementation, verification, code review로 이어지는 절차가 더 길다. 새 module이면 settings.gradle.kts, README locale, repo-local module list, CI, Nightly, coverage, BOM/catalog까지 등록 사슬을 확인한다. 파일 몇 개를 만들었다고 module 추가가 끝나는 것은 아니다. 특히 2-R, 3-R, 6-R은 각각 spec, plan, 현재 diff를 독립적으로 검토하며, 어느 단계든 P0/P1=0이 아니면 다음 단계가 열리지 않는다.

Maintenance

Type E는 실제 동작을 바꾸지 않는다. README, blog, AGENTS, skill, config 같은 운영 표면을 다룬다. 특히 Codex guidance는 live 파일이 아니라 managed source부터 고쳐야 다음 chezmoi apply 뒤에도 변경이 남는다.

Publish와 Self Improve

Type P는 release 체크리스트에 target version, 현재 외부 version, publish authority, consumer scope와 dispatch hold를 명시한다. 계획을 승인받았더라도 tag, stable publish, release 생성처럼 되돌리기 어려운 동작은 별도 권한을 다시 확인한다.

Type F를 시작하려면 objective, primary metric, benchmark command, fresh baseline, threshold, stop condition이 있어야 한다. 한 번에 하나의 가설만 시험하고 테스트, sealed-file validation, benchmark acceptance를 모두 통과한 후보만 반영한다.

진행 상황도 DoD를 중심으로 보고한다

작업 중에는 “계속 진행 중”이라고만 말하기보다 현재 gate와 증거를 짧게 보여 주는 편이 낫다.

Type E · BLOG-04 PASS
Action: 한국어 primary route를 작성했다.
Evidence: /ko/blog/... route와 source link 확인.
Next: naturalness review와 site build.

최종 보고에서는 적용한 체크리스트를 다시 세고, 누락된 ID를 숨기지 않는다.

Required checks: 18/18
N/A: 4
Blocked: 0
P0/P1: 0

PR을 만들었다면 assignee, milestone과 label, CI, review thread를 GitHub의 실제 metadata에서 다시 읽는다. PR body의 마지막 ## heading은 ## DoD Status여야 한다. Merge까지 승인받은 작업은 merge 뒤 실제 local checkout을 upstream과 맞춘 뒤에야 끝난다.

실제 작업 만족도는 어디까지 올라왔나

여기까지 오는 동안 시행착오가 많았다. 지침을 늘려도 일부 단계를 건너뛰고, 체크리스트를 만들고도 증거 없이 완료로 표시했으며, live 설정과 managed source가 어긋나 개선 내용이 사라지기도 했다. 이런 문제를 하나씩 workflow와 검증 gate에 반영한 뒤에는 체감 결과가 크게 달라졌다.

개인적인 작업 만족도는 gpt-5.5의 high reasoning부터 약 90%였고, 현재 gpt-5.6-sol의 high reasoning은 약 98%다. 정해진 benchmark suite로 측정한 성공률이 아니라, 실제 Bluetape 작업 결과를 검토하며 느낀 주관적인 만족도다. 모델 자체의 향상과 skill 개선 효과를 따로 떼어 계산한 값도 아니다. 같은 repository 규칙과 workflow를 반복해서 적용했을 때, 결과를 되돌려 고치거나 누락된 절차를 다시 지시하는 빈도가 눈에 띄게 줄었다는 운영 경험을 숫자로 표현한 것이다.

특히 만족도가 높아진 이유는 첫 답변의 문장 품질보다 작업의 연속성이 좋아졌기 때문이다. 승인된 범위에서는 멈추지 않고 진행하고, 단계마다 필요한 증거를 남기며, 실패한 gate를 뒤 단계의 성공으로 덮지 않는 경우가 늘었다. Full Feature에서는 2-R, 3-R, 6-R의 7-Tier review를 blocker가 없어질 때까지 반복하는 구조가 설계와 계획, 구현 사이의 누락을 크게 줄였다. 좋은 모델은 skill을 더 잘 따르고, 잘 정리된 skill은 좋은 모델이 repository 안에서 일관된 결과를 내도록 돕는다.

직접 사용할 때 기억할 점

첫 요청에 $bluetape-workflow를 붙인다. Router가 제시한 분류와 첫 계획을 확인한다. 승인한 뒤에는 각 단계의 설명보다 Evidence가 실제 command, file, URL, test 결과로 채워지는지 본다.

$bluetape-workflow

이 실패를 재현하고 root cause를 고친 뒤 regression test로 증명해 줘.

$bluetape-workflow

새 module을 추가하되 README locale, CI, Nightly, BOM 등록까지 확인해 줘.

$bluetape-workflow

이 PR은 수정하지 말고 P0/P1 우선으로 review해 줘.

Workflow를 쓴다고 긴 절차를 무조건 실행하는 것은 아니다. 작업을 정확히 분류하고 필요한 절차만 열되, 한 번 열린 gate는 증거 없이 지나가지 않는다는 뜻이다. 이 기준이 있으면 작은 문서 수정은 가볍게 끝내고, release나 새 module처럼 위험한 작업은 필요한 만큼 엄격하게 다룰 수 있다.

시리즈 글

• 먼저 읽기: AI와 일하는 환경을 인프라로 만들기
• Bluetape Skills Part 1: 팀과 공유하고 설치하는 방법
• Bluetape Skills Part 2: bluetape-workflow로 작업을 시작하는 방법
• Bluetape Skills Part 3: 중단된 workflow를 이어서 복구하는 방법

Repository

• bluetape4k/bluetape-skills