콘텐츠로 이동

워크플로

핵심 워크플로우

표준 기능 개발 워크플로우에서는 각 산출물에 출처를 연결하며 다음 순서로 진행합니다.

/specify          → requirements.md
/generate-spec    → spec.md       → review-spec
/spec-to-design   → design.md     → review-design
/design-to-plan   → plan.md       → review-plan
/plan-to-tasks    → tasks.md      → review-tasks → analyze
/implement-tasks  → implementation and complete-feature code review

아래 예시는 Claude의 /codexspec: 접두사를 사용합니다. Codex에서는 명령어 이름과 인수는 그대로 두고 $codexspec:을 사용하세요.

단계 명령어 목적과 산출물
프로젝트 원칙 /codexspec:constitution constitution.md를 작성·업데이트하고 영향을 받는 산출물 검증
요구사항 /codexspec:specify <idea> 의도를 논의하고 최종 요약을 확인한 뒤 requirements.md에 저장
명세서 /codexspec:generate-spec <feature-dir> 확정된 요구사항을 바탕으로 출처 참조가 포함된 spec.md 작성
시스템 설계 /codexspec:spec-to-design <feature-dir> 컴포넌트, 인터페이스, 주요 설계 결정을 담은 design.md 작성
구현 계획 /codexspec:design-to-plan <feature-dir> 구현 단계, 순서, 검증 방법을 담은 plan.md 작성
태스크 /codexspec:plan-to-tasks <feature-dir> 추적·검증 가능한 tasks.md를 작성하고 산출물 간 분석 실행
구현 /codexspec:implement-tasks <feature-dir> 태스크를 수행하고 결과를 검증하며, 독립적으로 검증된 리뷰 지적 수정

<feature-dir>를 요구사항 논의 중 반환된 기능 디렉터리로 바꾸세요. 해당 worktree에서 작업을 이어가거나 경로를 명시적으로 전달하면, 명령어나 세션이 바뀌어도 같은 기능으로 처리됩니다.

specify, clarify, analyze

  • specify는 요구사항 논의를 시작하거나 다시 진행합니다. 요구사항 요약은 명시적인 확인을 받아야 공식적인 판단 기준이 됩니다.
  • clarify는 기존 요구사항과 명세의 모호함을 해소합니다. 한 번 실행할 때 네 가지 범주에 걸쳐 최대 다섯 가지 질문을 합니다. 먼저 requirements.md를 업데이트하고, 그다음 spec.md를 동기화합니다.
  • analyze는 요구사항 → 명세 → 설계 → 계획 → 태스크의 전체 흐름을 확인합니다. 상위 판단 기준에 따라 수정 내용이 하나로 정해지는 경우 하위 산출물을 자동으로 수정합니다. requirements.md는 절대 편집하지 않습니다. 해결되지 않은 지적은 보고합니다. 태스크 리뷰를 통과하면 자동으로 실행되지만, 정보를 제공하는 절차이며 구현의 통과 여부를 판정하지는 않습니다.
/codexspec:clarify <feature-dir>
/codexspec:analyze <feature-dir>

Quick으로 작은 변경 수행

국소적인 수정처럼 작고 범위가 명확한 변경에는 quick을 사용하세요.

/codexspec:quick Fix the empty-state message on the task list

Quick은 간결한 요구사항 요약을 확인하고 저장한 다음 명세 작성, 계획, 태스크, 구현을 순서대로 진행합니다. 각 생성 명령어의 리뷰도 함께 수행합니다. 변경 범위가 넓거나 제품·설계 선택이 아직 해결되지 않았다면 표준 워크플로우를 사용하세요. Quick은 새로운 결정이 필요할 때 일시 중지합니다.

워크플로우 자동화

