터미널 작업은(는) 무엇을 하나요?
사용자가 실제 저장소 실행(명령 실행, 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 관련 작업은 저장소 경로와 브랜치를 명시합니다.
- 푸시 주장에는 대상 브랜치와 정확한 결과가 포함됩니다.