자동화

반복 작업을 백그라운드에서 자동화합니다. Codex는 발견 항목을 받은 편지함에 추가하거나, 보고할 내용이 없으면 작업을 자동으로 보관합니다. 더 복잡한 작업에는 자동화를 스킬과 결합할 수 있습니다.

프로젝트 범위 자동화의 경우 앱이 실행 중이어야 하고 선택한 프로젝트가 디스크에서 사용할 수 있어야 합니다.

Git 저장소에서는 자동화가 로컬 프로젝트에서 실행될지, 새 워크트리에서 실행될지 선택할 수 있습니다. 두 옵션 모두 백그라운드에서 실행됩니다. 워크트리는 자동화 변경 사항을 끝나지 않은 로컬 작업과 분리하고, 로컬 프로젝트에서 실행하면 현재 편집 중인 파일이 수정될 수 있습니다. 버전 관리되지 않는 프로젝트에서는 자동화가 프로젝트 디렉터리에서 직접 실행됩니다.

모델과 추론 강도는 기본 설정으로 둘 수도 있고, 자동화 실행 방식을 더 제어하고 싶다면 명시적으로 선택할 수도 있습니다.

작업 관리

모든 자동화와 실행 기록은 Codex 앱 사이드바의 자동화 패널에서 찾을 수 있습니다.

"Triage" 섹션은 받은 편지함 역할을 합니다. 발견 항목이 있는 자동화 실행이 여기에 표시되며, 받은 편지함을 필터링해 모든 자동화 실행 또는 읽지 않은 항목만 볼 수 있습니다.

독립형 자동화는 일정에 따라 새 실행을 시작하고 결과를 Triage에 보고합니다. 각 실행이 독립적이어야 하거나 하나의 자동화가 하나 이상의 프로젝트에서 실행되어야 할 때 사용합니다. 사용자 지정 주기가 필요하면 사용자 지정 일정을 선택하고 cron 문법을 입력합니다.

Git 저장소에서는 각 자동화가 로컬 프로젝트 또는 전용 백그라운드 워크트리에서 실행될 수 있습니다. 끝나지 않은 로컬 작업과 자동화 변경 사항을 분리하려면 워크트리를 사용합니다. 자동화가 main 체크아웃에서 직접 작업하길 원하면 로컬 모드를 사용하되, 현재 편집 중인 파일을 변경할 수 있음을 고려하십시오. 버전 관리되지 않는 프로젝트에서는 자동화가 프로젝트 디렉터리에서 직접 실행됩니다. 같은 자동화를 둘 이상의 프로젝트에서 실행할 수도 있습니다.

자동화는 기본 샌드박스 설정을 사용합니다. read-only 모드에서는 파일 수정, 네트워크 접근, 컴퓨터의 앱 작업이 필요한 도구 호출이 실패합니다. full access가 활성화된 백그라운드 자동화는 위험이 높습니다. 설정에서 샌드박스 설정을 조정하고 규칙으로 명령을 선택적으로 허용 목록에 추가할 수 있습니다.

자동화는 Codex가 사용할 수 있는 같은 플러그인과 스킬을 사용할 수 있습니다. 자동화를 유지 관리 가능하고 팀 간 공유하기 쉽게 만들려면 스킬을 사용해 액션을 정의하고 도구와 컨텍스트를 제공합니다. 자동화 안에서 $skill-name을 사용해 스킬을 명시적으로 호출할 수 있습니다.

Codex에게 자동화 생성 또는 업데이트 요청

일반 Codex 스레드에서 자동화를 만들고 업데이트할 수 있습니다. 작업, 일정, 자동화가 현재 스레드에 붙어 있어야 하는지 또는 새 실행을 시작해야 하는지 설명합니다. Codex는 자동화 프롬프트를 초안으로 만들고, 올바른 자동화 유형을 선택하고, 범위나 주기가 바뀌면 업데이트할 수 있습니다.

예를 들어 배포가 끝나는 동안 이 스레드에서 리마인더를 달라고 요청하거나, 반복 일정으로 프로젝트를 확인하는 독립형 자동화를 만들라고 요청할 수 있습니다.

스킬도 자동화를 만들거나 업데이트할 수 있습니다. 예를 들어 pull request를 계속 확인하는 스킬은 GitHub 플러그인으로 PR 상태를 확인하고 새 리뷰 피드백을 수정하는 반복 자동화를 설정할 수 있습니다.

스레드 자동화

스레드 자동화는 현재 스레드에 연결된 하트비트 방식의 반복 호출입니다. Codex가 같은 대화로 일정에 따라 계속 돌아오길 원할 때 사용합니다.

예약된 작업이 매번 새 프롬프트에서 시작하는 대신 스레드 컨텍스트를 유지해야 한다면 스레드 자동화를 사용합니다.

