PABCD 워크플로우 기본 활성

Plan(계획) → Audit(감사) → Build(구현) → Check(검증) → Done(완료) 구조화된 개발 워크플로우로, 각 게이트마다 사용자 체크포인트가 필수입니다.

자동 활성 스킬. dev-pabcd는 모든 세션에 자동으로 주입되는 10개의 개발 스킬 중 하나입니다. 오케스트레이션 모드에서 활성화되며, 검토된 계획 없이는 아무것도 구현되지 않도록 보장하는 구조화된 5단계 워크플로우를 제공합니다.

빠른 참조

속성
스킬 이름dev-pabcd
카테고리개발 / 오케스트레이션
기본 활성예 — 세션 시작 시 주입
/skill load 필요 여부아니오
단계P (Plan) → A (Audit) → B (Build) → C (Check) → D (Done)
사용자 게이트P, A, B는 승인 필요 — C, D는 자동 진행
워커 역할읽기 전용 검증자 (코드 작성 불가)
초기화 명령어cli-jaw orchestrate reset

상태 머신

PABCD는 단방향 루프입니다 — 앞으로만 진행하며, 단계를 건너뛸 수 없습니다. 각 단계는 다음 단계로 넘어가기 전에 반드시 완료되어야 합니다.

IDLE ──→ P ──→ A ──→ B ──→ C ──→ D ──→ IDLE
         │      │      │      │      │
        STOP   STOP   STOP   auto   auto
        wait   wait   wait

P, A, B 단계는 진행 전에 사용자 승인을 대기합니다. CD 단계는 작업이 완료되면 자동으로 진행됩니다.

전환 명령어

명령어전환전제 조건
cli-jaw orchestrate P계획 단계 진입IDLE 상태여야 함
cli-jaw orchestrate A계획 감사 단계 진입P 상태여야 함 (계획 승인됨)
cli-jaw orchestrate B구현 단계 진입A 상태여야 함 (감사 통과됨)
cli-jaw orchestrate C검증 단계 진입B 상태여야 함 (구현 승인됨)
cli-jaw orchestrate D완료 단계 진입C 상태여야 함 (검증 완료됨)
cli-jaw orchestrate resetIDLE로 복귀모든 상태에서 가능

단계 상세

P — Plan (계획) 사용자 승인 필요

계획 단계에서는 프로젝트 문서와 개발 스킬을 읽은 후 두 부분으로 구성된 계획을 작성합니다:

  • 파트 1 — 쉬운 설명: 무엇을 만들 것인지 비개발자 용어로 설명합니다. 누구나 이해할 수 있어야 합니다.
  • 파트 2 — Diff 수준의 정밀도: 정확한 파일 경로 (NEW / MODIFY / DELETE), MODIFY의 경우 변경 전/후 diff, NEW의 경우 전체 내용을 포함합니다.

범위 명확화

요청의 범위가 불명확하거나 기술이 지정되지 않은 경우, 계획 수립자가 먼저 명확히 합니다:

  • <기술명> -- <쉬운 설명> 형태로 2-3개 옵션을 제시합니다
  • 프로젝트에 맞는 근거와 함께 하나를 추천합니다
  • 한 번 확인 후 진행합니다

저장소 스캔 (광범위한 변경)

광범위한 변경이나 익숙하지 않은 저장소의 경우, P 단계에서 반드시 다음을 포함해야 합니다:

  • 현재 저장소 구조의 간결한 트리
  • 감지된 저장소 규칙: 문서, 계획, 아키텍처 노트, 진실 소스(source-of-truth) 로그, 네이밍, 테스트
  • 기존 structure/, devlog/, docs/, plans/ 또는 동등한 로그를 읽었는지 여부와 재사용 계획
  • structure/ 또는 devlog/ 생성 제안 여부

Devlog 명명 규칙

PABCD 작업에서 devlog/ 계획 산출물을 생성하거나 업데이트하는 경우, 계획에 정확한 번호가 매겨진 Jawdev 파일명을 나열해야 합니다:

00_overview.md
01_phase1_<slug>.md
02_phase2_<slug>.md

PLAN.md, DIFF_PLAN.md, PHASES.md, RCA.md, plan.md 같은 단순 파일명은 새로운 devlog 단계 파일로 허용되지 않습니다.

게이트 질문

계획을 제시하기 전에 계획 수립자가 질문합니다:

  1. "제가 단독으로 결정하면 안 되는 비즈니스 로직이 있나요?"
  2. "파트 1이 의도와 일치하나요?"

계획이 제시되고 피드백에 따라 수정됩니다. 사용자가 승인하면 cli-jaw orchestrate A로 전환합니다.

