검증과 배포 흐름을 Skill로 저장하기

지난 다섯 강에서 명세, 계획, 구현, 검증, 리뷰를 순서대로 반복했어요. 다음 프로젝트에서도 매번 긴 프롬프트를 다시 써야 할까요? Codex의 Skill은 이런 반복 작업을 이름 붙은 절차로 저장합니다.

공식 Skill 만들기 안내에 따르면 Skill은 SKILL.md와 선택적인 자료·스크립트로 이루어진 폴더예요. 저장소 전용 Skill은 프로젝트의 .agents/skills 아래 두고 Git에 함께 보관할 수 있습니다. Codex IDE 확장, CLI, 데스크톱 앱에서 사용할 수 있어요.

오늘 만들 것

두 가지가 남습니다.

1. $release-check라고 부를 수 있는 저장소 전용 출시 점검 Skill
2. 인터넷에서 열리는 /tasks.html 할 일 웹앱

Skill은 검사 결과를 보여 주고 사람이 승인하기 전에는 푸시하거나 배포하지 않는 것이 핵심 경계예요.

준비물

• 5강에서 만든 Git 커밋
• 입문 코스에서 연결한 GitHub와 Cloudflare Pages
• 약 35분

따라 하기

1. 반복 절차를 재료로 정리하기

Skill에 넣을 절차를 먼저 다섯 줄로 요약해 보세요.

1. Git 상태와 대상 변경 확인
2. 명세·계획·검증 보고서 읽기
3. 가능한 검사 실행, 못 한 것은 사람 확인으로 표시
4. diff 리뷰와 비밀값 점검
5. 결과 보고 후 사용자 승인 대기

이 절차에는 특정 앱 이름이 없어요. 그래서 다음 작은 웹 프로젝트에도 다시 쓸 수 있습니다.

2. $skill-creator로 Skill 만들기

Codex 작성창에 $skill-creator를 입력해 내장 Skill 제작기를 호출하세요. 목록에서 선택한 뒤 아래 요청을 붙입니다.

이 저장소에서 정적 웹사이트를 출시하기 전에 쓰는 repo Skill을 만들어 줘.

이름: release-check
위치: .agents/skills/release-check
호출할 때 할 일:
- Git 상태와 변경 범위를 먼저 확인
- 프로젝트의 명세, 계획, 테스트 보고서가 있으면 읽기
- 저장소에 적힌 검증 명령과 실제 페이지 점검 실행
- 실행하지 못한 검사는 통과로 표시하지 않기
- diff에서 회귀, 개인정보, API 키, 범위 밖 변경 점검
- 결과를 PASS, FAIL, NEEDS HUMAN으로 요약
- FAIL이 있거나 사용자가 승인하기 전에는 commit, push, deploy 금지

설명 중심의 간단한 SKILL.md로 만들고, 새 패키지나 스크립트는 추가하지 마.
완성 뒤 어떤 요청에서 자동으로 쓰이는지도 설명해 줘.

제작기가 질문하면 “이 저장소 안에서만 사용”, “명시적으로 $release-check라고 부를 때 우선 사용”, “배포는 항상 승인 후”라고 답하세요.

$skill-creator가 보이지 않는 환경이라면 Codex에게 .agents/skills/release-check/SKILL.md를 직접 만들게 해도 돼요. 최소 형식은 다음과 같습니다.

---
name: release-check
description: Check a static website before release; never push or deploy before user approval.
---

1. Inspect Git status and the intended scope.
2. Read project guidance, brief, plan, and test report when present.
3. Run available checks. Mark anything unverified as NEEDS HUMAN.
4. Review the diff for regressions, secrets, and unrelated changes.
5. Report PASS, FAIL, and NEEDS HUMAN. Wait for explicit approval before push or deploy.

3. 새 Skill 시험하기

새 작업을 열거나 현재 작업에서 다음처럼 호출하세요.

$release-check

이번 출시 대상은 할 일 웹앱 커밋이야.
아직 푸시하거나 배포하지 말고 출시 준비 상태만 점검해 줘.