workflow.auto_next의 기본값은 false입니다. 현재 작업 공간의 설정이 true이면 최종 요구사항 확인 후 명세 작성으로 진행합니다. 각 생성 단계는 PASS 또는 PASS_WITH_WARNINGS이면 다음 단계로 넘어가고, NEEDS_REVISION 또는 BLOCKED이면 멈춥니다. implement-tasks가 마지막 단계입니다.

산출물 자동 수정은 검증된 결함 중 상위 근거에 따라 수정 방향이 정해지는 경우에만 적용됩니다. 수정과 리뷰는 최대 두 라운드까지 수행하며, 권고 사항은 별도로 다룹니다. 구현의 리뷰·수정 반복에는 아래에서 설명하는 별도의 완료 조건이 있습니다.

공유 블루프린트와 자율 개발

개발 전에 확정된 요구사항을 여러 개 준비하려면 blueprint를, 그 대기열을 개발하려면 auto-dev를 사용하세요.

/codexspec:blueprint Add a confirmed requirement for task reminders
/codexspec:auto-dev

블루프린트의 요구사항 논의에서는 사용자가 정해야 할 방향, 선택, 제약을 해결한 다음 요구사항을 대기열에 넣습니다. 공유 .codexspec/blueprint.md에서는 pending, in_progress, completed 상태를 사용합니다. 대기 중인 요구사항은 추가, 교체, 삭제하거나 순서를 바꿀 수 있습니다. 진행 중이거나 완료된 항목은 블루프린트 관리 작업에서 읽기 전용입니다.

Auto-dev는 문서에 나온 순서대로 개발하며, 진행 중인 기능이 있으면 다른 기능을 시작하기 전에 재개합니다. 기능이 완료될 때마다 대기열을 다시 읽으므로 새로 추가한 대기 작업도 현재 실행에서 처리할 수 있습니다. 확정된 요구사항의 범위 안에서 SDD 단계, 구현, 검증, 리뷰, 수정을 수행합니다. auto-dev를 호출하면 workflow.auto_next와 관계없이 자동화가 활성화되며, 이 설정 자체는 바꾸지 않습니다.

두 명령어는 codexspec/auto-dev 브랜치의 worktree-for-codexspec-auto-dev를 공유합니다. 공통 소유권 관리와 쓰기 보호에 따라 동시에 사용할 수 있지만, 요구사항 개발은 그 작업 공간에서 순차적으로 진행합니다. 확정된 요구사항만으로 정할 수 없는 제품 결정이 필요하면, 일반적인 자율 실행 중에는 질문하지 않고 근거를 제시한 뒤 실행을 멈춥니다.

현재 공유 블루프린트를 변경하지 않고 확인하려면 다음을 실행합니다.

codexspec show-blueprint

worktree 개발

Git worktree는 같은 리포지토리의 별도 작업 디렉터리로, 각 디렉터리에 브랜치를 체크아웃할 수 있습니다. CodexSpec은 기본적으로 일반 기능마다 하나씩 생성합니다. 첫 요구사항을 쓰기 전에 worktree를 만들고, 그 기능의 문서, 구현, 테스트, 수정 사항을 같은 곳에서 관리합니다.

projects/
├── my-project/
└── my-project-codexspec-worktrees/
    ├── <feature-id>-task-reminders/
    ├── <feature-id>-search/
    ├── worktree-for-codexspec-maintenance/
    └── worktree-for-codexspec-auto-dev/

기능 작업을 이어갈 때는 같은 작업 공간을 재사용합니다. 독립적인 설정, 프로젝트 헌법, 프로파일 변경은 유지보수 worktree에서 수행합니다. 진행 중인 기능에서 발생한 변경은 그 작업 공간에 남습니다. 설정은 체크아웃별로 적용됩니다. 작업 대상으로 선택된 worktree에서 바꾼 설정은 먼저 그곳에서 적용되고, Git으로 통합하면 다른 체크아웃에도 전달됩니다. CLI 명령어와 검사는 반환된 작업 공간에서 실행하세요.

