Communitygithub.com

Irnist/website-pipeline

최소한의 사용자 입력만으로 원시 입력에서 배포된 프리뷰까지 클라이언트 웹사이트를 구축하는 엔드투엔드 자동 파이프라인입니다. 수집 → 방향 설정 → 빌드 → QA → 프리뷰 배포 → 인계까지 자동으로 실행되며, 중요한 질문에 대해서만 멈춥니다.

website-pipeline란 무엇인가요?

이 스킬은 AI 에이전트가 처음부터 완전히 배포된 프리뷰까지 클라이언트 웹사이트를 구축하는 완전 자동화 파이프라인을 제공합니다. Claude Code, Cursor 또는 유사한 AI 코딩 에이전트를 위해 설계되었으며, /website 명령을 실행할 때, '클라이언트 웹사이트 시작/빌드/계속' 요청을 받을 때, 또는 'New Website' 실행기가 만든 폴더 내에서 실행될 때 트리거됩니다. 이 파이프라인은 수집, 방향 설정, 빌드, QA, 배포 및 인계 단계를 포함하여 최대한 자율적으로 작동하며, 사용자에게 질문을 해야 하는 중요하고 되돌릴 수 없는 결정에 대해서만 멈춥니다. 견본(포트폴리오) 모드와 실제 클라이언트 모드를 모두 지원하며, 런타임에 BRIEF.md 파일의 '프로젝트 유형'을 기반으로 모드를 전환합니다. 이 파이프라인은 자체 git 저장소, 재개 가능 상태를 위한 PROJECT.md 체크리스트, QA.py, browser_qa.mjs, deploy.py와 같은 공유 도구 세트, 그리고 LESSONS.md 및 RULES.md에 캡슐화된 이전 경험을 활용하여 일관된 품질을 보장합니다. 사용자는 'status', 'qa', 'deploy', 'handoff'와 같은 인수를 제공하여 특정 단계를 실행하거나, 시작하기 위해 자유 텍스트 비즈니스 정보(회사명, 전화번호, 링크 등)를 제공할 수 있습니다.

지원 대상✓Claude Code~Codex CLI~Cursor
npx skills add Irnist/website-pipeline

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

웹사이트 파이프라인

원시 입력에서 배포된 프리뷰까지 클라이언트 웹사이트를 최소한의 사용자 입력으로 실행합니다. 먼저, 매 실행(새 실행, 재개 또는 단일 단계)마다: <pipeline>/RULES.md (웹사이트 규칙)을 읽으세요. 단, 이 세션에서 이미 읽은 경우는 제외합니다. 이 규칙은 모든 단계에 적용됩니다. tools/의 도구는 대부분의 규칙을 기계적으로 적용하므로, 눈으로 다시 확인하는 대신 도구를 실행하세요.

작업 공간

모든 것은 하나의 작업 공간인 C:\Users\Administrator\Desktop\Claude Workspace (<workspace>)에 있습니다. 아래 경로는 이에 상대적입니다. 스크립트에서는 하드코딩된 Desktop 경로 대신 스크립트 자체 위치(Path(__file__))에서 경로를 파생시키세요.

항목위치
파이프라인 (<pipeline>)Workflow and Pipeline/website-pipeline/ (~/.claude/skills/website는 이에 대한 정션입니다)
공유 도구<pipeline>/tools/: qa.py, browser_qa.mjs, deploy.py…의 단일 복사본. 각 사이트의 tools/에는 해당 사이트에서 이 도구를 실행하는 스텁이 있습니다(L-052). 따라서 수정이나 새 검사가 모든 사이트에 동시에 적용됩니다. 사이트 전용 스크립트는 스텁 옆에 있습니다.
샘플 사이트Concept Websites/<Name> Website/
소유자 포트폴리오Portfolio Site/
포트폴리오 스크린샷Portfolio Screenshots/: 완성된 사이트 스크린샷만, 다른 것은 없음
임시 파일 (테스트 스크립트, 테스트 스크린샷, 백업, 심어진 결함)_temp/, 시스템 임시 폴더, 프로젝트 또는 템플릿이 아님

0. 나는 어디에 있는가?

폴더 상태와 인수에 따라 진입점을 결정합니다:

상태작업
cwd에 _src/build.py가 없음스캐폴딩: powershell -NoProfile -ExecutionPolicy Bypass -File "<pipeline>/scaffold.ps1" -Target "<cwd>" -NoLaunch, 그런 다음 수집 단계로 이동. cwd에 관련 없는 파일이 있으면 중단하고 질문(중요 질문).
PROJECT.md의 모든 단계가 완료됨(완성된 사이트가 같은 이름으로 다시 열림) 및 인수가 비어 있거나 새 사이트 수집용이며, 단계 인수나 변경 요청이 아님먼저, 실행하거나 변경하기 전에 질문(사용자, 2026-10-10, L-057). 하나의 AskUserQuestion 사용: "은(는) 이미 완료되었습니다(프리뷰 ). 재설계하시겠습니까?" 아니요, 그대로 둠 및 예, 재설계 옵션 포함. 아니요: 중단하고 아무것도 하지 않음. 도구 동기화, QA 또는 배포조차 하지 않음. 예: 새 사이트와 정확히 동일하게 시작. 이전 브리핑에서 스스로 재설계하지 않음(L-058). (1) 진행 중인 변경 사항을 커밋하고 이전 버전에 태그 지정: git tag previous-<date>. 그런 다음 client-assets/ 및 .git/를 제외한 모든 항목(이전 BRIEF.md 포함)을 <workspace>/_temp/<Name>-previous-<date>/로 이동(삭제가 아닌 보관). 태그는 _temp 정리 후에도 이전 사이트를 복원 가능하게 함. (2) 다시 스캐폴딩. 템플릿의 빈 BRIEF.md를 복사하고 Business name: 줄을 설정. (3) 브리핑 양식 열기: python "<pipeline>/brief-form/brief_form.py" "<project>"를 백그라운드 명령으로 실행. 사용자에게 창이 열렸다고 알리고 대기. 그동안 방향 설정, 라이브러리 학습, 스톡 검색 또는 디자인 작업을 하지 않음. (4) 종료 코드 0("Start building"): 새 브리핑에 대해 수집 단계부터 일반 새 사이트 프로세스를 실행. 종료 코드 3(닫힘): 중단하고 브리핑이 저장되었다고 말함. 인계 시, 두 번째 항목을 추가하는 대신 사이트의 디자인 라이브러리 항목을 교체.
PROJECT.md에 완료되지 않은 단계가 있음첫 번째 완료되지 않은 단계에서 재개. 재개 중인 위치를 한 줄로 말함.
기존 프로젝트 재개 또는 변경도구 동기화 불필요: tools/에는 공유 도구용 스텁이 포함됨. 사이트에 .git/이 없으면 git init -b main, git config core.autocrlf false 실행. 템플릿의 .gitignore를 복사하고 기본 커밋 수행. qa.py가 공유 도구의 전체 복사본에 대해 경고하면(2026-10-13 이전 사이트), python "<pipeline>/dev/use_shared_tools.py" "<project>" 실행 및 커밋. 또한 요청에 필요한 템플릿 기능도 가져옴(예: GSAP: build.py의 h_gsap, {{fn:gsap}}, tools/vendor/, motion.js).
인수 status단계 체크리스트와 열린 플레이스홀더를 출력. 다른 작업은 하지 않음.
인수 learn<pipeline>/design-library/inspiration/에 놓인 디자인 이미지 및 DESIGN.md 파일 학습: design-library/LEARN.md를 따른 후, 참조당 한 줄씩 보고. 다른 작업은 하지 않음.
인수 qa / deploy / handoff해당 단계만 실행.

자유 텍스트 인수는 수집 자료(회사명, 전화, 링크, 메모)입니다. BRIEF.md와 동일하게 취급합니다.

모드: 샘플 또는 클라이언트

BRIEF.md › Project type이 모드를 설정합니다. 기본값은 sample(포트폴리오 작품)입니다. 인수에 명시적인 지침이 있으면 우선합니다.