스레드 자동화는 활성 후속 반복에는 분 단위 간격을 사용할 수 있고, 특정 시간에 확인이 필요할 때는 일별 및 주별 일정을 사용할 수 있습니다.

스레드 자동화는 다음에 유용합니다.

• 오래 실행되는 명령이 끝날 때까지 확인
• 결과가 같은 스레드에 남아야 하는 Slack, GitHub 또는 다른 연결 소스 폴링
• 고정된 주기로 리뷰 반복을 계속하라고 Codex에게 알림
• PR 상태 확인과 새 피드백 처리처럼 플러그인을 사용하는 스킬 기반 워크플로 실행
• 진행 중인 조사 또는 분류 작업에 집중된 채팅 유지

각 실행이 독립적이어야 하거나, 둘 이상의 프로젝트에서 실행되어야 하거나, 발견 항목이 Triage의 별도 자동화 실행으로 표시되어야 한다면 독립형 또는 프로젝트 자동화를 사용합니다.

스레드 자동화를 만들 때 프롬프트를 오래 유지될 수 있게 작성합니다. 스레드가 깨어날 때마다 Codex가 무엇을 해야 하는지, 보고할 중요한 내용이 있는지 어떻게 판단할지, 언제 멈추거나 사용자 입력을 요청할지를 설명해야 합니다.

자동화 테스트

자동화를 예약하기 전에 먼저 일반 스레드에서 프롬프트를 수동으로 테스트합니다. 이렇게 하면 다음을 확인할 수 있습니다.

• 프롬프트가 명확하고 범위가 올바릅니다.
• 선택한 모델 또는 기본 모델, 추론 강도, 도구가 예상대로 동작합니다.
• 결과 diff를 리뷰할 수 있습니다.

예약 실행을 시작하면 처음 몇 개 출력을 검토하고 필요에 따라 프롬프트나 주기를 조정합니다.

자동화 워크트리 정리

Git 저장소에서 워크트리를 선택하면 자주 실행되는 일정이 시간이 지나면서 많은 워크트리를 만들 수 있습니다. 더 이상 필요하지 않은 자동화 실행을 보관하고, 워크트리를 유지하려는 경우가 아니라면 실행을 고정하지 마십시오.

권한과 보안 모델

자동화는 무인으로 실행되며 기본 샌드박스 설정을 사용합니다.

• 샌드박스 모드가 read-only이면 파일 수정, 네트워크 접근, 컴퓨터의 앱 작업이 필요한 도구 호출이 실패합니다. 샌드박스 설정을 workspace-write로 업데이트하는 것을 고려하십시오.
• 샌드박스 모드가 workspace-write이면 작업 공간 밖의 파일 수정, 네트워크 접근, 컴퓨터의 앱 작업이 필요한 도구 호출이 실패합니다. 규칙을 사용해 샌드박스 밖에서 실행할 명령을 선택적으로 허용 목록에 추가할 수 있습니다.
• 샌드박스 모드가 full access이면 Codex가 묻지 않고 파일을 변경하고, 명령을 실행하고, 네트워크에 접근할 수 있으므로 백그라운드 자동화의 위험이 높아집니다. 샌드박스 설정을 workspace-write로 업데이트하고, 규칙으로 에이전트가 full access로 실행할 수 있는 명령을 선택적으로 정의하는 것을 고려하십시오.

관리형 환경에서는 관리자가 관리자 강제 요구 사항으로 이러한 동작을 제한할 수 있습니다. 예를 들어 approval_policy = "never"를 금지하거나 허용된 샌드박스 모드를 제한할 수 있습니다. 관리자가 강제하는 요구 사항(requirements.toml)를 참고하십시오.

조직 정책이 허용하면 자동화는 approval_policy = "never"를 사용합니다. 관리자 요구 사항이 approval_policy = "never"를 금지하면 자동화는 선택한 모드의 승인 동작으로 대체됩니다.

예시

새 스킬 자동 생성

지난 하루 동안의 모든 `~/.codex/sessions` 파일을 살펴보고 특정 스킬 사용에 문제가 있었다면 해당 스킬을 더 유용하게 업데이트하십시오. 개인 스킬만 대상으로 하고, 저장소 스킬은 제외합니다.

자주 하면서도 어려움을 겪는 작업 중 앞으로 속도를 높이기 위해 스킬로 저장해야 할 것이 있다면 그렇게 하십시오.

반드시 업데이트할 필요는 없습니다. 좋은 이유가 있을 때만 업데이트하십시오.

새로 만든 것이 있으면 알려 주십시오.

프로젝트 최신 상태 유지

최신 원격 `origin/master` 또는 `origin/main`을 확인한 뒤, `{DIRECTORY}`를 건드린 최근 24시간 커밋에 대한 실행 브리핑을 작성하십시오.

형식 + 구조:

- 풍부한 Markdown을 사용합니다(H1 워크스트림 섹션, 부제 이탤릭체, 필요한 경우 가로선).
- 시작 문장은 “다음은 {directory}에 대한 최근 24시간 브리핑입니다:”처럼 작성할 수 있습니다.
- 부제는 “소유자별 내러티브 설명, 워크스트림 기준 그룹화”로 작성합니다.
- 각 커밋을 나열하기보다 워크스트림별로 묶습니다. 워크스트림 제목은 H1이어야 합니다.
- 워크스트림마다 변경 사항을 쉬운 말로 설명하는 짧은 내러티브를 작성합니다.
- 가독성에 도움이 되면 글머리표와 굵게 표시를 사용합니다.
- 사람별로 글머리표를 나눠도 되지만 이름은 굵게 표시합니다.

내용 요구 사항:

- PR 링크는 “PRs:” 라벨 없이 인라인으로 포함합니다(예: [#123](...)).
- 커밋 해시나 “주요 커밋” 섹션은 포함하지 않습니다.
- 하나의 워크스트림 아래에 여러 PR이 있어도 괜찮지만, 커밋별 글머리표 목록은 피합니다.

범위 규칙:

- 현재 cwd 또는 이에 해당하는 main 체크아웃 안의 변경 사항만 포함합니다.
- 지난 24시간의 커밋만 포함합니다.
- 도움이 된다면 `gh`를 사용해 PR 제목과 설명을 가져옵니다.
  PR 리뷰와 댓글도 가져와도 됩니다.

스킬과 자동화를 결합해 자신의 버그 수정

최근 커밋에서 생긴 버그를 찾아 고치는 새 $recent-code-bugfix 스킬을 만들고 개인 스킬에 저장합니다.

---
name: recent-code-bugfix
description: 현재 작업 디렉터리에서 지난주 안에 현재 작성자가 만든 버그를 찾아 수정합니다. 사용자가 최근 변경 사항에 대한 선제적 버그 수정을 원하거나, 프롬프트가 비어 있거나, 최근 커밋으로 생긴 문제를 분류하고 수정해 달라고 요청할 때 사용합니다. 근본 원인은 작성자 자신의 변경 사항과 직접 연결되어야 합니다.
---

# 최근 코드 버그 수정

## 개요

지난주 안에 현재 작성자가 만든 버그를 찾고, 수정 사항을 구현하고, 가능하면 검증합니다. 현재 작업 디렉터리에서 작업하고, 코드는 로컬에 있다고 가정하며, 근본 원인이 작성자 자신의 수정 사항과 직접 연결되어 있는지 확인합니다.

## 워크플로

### 1) 최근 변경 범위 설정

Git을 사용해 작성자와 지난주 변경된 파일을 확인합니다.

- `git config user.name`/`user.email`에서 작성자를 확인합니다. 사용할 수 없으면 환경의 현재 사용자 이름을 사용하거나 한 번만 물어봅니다.
- `git log --since=1.week --author={author}`로 최근 커밋과 파일을 나열합니다. 해당 커밋이 건드린 파일에 집중합니다.
- 사용자 프롬프트가 비어 있으면 이 기본 범위로 바로 진행합니다.

### 2) 최근 변경과 연결된 구체적 실패 찾기

작성자의 수정 사항에 직접 기인한 결함을 우선시합니다.

- 로그나 CI 출력을 로컬에서 사용할 수 있다면 최근 실패(테스트, lint, 런타임 오류)를 찾습니다.
- 제공된 실패가 없으면 수정된 파일과 관련된 가장 작은 검증(단일 테스트, 파일 단위 lint, 대상 재현)을 실행합니다.
- 근본 원인이 무관한 기존 문제가 아니라 작성자의 변경 사항과 직접 연결되어 있는지 확인합니다. 무관한 실패만 발견되면 중단하고 조건에 맞는 버그를 찾지 못했다고 보고합니다.

### 3) 수정 구현

프로젝트 관례에 맞는 최소 수정을 만듭니다.

- 문제 해결에 필요한 파일만 업데이트합니다.
- 추가 방어 코드나 무관한 리팩터링을 피합니다.
- 변경 사항을 로컬 스타일과 테스트에 맞게 유지합니다.

### 4) 검증

가능하면 검증을 시도합니다.

- 가장 작은 검증 단계(대상 테스트, 집중 lint, 직접 재현 명령)를 선호합니다.
- 검증을 실행할 수 없다면 무엇을 실행할 예정이었고 왜 실행하지 못했는지 설명합니다.

### 5) 보고

근본 원인, 수정 사항, 수행한 검증을 요약합니다. 근본 원인이 작성자의 최근 변경 사항과 어떻게 연결되는지 명확히 설명합니다.

그 뒤 새 자동화를 만듭니다.

지난 24시간 동안의 내 커밋을 확인하고 `$recent-code-bugfix`를 제출하십시오.