A — Plan Audit (계획 감사) 사용자 승인 필요

워커가 생성되어 계획을 감사합니다 (코드가 아님). 워커가 검증하는 항목:

  • 계획에 있는 모든 파일 경로와 import가 실제로 존재하는지
  • 함수 시그니처가 실제 코드와 일치하는지
  • 통합 위험이 없는지
  • 기존 진실 소스(source-of-truth) 문서/로그가 있을 때 읽었는지
  • 사용자 승인 없이 새로운 structure/, devlog/, 문서, AGENTS 파일이 도입되지 않았는지
  • 새 JS/TS 파일이 TypeScript 우선 규칙을 따르는지 (계획에서 JS가 필요한 이유를 명시하지 않는 한)
  • 새 TypeScript가 strict 호환이거나 제한 사항이 명시되었는지
  • 새 devlog 단계 문서가 번호가 매겨진 Jawdev 파일명 규칙을 따르는지

워커가 감사 결과를 JSON으로 출력합니다. 결과가 검토됩니다:

  • FAIL → 계획을 수정하고 재감사
  • PASS → 결과를 사용자에게 보고

사용자가 승인하면 cli-jaw orchestrate B로 전환합니다.

B — Build (구현) 사용자 승인 필요

구현 단계입니다. 보스가 모든 코드를 직접 작성합니다. 워커는 읽기 전용 검증자 역할만 합니다.

구현 후, 코드가 존재하고 깔끔하게 통합되는지 확인하기 위해 워커가 검증에 투입됩니다:

  • NEEDS_FIX → 보스가 문제를 수정하고 재검증
  • DONE → 결과를 사용자에게 보고

P 단계에서 승인되었거나 명시적으로 요청되지 않는 한 structure/ 또는 devlog/를 생성하지 않습니다.

사용자가 승인하면 cli-jaw orchestrate C로 전환합니다.

C — Check (검증) 자동 진행

자동으로 실행되는 최종 정합성 검사입니다:

  1. 모든 파일이 저장되고 일관성이 있는지 확인
  2. npx tsc --noEmit 실행 (TypeScript 프로젝트인 경우)
  3. 해당하는 경우 프로젝트 구조 문서 업데이트
  4. 완료 요약 보고

완료되면 cli-jaw orchestrate D를 통해 자동으로 D 단계로 전환됩니다.

D — Done (완료) 자동 진행

전체 PABCD 흐름을 요약합니다:

  • 계획된 내용(P), 감사된 내용(A), 구현된 내용(B), 검증된 내용(C)
  • 변경된 파일 목록
  • 후속 작업 항목

상태가 자동으로 IDLE로 돌아갑니다.

규칙

#규칙상세
1응답당 하나의 단계작업을 제시한 후, P, A, B 게이트에서 사용자 승인을 대기합니다. 절대 앞서 나가지 않습니다.
2엄격한 순서P → A → B → C → D. IDLE에서 다시 시작하려면 cli-jaw orchestrate reset을 사용합니다.
3워커는 검증, 보스가 작성워커는 읽기 전용입니다. 모든 코드는 B 단계에서 보스가 직접 작성합니다.

저장소 루트 계약

PABCD 계획을 작성하거나 워커를 디스패치하기 전에, 대상 저장소에서 pwd -P로 실제 작업 저장소 루트를 확인합니다.

모든 A/B 단계 cli-jaw dispatch 작업 본문은 반드시 다음으로 시작해야 합니다:

Project root: /absolute/path/to/current/repo
규칙설명
Project root = 작업 저장소현재 작업 중인 저장소여야 하며, JAW_HOME이 아닙니다
추론 금지워커가 ~/.cli-jaw*, process.cwd(), 또는 직원 임시 디렉토리에서 저장소 루트를 추론하도록 두지 않습니다
절대 경로모든 상대 저장소 경로 (src/, tests/, structure/, skills_ref/)를 Project root 기준으로 해석합니다
루트 미확인 = 중단Project root를 알 수 없으면, 디스패치 전에 중단하고 확인합니다

공유 계획 주입

P가 완료되면, 계획은 worklog ## Plan 섹션 (단일 진실 소스)에 저장되고 ctx.plan에 유지됩니다. 프로젝트 루트에 파일이 생성되지 않습니다.

자동 주입: A와 B 단계에서 오케스트레이터가 모든 cli-jaw dispatch 작업의 상단에 ## Approved Plan 아래에 전체 계획 본문을 자동으로 주입합니다. 워커는 계획 파일을 읽을 필요가 없습니다 — 자동으로 앞에 추가됩니다.

