@qualisoft/ai-skills 1.0.0

package/skills/project-init/modules/core.json

@@ -0,0 +1,132 @@
+{
+  "name": "core",
+  "label": "핵심 — 모든 프로젝트 공통",
+  "docs": [
+    {
+      "name": "readme",
+      "file": "README.md",
+      "role": "readme",
+      "template": "readme",
+      "phase": "00. 관제탑",
+      "title": "문서 체계 안내",
+      "summary": "이 Docs 체계가 무엇이고, 어떻게 쓰고, 다른 프로젝트에 어떻게 재사용하는지."
+    },
+    {
+      "name": "deliverable-register",
+      "role": "deliverable",
+      "template": "spec",
+      "phase": "00. 관제탑",
+      "title": "산출물 정의서",
+      "summary": "이 프로젝트가 무엇을 만들어 내는지의 전체 목록. 메뉴와 WBS의 원천.",
+      "outline": [
+        [
+          "산출물 목록",
+          "`DLV-01` 형식. 컬럼은 `코드 / 산출물명 / 공정 / 필수 / 고객공유 / 담당 / 상태 / 근거`. **근거 칸에는 기획안 조항이나 요구사항 ID를 쓴다** — 비어 있으면 그 산출물은 만들 이유가 없다는 뜻이다"
+        ],
+        [
+          "공정별 집계",
+          "공정마다 산출물 몇 종인지. 한 공정에 7종을 넘으면 묶을 수 있는지 다시 본다"
+        ],
+        [
+          "제외한 산출물",
+          "만들지 **않기로** 한 것과 그 이유. 이걸 안 적으면 나중에 '왜 없냐'가 반복된다"
+        ],
+        [
+          "버전 이력",
+          "컬럼은 `일자 / 버전 / 변경 / 사유 / 요청자`. **덮어쓰지 않고 쌓는다.** 고객과 범위를 다툴 때 유일한 근거다"
+        ]
+      ]
+    },
+    {
+      "name": "wbs-schedule",
+      "role": "wbs",
+      "template": "spec",
+      "phase": "00. 관제탑",
+      "title": "WBS · 일정",
+      "summary": "공정별 과업과 일정. 과업 하나는 산출물 하나를 낳는다.",
+      "outline": [
+        [
+          "과업 도출 규칙",
+          "**산출물이 없는 과업은 올리지 않는다.** 이 규칙이 과업 폭증을 막는다. 계층은 공정 → 과업 2단까지만"
+        ],
+        [
+          "공정 정의",
+          "이 프로젝트가 쓰는 공정과 각 공정의 시작·종료 판단 기준. 기본은 상시·사업관리 + 5공정"
+        ],
+        [
+          "과업 목록",
+          "`W-01` 형식. 컬럼은 `과업ID / 공정 / 과업명 / 가중치 / 시작 / 종료 / 담당 / 진척 / 산출물 / 선행`. **산출물 칸이 빈 행은 지운다**"
+        ],
+        [
+          "진척 계산",
+          "가중치 반영 총 진척률 = Σ(과업진척 × 가중치) ÷ Σ가중치. 가중치를 안 쓰면 전부 1로 둔다"
+        ],
+        [
+          "마일스톤",
+          "고객 보고·승인 시점만. 내부 일정은 과업 목록에 둔다"
+        ],
+        [
+          "지연 판정",
+          "종료일이 지났고 진척이 100%가 아니면 지연이다. 판정은 사람이 아니라 이 규칙이 한다"
+        ]
+      ]
+    },
+    {
+      "name": "project-brief",
+      "template": "spec",
+      "phase": "01. 상시 · 사업관리",
+      "title": "프로젝트 브리프",
+      "summary": "무엇을, 왜, 어디까지 만드는가. 모든 문서의 상위 전제.",
+      "outline": [
+        [
+          "프로젝트 정의",
+          "이름, 유형, 저장소, 상위 근거 문서"
+        ],
+        [
+          "배경",
+          "왜 지금 만드는가. 없으면 무엇이 문제인가"
+        ],
+        [
+          "목표",
+          "`G-01` 형식으로 번호를 붙이고, 목표마다 성공 판단 기준을 함께 적는다"
+        ],
+        [
+          "범위",
+          "포함과 **제외**를 함께 적는다. 제외를 안 적으면 나중에 분쟁이 된다"
+        ],
+        [
+          "제약",
+          "지켜야 하는 규칙과 그 출처"
+        ],
+        [
+          "이해관계자",
+          "역할, 담당, 결정 권한. RACI로 적으면 A(최종승인)는 한 명이어야 한다"
+        ]
+      ]
+    },
+    {
+      "name": "risk-open-questions",
+      "role": "risk",
+      "template": "register",
+      "phase": "01. 상시 · 사업관리",
+      "title": "리스크 · 미결정 사항",
+      "summary": "착수를 막는 미결정 항목과 프로젝트 리스크."
+    },
+    {
+      "name": "decision-log",
+      "role": "decision",
+      "template": "log",
+      "phase": "01. 상시 · 사업관리",
+      "title": "의사결정 기록",
+      "summary": "확정된 결정과 그 근거."
+    },
+    {
+      "name": "glossary",
+      "template": "reference",
+      "phase": "01. 상시 · 사업관리",
+      "title": "용어 정의",
+      "summary": "프로젝트 내에서 뜻이 흔들리기 쉬운 용어를 고정한다.",
+      "minScale": "small"
+    }
+  ]
+}