새 기능의 기준을 정할 때는 커밋된 로컬 main 브랜치 이력과 fetch로 가져온 원격 main 브랜치 이력을 Git의 조상 관계로 비교합니다. 이력이 갈라졌다면 새 worktree 안에서 병합하고 검증해야 합니다. fetch에 실패하면 경고를 표시하고 로컬에서 사용할 수 있는 참조로 계속 진행할 수 있습니다. worktree 생성에 실패하더라도 main 체크아웃에 쓰는 방식으로 전환하지 않습니다.

workflow.worktrees의 기본값은 true입니다. YAML 리터럴 false를 지정한 경우에만 일반 기능 및 유지보수 작업의 격리가 꺼집니다. 이 설정과 관계없이 blueprint/auto-dev는 고정된 공유 worktree를 사용합니다. 초기화와 설치 업데이트는 사용자가 명시적으로 선택한 체크아웃에서 수행합니다. 완료된 worktree는 보존하며, 작업 완료 시 자동으로 병합하거나 삭제하지 않습니다.

worktree 개발과 설정을 참고하세요.

기존 코드 작업

기존 코드에는 목적에 따라 두 가지 명령어를 사용합니다.

명령어 용도 산출물과 작업 범위
onboard [path] 기존 코드베이스에서 재사용할 수 있는 프로젝트 지식을 초기 등록 관례 후보와 근거에 따라 범위를 한정한 제약을 프로파일에 기록. 코드는 읽기 전용
reverse-spec [path] 기존 아키텍처를 이해하거나 확정된 의도와 코드를 비교 산출물 초안 또는 차이 보고서. 코드는 읽기 전용 
/codexspec:onboard src/
/codexspec:reverse-spec
/codexspec:reverse-spec src/auth

Onboard는 관찰할 수 있는 코드에서 관례를 추론하며, 명시적인 금지 사항이 있을 때만 제약을 제안합니다. 관례 후보는 로컬에 즉시 적용됩니다. 제약 후보는 세션 안에서 저장·편집·제외 여부를 결정해야 합니다. 기존 지식은 보존합니다. 처음 수행하는 코드 스캔만으로 과거 결정의 이유나 실제로 경험했는지 알 수 없는 함정을 지어내지 않습니다.

Reverse-spec에는 세 가지 모드가 있습니다.

  • 개요: 경로를 지정하지 않거나 리포지토리 루트를 지정한 경우입니다. 조사할 모듈을 선택할 수 있도록 아키텍처의 요점을 담은 design.md와 slices.md를 만듭니다.
  • 생성: 확정된 기준이 없는 모듈 경로를 지정한 경우입니다. spec.md, design.md, 미확정·추론 단계의 요구사항을 초안으로 만듭니다.
  • 대조: 확정된 기준이 있는 모듈을 지정한 경우입니다. reconcile.md를 만들고, 확정된 명세·설계와 비교해 문서화되지 않은 동작, 구현되지 않은 명세, 의미 불일치를 보고합니다. 제품 의도는 요구사항을 기준으로 판단합니다.

추론으로 만든 초안은 사람이 확인해야 기준으로 사용할 수 있습니다. 대조에서는 코드 수정, 문서 업데이트, 의도 결정 중 어느 방향으로 진행할지 제안하며, 이를 자동으로 적용하지는 않습니다.

리뷰와 디버깅

네 가지 산출물 리뷰어 review-spec, review-design, review-plan, review-tasks는 충실도, 요구사항 충족 범위, 실현 가능성, 내부 품질을 확인합니다. 생성 후 자동으로 실행되며 수동으로 호출할 수도 있습니다. 보고서는 검증된 결함과 통과 여부에 영향을 주지 않는 위험 권고 및 설계 개선안을 구분하고, 적합도 점수도 제공합니다.

review-code는 선택한 변경에 적용되는 별도의 결함 게이트와 명시적인 코드 전체 품질 평가를 제공합니다.

