All authors
Claude Skills by GangJaeYu
github.com/GangJaeYu13 skills0 installs30 views
- Architecture Generatordocs/PRD.md와 docs/TRD.md를 읽고 프로젝트 전체 아키텍처를 docs/ARCHITECTURE/ 아래에 작성한다. overview.md에 시스템 구성·경계·핵심 흐름을 담고, frontend.md·backend.md·database.md·auth.md·security.md 등 영역별 문서로 나눠 기록하며, 무엇보다 PRD·TRD와 충돌하는 설계가 있는지 검토해 봉합하지 않고 드러낸다. 사용자가 "아키텍처 설계해줘", "구조 잡아줘", "설계 문서 써줘", "테이블 설계해줘", "API 설계해줘", "폴더 구조 어떻게 나눌지 정해줘"라고 하거나, TRD 검토를 마치고 다음 단계로 넘어갈 때 반드시 이 스킬을 사용한다. 요구사항과 기술 스택은 정해졌는데 구조가 문서로 없는 상태에서 개발 계획을 세우거나 코드를 짜기 시작하려 할 때도 이 스킬로 먼저 설계를 고정한다.Votes: 0GitHub stars: 3
- Bug Fix완료된 프로젝트(plan_setup·harness_setup·loop_setup/LOOP.md 가 있고 STATE.md 의 Phase Overview 에 in_progress 가 없는 상태)에서 실제 사용 중에 발견된 문제 하나를 고친다. "xx 가 안 돼" 로 시작하는 신고를 받아 버그인지 요구 변경인지 먼저 가르고(문서·OQ 근거), 재현 절차와 기대 동작을 LOG.md 에 "### BUG-NN" 한 줄로 먼저 적고, 원인을 확인하고, 그 버그를 잡는 회귀 검사를 harness-update 로 게이트에 즉시 활성으로 넣고(고치기 전 실패를 실제로 확인), 코드를 고치고, 게이트 넷을 통과시키고(task_validation 은 분리 세션이 그 재현 줄을 수용 기준으로 판정), 커밋 1회(메시지에 BUG-NN) 한다. 문서·플랜·phase·STATE.md 는 건드리지 않는다. 사용자가 "필터가 안 돼", "저장했는데 사라져", "이 버튼 누르면 에러 나", "쓰다 보니 이상한 ...Votes: 0GitHub stars: 3
- Code To Docs문서 없이 만들어진 코드베이스(바이브 코딩 프로젝트, 인수받은 레거시, README 한 줄뿐인 앱)를 읽고 "이렇게 만들자"가 아니라 "지금 이렇게 되어 있다"를 적은 as-is 문서 셋 — docs/PRD.md·docs/TRD.md·docs/ARCHITECTURE/ — 를 만든 뒤, plan-generator(phase-01 현행 고정 — as-is 동작을 붙잡는 테스트 태스크만) → harness-setup → loop-setup 을 원래 순서대로 불러 그 프로젝트를 하네스-루프 풀스택 플러그인으로 만든 프로젝트와 같은 상태로 올린다. 사용자가 "이 코드 문서화해줘", "문서 없는 프로젝트인데 이 플러그인에 올리고 싶어", "바이브 코딩으로 만든 건데 정리해줘", "기존 코드 읽고 PRD/TRD 뽑아줘", "레거시 코드에 테스트부터 붙이자", "이 저장소 현재 상태를 문서로 남겨줘"라고 하거나, docs/PRD.md 가 없는 코드베이스에서 리팩토링·기능 추가·버그 수정·하네...Votes: 0GitHub stars: 3
- Feature Add완료된 프로젝트(docs/PRD.md·plan_setup·harness_setup·loop_setup/LOOP.md 가 있고 루프가 도는 중이 아닌 상태)에 기능을 더한다. "xx 기능 추가하려는데" 로 시작하는 요청을 받아, 요청이 모호하면 idea-brainstorm 부터, 명확하면 prd-generator 부터 필요한 기존 스킬(idea-brainstorm → prd-generator → trd-generator(기술 결정이 새로 생기거나 바뀔 때만) → architecture-generator → plan-generator)을 순서대로 부르되 각 문서를 처음부터 다시 쓰지 않고 후미에 "## 추가 N: <기능>" 절만 붙이게 하고(N 은 요청 단위의 공통 번호, FR·US·TD·설계 단위 번호는 이어짐, 기존 항목의 변경은 "FR-003 수용 기준 2 를 다음으로 대체"), plan_setup/ 에 phase-NN-<기능이름> 을 끝번호로 더한 뒤 harness-upda...Votes: 0GitHub stars: 3
- Harness Setupdocs/PRD.md·docs/TRD.md·docs/ARCHITECTURE/·plan_setup/(PLAN.md·phase·task) 을 읽고 프로젝트의 검증 하네스를 harness_setup/ 아래에 세운다. quality_gates/ 에 lint·unit·e2e·task_validation 네 게이트의 정의서(무엇을 검사하고 어떤 명령으로 돌며 무엇이 통과인가, 언제부터 활성인가)를 만들고, scripts/ 에 사용자 OS에 맞는 local-dev 스크립트(DB·API·앱 서버·Redis 같은 의존 서비스를 한 명령으로 준비)를 만들며, task_validation 이 구현 세션과 분리된 독립 세션에서 돌도록 절차를 고정한다. 사용자가 "하네스 세팅해줘", "품질 게이트 만들어줘", "테스트 파이프라인 구성해줘", "검증 환경 세팅해줘", "로컬 개발 환경 세팅해줘", "lint/테스트 어떻게 돌릴지 정해줘", "E2E 붙여줘"라고 하거나, 마스터 플랜 검토를 마치고 다음 ...Votes: 0GitHub stars: 3
- Harness Update이미 있는 harness_setup/ 을 프로젝트 진행에 맞춰 갱신한다. 활성 시점에 도달한 게이트를 미활성에서 활성으로 올리고, 대기 중이던 E2E 흐름과 필수 커버 영역을 활성화하며, 차단(OQ·CF)이 풀린 태스크를 검증 대상에 넣고, 새로 생긴 의존 서비스(Redis·API 서버 등)를 구성 요소 표와 local-dev 스크립트에 더하고, 게이트 명령이 실제와 어긋난 곳을 맞춘다. 사용자가 "하네스 업데이트해줘", "게이트 갱신해줘", "이 흐름도 E2E에 넣어줘", "Redis 추가됐으니 local-dev 고쳐줘", "테스트가 계속 깨지는데 하네스 좀 봐줘", "차단 풀렸으니 검증 대상에 넣어줘"라고 하거나, 개발 루프가 태스크·phase 를 완료한 뒤 하네스가 실제와 맞지 않는다고 판단했을 때 반드시 이 스킬을 사용한다. 게이트가 실패하는데 그 원인이 코드가 아니라 하네스 쪽(낡은 흐름 정의, 준비되지 않는 개발 환경)일 때도 이 스킬로 고친다. harness_set...Votes: 0GitHub stars: 3
- Idea Brainstorm아직 모호한 제품/서비스 아이디어를 역질문과 선택지 제안으로 구체화해서, 다음 단계(PRD 작성)에 바로 쓸 수 있는 docs/IDEA.md 초안을 만든다. 사용자가 "앱 하나 만들고 싶은데", "이런 서비스 어때?", "아이디어 좀 같이 정리하자", "뭘 만들지 고민 중", "브레인스토밍" 같은 말을 하거나, 무엇을 만들지가 확정되지 않은 상태에서 기획/PRD/개발을 요청할 때 반드시 이 스킬을 먼저 사용한다. 요구사항이 흐릿한데 곧바로 코드나 문서를 쓰려는 상황이면 이 스킬로 먼저 범위를 좁힌다.Votes: 0GitHub stars: 3
- Loop Setupplan_setup/(PLAN.md·phase·task·STATE.md·LOG.md) 과 harness_setup/(HARNESS.md·quality_gates/) 을 읽고 이 프로젝트의 개발 루프를 loop_setup/LOOP.md 한 문서로 고정한다. 다음 태스크를 어떻게 고르고, 태스크의 verification 값으로 어느 게이트를 어떤 순서로 돌리며, 실패를 진짜 결함·낡은 스펙·환경 문제로 어떻게 분류하고, 재수정 사이클을 최대 3회로 세다가 언제 멈춰 사용자에게 보고하며, task_validation 을 구현 세션과 어떻게 분리하고, STATE.md·LOG.md 를 언제 갱신하고 언제 커밋하며, 차단이 풀린 태스크를 어떻게 여는지, 태스크마다 새 세션을 누가 어떻게 여는지(스크립트 구동·오르카·서브에이전트), 병렬 운용(기본)을 위해 태스크 단위 DAG 를 머메이드로 그리고 자원 충돌을 사전 검사하며 코디네이터·슬롯 워크트리를 어떻게 운용하는지, 오르카 구동이 진행할...Votes: 0GitHub stars: 3
- Loop Update이미 있는 loop_setup/LOOP.md 를 프로젝트 진행에 맞춰 갱신한다. 세팅 때 껐던 병렬을 켤 때 슬롯 간 DB·포트 격리 미결을 닫고 STATE.md 의 절 형식을 넓혀 에이전트끼리 기록을 덮어쓰지 않게 하고, 동시 에이전트 수·슬롯·격리 방식·구동기 모드가 바뀐 것을 반영하고, local-dev 옵션이나 task_validation 분리 수단이 바뀐 것을 규칙에 반영하고, 태스크가 추가되어 달라진 DAG.md 를 스크립트로 다시 만들고 자원 충돌 표·병렬 폭을 다시 재고, 루프가 같은 자리에서 반복해 멈출 때 규칙이 현실과 어긋난 곳을 고치며, 1.10.0 이전 loop-setup 이 만든 LOOP.md(상주 코디네이터·알림이 쌓이기만 하는 구조)를 구동 스크립트·반복 판정·알림 만료 구조로 옮기고, 1.11 이전 구동 스크립트에 정지 감시(터미널 밖 분리 실행·시작 확인·잠든 워커 깨우기·자식 실패 재시도·밖의 감시 알림)를 넣는다. 사용자가 "루프 업데이트해줘...Votes: 0GitHub stars: 3
- Plan Generatordocs/PRD.md·docs/TRD.md·docs/ARCHITECTURE/ 를 읽고 프로젝트 전체 마스터 플랜을 plan_setup/ 아래에 만든다. PLAN.md(전체 지도), phase-NN/phase-NN-<이름>.md(검증 가능한 단계), phase-NN-tasks/phase-NN-task-MM.md(YAML frontmatter를 가진 실제 작업 단위), STATE.md(지금 어디인가), LOG.md(무슨 일이 있었는가)를 생성하고, PRD 추적표의 '담당 태스크' 열을 채우며, 차단 미결·미해소 충돌에 걸린 태스크를 blocked 로 표시한다. 사용자가 "개발 계획 세워줘", "태스크 나눠줘", "플랜 짜줘", "phase 구성해줘", "뭐부터 만들지 정해줘", "작업 목록 만들어줘", "마스터 플랜 만들어줘"라고 하거나, 아키텍처 검토를 마치고 다음 단계로 넘어갈 때 반드시 이 스킬을 사용한다. 설계 문서는 있는데 무엇부터 구현할지가 문서로 없는 상태에서 코드를 ...Votes: 0GitHub stars: 3
- Prd Generator아이디어나 docs/IDEA.md를 받아 "무엇을 만들 것인가"를 정의하는 PRD(docs/PRD.md)를 작성한다. 요구사항마다 고유 ID와 검증 가능한 수용 기준을 붙여, 이후 아키텍처·플랜·태스크·품질 게이트가 그대로 참조할 수 있게 만든다. 사용자가 "PRD 써줘", "요구사항 정리해줘", "기획서 만들어줘", "제품 스펙 문서", "유저 스토리 정리"라고 하거나, 아이디어 브레인스토밍을 마치고 다음 단계로 넘어갈 때 반드시 이 스킬을 사용한다. 무엇을 만들지는 정해졌는데 기능 목록과 수용 기준이 문서로 없는 상태에서 개발이나 설계를 시작하려 할 때도 이 스킬로 먼저 요구사항을 고정한다.Votes: 0GitHub stars: 3
- Refactor Plan완료된 프로젝트(문서·플랜·하네스·LOOP.md 가 있고 루프가 도는 중이 아닌 상태)의 코드 품질을 올리는 리팩토링을 계획한다. 범위 셋(기저 언어·프레임워크 교체 / 라이브러리 최신화 / 코드 정리 — 중복 제거·안 쓰는 코드·너무 큰 파일·계층 어김) 중 무엇인지 먼저 묻고, 코드를 읽어 고칠 목록(문서와 어긋난 곳 포함)을 만들고, 스택·라이브러리가 바뀌면 docs/TRD.md 후미에, 구조가 바뀌면 docs/ARCHITECTURE/ 후미에 "## 리팩토링 N: <이름>" 절을 붙이고, plan-generator 를 부분 갱신 모드로 불러 plan_setup/ 에 phase-NN-refactor-<이름> 을 끝번호로 더한 뒤 harness-update·loop-update 를 부른다. 통과 조건은 새 수용 기준이 아니라 "기존 게이트 전부 통과(행위 보존)" + 구조 조건이다. 사용자가 "리팩토링하자", "코드 정리 좀 하자", "중복 없애줘", "파일이 너무 커서 나누...Votes: 0GitHub stars: 3
- Trd Generatordocs/PRD.md를 받아 "어떤 기술로 만들 것인가"를 정의하는 TRD(docs/TRD.md)를 작성한다. 스택·데이터·API·인증·보안·테스트·배포를 결정 단위로 확정하고, 각 결정에 근거가 된 요구사항과 검증 방법·되돌리기 비용을 붙여 아키텍처와 하네스가 그대로 참조할 수 있게 만든다. 사용자가 "TRD 써줘", "기술 스택 정해줘", "어떤 기술로 만들지 정리해줘", "기술 명세서", "DB 뭐 쓸지 정해줘", "배포는 어떻게 할지 정리해줘"라고 하거나, PRD 작성을 마치고 다음 단계로 넘어갈 때 반드시 이 스킬을 사용한다. 요구사항은 정해졌는데 기술 선택이 문서로 없는 상태에서 아키텍처 설계나 개발을 시작하려 할 때도 이 스킬로 먼저 기술 결정을 고정한다.Votes: 0GitHub stars: 3