package/skills/project-init/modules/design.json

@@ -0,0 +1,72 @@
+{
+  "name": "design",
+  "label": "디자인 시스템",
+  "docs": [
+    {
+      "name": "design-system",
+      "template": "spec",
+      "phase": "20. 설계",
+      "title": "디자인 가이드",
+      "summary": "색·타이포·간격 토큰과 컴포넌트, 그리고 움직임 규칙.",
+      "outline": [
+        [
+          "비주얼 방향",
+          "레퍼런스에서 가져올 것과 가져오지 않을 것을 나눠 적는다"
+        ],
+        [
+          "컬러 토큰",
+          "**HEX 값까지 적는다.** 이름만 적으면 구현할 수 없다. 텍스트 사용 가능 여부를 명도비로 판정해 함께 표기"
+        ],
+        [
+          "타이포그래피",
+          "폰트 스택 + 크기·행간·자간 스케일. 국문은 `word-break: keep-all` 전제"
+        ],
+        [
+          "레이아웃",
+          "최대 폭, 여백, 그리드, 섹션 리듬"
+        ],
+        [
+          "형태",
+          "radius, shadow. 절제된 값이 엔터프라이즈 톤을 만든다"
+        ],
+        [
+          "반응형",
+          "브레이크포인트별 규칙. 모바일은 축소판이 아니라 별도 정보 계층"
+        ],
+        [
+          "컴포넌트 인벤토리",
+          "각 컴포넌트는 특정 페이지에 종속되지 않게"
+        ],
+        [
+          "안티패턴",
+          "하지 말아야 할 것을 구체적으로. 이 목록이 'AI가 만든 티'를 막는다"
+        ],
+        [
+          "다크 모드",
+          "토큰 이중화 범위와 전환 방식",
+          "darkmode"
+        ],
+        [
+          "원칙",
+          "모션은 멋있으려고가 아니라 정보 구조를 이해시키려고 쓴다"
+        ],
+        [
+          "상태 정의",
+          "Default / Hover / Focus / Active / Disabled / Loading / Success / Error 전부. 하나라도 빠지면 미완성"
+        ],
+        [
+          "모션 스펙",
+          "duration, easing, 이동량, stagger 상한"
+        ],
+        [
+          "허용 / 금지",
+          null
+        ],
+        [
+          "접근성 연계",
+          "`prefers-reduced-motion` 대응. 스크립트가 실패해도 콘텐츠가 사라지지 않아야 한다"
+        ]
+      ]
+    }
+  ]
+}

