누구나 전문 개발자처럼

• 처음 만들어 보는 사람

  AI가 만든 화면이 제대로 동작하는지 혼자 판단하기 어려워요

  컨셉 한두 문장으로 모든 페이지를 만들고, 링크와 버튼을 모두 눌러 본 뒤 HTML로 내보내요

  시작하기컨셉으로 화면 만들기 · 고루

• 기획자·디자이너

  화면마다 색과 글꼴이 달라져 결과를 그대로 쓰기 어려워요

  어울리는 스타일 1~3위를 추천받아 DESIGN.md 하나로 정하고, 그림을 그릴 수 있으면 첫 화면 시안 세 장을 비교해 골라요

  시작하기UI/UX 흐름 · DESIGN.md

• 1인 개발자·작은 팀

  거의 맞는 코드를 고치느라 시간이 들고, 세션이 바뀌면 맥락이 사라져요

  로그인·DB·배포를 갖춘 템플릿 위에서 작업마다 할 일 목록과 실행 증거를 남기고, 만들지 않은 에이전트가 따로 리뷰해요

  시작하기빠른 시작: 서비스 만들기 · Claudle 튜토리얼

• 배우는 개발자

  AI가 짠 코드를 이해하지 못한 채 다음으로 넘어가요

  설계 확인, 구현, 검사, 리뷰로 이어지는 프로 개발자의 순서를 라운드마다 남는 기록으로 보며 따라가요

  시작하기Nextflix 튜토리얼 · dev-cycle 라운드

• 가르치는 사람

  학생이 무엇을 만들고 무엇을 확인했는지 함께 점검하기 어려워요

  장마다 같은 프롬프트와 성공 기준이 있고, 라운드마다 실행한 검사가 기록으로 남아요

  시작하기튜토리얼

• 팀·외주 작업자

  사람마다 AI를 쓰는 방식이 달라 결과가 들쭉날쭉해요

  프로젝트마다 같은 규칙, 스킬, 리뷰 에이전트, 비밀값 검사를 설치하고 템플릿이 바뀌면 차이를 보고 반영해요. MIT라 고객 프로젝트에도 써요

  시작하기하네스 엔지니어링 · 기존 프로젝트에 갱신 반영

이런 분께는 맞지 않아요

몇 분 만에 결과만 받고 싶을 때

검사와 확인을 마쳐야 끝나서 그냥 맡길 때보다 오래 걸려요. 가장 작은 프리셋(고루, 7쪽)도 프리셋 팩으로 만들 때 한 번에 완성하면 약 1시간~2시간(여러 번 고쳐 달라고 하면 약 3시간까지) 걸려요

웹이 아닌 앱을 만들 때

템플릿은 Next.js 웹 앱만 만들어요. 모바일 앱은 선택 스킬 묶음으로 따로 만들어요

준비물이나 사용량이 부담될 때

Node, pnpm, git이 있어야 하고 서비스까지 만들려면 컨테이너 엔진도 필요해요(준비물). Windows는 WSL2에서만 돼요. 큰 프리셋은 5시간 한도에 여러 번 걸려요

문서에서 자세히

• 사용자가 결과를 보기도 전에 다음 기능으로 넘어가요

  대조표의 마지막 행이 사용자 확인이라서 확인해야 라운드가 끝나요. 이 행은 N/A(해당 없음)로 넘길 수 없어요

• 테스트를 돌리지 않고 "완료했습니다"라고 해요

  대조표의 모든 칸에 실행한 명령과 결과가 있어야 audit이 통과해요. 통과하기 전에는 완료라고 하지 않아요

• 매번 다른 모양, 기본 컴포넌트 그대로인 화면

  첫 화면 전에 디자인 스타일을 골라 DESIGN.md로 정해 두고, 코드 전에 화면 설계를 확인받아요. 만든 뒤에는 스크린샷과 디자인·접근성 점수로 검사해요