/codexspec:review-code --feature <feature-dir>
/codexspec:review-code --uncommitted
/codexspec:review-code --audit src/

기본 리뷰 대상은 기능 브랜치의 전체 변경분입니다. 커밋된 변경, 스테이징된 변경, 스테이징되지 않은 변경, Git 무시 대상이 아닌 미추적 변경이 모두 포함됩니다. 커밋된 변경, 미커밋 변경, 단일 커밋 중 하나를 명시적으로 선택할 수도 있습니다. --feature는 요구사항 맥락을 추가하지만 Git 범위를 좁히지는 않습니다. --audit는 지정된 경로를 평가하고 완료 판정 대신 권고용 평가표를 작성합니다.

리뷰는 .codexspec/review-code/에서 공통 기준을 읽고, 관련 동작 관점과 언어·프레임워크 검사를 선택합니다. 지적에는 구체적인 근거, 실제로 발생할 수 있는 조건, 선택한 변경에서 비롯되었다는 설명, 영향이 필요합니다. 리뷰어는 파일을 편집하지 않고 결함과 근거가 있는 유지보수 제안을 보고합니다. 수정을 수행하는 호출자는 이를 독립적으로 검증합니다.

구현할 때 코드 태스크는 테스트를 먼저 작성하고, 문서와 설정은 직접 변경한 뒤 적절한 검사를 수행합니다. 수정 후의 점진적인 재리뷰에서는 영향을 받지 않은 범위의 확인 결과를 재사용할 수 있습니다. 최종 승인을 받으려면 새로 수행한 기능 전체 리뷰에서 PASS를 받아야 하며, 대상 범위 확인과 검증이 완료되고, 인정된 P0–P3 결함이 하나도 남지 않아야 합니다. 근거가 있는 유지보수 제안은 별도로 보고합니다.

workflow.auto_maintenance의 기본값은 true입니다. 수정을 수행하는 호출자가 검증되었으며 호환성을 유지하는 유지보수 개선도 적용할지 이 설정으로 제어합니다. 꺼도 제안은 계속 보고하며, 결함 수정이나 필수 검사가 면제되지는 않습니다. 단계 자동 진행과는 별개이며 implement-tasks의 인수가 아닙니다.

근본 원인부터 조사하는 디버깅에는 다음 명령어를 사용합니다.

/codexspec:debug Investigate intermittent failures when saving a task

Debug는 조사 → 패턴 분석 → 단일 가설 검증 → 실패하는 테스트를 먼저 작성한 뒤 수정하는 순서로 진행합니다. 구현 중 수정이 막히거나, 단순하지 않은 동작상 결함의 원인을 추적해야 하거나, 같은 유형의 근본 원인이 여러 리뷰 라운드에서 재발하면 이 절차로 전환합니다. 수정이 세 번 실패하면 아키텍처를 재검토합니다.

요구사항의 명확성, 완전성, 일관성을 평가하려면 checklist를 사용하세요.

/codexspec:checklist Check the authentication requirements for completeness

리뷰 대상을 선택하는 방법, 인수, 자세한 절차는 명령어 참조를 참고하세요.

프로젝트 지식

프로젝트 프로파일은 재사용할 수 있는 지식을 .codexspec/profile/에 저장합니다.

범주 내용
constraints/ 명시적인 금지 사항과 반드시 지켜야 할 경계. 가장 먼저 읽음
conventions/ 패턴, 명명 규칙, 여러 기능에 공통으로 적용되는 지침
pitfalls/ 실제로 겪은 함정과 그 원인, 우회 방법, 교훈
decisions/ 재사용할 수 있는 아키텍처 결정 및 여러 기능에 걸친 결정
strategies/ 작업 방식을 바꿔야 한다는 신호
runbooks/ 순서에 따른 작업 절차와 실패 시 복구 방법