package/skills/project-init/modules/engineering.json

@@ -0,0 +1,86 @@
+{
+  "name": "engineering",
+  "label": "엔지니어링 — 아키텍처 · 개발표준",
+  "docs": [
+    {
+      "name": "tech-architecture",
+      "template": "spec",
+      "phase": "20. 설계",
+      "title": "기술 아키텍처",
+      "summary": "스택과 그 선택 근거, 구조, 그리고 성능 기준.",
+      "outline": [
+        [
+          "스택",
+          "선택과 **근거**를 함께"
+        ],
+        [
+          "렌더링 전략",
+          "페이지별 정적/서버/클라이언트"
+        ],
+        [
+          "폴더 구조",
+          null
+        ],
+        [
+          "코드 규칙",
+          "컴포넌트 분할 기준, 죽은 코드, 콘솔 경고"
+        ],
+        [
+          "외부 연동",
+          "폼 수신 경로 등. 미연결이면 데모임을 명시한다"
+        ],
+        [
+          "환경 변수",
+          "키 목록만 공유한다. 시크릿은 커밋하지 않는다"
+        ],
+        [
+          "브라우저 지원",
+          null
+        ],
+        [
+          "목표",
+          "Core Web Vitals 수치와 Lighthouse 기준"
+        ],
+        [
+          "자원 예산",
+          "JS / CSS / 폰트 / 이미지 상한을 숫자로"
+        ],
+        [
+          "최적화 방침",
+          "예산을 넘으면 기능이 아니라 **원인**을 제거한다. 라이브러리 추가 전에 플랫폼 기능으로 되는지 먼저 확인"
+        ],
+        [
+          "측정",
+          "도구와 릴리즈 게이트",
+          "perfbudget"
+        ]
+      ]
+    },
+    {
+      "name": "dev-standard",
+      "template": "spec",
+      "phase": "30. 구축",
+      "title": "개발 표준",
+      "summary": "코드를 어떻게 쓰고 합치고 리뷰하는지의 약속.",
+      "outline": [
+        [
+          "디렉터리 · 네이밍",
+          "폴더 구조와 파일·변수 이름 규칙. 예시를 하나씩 붙인다"
+        ],
+        [
+          "브랜치 · 커밋",
+          "브랜치 전략과 커밋 메시지 형식, 리뷰 통과 조건"
+        ],
+        [
+          "공통 규칙",
+          "에러 처리, 로깅, 환경변수 취급. **팀이 실제로 어긴 것만 적는다** — 일반론은 적지 않는다"
+        ],
+        [
+          "완료의 정의 (DoD)",
+          "과업을 '끝났다'고 부를 조건. 테스트·리뷰·문서 갱신 중 무엇이 필수인지"
+        ]
+      ],
+      "minScale": "small"
+    }
+  ]
+}

package/skills/project-init/modules/mobile.json

@@ -0,0 +1,22 @@
+{
+  "name": "mobile",
+  "label": "모바일 앱 — 권한 · 스토어",
+  "docs": [
+    {
+      "name": "permissions-privacy",
+      "template": "spec",
+      "phase": "20. 설계",
+      "title": "권한 · 개인정보",
+      "summary": "요청 권한과 사유, 수집 항목, 스토어 고지 대응.",
+      "minRisk": "standard"
+    },
+    {
+      "name": "release-store",
+      "template": "spec",
+      "phase": "50. 오픈 · 안정화",
+      "title": "배포 · 스토어 심사",
+      "summary": "빌드 채널, 심사 준비물, 단계적 배포, 롤백.",
+      "minDelivery": "production"
+    }
+  ]
+}

package/skills/project-init/modules/ops.json

