lee-chance/agent-skills

안정적인 API와 인터페이스 설계를 안내합니다. API, 모듈 경계, 공개 인터페이스를 설계할 때 사용하세요. REST 또는 GraphQL 엔드포인트를 만들거나, 모듈 간 타입 계약을 정의하거나, 프론트엔드와 백엔드 사이의 경계를 정할 때 사용하세요.

Chrome DevTools MCP로 실제 브라우저에서 테스트합니다. 브라우저에서 실행되는 것을 만들거나 디버깅할 때 사용하세요. DOM 검사, 콘솔 오류 캡처, 네트워크 요청 분석, 성능 프로파일링, 실제 런타임 데이터로 시각적 출력을 확인할 때 사용하세요. chrome-devtools MCP 서버 구성이 필요합니다.

CI/CD 파이프라인 설정을 자동화합니다. 빌드와 배포 파이프라인을 설정하거나 수정할 때 사용하세요. 품질 게이트를 자동화해야 할 때, CI에서 테스트 러너를 구성할 때, 배포 전략을 세울 때 사용하세요.

여러 축으로 코드 리뷰를 수행합니다. 어떤 변경이든 머지하기 전에 사용하세요. 자신, 다른 에이전트, 또는 사람이 작성한 코드를 리뷰할 때 사용하세요. 변경이 메인 브랜치에 들어가기 전에 여러 차원에서 코드 품질을 평가해야 할 때 사용하세요. diff나 풀 리퀘스트를 리뷰해 달라는 요청이 있을 때, diff가 본문에 그대로 붙여넣어진 경우에도 사용하세요.

명확함을 위해 코드를 단순화합니다. 동작을 바꾸지 않고 명확하게 코드를 리팩터할 때 사용하세요. 코드는 동작하지만 읽기, 유지보수, 확장이 필요 이상으로 어려울 때 사용하세요. 불필요한 복잡성이 쌓인 코드를 리뷰할 때 사용하세요. 이미 동작하는 함수나 모듈을 단순화하거나, 정리하거나, 중첩을 줄여 달라는 요청이 있을 때 사용하세요. 코드가 인라인으로 붙여넣어졌고 그 밖에 바꿀 것이 없는 경우도 포함합니다.

프로젝트의 품질 기준을 문서로 된 계약으로 고정하고, 에이전트가 그 기준을 조용히 낮추지 못하게 합니다. 어떤 차원이 중요한지 사용자에게 질문하고, 정해 둔 숫자가 없으면 합리적인 기본 임계값을 제시하며, 모든 내용을 CONSTRAINTS.md에 기록하고, 기준이 약해졌는지 diff를 지켜봅니다. 새 @ts-ignore나 eslint-disable 억제, 건너뛰거나 삭제된 테스트, 빼낸 어서션, 구현되지 않은 스텁, 낮춰 고친 임계값이 그 대상입니다. 품질 기준이 문서로 없을 때, 사용자가 'set up constraints' 또는 'define our standards'라고 할 때, 접근성, 웹 성능, 커버리지처럼 신경 쓰는 차원을 강제되는 제약 조건으로 두고 싶을 때, 에이전트가 통과시키려고 검사를 끄거나 테스트를 건너뛸 때, 커버리지나 성능 임계값이 필요한데 어떤 숫자를 고를지 모를 때, 또는 에이전트가 아무도 읽지 않을 만큼 많은 코드를 쓸 때 사용하세요.

에이전트 컨텍스트 설정을 최적화합니다. 새 세션을 시작할 때, 에이전트 출력 품질이 떨어질 때, 작업 사이를 전환할 때, 또는 프로젝트의 규칙 파일과 컨텍스트를 구성해야 할 때 사용하세요.

체계적인 근본 원인 디버깅을 안내합니다. 테스트가 실패하거나, 빌드가 깨지거나, 어제까지 되던 것이 깨지거나, 동작이 기대와 다르거나, 예상치 못한 오류를 만났을 때 사용하세요. 무엇이 왜 깨졌는지 밝혀야 할 때 사용하세요. 추측 대신 근본 원인을 찾아 고치는 체계적인 접근입니다.