• 자기가 짠 코드를 자기가 검토해요

  읽기 전용 prokit-reviewer가 따로 검토하고, 리뷰 칸은 그 결과로만 채워요

• 새 세션마다 프로젝트를 다시 설명해야 해요

  시작할 때 AGENTS.md, GLOSSARY.md, docs/domain/project.md를 읽어요. 라운드마다 두 문서에 바꿀 내용이 있는지 확인해 고쳐요

• 막힌 단계를 조용히 건너뛰어요

  실행하지 못한 검사는 blocked: 사유로 남기고 "부분 완료"로 보고해요. 그런 라운드는 사용자가 동의해야 끝나요

프로킷이란

1. 01

   작업 폴더에서 에이전트 열기

   프로젝트를 모아 둘 폴더(예: ~/projects)에서 에이전트(Claude Code, Codex, Antigravity, Grok Build 중 하나)를 열어요.

   mkdir -p ~/projects && cd ~/projects
   claude              # Codex는 codex, Antigravity는 agy, Grok Build는 grok --trust

   복사복사됨
2. 02

   프롬프트 보내기

   만들고 싶은 서비스를 한두 문장으로 적어 아래 프롬프트처럼 보내요.

   https://github.com/roadkwon-ai/pro-kit 을 이 폴더에 받고, 그 안의 AGENTS.md대로 화면만 만들 프로젝트를 pro-kit 옆에 living 폴더로 만들어줘. DB는 쓰지 않아. 없는 준비물은 설치해줘. 같이 사는 사람들이 함께 쓴 생활비를 적고, 월말에 누가 누구에게 얼마를 보내면 되는지 알려 주는 서비스를 만들고 싶어. 필요한 화면을 모두 예시 데이터로 만들어줘. 로그인이나 저장 같은 기능은 빼고 화면만 만들어. 디자인 스타일은 서비스에 어울리는 걸로 추천해주고, 다 만들면 HTML 파일로 내보내줘.

   복사복사됨

   에이전트가 pro-kit을 받아 DB 없는 프로젝트를 만들고, 전용 스킬과 검사 도구를 설치한 뒤 커밋해요. 끝나면 새 폴더에서 이어 갈 명령 한 줄을 알려 줘요.

3. 03

   알려 준 한 줄로 새 폴더에서 열기

   알려 준 한 줄로 새 폴더에서 에이전트를 열어요. 그 프로젝트의 규칙과 스킬은 새 폴더에서 열어야 켜져요.

   cd <프로젝트 절대 경로> && claude "docs/first-request.md의 요청대로 이어서 해줘"

   복사복사됨

빠른 시작: 화면만 만들기튜토리얼

$ pnpm dev-cycle status
활성 라운드 없음 — pnpm dev-cycle case로 판정한 뒤 pnpm dev-cycle table <케이스> --write --title "<요약>"으로 연다 (케이스는 요청 기준, 아직 diff가 없으면 판정은 A)
$ pnpm dev-cycle case
A — base 3ddc9fd3e038c312d0a6b0040dd422a993b87cc6

$ pnpm dev-cycle table F --write --title "R29 프로킷 소개(/about)·릴리스 노트 sync·헤더 메뉴, …
tasks/todo.md에 케이스 F 대조표(32행)를 썼다