@@ -0,0 +1,122 @@
+{
+  "name": "ops",
+  "label": "오픈 · 운영",
+  "docs": [
+    {
+      "name": "qa-test-plan",
+      "template": "spec",
+      "phase": "40. 검증",
+      "title": "QA · 테스트 계획",
+      "summary": "검증 범위, 기기 매트릭스, 릴리즈 체크리스트, 통과 기준.",
+      "outline": [
+        [
+          "검증 범위",
+          "기능 · 반응형 · 접근성 · 성능 · SEO · 콘텐츠 무결성"
+        ],
+        [
+          "기기 · 브라우저 매트릭스",
+          null
+        ],
+        [
+          "릴리즈 체크리스트",
+          "체크박스로 작성한다. 레이아웃 / 기능 / 콘텐츠 / 품질 / 게이트 / 최종 판정"
+        ],
+        [
+          "자동화",
+          "타입 체크 · 린트 · 빌드는 최소 필수"
+        ]
+      ],
+      "minScale": "small"
+    },
+    {
+      "name": "release-ops",
+      "template": "spec",
+      "phase": "50. 오픈 · 안정화",
+      "title": "오픈 · 운영 가이드",
+      "summary": "배포 절차, 운영 이관, 사용자 교육, 그리고 측정.",
+      "outline": [
+        [
+          "환경",
+          "local / preview / production"
+        ],
+        [
+          "브랜치 · 배포 흐름",
+          null
+        ],
+        [
+          "출시 전 준비",
+          "도메인, 이메일, 로고·파비콘·OG, 법적 문서, 사업자 정보. 미완이면 Placeholder가 그대로 노출된다"
+        ],
+        [
+          "운영",
+          "주기별 작업(문의 확인, 의존성 갱신, 성능 재측정)"
+        ],
+        [
+          "장애 대응",
+          "롤백 기준과 절차"
+        ],
+        [
+          "백업",
+          null
+        ],
+        [
+          "정착 성공 기준",
+          "기존 방식과 **병행 운영되면 실패다.** 폐기 시점을 기준으로 잡는다"
+        ],
+        [
+          "대상과 범위",
+          "역할별로 무엇까지 가르치는가"
+        ],
+        [
+          "산출물",
+          "운영 매뉴얼, 교육 세션, 자주 하는 실수 정리"
+        ],
+        [
+          "정착 관찰 기간",
+          "초기에는 병행을 허용하되 양쪽 기록을 대조한다. 불일치가 없으면 기존 방식을 폐기한다"
+        ],
+        [
+          "KPI",
+          "기준 데이터가 없으면 목표 수치를 만들지 않는다. 출시 후 일정 기간을 베이스라인으로 삼는다",
+          "analytics"
+        ],
+        [
+          "이벤트 택소노미",
+          "명명 규칙과 이벤트 목록. **개인정보(이름·이메일·문의 본문)를 이벤트 속성에 담지 않는다**",
+          "analytics"
+        ],
+        [
+          "퍼널",
+          "유입 · 설득 · 폼 중 어디서 막히는지 구분 가능해야 한다",
+          "analytics"
+        ],
+        [
+          "도구",
+          "**GA4**(측정)와 **GTM**(태그 관리)은 다른 물건이다. 쿠키리스 대안도 함께 검토",
+          "analytics"
+        ],
+        [
+          "태그 관리",
+          "GTM 도입 여부. 컨테이너 하나로 코드 수정 없이 태그를 관리하지만, 스크립트가 늘면 성능 예산과 충돌하므로 예산 안에서만",
+          "tagmanager"
+        ],
+        [
+          "전환 추적",
+          "광고 집행 시에만 필요. 폼 제출 = 전환 이벤트. 픽셀은 개인정보 동의 대상",
+          "adtracking"
+        ],
+        [
+          "검색 노출 성과",
+          "서치콘솔 · 서치어드바이저 지표를 KPI에 편입",
+          "seo"
+        ],
+        [
+          "개인정보 · 동의",
+          "쿠키 동의 배너 필요 여부(법무 확인), 수집 항목, 보관 기간",
+          "consent"
+        ]
+      ],
+      "minScale": "small"
+    }
+  ]
+}