sample (포트폴리오)client (실제 비즈니스)
누락된 사실브리핑이 부족할 때, 그럴듯하고 일관된 가상 비즈니스(이름, 스토리, 서비스, 영업 시간)를 창작. 실제 인물에게 도달하지 않도록 555-01xx 전화번호와 example.com 이메일 사용.절대 창작하지 않음. 플레이스홀더와 data-todo 사용.
리뷰, 통계, 자격 증명가상 비즈니스의 경우 허용. 인계 시 가상임을 명시. 샘플이 실제 비즈니스를 사용하는 경우, 실제 공개된 사실만 사용: 실제 인물이나 회사에 대한 창작 리뷰, 주장 또는 가격은 금지.클라이언트가 제공한 것만.
질문거의 없음: 파일 삭제, 비용 지출, 실제 세계 연락(실제 받은 편지함, 실제 전화번호), 및 중요 디자인 비평(#5)만.아래 전체 질문 정책 적용.
양식데모 모드 허용.실제 엔드포인트 필요. 누락 시 질문.
배포noindex 프리뷰noindex 프리뷰; 프로덕션은 요청 시에만.
인계 추가포트폴리오 스크린샷 (인계 참조)클라이언트용 플레이스홀더 목록 작성

운영 규칙

  • 자동 조종. "계속할까요?"라고 묻지 않고 단계를 단계로 이동. 각 단계 후, PROJECT.md › Status에서 체크. 이렇게 하면 압축 또는 새 세션 후에도 실행을 재개할 수 있음.
  • Git (모든 사이트와 파이프라인은 저장소). 체크된 각 단계 후 사이트에서 커밋(<Phase>: <수행된 작업>). 요청된 각 변경 라운드 후에도 커밋하여 모든 상태를 비교하거나 복원할 수 있도록 함. 파이프라인 변경 사항(공유 도구, 템플릿, SKILL.md, LESSONS.md, 디자인 라이브러리)은 파이프라인 저장소에 커밋. 메시지에 레슨 ID가 있으면 포함. dist/, qa/ 및 캐시는 .gitignored 처리됨. 기록을 덮어쓰거나, 강제 푸시하거나, 푸시하지 않음. 원격 저장소 없음.
  • 질문은 아래 정책을 따름. 그 외 모든 것은 결정: 결정을 내리고, PROJECT.md › Decisions에 한 줄(무엇 + 이유)을 추가하고 계속 진행.
  • 클라이언트 모드: 클라이언트 사실을 절대 조작하지 않음. 여기에는 사용후기, 리뷰 수, 업력, 라이선스, 인증, 가격, 보증, 수상 내역 및 팀 이름이 포함됨. 입력 자료에 없는 경우, 사실이 필요하지 않도록 카피를 작성. 정말 필요한 경우, data-todo="필요한 것"으로 요소를 표시하여 QA에서 인계 목록에 포함하도록 함. 샘플 모드는 모드 표를 따름.
  • 실수는 발생 즉시 PROJECT.md › Mistakes에 기록. 인계를 기다리지 않음. 그 전에 컨텍스트가 압축될 수 있음. 실수는 사용자가 수정하는 모든 것, QA, 비평 또는 리뷰어가 지적하는 모든 첫 번째 초안 오류(인스턴스별로 하나가 아닌 유형별로 하나의 항목 기록), 및 잘못된 가정이나 도구 오용이 포함됨. 각 항목은 발생 상황, 발견자, 근본 원인, 수정 사항 및 예방 방법을 기록.
  • 진실 공급원: _src/(페이지, 부분 템플릿, site_config.py) 및 assets/를 편집한 후 python _src/build.py를 실행. 절대 dist/를 편집하지 않음.
  • 스크립트 편집 (L-027): 단일 변경은 Edit 사용. 한 번에 여러 개의 대체는 Write로 작성된 Python 스크립트(<workspace>/_temp에)에 넣고, 셸 heredoc은 사용하지 않음. 스크립트는 각 일치 횟수가 정확히 1이 아닌 경우 종료되며, 파일을 쓰기 전에 모든 파일을 확인. 그 후 편집된 .py 파일을 py_compile하고 다시 빌드.
  • 컨텍스트 위생: 도구를 실행하고 보고서(qa/*.md)를 읽고, 원시 출력은 읽지 않음. 긴 보고서, 로그 및 목록은 전체를 읽는 대신 컨텍스트 모드(ctx_execute_file / ctx_batch_execute 및 "오류 및 경고만"과 같은 질문)를 통해 쿼리. 스크린샷은 Read 도구로 확인. 전체 HTML 파일을 대화에 덤프하지 않음.

질문 정책 (중요 사항만)

다음 중 하나에 해당하는 경우에만 질문. 이는 클라이언트 모드입니다. 샘플 모드에서는 #2와 #5만 적용되며, noindex 프리뷰는 질문이 필요하지 않습니다.

  1. 신원을 알 수 없음. 어떤 입력이나 공개 소스에서도 비즈니스가 무엇을 하는지, 어디에 있는지, 누구를 대상으로 하는지 알 수 없음. 잘못된 추측은 사이트 재작성을 의미.
  2. 대외적이거나 되돌릴 수 없음. 프로덕션 배포, 사용자 정의 도메인, 실제 받은 편지함에 양식 연결, 비용 지출, 사용자 파일 삭제. BRIEF.md에 Deploy preview: yes라고 명시된 경우 noindex 프리뷰 배포는 사전 승인됨.
  3. 법적 또는 사실적 주장 사이트가 할 수 있으며 클라이언트만 확인할 수 있는 경우(라이선싱, 가격, 보증). 기본적으로 생략. 브리핑이 이를 중심으로 하는 경우에만 질문.
  4. 상충되는 지침 브리핑, 사용자 메시지, RULES.md 및 CLAUDE.md 사이에서, 두 해석이 모두 그럴듯한 경우.
  5. 중요 디자인 비평. 완벽한 비평 또는 마무리 리뷰어가 P0(차단) 또는 P1(중대) 문제를 보고. 아래 비평 게이트를 따름. 이는 빌드 중간에 허용되는 유일한 질문.

질문 방법:

  • 한 배치로, 수집 단계 끝에. 1~4개의 질문이 있는 단일 AskUserQuestion 사용. 권장 답변을 먼저 "(Recommended)"로 표시하여 배치. 빌드 중간에 질문하지 않음. 비평 게이트(#5)는 예외. 나중에 차단 문제가 발생하면 명확하게 표시된 플레이스홀더를 사용하고, 지연 질문(Deferred questions) 아래에 기록하고 인계 시 표면화.
  • 다음에 대해 절대 묻지 않음: 팔레트, 글꼴, 레이아웃, 카피 톤, 페이지 목록, 사용할 스톡 사진, 섹션 순서, 기술 스택, 파일 이름, 또는 QA 결과를 수정할지 여부. 이는 결정. 유일한 예외는 P0/P1 비평 결과(#5).
  • 중요한 것이 없으면 아무것도 묻지 않음. "차단 질문 없음. 진행."이라고 말하고 계속.

비평 게이트 (완벽한 결과)

완벽한(impeccable) 자체 심각도 척도(P0 차단, P1 중대, P2 경미, P3 다듬기)를 사용합니다. 각 결과-리뷰어 항목을 동일한 척도로 평가합니다.

  • P2/P3 (경미): 수정하지 않고 진행. PROJECT.md › Decisions에 결과당 한 줄 기록: "건너뜀: 경미(P2/P3), <결과>".
  • P0/P1 (치명적): 변경하기 전에 중단하고 질문. 최대 4개의 질문이 있는 하나의 AskUserQuestion 배치 사용. 결과당 하나의 질문을 작성하거나, 4개 이상인 경우 클래스별로 그룹화. 각 질문은 문제가 무엇이고 어디에 있는지(페이지, 섹션, 스크린샷 파일) 명시. 2~3개의 구체적인 수정 옵션을 제공하며, 권장 옵션을 먼저 "(Recommended)"로 표시하고, "그대로 두기" 옵션도 포함. 그런 다음 사용자의 선택을 전체 클래스에 사이트 전체에 적용(L-016)하고, 다시 빌드하고, 결정(Decisions)에 기록.
  • 재확인: 선택을 적용한 후 동일한 비평을 한 번 더 실행. 새로운 P0/P1은 게이트를 다시 통과. 경미한 결과는 위와 같이 건너뜀.
  • 게이트에 포함되지 않음: qa.py, browser_qa.mjs, LESSONS.md 또는 RULES.md에서 이미 금지하는 객관적 규칙 위반(예: 4.5:1 미만 대비, 오버플로, 반복된 사진, 텍스트 위의 광택이 대비를 낮추는 경우(광택 자체는 허용됨), 잘린 피사체, 기본값으로 미리 채워진 선택). 이러한 것은 비평이 부여한 심각도와 관계없이 자동으로 수정. 이는 디자인 선택이 아닌 결함이기 때문. impeccable detect 플래그는 위 규칙 중 하나에 해당하지 않는 한 경미한 것으로 간주. 이전과 같이 알려진 오탐(L-000) 참고.

단계

1 · 수집

  1. <pipeline>/LESSONS-INDEX.md 읽기 (LESSONS.md에서 생성된 레슨당 한 줄). 모든 레슨은 첫 번째 초안부터 적용. 이 프로젝트와 관련된 각 레슨에 대해 전체 LESSONS.md 항목을 열고, 해당 ID와 몇 마디 설명을 PROJECT.md › Mistakes › "Watch for"에 나열. ID만 나열. 레슨 텍스트를 복사하지 않음: 복사본은 레슨이 대체될 때 오래됨(Trevor Travis 및 Gadget Zone은 광택이 허용된 후에도 "광택 없음" 유지).
  2. BRIEF.md, 인수 및 client-assets/의 모든 항목 읽기. 모든 사진을 Read로 열고 PROJECT.md › Assets에 카탈로그화. 피사체, 품질, 문제(판, 로고, 혼란, 자르기) 및 가장 적합한 슬롯(히어로/특징/갤러리/건너뛰기)을 기록. 이미지에 있는 타사 브랜드 로고(보드, 간판, 렌더링)는 보증으로 읽힘: "사용 전 자르기" 또는 건너뛰기로 표시(L-028). 동일한 촬영에서 오거나 동일한 뷰를 보여주는 사진 기록(L-029).
  3. 링크(기존 사이트, Google 비즈니스 프로필, Facebook)가 제공된 경우, 이를 가져와 사실 추출: 서비스, 서비스 지역, 영업 시간, 스토리, 소유자, 업력, 실제 프로젝트. 각 사실 옆에 출처를 PROJECT.md › Facts에 인용.
    • 캡션, 리뷰 및 소유자 인용문을 소스 파일(예: client-assets/sources.md)에 그대로 저장. 여기서 인용문을 복사. 기억에서 다시 입력하거나 의역하지 않음(L-007).
    • 각 프로젝트의 크레딧 라인(디자인 / 구축 / 연도)을 Facts에 기록. 비즈니스가 구축만 한 프로젝트는 절대 "디자인"한 것으로 간주하지 않음.
  4. 클라이언트 사진 최적화: python tools/optimize_images.py (client-assets → assets/img/client/, EXIF 회전 적용, 최대 2000px).
  5. _src/site_config.py 채우기: BIZ, HOURS, SERVICES, PRIMARY_CTA, PAGES, FORM_ENDPOINT, SEO. 알 수 없는 연락처 값은 ""로 유지. 빌드는 이를 보이는 {{TOKEN}} 플레이스홀더로 남겨두고 QA에서 보고.
    • 문의 양식. 브리핑의 Form endpoint:를 FORM_ENDPOINT에 복사: 빈칸 = 데모 모드; netlify = Netlify Forms(Deploy host: netlify인 경우에만, 그렇지 않으면 qa.py 오류); web3forms:<access key> = 모든 호스트에서 Web3Forms(받은 편지함 소유자가 web3forms.com에서 키 생성); 또는 Formspree 스타일 URL. {{fn:form_fields}}는 일치하는 숨김 필드와 스팸 트랩을 추가. 직접 실제 받은 편지함을 선택하거나 연결하지 않음: 빈 브리핑은 데모 모드로 유지되고 인계 목록에 포함. 클라이언트 모드에서는 어떤 받은 편지함이 메시지를 받을지 질문 사항. Online booking link:를 BOOKING_URL에 복사; {{fn:booking}}은 연락처 페이지에 통화 버튼 옆에 표시.
    • GSAP 모션. 선택 사항, 기본적으로 꺼짐. 브리핑에 GSAP motion: yes라고 명시된 경우에만 활성화. 활성화되면 h_gsap=True를 설정하고 build.py가 GSAP CDN 스크립트를 포함. 추가 구성은 <pipeline>/design-library/motion-patterns/ 참조.

[참고: 원본 SKILL.md가 잘려서 완전히 제공되지 않았으므로, 이후 단계(방향 설정, 빌드, QA, 배포, 인계)에 대한 번역은 생략되었습니다. 위 내용은 제공된 원본을 최대한 정확히 번역한 것입니다.]

관련 스킬