## 라운드: F — R28 문서(/docs) 페이지·handbook sync, 튜토리얼 팩 주소 sync, 빌드 스타 수 한 값, 튜토리얼·문서 마스코트와 로고
| # | 단계 | 증거 |
| 1 | 스펙 작성 (brainstorming + ponytail 사다리로 범위 줄이기, …
| 6 | [verify] 타입·린트 검사 (commands.typecheck, commands.lint) → 명령과 결과 요약 | `pnpm check-types` → exit 0…
| 28 | [review] prokit-reviewer(code) 전체 diff 최종 리뷰 → verdict, max_severity, 반영·기각 내역 | prokit-reviewer(code): approve, max=low…

| 19 | [verify] 타입·린트·빌드 → 명령과 결과 | 마지막 코드 기준(리뷰·QA 반영 뒤): `pnpm check-types` → exit 0(tasks/evidence/R28/final-check-types.txt), `pnpm exec biome check .` → 기존 1건만…

$ node scripts/dev-cycle.mjs audit
audit 통과

| 33 | [confirm] 사용자 확인 (결과를 사용자에게 보여 주고 사용자가 직접 보거나 써 본 뒤 확인한다. N/A 불가) → 확인한 내용과 날짜 | 사용자 확인(2026-10-07): 3012에서 R28을 보고 "확인했어"로 확정…
배포 PASS: 사용자 지시(사이트 배포는 모든 라운드가 끝난 뒤 사용자가 따로 지시할 때 pro-kit 세션이 publish-root.sh로 한다)

케이스 A~F·H와 대조표프리셋을 만든 실제 기록

• prokit-dev-cycle

  작업 진행. 요청을 케이스로 나누고 대조표를 열어요

  지키게 하는 것: 모든 단계에 증거를 남기고 audit을 통과해야 완료

• prokit-web

  화면 동작(라우팅, 데이터 불러오기, 캐시)

  지키게 하는 것: 로그인 확인은 서버에서, 로딩·빈·오류 상태 구분, 서버 비밀값은 브라우저로 보내지 않기

• prokit-ui

  화면 모양과 사용 경험(impeccable)

  지키게 하는 것: 첫 화면 전에 디자인 스타일 후보 1~3개 추천, DESIGN.md 스펙 검사(lint), 코드 전에 브리프 확인, 디자인 토큰만 사용, 점수 기준(audit 16/20)

• prokit-api

  서버 API, 로그인, 권한

  지키게 하는 것: 로그인 필수, 자기 데이터만 접근, 입력 검증, 2계정 격리 테스트

• prokit-db

  테이블과 마이그레이션

  지키게 하는 것: 마이그레이션 파일로만 변경, 로컬 → 병합 전(기본 브랜치에 합치기 전) → 운영 순서, 데이터를 잃을 수 있는 변경은 두 단계. Supabase는 모든 테이블에 RLS(행 단위 접근 제한)

• prokit-verify

  검사 선택과 증거 기록

  지키게 하는 것: 실행하지 않은 검사는 통과로 적지 않기

• prokit-deploy

  Vercel 배포(develop, production)와 되돌리기

  지키게 하는 것: 요청하거나 라운드 끝에서 고를 때만 배포, DB 먼저 적용, 로컬 .env는 올리지 않고 배포 값은 Vercel 환경변수에만, 운영은 기본 브랜치에서만

• prokit-skills-update

  에이전트가 쓰는 외부 스킬 업데이트

  지키게 하는 것: 작업을 시작할 때 하루 한 번 새 버전 확인, 업데이트는 물어보고 한 라운드로 커밋, 원격에서 없어진 스킬은 지우지 않고 알림

prokit 스킬 8개

템플릿 두 가지

운영 DB를 어디에 둘지로 골라요. 앱 코드 구성은 두 템플릿이 같아요.

템플릿 고르기

1. 01스타일 추천 1~3위화면은 prokit-ui 스킬이 맡아요. 코드를 쓰기 전에 서비스를 파악하고, 어울리는 디자인 스타일을 추천받아 고른 뒤 화면 설계(브리프)를 확인받아요. 만든 뒤에는 모든 링크와 버튼을 눌러 보고 디자인 점수로 검사해요.UI/UX 흐름
2. 02DESIGN.mdDESIGN.md는 색, 글꼴, 간격 같은 디자인 값을 모아 둔 파일 하나예요. 에이전트는 화면을 만들 때마다 이 파일을 읽어서 새 세션에서도 같은 디자인을 이어 가요. 형식은 Google의 DESIGN.md 스펙을 따르고, 저장할 때마다 검사기로 확인해요.DESIGN.md
3. 03내보내기와 배포화면만 만든 프로젝트는 HTML 파일로 내보내 GitHub Pages나 Vercel에 무료로 올릴 수 있어요. "GitHub Pages에 배포해줘"라고 하면 에이전트가 저장소가 없으면 만들어 올리고 주소를 알려 줘요. 필요한 토큰만 미리 작업 폴더의 .env에 넣어 두면 돼요.GitHub Pages 배포

에이전트별 차이지원하는 에이전트

프로킷 없이 vs 프로킷으로

%는 같은 요청 13개를 스킬이 있을 때와 없을 때로 나눠 맡기고, 프로킷 규칙을 지켰는지 체크 항목 52개로 채점한 비율이에요. 코드 품질 점수는 아니에요. "프로킷 없이" 칸의 %는 그 스킬만 뺀 같은 프로젝트(규칙 문서와 다른 스킬은 그대로)에서, 디자인 줄은 프로킷 규칙은 따르되 DESIGN.md 없이 브랜드 이름과 대표 색만 줬을 때 서비스 4개에서 잰 값이에요. 프로킷을 전혀 쓰지 않을 때를 잰 것은 아니에요.

대신 시간이 더 들어요. 확인을 마쳐야 끝나서, 올곧은 만들기 시간의 60%가 모든 페이지 확인이었어요(시간이 어디에 쓰이나요).

실제 사례

• 올곧

  입시학원 웹 앱 203쪽(48종)을 같은 흐름으로 만들고 모든 페이지의 링크와 버튼을 눌러 봤어요

  눌러 본 링크와 버튼 2,025번 · 식단표 한 줄 고치기는 고치기 1분, 앞뒤 확인 6분

  기록올곧

• Claudle

  실제 서비스를 둘러보는 리서치부터 프리셋 팩, 모든 화면, 공개 전 손보기까지 했어요. 공개 전 손보기에서 리뷰 에이전트의 지적까지 고쳤어요

  리서치부터 끝까지 약 7시간 55분 · 공개 전 두 군데 손보기 약 28분

  기록Claudle을 리서치부터 만든 시간

• 같은 요청 비교

  같은 요청을 스킬과 DESIGN.md가 있을 때와 없을 때로 나눠 맡기고 채점했어요

  화면 설계 12% → 100% · 작업 진행 27% → 93% · 목표 색 71% → 99%

  기록검증 결과

같은 요청 비교는 neon 템플릿의 첫 측정이에요. 스킬마다 채점자 한 명이 채점했고, 조건마다 한 번씩만 돌려 편차는 몰라요. 스킬이 있을 때 값은 평가를 1~3번 돌리며 스킬을 고친 뒤의 최종 값이에요. supabase의 DB 스킬은 규칙 문서에 같은 보안 규칙이 있어 없을 때 점수가 더 높았어요(검증 결과). DESIGN.md가 있어도 두 번째 화면의 일관성은 차이가 없었어요(DESIGN.md 효과(새 탭)).

만든 과정만드는 과정과 걸리는 시간검증 결과 문서

만들어진 것

프로킷으로 만든 프리셋 9개예요. 모든 페이지를 열어 볼 수 있어요.

• 울림AI 내레이션 스튜디오
• 제철상자제철 농산물 정기배송
• PACECREW동네 러닝 크루 매칭
• AFTERGLOW태양광 배터리 판매·설치 상담

• 프리셋 9
• ·페이지 337
• ·눌러 본 링크와 버튼 3,460
• ·문제 0

프리셋 모두 보기검증 결과

1. v0.1.0(새 탭)

   2026-10-09

   ProKit first public release

   Features

   • 프로킷 템플릿과 학습 자료 첫 공개

전체 릴리스 보기(새 탭)