디스패치 작업 본문에는 실제 감사/검증 지시만 포함하면 됩니다. 예시:

cli-jaw dispatch --agent "Backend" --task "Project root: /path/to/repo

Audit: verify the imports in src/routes/auth.ts..."

"계획을 읽어라"라는 줄은 필요하지 않습니다 — 계획이 이미 주입되어 있습니다.

주의사항

PABCD 실행 시 반드시 피해야 할 치명적인 안티패턴입니다.

위임 함정

B 단계에서 보스가 모든 코드를 작성합니다. 워커는 읽기 전용 검증자입니다.

디스패치예시
금지작성/구현"implement the feature", "write the code", "create the file"
허용검증/확인"verify src/x.ts compiles", "check integration of Y", "report DONE or NEEDS_FIX"

컨텍스트 드리프트

워커가 "계획에 대한 추정을 바탕으로 진행하겠습니다"라고 하면 — 중단하세요. 디스패치가 /api/orchestrate/dispatch를 통해 전달되었는지 확인하세요 (해당 경로만 계획을 자동 주입합니다). 워커가 짧은 작업 설명에서 계획을 재구성하도록 두지 마세요.

단계 건너뛰기

A (감사)는 절대 "불필요"하지 않습니다. 아무리 간단한 계획이라도 통합 문제가 발생할 수 있습니다. 먼저 감사하세요. B 검증은 절대 "건너뛸 수 없습니다". 테스트되지 않은 코드는 "완료"가 아닙니다. 현재 오케스트레이터가 이 게이트를 강제하지 않습니다 — 당신이 강제해야 합니다.

"~해줘" 사용 예시

자연어로 PABCD 워크플로우를 트리거하는 실제 예시입니다.

기능 개발
"이 프로젝트에 WebSocket 채팅 기능 추가해줘"

전체 PABCD가 트리거됩니다: WebSocket 아키텍처를 계획하고, import와 통합 지점을 감사하고, 구현을 빌드하고, TypeScript 컴파일을 검증하고, 변경된 파일을 요약합니다.

계획을 포함한 리팩토링
"인증 시스템 전체 리팩토링해줘 -- JWT에서 세션 기반으로"

범위가 넓으므로 P 단계에서 저장소 트리를 스캔하고, 인증 관련 파일을 모두 식별하며, diff 수준의 정밀 계획을 작성합니다. A 단계에서 import 경로가 깨지지 않았는지 감사합니다.

데이터베이스 마이그레이션
"D1 데이터베이스 스키마 마이그레이션 계획 세워줘"

P 단계에서 마이그레이션 범위(어떤 테이블인지, 하위 호환성)를 명확히 하고, 파트 1 쉬운 설명과 파트 2 정확한 SQL 마이그레이션 파일을 작성합니다. A 단계에서 기존 스키마 참조를 검증합니다.

다중 파일 기능
"API 라우트 5개 새로 만들고 테스트도 다 붙여줘"

P 단계에서 모든 NEW 파일과 전체 내용을 나열합니다. B 단계에서 각 라우트와 테스트 파일을 구현합니다. C 단계에서 프로젝트 전체에 tsc --noEmit을 실행하여 타입 오류를 잡습니다.

감사 포함 버그 수정
"프로덕션 에러 원인 찾아서 고쳐줘 -- PABCD로 진행해"

버그 수정의 경우에도 PABCD는 근본 원인이 P에 문서화되고, 수정 계획이 A에서 감사되며, 구현이 B에서 검증되고, 다른 부분이 C에서 깨지지 않도록 보장합니다.

다른 스킬과의 관계

PABCD는 다른 개발 스킬을 감싸는 구조화된 워크플로우 레이어입니다. PABCD가 활성화되면 dev-backend, dev-frontend, dev-testing 같은 전문 스킬이 PABCD의 감독 하에 B (Build) 단계 내에서 동작합니다.

스킬PABCD와의 관계
dev복잡한 작업에 대해 PABCD를 활성화할 수 있는 오케스트레이터
dev-backend / dev-frontendB 단계 구현 시 주입되는 전문 컨텍스트
dev-testing테스트 작성은 B 단계에서, 테스트 실행은 C 단계에서 수행
dev-code-reviewer빌드 후 코드 품질을 검토하여 A 단계를 보완
dev-debugging구조화된 버그 수정 워크플로우를 위해 PABCD를 트리거 가능
dev-security보안 검사가 A (계획 감사) 및 C (검증) 단계에 통합
참고: 상위 수준 개요는 개념 → PABCD를, 자동 활성 개발 스킬의 전체 목록은 개발 스킬을 참조하세요.