jaimegago/agent-skills

워크플로우

다음 단계를 순서대로 실행합니다. 단계가 실패하면 중단하고 사용자에게 보고합니다.

1. 작업 트리 평가

git status와 git diff(스테이징 및 언스테이징 모두)를 실행하여 변경 사항을 파악합니다. 변경 사항이 전혀 없으면 사용자에게 커밋할 내용이 없다고 알리고 중단합니다.

2. 더티 서브모듈 정리

git status에 "(modified content)"가 있는 서브모듈이 표시되지만 스테이징되거나 의도된 서브모듈 포인터 변경이 없는 경우, 이는 중첩된 하위 서브모듈이 변경된 것입니다(일반적으로 재귀적 --remote 업데이트로 인해 발생). 각 더티 서브모듈에 대해 git -C <서브모듈-경로> submodule update --init을 실행하여 중첩된 참조를 상위 서브모듈이 예상하는 커밋으로 복원합니다. 정리 후 git status를 다시 확인하여 더티 상태가 사라졌는지 확인합니다. 사용자가 명시적으로 변경하지 않는 한 서브모듈 포인터 변경을 스테이징하지 마십시오.

3. 사용자가 달리 지정하지 않으면 모든 것을 스테이징

사용자가 특정 파일을 지정하지 않았다면 git add -A로 모든 변경 사항(추적 및 추적되지 않음)을 스테이징합니다. 사용자가 특정 파일이나 경로를 지정했다면 해당 파일만 스테이징합니다.

4. 린트 및 자동 수정

커밋 전에 프로젝트의 린터를 감지하고 스테이징된 파일에 대해 자동 수정을 실행합니다. 감지 순서:

• 먼저 프로젝트 수준 린트 대상: Makefile에 lint 또는 lint:fix 대상이 있거나 package.json에 lint 또는 lint:fix 스크립트가 있으면 이를 우선 사용합니다. 이는 프로젝트 자체 규칙을 존중합니다. 프로젝트 수준 대상이 없을 경우에만 언어별 감지로 넘어갑니다.
• Go (go.mod 존재): 스테이징된 .go 파일에 대해 gofmt -w를 실행한 후 go vet ./... 실행
• JavaScript/TypeScript (package.json 존재): ESLint 설정이 있으면 스테이징된 JS/TS 파일에 대해 npx eslint --fix 실행. Prettier가 설정되어 있으면 해당 파일에 대해 npx prettier --write도 실행.
• Python (pyproject.toml, setup.py, 또는 requirements.txt 존재): Ruff가 설정되어 있으면 스테이징된 .py 파일에 대해 ruff check --fix와 ruff format 실행. 설치된 경우 black으로 대체. 설치된 경우 flake8으로 대체(보고 전용, 자동 수정 불가).
• Rust (Cargo.toml 존재): cargo fmt와 cargo clippy --fix --allow-dirty 실행
• 감지된 린터 없음: 이 단계를 건너뛰고 진행합니다.

자동 수정 후 git add -u로 수정된 파일을 다시 스테이징합니다. 린터가 자동 수정할 수 없는 오류를 보고하면 중단하고 사용자에게 보고합니다. 알려진 린트 실패 상태로 커밋하지 마십시오.

린터가 감지되었지만 바이너리가 설치되지 않은 경우 사용자에게 경고하고 린트 없이 진행할지 또는 중단할지 묻습니다.

5. 커밋 메시지 생성

스테이징된 diff를 분석하여 Conventional Commit 메시지를 생성합니다:

type(scope): 짧은 요약

변경 사항과 그 이유에 대한 선택적 본문

규칙:

• type: feat, fix, refactor, docs, test, chore, ci, perf, style, build 중 하나
• scope: 선택 사항이지만 권장됨 — 주요 패키지, 모듈 또는 변경된 디렉토리에서 파생. 변경 사항이 단일 범위가 의미 있게 표현하기 어려울 정도로 많은 영역에 걸쳐 있을 때만 생략.
• 요약 줄: 소문자, 명령형, 마침표 없음, 최대 72자.
• 본문: diff가 단순하지 않고 요약만으로 리뷰어에게 충분한 맥락을 제공하지 못할 때만 추가. 간결하게 유지.
• 여러 논리적 변경: type/scope에 대해 지배적인 것을 선택하고, 본문에서 보조 변경 사항을 언급. 사용자가 명시적으로 요청하지 않는 한 여러 커밋으로 분할하지 마십시오.
• Breaking changes: BREAKING CHANGE 바닥글을 추가하거나 ! 접미사 사용 (예: feat!: ...).
• 린터가 파일을 자동 수정한 경우 본문에 언급 (예: "Includes gofmt auto-fixes.").

6. 커밋

생성된 메시지로 git commit을 실행합니다. 요약 전용 메시지에는 -m을 사용합니다. 본문이 있는 메시지는 임시 파일에 작성하고 git commit -F를 사용하여 줄바꿈을 유지한 후 임시 파일을 정리합니다.

7. 원격과 동기화

현재 브랜치 이름을 확인합니다. 그런 다음:

• 브랜치에 업스트림이 있으면 git push를 실행합니다.
• 브랜치에 업스트림이 없으면 git push -u origin <브랜치-이름>을 실행합니다.
• 원격이 앞서 있어 푸시가 거부되면 git pull --rebase를 실행한 후 다시 푸시합니다. 리베이스 중 충돌이 발생하면 중단하고 보고합니다. 병합 충돌을 자동으로 해결하지 마십시오.

8. 확인

사용자에게 보고:

• 커밋 해시 (짧은 형태)
• 사용된 커밋 메시지
• 브랜치 이름 및 원격 동기화 상태
• 변경된 파일, 삽입, 삭제 (커밋의 git diff --stat에서)
• 실행된 린터 (또는 감지되지 않았음)

엣지 케이스

• 원격이 설정되지 않음: 로컬에서 커밋하고 사용자에게 알림.
• 분리된 HEAD: 커밋 전에 경고하고 먼저 브랜치 생성 제안.
• 추적되지 않은 파일만 있는 경우: 정상적으로 스테이징하고 커밋.
• .gitignore 존중 — 사용자가 명시적으로 요청하지 않는 한 무시된 파일을 강제로 추가하지 마십시오.