지원 종료와 마이그레이션을 관리합니다. 기존 시스템, API, 기능을 제거할 때 사용하세요. 사용자를 한 구현에서 다른 구현으로 옮길 때 사용하세요. 프로덕션에서 데이터베이스 스키마를 마이그레이션할 때, 예를 들어 다운타임 없이 컬럼 이름을 바꾸거나 삭제할 때(expand/contract) 사용하세요. 기존 코드를 유지할지 종료할지 결정할 때 사용하세요.

결정과 문서를 기록합니다. 아키텍처 결정(ADR)이나 설계 선택의 근거를 문서화해야 할 때, 공개 API를 바꾸거나 기능을 출시할 때, 또는 미래의 엔지니어와 에이전트가 코드베이스를 이해하려면 남겨야 할 맥락을 기록해야 할 때 사용하세요.

사소하지 않은 결정이 성립하기 전에, 매번 새 컨텍스트의 적대적 리뷰를 거치게 합니다. 진행하기 전에 모든 가정을 캐묻고 싶을 때, 계획에 숨은 실패 모드가 있는지 스트레스 테스트할 때, 속도보다 정확성이 중요할 때, 익숙하지 않은 코드에서 작업할 때, 이해관계가 클 때(프로덕션 인증, 보안에 민감한 로직, 고위험 마이그레이션, 되돌릴 수 없는 작업), 또는 자신 있는 출력을 나중에 디버깅하는 것보다 지금 검증하는 편이 더 쌀 때 사용하세요.

프로덕션 품질의, 접근 가능하고 반응형인 사용자 대면 UI를 만듭니다. 인터페이스와 페이지를 만들거나 수정할 때, 컴포넌트를 만들 때, 레이아웃을 구현할 때, WCAG 접근성 요구사항을 맞출 때, 상태를 관리할 때, 또는 결과물이 AI가 생성한 느낌이 아니라 프로덕션 품질의 모습과 느낌이어야 할 때 사용하세요.

Git 워크플로우 관행을 구조화합니다. 코드 변경을 할 때마다 사용하세요. 커밋, 브랜치, 충돌 해결, 어수선한 워킹 트리의 커밋되지 않은 작업을 깨끗한 원자적 커밋으로 나누기, 풀 리퀘스트를 열거나 리뷰하기, 리모트에 푸시하기, 여러 병렬 흐름에 걸쳐 작업을 정리할 때 사용하세요. 릴리스를 내거나, 시맨틱 버전 범프를 고르거나, 태그를 달거나, 변경 이력을 쓸 때 사용하세요. 변경의 커밋 메시지 또는 변경 이력 항목을 작성해 달라고 하거나 변경을 커밋으로 나누라고 할 때도 사용하세요. diff가 인라인으로 붙여넣어져 있고 그 diff만으로 메시지가 쉬워 보여도 마찬가지입니다.

막연한 아이디어를 구조적인 발산 사고와 수렴 사고로 날카롭고 실행 가능한 개념으로 다듬습니다. 아이디어가 아직 모호할 때, 계획에 착수하기 전에 가정을 스트레스 테스트해야 할 때, 하나로 좁히기 전에 선택지를 넓히고 싶을 때 사용하세요. "ideate", "refine this idea", "stress-test my plan"에서 트리거됩니다.

변경을 얇고 검증 가능한 조각으로 점진적으로 전달합니다. 파일을 둘 이상 건드리는 기능이나 변경을 구현할 때, 또는 계획에서 다음 작업을 집어 들 때 사용하세요. 피처 플래그 뒤에 변경을 롤아웃할 때, 한 번에 많은 코드를 쓰려 할 때, 또는 작업이 한 단계에 넣기에는 너무 커 보일 때 사용하세요.

사용자가 원해야 한다고 생각하는 것이 아니라, 실제로 원하는 것을 끌어냅니다. 기저 의도에 약 95% 확신이 들 때까지 한 번에 질문 하나씩 인터뷰해서 이룹니다. 요청이 덜 명세되었을 때("for whom"이나 "why now" 없이 "build me X"), 사용자가 명시적으로 호출할 때("interview me", "grill me", "are we sure?", "stress-test my thinking"), 또는 계획, 스펙, 코드가 있기 전에 모호한 요구사항을 조용히 채워 넣고 있는 자신을 알아차릴 때 사용하세요.

