bhoon716

Use when the user wants a pull request, diff, commit, patch, branch, or set of changed files reviewed through independent specialist passes for actionable issues introduced or worsened by the change. Orchestrate mandatory correctness and contract-test reviews, conditionally add security, reliability, architecture, or infrastructure reviews, independently verify candidate findings, remove root-cause duplicates, and synthesize only confirmed issues into an evidence-backed verdict. Do not use for simple code explanations, implementation-only requests, formatting-only cleanup, generic programming advice, or full-codebase audits unrelated to a specific change.

Use when the user asks to design, evaluate, document, or review software architecture for a new or existing system, including architecture alternatives, ADRs, component or integration boundaries, layered or modular monolith design, service decomposition, scalability, availability, quality attributes, runtime or deployment views, architecture risks, or migration plans. Inspect repository evidence when available, compare explicit tradeoffs, separate facts from assumptions, and produce decision-ready artifacts. Do not use for simple architecture definitions, generic brainstorming, isolated bug fixes, feature implementation, or behavior-preserving refactoring unless an explicit architecture decision is the task.

Use when the user wants to grill, stress-test, pressure-test, or otherwise validate a plan, design, product idea, architecture decision, implementation plan, business strategy, writing direction, research question, learning plan, personal decision, or Agent Skill design through Socratic, one-question-at-a-time interrogation with options and session logging. Also trigger on casual pre-execution phrasing like "X 하려고 하는데 파헤쳐줘", "빈틈없이 검증해줘", "질문으로 털어줘", "반대신문하듯 봐줘", "압박 검증해줘", or vague validation asks such as "이거 괜찮아?". Do not use for simple factual Q&A, brainstorming lists, text formatting, direct summaries, direct rewrites, or immediate code/plan generation.

Use when the user asks to fix broken, incorrect, failing, flaky, or regressed behavior, such as failing tests, wrong status codes, crashes, ignored CLI flags, duplicate output, wrong UI rendering, infinite retries, stack traces, or behavior that used to work and no longer does. This skill guides regression-test-driven bug fixing through Reproduce → Root Cause → Regression Test → Minimal Fix → Verify by capturing the symptom, reproducing or representing the failure, defining expected behavior, localizing the root cause, adding or updating a failing regression test when feasible, applying the smallest safe fix, and verifying honestly. Do not use for new feature development, behavior-preserving refactoring, speculative cleanup, architecture redesign, dependency upgrades, documentation-only work, test-only cleanup, or general investigation without a fix.

Use when the user asks to add, implement, create, support, enable, expose, integrate, or build a new capability, API, UI behavior, command, option, workflow, or product behavior in a codebase using strict test-driven development. This skill guides feature development through Red → Green → Refactor by framing the requested behavior, writing or updating tests before production code, confirming meaningful failure, implementing the smallest passing change, refactoring only after green, and reporting real validation. Do not use for bug fixing, behavior-preserving refactoring, investigation-only tasks, documentation-only changes, test-only cleanup, or dependency upgrades unless the upgrade is directly required for the feature.

Use when the user asks to refactor, clean up, simplify, extract, rename, remove duplication, improve readability, split files, improve separation of concerns, or make code easier to test while preserving externally observable behavior. This skill guides conservative, test-protected refactoring through Baseline → Transform → Same Tests by defining the behavior boundary, running baseline tests before editing, applying one small safe transformation at a time, re-running the same tests, and stopping if behavior preservation cannot be verified. Do not use for feature development, bug fixing, intentional behavior changes, speculative rewrites, architectural redesigns, dependency upgrades, or broad cleanup.

Use when the user needs a specific repeatable workflow. Describe the trigger clearly. Do not use for unrelated tasks, simple factual Q&A, or requests that should be handled directly without this workflow.