package/skills/project-init/modules/process.json

@@ -0,0 +1,104 @@
+{
+  "name": "process",
+  "label": "업무 프로세스 · 이관",
+  "docs": [
+    {
+      "name": "as-is-to-be",
+      "template": "spec",
+      "phase": "10. 착수 · 분석",
+      "title": "현행 · 개선 업무 분석",
+      "summary": "지금 일이 어떻게 흐르는가, 무엇을 바꾸는가.",
+      "minScale": "small",
+      "outline": [
+        [
+          "현행 업무 흐름",
+          "단계별로 적고 **각 단계의 문제를 함께** 적는다. 문제 없는 단계는 건드리지 않는다"
+        ],
+        [
+          "정량 데이터",
+          "건수·소요시간·오류율. **없으면 없다고 적는다.** 지어낸 수치가 개선 효과의 기준선이 되면 프로젝트 전체가 흔들린다"
+        ],
+        [
+          "벤치마킹",
+          "비교 대상이 있으면 **계승할 구조와 배제할 구현을 분리**해 표로 적는다. 좋은 사례와 싫은 사례가 같은 대상일 수 있다"
+        ],
+        [
+          "현행 도구",
+          "지금 무엇으로 버티고 있는가. 이관 대상이 여기서 나온다"
+        ],
+        [
+          "목표 흐름",
+          "주체별로 적는다. 고객과 운영자의 흐름이 어디서 만나는지 보여야 한다"
+        ],
+        [
+          "단계별 전환",
+          "현행 → 목표를 나란히 놓는다. 바뀌지 않는 단계도 적어야 범위가 닫힌다"
+        ],
+        [
+          "전환 성공 조건",
+          "무엇이 되면 전환된 것인가. **기존 방식과 병행 운영되면 실패다** — 폐기 시점을 적는다"
+        ],
+        [
+          "남는 수작업",
+          "시스템이 덮지 못하는 부분. 숨기면 오픈 후 불만이 된다"
+        ]
+      ]
+    },
+    {
+      "name": "role-permission",
+      "template": "spec",
+      "phase": "20. 설계",
+      "title": "역할 · 권한 정의서",
+      "summary": "역할별 접근 범위와 승인 흐름.",
+      "minScale": "standard",
+      "outline": [
+        [
+          "역할 후보",
+          "**실제 인원이 확인되기 전에는 확정하지 않는다.** 1인 운영이면 역할 분리가 과설계이고, 3인 이상이면 분리가 필요하다"
+        ],
+        [
+          "역할별 접근 범위",
+          "화면·기능 단위로"
+        ],
+        [
+          "이력이 필요한 조작",
+          "금액에 영향을 주는 조작(환불 실행, 가격 일괄 변경, 단가 설정)은 누가 했는지 남긴다"
+        ],
+        [
+          "개인정보 열람 범위",
+          "역할별로 제한하고 열람 기록을 남긴다"
+        ]
+      ]
+    },
+    {
+      "name": "data-migration",
+      "template": "spec",
+      "phase": "30. 구축",
+      "title": "데이터 이관 계획",
+      "summary": "이관 대상, 정제 규칙, 검증, 되돌리기.",
+      "minScale": "large",
+      "outline": [
+        [
+          "이관 대상과 출처",
+          "무엇을 어디서 가져오는가. 신규 구축이면 '이관 없음'도 명시한다"
+        ],
+        [
+          "요구 형식",
+          "**필수 항목과 있으면 좋은 항목을 나눈다.** 빠지면 어떤 기능이 죽는지 함께 적는다 — 그래야 자료 요청의 우선순위가 선다"
+        ],
+        [
+          "절차",
+          "매핑 → 형식·중복 검증 → 스테이징 적재 → 표본 검수 → 운영 적재"
+        ],
+        [
+          "데이터가 없을 경우",
+          "**입력 대행은 개발 공수가 아니라 데이터 작업이다.** 별도 범위와 정산 방식임을 계약 전에 명시한다"
+        ],
+        [
+          "이후 갱신 경로",
+          "초기 적재 뒤 누가 어떻게 갱신하는가"
+        ]
+      ]
+    }
+  ]
+}