distill은 작업에서 재사용할 수 있는 지식을 추출합니다. 기능별 의도는 해당 기능의 요구사항·설계·계획에 남깁니다. 초기화는 CLAUDE.md 또는 AGENTS.md, 혹은 두 파일 모두에 지침을 추가해 본격적인 작업 전에 모든 제약과 관련 지식을 읽도록 합니다. 나중에 추가한 지식도 재초기화 없이 적용될 수 있습니다. 후보 기록은 신중하게 사용하며, 검토·승인된 기록에는 결과 검증과 사람의 승인이 필요합니다.

/codexspec:distill Capture the reusable lessons from this work
/codexspec:distill review
/codexspec:evolve

수동 distill review 또는 새로 추출할 자료가 없는 상태에서 직접 호출한 distill은 로컬에서 동작하는 오프라인 브라우저 작업 공간을 엽니다. 기록을 수정, 검토·승인, 폐기, 보류, 통합하고 최종 Markdown을 미리 본 다음 모두 적용을 선택할 수 있습니다. 적용 전까지 결정은 복구 가능한 초안으로 저장됩니다. 충돌 검사는 일부만 적용되거나 알림 없이 덮어쓰는 일을 막습니다. 브라우저를 사용할 수 없는 환경에서는 명시적으로 텍스트 방식으로 전환할 수도 있습니다.

workflow.auto_distill의 기본값은 true이며, 세 가지 마무리 훅을 제어합니다. implement-tasks 성공 시, commit-staged로 커밋을 실행할 때, pr 생성 시입니다. 커밋 미리보기는 지식 추출을 실행하지 않습니다.

설치된 프로젝트 지침은 일반 대화, SDD 밖의 수정, 긴 implement-tasks 실행 중에도 재사용할 수 있는 지식이 생길 때마다 기록하도록 에이전트에 요구합니다. 이 지침은 마무리 설정과 별개로 적용됩니다. 태스크 종료 시의 추출은 누락을 막기 위한 마지막 기회입니다.

같은 세션에서 반복 호출되면 새 자료만 처리합니다. 세션이 바뀌면 distill은 프로파일을 읽고 이미 다룬 지식을 건너뜁니다. 재사용할 내용이 남아 있지 않으면 쓰지 않고 종료합니다. 자동 추출은 수동 리뷰를 열거나 사람의 응답을 기다리거나 호출한 워크플로우를 막지 않습니다.

evolve는 검토·승인된 지식 중 프로젝트 밖에서도 유용한 것만 선택해 명령어·스킬 초안으로 정리합니다. 푸시하거나 사람이 리뷰할 기여 PR을 만들기 전에 명시적인 승인을 받습니다.

자세한 지침은 프로젝트 지식을 참고하세요.

과거 결정 재사용

에이전트는 변경 사항에 관해 사용자에게 질문하기 전에 .codexspec/specs/에서 관련 기능의 개발 이력을 살펴봅니다. requirements.md에 기록된 확정된 결정을 읽고, 이후 추가된 내용과 명시적으로 대체된 결정을 추적합니다. 필요하면 설계 이유나 구현 근거도 확인합니다. 설계, 구현, 디버깅, 리뷰에 관한 실질적인 판단을 내리기 전에도 이러한 준비가 필요하며, 일반 대화와 SDD 워크플로우 모두에 적용됩니다.

기능 디렉터리의 타임스탬프는 개발 과정의 선후 관계를 파악하는 데 사용합니다. 더 최근 문서가 있다고 해서 이전 결정이 자동으로 무효가 되는 것은 아닙니다. 이전에 확정되고 변경되지 않은 요구사항은 계속 적용되며, 아직 논의 중인 제안을 확정된 의도로 취급하지 않습니다. 검색은 현재 작업과 관련된 범위로 한정하고, 판단에 필요한 배경 정보가 충분히 모이면 멈춥니다. 이후 단계에서도 이 정보를 재사용합니다.