결과에 PASS, FAIL, NEEDS HUMAN이 구분되는지 확인하세요. Skill이 바로 푸시하려 한다면 SKILL.md의 승인 경계를 더 강하게 고쳐야 해요. 반복 절차가 실제로 원하는 행동을 만들 때까지 Skill도 작은 소프트웨어처럼 다듬습니다.

4. Skill 자체도 변경사항에 포함하기

.agents/skills/release-check/SKILL.md는 방금 생긴 새 파일이라 아직 앞선 커밋에 없어요. 내용을 직접 읽고 너무 넓은 권한이나 불명확한 명령이 없는지 확인한 뒤 별도 커밋을 만드세요.

release-check Skill의 범위와 승인 경계를 다시 검토해 줘.
문제가 없으면 Skill 파일만 스테이징해
"Add reusable release check skill"로 커밋해 줘.
아직 푸시하지 마.

5. 승인하고 기존 사이트 업데이트하기

Skill 결과에 설명되지 않은 FAIL이 없고 사람 확인도 끝났다면 배포를 승인합니다.

출시 점검 결과를 확인했어. 두 커밋을 기존 GitHub 원격 저장소에 푸시해 줘.
푸시 전에 현재 브랜치와 원격 주소를 다시 보여 주고,
Cloudflare Pages 배포가 시작되는지 확인해 줘.
새 프로젝트나 새 배포 사이트는 만들지 마.

원격 주소가 내 저장소인지 확인한 뒤 권한을 승인하세요. 기존 Cloudflare Pages가 GitHub 브랜치를 보고 있다면 푸시 뒤 자동 배포가 시작됩니다.

배포가 끝나면 휴대폰 또는 시크릿 창에서 내주소/tasks.html을 열어 다음을 확인하세요.

• 페이지가 200으로 열린다
• 할 일을 추가하고 새로고침해도 남는다
• 기존 소개 페이지도 그대로 열린다
• 소개 페이지의 링크로 할 일 앱에 들어갈 수 있다

브라우저 저장은 기기별로 따로예요. 컴퓨터에서 적은 할 일이 휴대폰에 보이지 않는 것은 이번 명세에 맞는 정상 동작입니다.

막혔을 때

• Skill이 목록에 안 보여요 — 경로가 .agents/skills/release-check/SKILL.md인지 확인하고 Codex를 새로 시작하세요.
• Skill이 자동으로 배포해요 — “사용자의 명시적 승인 전 commit, push, deploy 금지”를 설명과 본문 양쪽에 넣고 다시 시험하세요.
• 푸시했는데 배포가 안 돼요 — 입문 6강의 Cloudflare Pages 프로젝트에서 연결 브랜치와 최근 배포 로그를 확인하세요.
• tasks.html이 404예요 — 파일이 커밋·푸시됐는지, 대소문자가 URL과 같은지 확인하세요.
• 다른 기기에서 목록이 비어 있어요 — localStorage는 기기와 브라우저별 저장소라 정상입니다. 동기화는 다음 버전의 별도 프로젝트예요.

마무리 체크

□ .agents/skills/release-check/SKILL.md가 있다
□ Skill은 확인하지 않은 검사를 PASS라고 하지 않는다
□ Skill은 승인 전에 push·deploy하지 않는다
□ Skill과 할 일 앱이 각각 Git 커밋으로 남았다
□ 기존 GitHub 저장소에 푸시했다
□ 실제 URL에서 할 일 앱과 기존 소개 페이지가 모두 열린다

실전 코스 졸업이에요. 이번에 배운 건 할 일 앱 하나의 코드보다 오래갑니다. 막연한 목표를 명세로 바꾸고 → 계획하고 → 구현하고 → 검증하고 → 리뷰하고 → 잘된 절차를 Skill로 남기는 흐름. 다음 아이디어가 떠오르면 새 도구부터 찾지 말고, 이 여섯 칸을 다시 한 바퀴 돌면 됩니다.