사용자가 Pull Request, diff, commit, patch, branch 또는 변경 파일을 여러 독립 전문 관점으로 심층 리뷰해 달라고 요청할 때 사용한다. 변경으로 새로 도입되거나 악화된 문제만 찾고, correctness와 contract-tests를 필수로 실행하며, 필요에 따라 security·reliability·architecture·infrastructure reviewer를 추가하고, candidate finding을 독립 검증한 뒤 confirmed finding만 최종 리뷰로 합성한다. 단순 코드 설명, 구현만 요청하는 작업, formatting-only 정리, 일반 프로그래밍 조언, 특정 변경과 무관한 전체 저장소 감사에는 사용하지 않는다.

사용자가 계획, 제품 아이디어, 기술 설계, 아키텍처 결정, 구현 계획, 사업 전략, 글쓰기 방향, 연구 질문, 학습 계획, 개인 의사결정, 또는 Skill 설계를 한 번에 하나의 질문으로 압박 검증해서 중요한 모호성이 남지 않을 때까지 명확화하고 싶을 때 사용한다. 또한 "X 하려고 하는데 파헤쳐줘", "빈틈없이 검증해줘", "질문으로 털어줘", "반대신문하듯 봐줘", "압박 검증해줘" 같은 자연어도 강한 trigger 로 취급한다. 단순 사실 Q&A, 브레인스토밍 목록, 요약, 문장 교정, 즉시 실행 요청, 가벼운 설명에는 사용하지 않는다.

사용자가 깨진 동작, 잘못된 동작, 실패하는 테스트, flaky 동작, 회귀된 동작을 고치라고 요청할 때 사용한다. 예를 들면 failing test, 잘못된 status code, crash, 무시되는 CLI flag, 중복 output, 잘못 렌더링되는 UI, 무한 retry, stack trace, 예전에는 됐지만 지금은 안 되는 동작이다. 이 스킬은 Reproduce → Root Cause → Regression Test → Minimal Fix → Verify 루프로 증거 기반 버그 수정을 수행하게 한다. 증상을 포착하고, 실패를 재현하거나 대표 regression case 로 표현하고, expected/actual behavior 를 정의하고, root cause 를 좁힌 뒤, 가능하면 먼저 실패하는 regression test 를 추가/갱신하고, 최소 안전 수정만 적용하고, 검증을 정직하게 보고한다. 새 기능 개발, 동작 보존 리팩토링, 추측성 cleanup, 아키텍처 재설계, 의존성 업그레이드, 문서만 수정, 테스트 정리만 하는 작업, 수정 없는 일반 조사에는 사용하지 않는다.

사용자가 코드베이스에 새 기능, API, UI 동작, 명령, 옵션, 워크플로, 제품 동작을 추가, 구현, 생성, 지원, 활성화, 노출, 통합, 구축하라고 요청할 때 사용한다. 이 스킬은 Red → Green → Refactor 루프로 요청 동작을 테스트 가능한 기준으로 바꾸고, 프로덕션 코드보다 먼저 테스트를 작성하거나 갱신하며, 의미 있는 실패를 확인한 뒤, 통과를 위한 최소 변경만 구현하고, green 이후에만 리팩토링하며, 실제 검증 결과를 보고하게 한다. 버그 수정, 동작 보존 리팩토링, 조사만 하는 작업, 문서만 수정하는 작업, 테스트 정리만 하는 작업, 기능에 직접 필요하지 않은 의존성 업그레이드에는 사용하지 않는다.

사용자가 외부에서 관찰 가능한 동작을 보존하면서 refactor, cleanup, simplify, extract, rename, duplication 제거, readability 개선, file 분리, separation of concerns 개선, testability 개선을 요청할 때 사용한다. 이 스킬은 Baseline → Transform → Same Tests 루프로 보수적이고 테스트 보호된 리팩토링을 수행하게 한다. 먼저 보존해야 할 동작 경계를 정의하고, 편집 전 baseline test 를 실행하고, 한 번에 하나의 작은 안전한 변환만 적용하고, 같은 테스트를 다시 실행하며, 동작 보존을 검증할 수 없으면 중단한다. 기능 개발, 버그 수정, 의도적 동작 변경, 추측성 재작성, 아키텍처 재설계, 의존성 업그레이드, 광범위한 cleanup 에는 사용하지 않는다.