예를 들어 인터페이스를 변경할 때 과거 맥락을 확인하지 않았다면 다음과 같이 물을 수 있습니다.

“이 기능의 하위 호환성은 어떻게 처리할까요?”

관련 결정과 현재 구현을 확인한 뒤에는 질문의 범위를 좁힐 수 있습니다.

“이전에 기존 인터페이스를 유지하기로 확정했고, 현재 구현도 계속 지원하고 있습니다. 이번 변경에서도 유지하는 것을 제안합니다. 그렇게 진행할까요?”

이미 확정된 정보가 지금도 명확히 적용된다면 다시 묻지 않고 재사용합니다. 사용자가 이미 “이번에는 기존 인터페이스를 제거하세요”라고 명시했다면, 에이전트는 그 결정에 따라 진행하고 마이그레이션에 미치는 영향을 설명합니다. 사용자가 가장 최근에 명시한 결정이 항상 우선합니다. 과거 이력은 더 정확하게 질문하고 같은 질문을 반복하지 않기 위한 자료입니다.

이 지침을 받으려면 기존 프로젝트 설치를 갱신하세요.

Git 워크플로우

/codexspec:commit-staged -p
/codexspec:pr --spec <feature-dir>/spec.md
/codexspec:release-notes --from <ref> --to HEAD
/codexspec:tasks-to-issues <feature-dir>
  • commit-staged는 스테이징 영역의 실제 내용을 분석해 Conventional Commits 메시지를 생성합니다. -p는 커밋하지 않고 미리 보는 옵션입니다. 파일 선택과 스테이징은 호출한 워크플로우가 수행합니다. 승인된 실행에서는 보호된 런타임을 사용해 커밋할 내용이 분석 대상과 일치하는지 다시 확인합니다. 에이전트 커밋 지침은 일반 대화, SDD, blueprint, auto-dev에도 적용됩니다. 명령어를 사용할 수 있다는 사실만으로 호출이 이루어지거나 커밋 권한이 부여되는 것은 아닙니다.
  • pr은 변경분에서 구조화된 GitHub PR 또는 GitLab MR 설명을 생성합니다. --spec을 지정하면 spec.md 파일 경로, 또는 그 파일로 연결되는 기능 디렉터리 이름이나 접두사를 통해 기능 맥락을 추가할 수 있습니다. 기본 출력은 호스팅 플랫폼에서 사용할 텍스트입니다.
  • release-notes는 Git 이력에서 Keep a Changelog 항목과 릴리스 본문을 작성합니다. 기본 섹션은 [Unreleased]이며, --version을 지정하면 제공한 라벨을 사용합니다. 스테이징, 커밋, 버전 변경, 태그, 게시, 릴리스 생성을 수행하지 않습니다.
  • tasks-to-issues는 기존 태스크에서 의존성과 수용 기준을 포함한 GitHub 이슈를 생성합니다. 인증된 GitHub CLI가 필요합니다. 이슈 리포지토리가 설정된 원격과 일치하는지도 검증합니다.

커밋 미리보기나 승인된 커밋을 현재 체크아웃에서 실행하려면 Python 3.11+와 Git이 필요합니다. 런타임은 CLI로 초기화한 프로젝트에 설치되며 Claude 플러그인에도 포함됩니다. 에이전트가 생성하는 병합 중 내용 변경을 포함하는 병합도 스테이징 분석을 사용합니다. 이력만 연결하는 병합은 트리와 부모를 검증하면서 Git의 기본 메시지를 유지합니다. fast-forward는 커밋을 만들지 않습니다.

추적 가능성과 작업 재개

