새 기능이나 기획을 시작하기 전에 대화로 목적, 선호, 제약을 정리합니다. 필요하면 그림이나 시제품으로 이해를 확인하고 작업 규모에 맞는 설계를 작성합니다.
- 새 기능의 목적 명확히 하기
- 강연이나 사업 아이디어 정리
- 화면이나 방의 배치 비교
작업 완료나 오류 수정 성공을 보고하기 전에 테스트와 빌드를 실행하고 결과를 확인합니다. 커밋이나 풀 리퀘스트 생성 전에도 실제 출력을 근거로 현재 상태를 전달합니다.
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
작업 완료나 수정 성공을 보고하기 전에 근거를 확인합니다. 주장을 검증할 명령을 선택해 실행하고, 전체 출력과 종료 코드, 실패 건수를 확인한 뒤 상태를 전달합니다. 테스트, 빌드, 코드 규칙 검사를 구분하여 각각 필요한 증거를 확인합니다. 요구 사항은 항목별로 점검하며, 다른 에이전트가 변경한 내용도 변경 비교와 검증 결과를 통해 확인합니다.
수정한 코드를 제출하거나 커밋, 풀 리퀘스트 생성을 준비할 때 유용합니다. 과거 테스트 결과나 작동할 것이라는 추측만으로 완료를 판단하지 않고, 확인된 범위와 남아 있는 문제를 파악하려는 상황에 적합합니다.
대상 작업을 검증할 수 있는 명령과 실행 환경이 필요합니다. 이전 실행 결과나 일부만 확인한 결과는 현재 성공의 근거로 인정하지 않습니다. 결과가 주장을 뒷받침하지 못하면 실제 상태와 증거를 보고합니다.
이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.
AI가 SKILL.md의 내용만을 근거로 4가지 관점에서 판정했습니다. 스타 수나 인기도는 판정에 넣지 않았습니다.
총점은 각 항목을 A=25점, B=15점, C=5점으로 더한 값입니다. 2026년 10월 19일 기준으로 AI(OpenAI Codex)가 판정했습니다. 참고용이므로 설치 전에 원문도 확인해 주세요.
설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
Core principle: Evidence before claims, always.
Violating the letter of this rule is violating the spirit of this rule.
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the verification command in this message, you cannot claim it passes.
BEFORE claiming any status or expressing satisfaction:
1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
- If NO: State actual status with evidence
- If YES: State claim WITH evidence
5. ONLY THEN: Make the claim
Skip any step = lying, not verifying
| Claim | Requires | Not Sufficient |
|---|---|---|
| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
| Regression test works | Red-green cycle verified | Test passes once |
| Agent completed | VCS diff shows changes | Agent reports "success" |
| Requirements met | Line-by-line checklist | Tests passing |
| Excuse | Reality |
|---|---|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence ≠ evidence |
| "Just this once" | No exceptions |
| "Linter passed" | Linter ≠ compiler |
| "Agent said success" | Verify independently |
| "I'm tired" | Exhaustion ≠ excuse |
| "Partial check is enough" | Partial proves nothing |
| "Different words so rule doesn't apply" | Spirit over letter |
Tests:
✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"
Regression tests (TDD Red-Green):
✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)
Build:
✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)
Requirements:
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"
Agent delegation:
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report
ALWAYS before:
Rule applies to:
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
새 기능이나 기획을 시작하기 전에 대화로 목적, 선호, 제약을 정리합니다. 필요하면 그림이나 시제품으로 이해를 확인하고 작업 규모에 맞는 설계를 작성합니다.
superpowers 작업 기록을 읽고 중복 작업, 계획 이탈, 시간과 토큰 사용량을 조사합니다. 기록 파일의 경로와 줄 번호를 근거로 경위를 보고서로 정리합니다.
서로 독립적인 버그나 테스트 실패를 별도 에이전트에 맡겨 동시에 조사하고 수정합니다. 담당 범위를 정하고 결과 검토, 변경 충돌 확인, 전체 테스트와 통합까지 안내합니다.
같은 세션에서 기존 구현 계획을 작업별로 실행합니다. 테스트의 실패와 성공, 진행 상황과 판단을 기록하고 마지막에 브랜치 전체를 검토합니다.
구현이 끝나면 전체 테스트를 확인하고 로컬 병합, 풀 리퀘스트 생성, 현상 유지 중 선택한 작업을 수행합니다. 선택과 작업 환경에 따라 브랜치와 작업 공간을 정리합니다.
코드 리뷰 의견을 실제 코드와 지원 환경에 대조해 타당성을 확인합니다. 불명확한 내용을 정리하고 근거를 들어 답변하며, 수정 사항마다 테스트합니다.