kktbur/VibeCoding-Start

VibeCoding Start

이 스킬을 사용하여 Codex에 첫 번째 프로젝트 세션부터 릴리즈 및 관찰까지 경량 엔지니어링 시스템을 제공하십시오. 원하는 결과는 이후 세션에서 전체 채팅을 다시 실행하지 않고도 이해, 검토, 확인, 수락 및 안전하게 계속할 수 있는 프로젝트입니다.

첫 번째 작업

프로젝트의 AGENTS.md를 읽은 후 다음 핫 컨텍스트 순서를 따르십시오:

1. docs/INDEX.md
2. docs/CURRENT.md
3. docs/PRODUCT.md
4. docs/PRD.md
5. docs/ACCEPTANCE.md

docs/CODEMAP.md, 활성 ADR, 계획, 작업 로그, 표준 및 로컬 원시 증거는 작업에 필요할 때만 읽으십시오. 6개의 문서 골격이 없는 경우, 구현 전에 동반 vibecoding-project-knowledge 스킬의 INIT 모드를 사용하십시오.

절대적인 프로젝트 경계

• 모든 프로젝트는 동일한 최소 골격을 받습니다: AGENTS.md, docs/INDEX.md, PRODUCT.md, PRD.md, ACCEPTANCE.md, CURRENT.md, CODEMAP.md.
• 복잡성은 문서 깊이와 게이트 강도를 변경하지만 골격을 제거하지는 않습니다.
• PRODUCT.md는 이유(Why)를, PRD.md는 무엇(What)을, ACCEPTANCE.md는 증명 방법(How to prove)을 설명합니다. 이러한 책임을 묵시적으로 병합하지 마십시오.
• 세션이 요구사항, 기능, 비목표, 제약 조건 또는 의미 있는 사용자 시나리오를 변경하는 경우 PRD.md를 업데이트하십시오.
• 원시 세션, 로그, 실패한 시도, 조사 및 증거는 기본적으로 .project-memory/ 디렉토리 아래에 로컬로 보관하십시오. 편집되고 의도적으로 선별된 예제만 docs/examples/로 승격시키십시오.
• 사용자 정의 인프라보다 기존 프로젝트 기능, 표준 라이브러리, 공식 SDK/API/도구, 성숙한 오픈 소스 프로젝트, 패키지, 어댑터 또는 구성을 선호하십시오.
• 이 워크플로의 일부로 메모리 데이터베이스, 벡터 데이터베이스, 검색 엔진, 테스트 프레임워크, 배포 프레임워크, CI 서비스 또는 관찰 가능성 백엔드를 구축하지 마십시오.

엔지니어링 게이트

모든 프로젝트에 동일한 용어를 사용하면서 위험에 따라 깊이를 조정하십시오:

G0 범위(Scope)
→ G1 의도(Intent)
→ G2 재사용(Reuse)
→ G3 계획(Plan)
→ G4 구축(Build)
→ G5 적대적 검토(Adversarial Review)
→ G6 검증(Verification)
→ G7 인간 승인(Human Acceptance)
→ G8 릴리즈(Release)
→ G9 관찰(Observation)

G0 범위

작업을 애플리케이션/제품, 통합/어댑터, 또는 인프라/보안/런타임으로 분류하십시오. 인프라에 가까울수록 재사용, 검토 및 복구 증거가 더 강력해야 합니다.

G1 의도

체인을 명시적으로 만드십시오:

PRODUCT (이유) → PRD (무엇) → ACCEPTANCE (증명 방법)

구현 전에 문제, 사용자, 현재 및 원하는 상태, 기능 요구사항, 비목표, 제약 조건, 수락 기준 및 위험을 기록하십시오.

G2 재사용

중요하지 않은 일반 기능의 경우 구축하기 전에 검색하고 다음 순서로 결정하십시오:

사용(USE) → 적응(ADAPT) → 구성(COMPOSE) → 구축(BUILD) → 중지(STOP)

BUILD가 선택된 경우, 검색된 대안, 거부된 재사용 경로, 유지보수 책임 및 소유자의 수락 방법을 ADR에 기록하십시오. 모델이 코드를 작성할 수 있다는 사실이 사용자 정의 코드가 올바른 선택임을 증명하는 것은 아닙니다.

G3 계획

복잡한 작업을 각 마일스톤 이후에 검증 지점이 있는 작은 마일스톤으로 나누십시오. 범위, 아키텍처 또는 위험이 실질적으로 변경되면 중단하고 다시 계획하십시오.

G4 구축

구현을 작고 되돌릴 수 있게 유지하십시오. 기존 툴체인을 사용하고 추상화, 종속성 및 인프라를 투기적으로 추가하지 마십시오.

G5 적대적 검토

독립적인 검토자가 PRODUCT.md, PRD.md, ACCEPTANCE.md, 활성 결정, 관련 구조, diff 및 테스트를 검토합니다. 누락, 잘못된 가정, 회귀, 중복 기능, 과도한 설계, 보안/데이터 위험, 테스트 격차 및 롤백 실패를 찾으십시오. 중요한 변경 사항의 경우 작성자가 최종 검토자가 되어서는 안 됩니다.

G6 검증

위험에 비례하여 정상, 오류, 경계, 잘못된 입력, 회귀 및 복구 경로를 다루십시오. 기계 증거와 소유자가 읽을 수 있는 설명을 보고하십시오. 녹색 체크 표시는 실제로 확인하는 불변 속성만 증명합니다.

G7 인간 승인

소유자는 결과가 의도된 제품이고 관찰 가능한 동작을 이해할 수 있는지 확인합니다. 자동화된 검사와 독립적인 검토가 이 단계를 대체하지 않습니다.

G8 릴리즈

실제 사용 전에 버전, 마지막으로 알려진 정상 상태, 릴리즈 노트, 백업, 롤백 방법, 마이그레이션 위험 및 정확한 릴리즈 대상을 기록하십시오.

G9 관찰

릴리즈 후 상태 및 사용자 증거를 관찰하십시오. 정상일 때만 계속하고, 증거가 문제를 보여주면 중단하고 롤백하거나 롤 포워드하십시오. 결과를 적절히 테스트, 작업 로그, ADR, 제품 의도, 수락 기준 또는 사후 분석에 피드백하십시오.

지식 마무리

모든 실질적인 세션 종료 시 동반 vibecoding-project-knowledge 스킬의 UPDATE 모드를 사용하십시오:

1. 원시 세션 세부 정보와 대용량 출력을 로컬 .project-memory/ 디렉토리에 보존하십시오.
2. CURRENT.md 및 관련 활성 문서를 정리하십시오.
3. 구조가 변경되면 CODEMAP.md를 업데이트하십시오.
4. 요구사항, 기능, 비목표, 제약 조건 또는 사용자 시나리오가 변경되면 PRD.md를 업데이트하십시오.
5. 중요한 선택 사항을 ADR에 기록하십시오.
6. 인덱스와 작업 로그를 업데이트하십시오.
7. 관련 결정론적 감사를 실행하십시오.

기계 증거, 사람이 읽을 수 있는 설명 및 소유자 승인 방법 없이 완료를 주장하지 마십시오.

참고 자료

• 규범적 규칙 및 릴리즈 경계는 표준 v1.3을 읽으십시오.
• INIT, UPDATE 또는 AUDIT 절차는 동반 vibecoding-project-knowledge 스킬을 읽으십시오.