터미널 작업

터미널 작업은(는) 무엇을 하나요?

사용자가 실제 리포지토리 실행(명령 실행, Git 상태 검사, CI 또는 빌드 디버깅, 좁은 범위의 수정, 변경 및 검증된 사항 정확히 보고)을 원할 때 사용하세요.

이 스킬은 일반적인 코딩 지침보다 의도적으로 좁게 정의되어 있습니다. 증거 우선 터미널 실행을 위한 운영자 워크플로입니다.

스킬 스택

필요에 따라 다음 ECC 네이티브 스킬을 워크플로에 통합하세요:

• verification-loop: 변경 후 정확한 증명 단계를 위해
• tdd-workflow: 올바른 수정에 회귀 테스트 범위가 필요할 때
• security-review: 비밀, 인증, 외부 입력이 관련된 경우
• github-ops: 작업이 CI 실행, PR 상태, 릴리스 상태에 의존할 때
• knowledge-ops: 검증된 결과를 지속적인 프로젝트 컨텍스트에 저장해야 할 때

사용 시점

• 사용자가 "수정", "디버그", "실행", "리포지토리 확인", "푸시"라고 말할 때
• 작업이 명령 출력, Git 상태, 테스트 결과, 또는 검증된 로컬 수정에 의존할 때
• 답변이 로컬 변경, 로컬 검증, 커밋, 푸시를 명확히 구분해야 할 때

가드레일

• 편집하기 전에 먼저 검사하세요.
• 사용자가 감사/검토만 요청한 경우 읽기 전용으로 유지하세요.
• 즉석에서 만든 임시 래퍼보다 리포지토리 로컬 스크립트와 헬퍼를 선호하세요.
• 증명 명령이 재실행될 때까지 수정되었다고 주장하지 마세요.
• 브랜치가 실제로 업스트림으로 이동하지 않으면 푸시되었다고 주장하지 마세요.

워크플로

1. 작업 표면 확인

다음을 확정하세요:

• 정확한 리포지토리 경로
• 브랜치
• 로컬 diff 상태
• 요청된 모드:
  • 검사
  • 수정
  • 검증
  • 푸시

2. 먼저 실패 표면 읽기

무엇이든 변경하기 전에:

• 오류 검사
• 파일 또는 테스트 검사
• Git 상태 검사
• 맹목적으로 다시 읽기 전에 이미 제공된 로그나 컨텍스트 사용

3. 수정 범위를 좁게 유지

한 번에 하나의 주요 실패를 해결하세요:

• 가장 작고 유용한 증명 명령부터 시작하세요.
• 로컬 실패가 해결된 후에만 더 큰 빌드/테스트 통과로 확장하세요.
• 명령이 동일한 시그니처로 계속 실패하면 광범위한 재시도를 중단하고 범위를 좁히세요.

4. 정확한 실행 상태 보고

정확한 상태 단어를 사용하세요:

• 검사됨
• 로컬에서 변경됨
• 로컬에서 검증됨
• 커밋됨
• 푸시됨
• 차단됨

출력 형식

표면
- 리포지토리
- 브랜치
- 요청된 모드

증거
- 실패한 명령 / diff / 테스트

작업
- 변경된 사항

상태
- 검사됨 / 로컬에서 변경됨 / 로컬에서 검증됨 / 커밋됨 / 푸시됨 / 차단됨

함정

• 라이브 리포지토리 상태를 읽을 수 있을 때 오래된 메모리로 작업하지 마세요.
• 좁은 수정을 리포지토리 전체의 대규모 변경으로 확장하지 마세요.
• 파괴적인 Git 명령을 사용하지 마세요.
• 관련 없는 로컬 작업을 무시하지 마세요.

검증

• 응답에 증명 명령 또는 테스트 이름이 명시되어야 합니다.
• Git 관련 작업에는 리포지토리 경로와 브랜치가 명시되어야 합니다.
• 모든 푸시 주장에는 대상 브랜치와 정확한 결과가 포함되어야 합니다.