프로덕션 동작을 볼 수 있고 진단할 수 있도록 코드를 계측합니다. 로깅, 메트릭, 트레이싱, 알림을 추가할 때 사용하세요. 프로덕션에서 실행되는 기능을 출시하면서 동작한다는 증거가 필요할 때 사용하세요. 프로덕션 이슈가 보고되었지만 있는 데이터만으로는 무슨 일이 있었는지 알 수 없을 때 사용하세요.

프론트엔드, 백엔드, 쿼리, 데이터베이스에 걸친 애플리케이션 성능을 최적화합니다. 성능 요구 사항이 있을 때, 성능 회귀가 의심될 때, Core Web Vitals나 로드 시간을 개선해야 할 때, N+1 쿼리 패턴을 고쳐야 할 때, 프로파일링에서 병목이 드러날 때 사용하세요.

작업을 순서가 있는 작업으로 나눕니다. 스펙이나 명확한 요구사항이 있어 구현 가능한 작업으로 나눠야 할 때 사용하세요. 작업이 너무 커서 시작하기 어렵거나, 범위를 가늠해야 하거나, 병렬 작업이 가능할 때 사용하세요.

취약점에 대비해 코드를 하드닝합니다. 입력 핸들러의 취약점을 감사할 때, 사용자 입력, 인증, 데이터 저장, 외부 연동을 다룰 때, 또는 로그인 흐름이 OWASP Top Ten에 안전한지 확인할 때 사용하세요. 신뢰할 수 없는 데이터를 받는 기능, 사용자 세션이나 세션 쿠키를 관리하는 기능, 제3자 서비스와 상호작용하는 기능을 만들 때 사용하세요. 알려진 취약점에 대해 의존성을 감사하거나, 패키지 매니저 감사 결과를 트리아지하거나, 새 패키지의 공급망 위험을 평가할 때 사용하세요. 개인 데이터나 프라이버시 준수(GDPR, CCPA)가 관련될 때 사용하세요.

프로덕션 출시를 준비합니다. 프로덕션 배포를 준비할 때, 또는 출시 전에 무엇을 갖춰야 하는지 물을 때 사용하세요. 출시 전 체크리스트가 필요할 때, 모니터링을 설정할 때, 단계적 롤아웃을 계획할 때, 롤백 전략이 필요할 때 사용하세요.

모든 구현 결정을 공식 문서에 근거하게 합니다. 구현 전에 접근을 공식 문서와 대조해 확인하고 싶거나, 낡은 패턴이 없는 권위 있고 출처가 인용된 코드가 필요할 때 사용하세요. 정확성이 중요한 프레임워크나 라이브러리로 만들 때 사용하세요.

코드를 작성하기 전에 스펙을 만듭니다. 새 프로젝트, 기능, 또는 큰 변경을 시작하는데 아직 스펙이 없을 때 사용하세요. 목표와 범위가 있는 PRD나 요구사항 문서를 작성할 때, 또는 요구사항이 불명확하거나 모호하거나 막연한 아이디어로만 있을 때 사용하세요. 요구사항 하나가 독립적으로 테스트할 수 있는 여러 기능에 걸쳐 있어, 스펙을 쓰기 전에 모듈의 기능 맵으로 분해해야 할 때 사용하세요.

red-green-refactor 루프로 테스트를 통해 개발을 이끕니다. 어떤 로직이든 구현할 때, 어떤 버그든 고칠 때, 어떤 동작이든 바꿀 때 사용하세요. 코드가 동작함을 증명해야 할 때, 버그 리포트가 도착했을 때, 기존 기능을 수정하려 할 때 사용하세요. 함수에 테스트를 추가하거나 그 함수의 버그를 고치거나 동작을 바꾸라는 요청에도 사용하세요. 코드가 인라인으로 붙여넣어졌고 요청이 테스트를 언급하지 않아도 마찬가지입니다.

에이전트 스킬을 찾고 호출합니다. 세션을 시작할 때, 또는 지금 하는 작업에 어떤 스킬이나 워크플로우를 적용할지 정해야 할 때 사용하세요. 다른 모든 스킬을 찾고 호출하는 방식을 관장하는 메타 스킬입니다.