菜单
태스크 완료를 주장하거나, "될 것 같다", 수정 완료를 선언하거나, "테스트 통과"라고 말하기 전에 실제 검증 명령을 실행해야 할 때 사용. Use when about to claim a task is complete, say "it should work", declare a fix is done, say "tests pass", or make any success assertion before running the actual verification commands.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
아이디어를 설계로 전환하거나, 새로운 기능을 만들거나, 구현 전 구조화된 설계가 필요한 창의적/탐색적 작업에 사용. Use when turning an idea into a design, creating a new feature, or when any creative/exploratory work needs structured design before implementation.
태스크나 unit 구현이 완료되어 머지 전 코드 리뷰가 필요할 때, 또는 사용자가 명시적으로 코드 리뷰를 요청할 때 사용. Use when a task or unit implementation is complete and needs code review before merging, or when the user explicitly requests a code review on their changes.
설계 문서를 상세 구현 계획으로 변환하거나, "구현 계획 작성", "plan 만들어줘" 요청 시 사용. INCEPTION 워크플로우 계획은 aidlc-workflow-planning 사용. Use when a design document needs to be converted into a detailed implementation plan with task breakdown, or when "구현 계획 작성", "plan 만들어줘" is requested. Not for INCEPTION workflow planning — use aidlc-workflow-planning instead.
Use when user explicitly requests "auto 모드", "자동 모드", "auto mode", or "알아서 만들어줘". 초보자를 위한 완전 자동 devflow. greenfield 전용. 요구사항 입력 → inception → construction → build-test를 자동 진행하며 각 flow 종료 시 멀티에이전트 리뷰 필수.
현재 세션에서 구현 계획을 실행할 때 사용. 독립 태스크별 신규 서브에이전트 컨텍스트 활용. Use when executing an implementation plan in the current session with independent tasks that benefit from fresh subagent context per task.
프로덕션 코드 작성, 버그 수정, 리팩토링 시 사용 — 예외 없이 RED-GREEN-REFACTOR 사이클을 강제. Use when writing any production code, fixing bugs, or refactoring — enforces RED-GREEN-REFACTOR cycle with no exceptions.
| name | aidlc-verification-before-completion |
| description | 태스크 완료를 주장하거나, "될 것 같다", 수정 완료를 선언하거나, "테스트 통과"라고 말하기 전에 실제 검증 명령을 실행해야 할 때 사용. Use when about to claim a task is complete, say "it should work", declare a fix is done, say "tests pass", or make any success assertion before running the actual verification commands. |
| metadata | {"version":"0.2.0","author":"Jay","category":"ai-dlc-workflow","invoke_mode":"user-invocable","return_behavior":"stop-no-gate","skill_nature":"compensation","lifecycle":"active","model_dependency":"모델이 완료 선언 전 검증 명령 실행을 생략함"} |
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
"통과됩니다", "동작합니다", "수정됐습니다"는 실제 실행 결과를 확인한 후에만 말할 수 있다. 에이전트의 성공 보고, 이전 실행 기억, 코드 리뷰 만으로는 부족하다.
code-generation이 이미 TDD + code-review를 거친 경우, 추가 수정이 없으면 재검증 불필요. 이 스킬은 code-generation 이후 추가 변경이 있거나, 사용자가 명시적으로 최종 검증을 요청했을 때 사용.
다음 행동을 하려는 순간 이 스킬을 실행한다:
실제로 실행하지 않은 코드에 대한 근거 없는 확신을 방지한다. "아마도 통과할 것"이 아니라 "지금 막 통과했음"만 허용된다.
다음 표현이 나오려 할 때 즉시 멈추고 Gate 프로세스를 실행한다:
| Red Flag 표현 | 왜 위험한가 |
|---|---|
| "should work" / "아마 될 것 같아요" | 실행하지 않은 코드에 대한 추측 |
| "에이전트가 성공했다고 보고했습니다" | 에이전트 보고 ≠ 실제 검증 |
| "이전에 테스트했을 때 됐어요" | 코드가 바뀌었을 수 있음 |
| "코드를 보니 맞는 것 같습니다" | 코드 리뷰 ≠ 실행 결과 |
| "로컬에서 됐으니 CI도 통과할 거예요" | 환경 차이 무시 |
완료 주장 전에 다음 5단계를 순서대로 수행한다:
주장 내용에 맞는 검증 명령을 목록화한다:
주장: "API 테스트가 통과합니다"
검증 명령:
- [ ] pytest tests/test_api.py -v
- [ ] 빌드: python -m py_compile src/api.py
주장: "리팩토링 후 기능이 동일합니다"
검증 명령:
- [ ] pytest tests/ -v (전체 회귀 테스트)
- [ ] 핵심 시나리오 수동 실행
식별한 모든 명령을 지금 이 순간 실행한다.
명령 출력의 전체를 읽는다:
출력이 실제로 주장을 뒷받침하는지 대조한다:
주장: "모든 테스트 통과"
출력: "5 passed, 2 warnings"
결과: 통과 ✓ (Warning은 별도 기록)
주장: "빌드 성공"
출력: "ERROR: ModuleNotFoundError: No module named 'pydantic'"
결과: 불통과 ✗ → 완료 선언 불가
4단계 결과가 모두 통과일 때만 완료를 선언한다.
완료 선언 형식:
## 검증 완료
실행한 검증:
- `pytest tests/` → 23 passed, 0 failed (2026-03-11 14:32)
- `ruff check src/` → All checks passed
결론: 모든 검증 통과. 완료 선언.
_shared/tdd-protocol.md의 "회귀 테스트 RED-GREEN 검증" 섹션을 수행한다.
적용 조건: systematic-debugging을 거쳐 수정한 경우, 또는 버그 수정 완료 주장 시. 미적용: 신규 기능 개발 (code-generation TDD에서 이미 커버).
5단계에서 검증이 모두 통과해도, 버그 수정인 경우 이 단계를 추가로 수행한다.
상황: FastAPI 엔드포인트 추가 완료 후 완료 보고 요청
잘못된 방법 (Red Flag):
엔드포인트 구현이 완료됐습니다. 코드를 보면 요구사항을 모두 충족하고 있어요.
테스트도 잘 작성되어 있으니 통과할 것입니다.
올바른 방법 (Gate 프로세스 적용):
# 1단계: 검증 명령 식별
# - pytest tests/test_endpoints.py -v
# - ruff check src/
# 2단계: 실행
$ pytest tests/test_endpoints.py -v
==================== test session starts ====================
test_create_item PASSED
test_read_item PASSED
test_delete_item PASSED
3 passed in 0.42s
$ ruff check src/
All checks passed.
완료 선언:
## 검증 완료
실행한 검증:
- `pytest tests/test_endpoints.py -v` → 3 passed, 0 failed
- `ruff check src/` → All checks passed
결론: 모든 검증 통과. 엔드포인트 구현 완료.
상황: 리팩토링 완료 주장 전 Gate 실행
$ pytest tests/ -v
==================== test session starts ====================
test_user_service.py::test_create_user PASSED
test_user_service.py::test_delete_user FAILED
AssertionError: Expected 204, got 500
2 passed, 1 failed
처리:
## 검증 실패 — 완료 선언 불가
실행한 검증:
- `pytest tests/` → 2 passed, 1 FAILED
실패한 테스트: test_delete_user
완료 선언을 보류합니다. systematic-debugging 프로세스로 실패 원인 조사를 시작합니다.
상황: systematic-debugging으로 버그 수정 완료 → 1~5단계 수행 후 6단계:
회귀 테스트 PASS → git stash → 회귀 테스트 FAIL(유효성 증명) → git stash pop → 전체 PASS
증상: 어떤 명령으로 검증해야 할지 모름 (새 프로젝트, 문서 부족 등)
처리 방법:
README, Makefile, package.json scripts, pyproject.toml 등을 확인한다pytest, python -m pytestnpm test, yarn testgo test ./...cargo test증상: 전체 테스트 스위트가 10분 이상 걸림
처리 방법:
pytest tests/test_changed_module.py -v
pytest -k "test_feature_name"