gener8v/gener8v.claude-skills.engineering

개발 명령어

1. 명령어 찾기

응답하는 첫 번째 소스를 사용하세요. 명령어를 실행하기 전에 명령어를 명시하세요.

1. 리포지토리 지침: CLAUDE.md, CONTRIBUTING.md, README.md. gener8v 파이프라인 리포지토리에서 .gener8v/context.md는 각 리포지토리의 검증 명령어를 나열합니다.
2. 태스크 러너: Makefile, justfile, Taskfile.yml, package.json 스크립트, pyproject.toml 도구 섹션, tox.ini, noxfile.py.
3. CI 워크플로우: .github/workflows/*.yml. CI가 실행하는 것이 "테스트 통과"를 정의합니다.
4. 생태계 기본값: resources/ecosystems.md.

프로젝트가 컨테이너(compose.yaml, docker-compose.yml, dev container)에서 실행되는 경우, 프로젝트 문서에 설명된 방식으로 컨테이너 내부에서 명령어를 실행하세요. resources/ecosystems.md를 참조하세요.

2. 실행

• 좁게 시작: 하나의 테스트 파일 또는 하나의 패키지. 그런 다음 보고하기 전에 전체 스위트를 실행하세요.
• watch 모드를 시작하지 마세요. 많은 테스트 러너가 기본적으로 watch합니다. "한 번 실행" 형식을 사용하세요 (resources/ecosystems.md 참조).
• 출력을 줄일 때 종료 코드를 유지하세요:

  set -o pipefail
  <command> 2>&1 | tail -n 60
  echo "exit=$?"
  

• 개발 서버를 백그라운드에서 시작하세요. URL이 응답할 때까지 기다리세요. 작업이 끝나면 중지하세요.

3. 결과 읽기

• 종료 코드가 결정합니다. "done"과 같은 텍스트는 성공을 의미하지 않습니다.
• 개수를 세세요. 통과, 실패, 건너뜀을 보고하세요. 건너뜀, 예상 실패, "수집된 테스트 없음"은 통과가 아닙니다.
• 플래키 테스트. 실패한 테스트를 한 번 더 단독으로 실행하세요. 통과하면 플래키로 보고하세요. 숨기지 마세요.
• 원래부터 있던 실패. 베이스 브랜치를 확인하세요: 최신 CI 실행(gh run list --branch <base> --limit 3) 또는 별도 작업 트리에서의 실행. 이러한 실패를 "<base>에서 이미 실패 중"으로 보고하세요. 자신의 실패를 변명하는 데 사용하지 마세요.
• 테스트를 통과시키기 위해 테스트를 약화시키지 마세요. 테스트가 잘못되었다면 이유를 말하고 별도의 눈에 띄는 커밋에서 수정하세요.

4. UI 작업을 위한 데이터

UI에 실제 데이터가 필요한 경우 resources/throwaway-data.md를 따르세요. 간단한 규칙: 오직 이 목적으로 생성한 데이터베이스에만 시드하세요. 프로젝트의 실제 데이터베이스, 기본 데이터베이스 또는 공유 데이터베이스는 절대 시드하지 마세요.

5. 보고

명령어, 종료 코드, 개수, 그리고 각 실패에 대한 첫 번째 실제 오류를 제공하세요. 실행하지 않은 것이 있다면(예: 자격 증명이 필요한 엔드투엔드 테스트) 그렇게 말하세요.

관련 스킬

• engineering:github-pr-merge와 engineering:github-issue-workflow는 PR 전에 이 스킬을 호출합니다.
• engineering:documentation-bootstrap은 문서에 나열해야 하는 명령어를 찾기 위해 이 스킬을 사용합니다.