package/skills/project-init/modules/product.json

@@ -0,0 +1,37 @@
+{
+  "name": "product",
+  "label": "요구사항 정의",
+  "docs": [
+    {
+      "name": "requirements",
+      "role": "requirement",
+      "template": "spec",
+      "phase": "00. 관제탑",
+      "title": "요구사항 정의서",
+      "summary": "기획안과 협의에서 확인된 요구사항, 타당성, 그리고 WBS·산출물 연결.",
+      "outline": [
+        [
+          "우선순위 · 타당성 기준",
+          "등급 정의를 먼저 고정한다. 우선순위는 `높음/보통/낮음`, 타당성은 `수용가능/추가검토/수용불가`"
+        ],
+        [
+          "요구사항 목록",
+          "`R-01` 형식. 컬럼은 `ID / 요청자 / 영역 / 현행문제 / 요구내용 / 타당성 / 우선순위 / 연계 과업 / 연계 산출물`. **연계 과업과 산출물이 비면 이 요구사항은 아직 계획에 없다는 뜻이다**"
+        ],
+        [
+          "비기능 요구사항",
+          "`N-01` 형식. 성능·접근성·보안은 여기서 기준만 정하고 상세는 각 문서로 링크"
+        ],
+        [
+          "수용 기준",
+          "요구사항마다 **무엇을 보면 완료인지**를 적는다. 없으면 완료 판정이 불가능하다"
+        ],
+        [
+          "수용하지 않은 요구사항",
+          "거절·보류한 것과 그 이유, 통보 여부. 기록이 없으면 같은 요구가 다시 올라온다"
+        ]
+      ],
+      "minScale": "small"
+    }
+  ]
+}

package/skills/project-init/modules/ux.json

@@ -0,0 +1,52 @@
+{
+  "name": "ux",
+  "label": "화면 설계",
+  "docs": [
+    {
+      "name": "screen-spec",
+      "template": "spec",
+      "phase": "20. 설계",
+      "title": "화면 설계서",
+      "summary": "화면 목록, 각 화면의 요소와 상태, 그리고 화면 간 이동.",
+      "outline": [
+        [
+          "표기 규칙",
+          "확정 카피와 `TODO(주체)` 구분"
+        ],
+        [
+          "페이지별 정의",
+          "화면마다 요소 · 카피 · 상태 · 조건부 렌더"
+        ],
+        [
+          "상세 페이지 템플릿",
+          "반복되는 페이지 유형의 블록 순서"
+        ],
+        [
+          "폼",
+          "필드, 필수 항목 최소화, 제출 상태 4종(idle/submitting/success/error)",
+          "contactform"
+        ],
+        [
+          "빈 상태 · 오류 화면",
+          "404 포함"
+        ],
+        [
+          "주 흐름",
+          "진입부터 목표 달성까지. 화면이 아니라 **판단 단위**로 끊는다"
+        ],
+        [
+          "이탈 지점",
+          "**어디서 끊기는가와 그 대응.** 퍼소나에서 도출한다 — 근거 없는 이탈 예측은 쓰지 않는다"
+        ],
+        [
+          "대체 흐름",
+          "실패·예외·빈 결과"
+        ],
+        [
+          "선행 결정에 종속된 흐름",
+          "결정에 따라 갈라지는 흐름은 **정의하지 않고 무엇에 종속되는지만** 적는다"
+        ]
+      ]
+    }
+  ]
+}