확인된 requirements.md가 기능 의도를 결정하며, 하위 산출물은 spec.md → design.md → plan.md → tasks.md 순서로 이어집니다. 적용되는 프로젝트 원칙과 검증된 저장소 사실도 함께 고려합니다. 요구사항에는 안정적인 ID를 사용하고, 명세 항목은 Sources로 출처를, 하위 작업은 Covers로 대응 관계를 표시합니다. 하위 산출물이 상위 결정을 조용히 바꿀 수는 없습니다. 권위 있는 근거가 충돌하거나 새 제품 결정이 필요하면 사용자가 해결해야 합니다. 기존 요구사항 기록이 없으면 최초 확인을 검증할 수 없음을 밝히며, 기존 설계 산출물이 없으면 문서화된 대체 경로를 따릅니다.

기능 선택이 모호하면 명시적인 기능 경로를 전달하세요. 명령은 가장 최근 디렉터리를 임의로 고르지 않습니다. worktree의 상위 디렉터리는 주 저장소를 기준으로 정하며, 하위 디렉터리나 다른 연결된 worktree에서 실행해도 같습니다. bare 저장소는 같은 상위 디렉터리 아래의 <bare-repository-name>-codexspec-worktrees를 사용합니다. 독립적인 유지보수에는 codexspec/maintenance 브랜치를 사용합니다.

worktree 준비가 실패해도 재개할 수 있도록 식별 정보를 유지합니다. 분기된 기준 이력을 병합한 경우 프로젝트 검사를 통과해야 기능 요구사항을 기록하거나 개발을 시작할 수 있습니다. 읽기 전용 검사는 원래 입력을 유지하고, 보고서는 결정된 출력 체크아웃에 씁니다. 커밋 실행은 선택된 인덱스를 유지하며 main의 스테이징된 변경을 다른 worktree로 옮기지 않습니다. 새 worktree에 필요한 설치 리소스가 없으면 해당 대상에서 먼저 초기화한 뒤 진행합니다.

리뷰 모델

리뷰는 세 종류의 산출물을 구분합니다:

  • 충실도 결함(Fidelity defects): 권위 있는 소스와 충돌하거나 필수 커버리지가 빠진 경우.
  • 내재적 결함(Intrinsic defects): 산출물 자체가 내적으로 모순되거나, 검증 불가능하거나, 실행 불가능한 경우.
  • 리스크 권고 / 설계 기회: 현재 결함의 증거 없이 제안되는 선택적 개선.

모든 결함은 증거·위치·불일치·영향·최소 수정 방안을 식별해야 합니다. 동일한 근본 원인을 가진 발견 항목은 병합됩니다. 권고는 상태, 점수, 자동 수정에 영향을 주지 않습니다.

리뷰 상태는 다음과 같습니다:

  • PASS: 치명적·경고·사소한 결함이 모두 없음.
  • PASS_WITH_WARNINGS: 사소한 결함만 남음.
  • NEEDS_REVISION: 하나 이상의 경고가 남음.
  • BLOCKED: 치명적 충돌이 안정적인 진행을 막음.

호환성 점수는 고정된 템플릿 섹션 감점이 아니라 동일하게 분류된 발견 항목들로부터 도출됩니다. 상태가 권위이며, 점수는 여전히 숫자를 기대하는 연동을 위해 존재합니다.

한정된 자동 리뷰

생성 명령은 매칭되는 리뷰를 자동으로 실행합니다. 이것은 증거 기반 리뷰 원칙의 실천입니다. 오직 증거가 뒷받침된 결함만 수리하고 최대 두 라운드까지만 재리뷰합니다. PASS이면 더 일찍 멈추며, 다음 상황에서는 사용자 입력을 기다리기 위해 멈춥니다:

  • 권위 있는 소스가 다른 소스와 충돌할 때;
  • 수정이 확정된 의도를 바꾸게 될 때;
  • 남은 항목이 결함이 아니라 권고일 때;
  • 두 라운드의 수리를 이미 사용했을 때.

수동 /codexspec:review-* 명령은 언제든 새 보고서를 얻기 위해 실행할 수 있습니다.