solmate-skills 1.0.2 → 2.0.1

package/verify-performance/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: verify-performance
+description: 브라우저 성능 및 Core Web Vitals를 점검합니다. Lighthouse 기준, LCP·CLS·FID, 번들 크기, 이미지 최적화, 렌더링 전략, 불필요한 클라이언트 코드를 체계적으로 검증합니다. 배포 전 성능 점검, "Lighthouse 확인", "성능 최적화 확인" 요청 시 사용합니다.
+argument-hint: "[선택사항: 점검할 페이지 경로 또는 집중 영역 (예: 홈, 이미지, 번들)]"
+---
+
+# 성능 점검 스킬 (verify-performance)
+
+Lighthouse 및 Core Web Vitals 기준으로 프론트엔드 성능을 검증합니다. 코드 분석 단계와 실측 점검 단계로 나누어 진행하고 발견된 이슈를 우선순위와 함께 보고합니다.
+
+---
+
+## 실행 시점
+
+- 배포 전 성능 최종 점검
+- 새 페이지·이미지·폰트·대형 컴포넌트 추가 후
+- "Lighthouse 점수가 낮다", "페이지가 느리다" 보고 시
+- `rules-workflow` Step 17 (배포 가능 퀄리티 최종 검토) 수행 시
+
+---
+
+## 목표 기준 (Lighthouse Performance Score)
+
+| 지표 | 목표 | 경고 |
+|------|:----:|:----:|
+| Performance Score | 90+ | 70 미만 시 차단 |
+| LCP (Largest Contentful Paint) | ≤ 2.5s | > 4.0s 위험 |
+| CLS (Cumulative Layout Shift) | ≤ 0.1 | > 0.25 위험 |
+| FID / INP (Interaction to Next Paint) | ≤ 200ms | > 500ms 위험 |
+| FCP (First Contentful Paint) | ≤ 1.8s | > 3.0s 위험 |
+| TTFB (Time to First Byte) | ≤ 800ms | > 1.8s 위험 |
+
+---
+
+## Step 0: 점검 범위 확정
+
+인자가 주어진 경우 해당 페이지/영역에 집중한다. 없으면 아래 기준으로 성능에 민감한 파일을 우선 탐색한다.
+
+```bash
+# 이미지 사용 현황
+grep -rn "<img\|Image from\|next/image" src/ --include="*.tsx" --include="*.jsx" -l
+
+# 동적 import 미적용 대형 컴포넌트 탐색
+grep -rn "^import.*from" src/ --include="*.tsx" | grep -v "dynamic\|lazy" | head -40
+
+# 클라이언트 컴포넌트 현황
+grep -rn "'use client'" src/ --include="*.tsx" -l
+```
+
+---
+
+## Check 1: 이미지 최적화
+
+**LCP·CLS·네트워크 비용에 가장 큰 영향**
+
+- `<img>` 태그 직접 사용 대신 `next/image` (또는 프레임워크 이미지 컴포넌트)를 사용하는지 확인한다.
+- `next/image` 사용 시 `width`, `height` 또는 `fill` 속성이 지정되어 CLS가 방지되는지 점검한다.
+- LCP 대상 이미지(히어로 이미지 등)에 `priority` 속성이 적용되어 있는지 확인한다.
+- 외부 이미지 도메인이 `next.config.js`의 `images.domains` 또는 `remotePatterns`에 등록되어 있는지 확인한다.
+
+```bash
+grep -rn "<img " src/ --include="*.tsx" --include="*.jsx"
+grep -rn "next/image" src/ --include="*.tsx" -l
+grep -rn "priority" src/ --include="*.tsx"
+```
+
+- 체크:
+  - [ ] `<img>` 직접 사용 없이 최적화 컴포넌트를 사용하는가?
+  - [ ] 이미지에 `width`/`height` 또는 `fill`이 지정되어 있는가?
+  - [ ] LCP 대상 이미지에 `priority`가 적용되어 있는가?
+
+---
+
+## Check 2: 렌더링 전략
+
+**TTFB·LCP·SEO에 영향**
+
+- 정적 콘텐츠(랜딩, 블로그, 약관)에 SSG 또는 RSC가 적용되어 있는지 확인한다.
+- 인증이 필요한 페이지가 아님에도 전체 페이지를 `'use client'`로 선언했는지 점검한다.
+- `useEffect`로 초기 데이터를 fetch하는 경우 서버 컴포넌트 또는 loader로 대체 가능한지 검토한다.
+- PPR(Partial Prerendering)이 적용 가능한 페이지가 있는지 확인한다 (정적 shell + 동적 Suspense).
+
+```bash
+# 전체 페이지 단위 'use client' 확인
+grep -rn "'use client'" src/app/ --include="*.tsx"
+
+# useEffect 데이터 fetch 패턴
+grep -rn "useEffect.*fetch\|useEffect.*axios\|useEffect.*api" src/ --include="*.tsx" -l
+```
+
+- 체크:
+  - [ ] 정적 콘텐츠에 SSG/RSC가 적용되어 있는가?
+  - [ ] 불필요하게 전체 페이지가 클라이언트 컴포넌트로 선언되지 않았는가?
+  - [ ] 초기 데이터 fetch를 서버에서 처리하는가?
+
+---
+
+## Check 3: 번들 크기
+
+**FCP·TTI(Time to Interactive)에 영향**
+
+- 빌드 출력에서 페이지별 번들 크기를 확인한다. 단일 페이지 JS가 250kB(gzip)를 초과하면 분할을 검토한다.
+- 초기 로드에 불필요한 대형 라이브러리(차트, 에디터, 날짜 피커 등)가 동적 import 없이 포함되었는지 확인한다.
+- `barrel export`(`index.ts`에서 전체 재내보내기) 사용 시 tree-shaking이 방해되는지 점검한다.
+
+```bash
+# 빌드 실행 및 번들 크기 확인
+npm run build 2>&1 | grep -E "Page|Size|First Load"
+
+# 대형 의존성 탐지
+grep -rn "^import.*from 'recharts\|chart.js\|@tiptap\|react-quill\|moment\|lodash'" src/ --include="*.tsx" --include="*.ts" | grep -v "dynamic"
+```
+
+- 체크:
+  - [ ] 단일 페이지 First Load JS가 250kB 이하인가?
+  - [ ] 대형 라이브러리에 동적 import(`next/dynamic`, `React.lazy`)가 적용되었는가?
+  - [ ] 사용하지 않는 패키지가 포함되지 않았는가?
+
+---
+
+## Check 4: 폰트 최적화
+
+**CLS·FCP에 영향**
+
+- `next/font` 또는 `@font-face`의 `font-display: swap`이 적용되어 있는지 확인한다.
+- Google Fonts를 `<link>` 태그로 직접 로드하는 경우 `next/font/google`로 대체를 권장한다.
+- 폰트 파일이 self-hosted인 경우 `preload` 힌트가 적용되어 있는지 확인한다.
+
+```bash
+grep -rn "fonts.googleapis\|fonts.gstatic" src/ --include="*.tsx" --include="*.html"
+grep -rn "next/font" src/ --include="*.tsx" -l
+```
+
+- 체크:
+  - [ ] Google Fonts를 `next/font/google`로 로드하는가?
+  - [ ] `font-display: swap`이 적용되어 레이아웃 시프트가 방지되는가?
+
+---
+
+## Check 5: 불필요한 리렌더링
+
+**INP·런타임 성능에 영향**
+
+- 부모 컴포넌트 상태 변경 시 자식이 불필요하게 리렌더링되는지 확인한다. `React.memo`, `useMemo`, `useCallback` 적용이 필요한 곳을 점검한다.
+- 리스트 렌더링에 `key` prop이 올바르게 사용되는지 확인한다 (index 사용 지양).
+- 전역 상태(Context, Zustand 등)가 너무 넓은 범위에서 구독되어 불필요한 리렌더링을 유발하는지 점검한다.
+
+```bash
+grep -rn "key={index}\|key={i}" src/ --include="*.tsx"
+grep -rn "React\.memo\|useMemo\|useCallback" src/ --include="*.tsx" -l
+```
+
+- 체크:
+  - [ ] 리스트 `key`에 index 대신 고유 ID를 사용하는가?
+  - [ ] 무거운 연산에 `useMemo`/`useCallback`이 적용되었는가?
+  - [ ] Context가 필요한 범위에만 적용되어 있는가?
+
+---
+
+## Check 6: Lighthouse 실측 점검
+
+코드 분석만으로는 실제 점수를 확인할 수 없다. 아래 방법으로 실측을 안내한다.
+
+**브라우저 직접 측정 (권장):**
+1. Chrome DevTools → Lighthouse 탭 → "Performance" 선택 → "Analyze page load" 실행
+2. Incognito 모드에서 실행 (확장 프로그램 영향 제거)
+3. Mobile / Desktop 각각 측정
+
+**CLI 측정:**
+```bash
+# Lighthouse CLI 설치 및 실행
+npx lighthouse http://localhost:3000 --view --output=html
+```
+
+**측정 결과 기록 위치:** `docs/05_QA_Validation/` 에 `PERFORMANCE_REPORT.md` 로 저장한다.
+
+---
+
+## 보고 형식
+
+```
+## 성능 점검 결과
+
+### Lighthouse 목표 대비 현황
+| 지표 | 목표 | 현재 | 상태 |
+|------|:----:|:----:|:----:|
+| Performance Score | 90+ | - | 실측 필요 |
+| LCP | ≤ 2.5s | - | 실측 필요 |
+| CLS | ≤ 0.1 | - | 실측 필요 |
+
+### PASS 항목
+- (문제 없는 체크 요약)
+
+### 개선 필요 항목
+| 위치 | 체크 영역 | 내용 | 예상 영향 |
+|------|-----------|------|:---------:|
+| src/pages/Home.tsx | 이미지 최적화 | <img> 직접 사용, LCP 지연 가능성 | LCP |
+| src/app/layout.tsx | 폰트 최적화 | Google Fonts <link> 직접 로드 | CLS·FCP |
+
+### 수정 권장 우선순위
+1. [높음] ...
+2. [중] ...
+3. [낮음] ...
+```
+
+---
+
+## Exceptions
+
+1. **관리자 페이지**: 내부 사용자 전용 페이지는 Performance 70+ 기준을 적용한다.
+2. **대형 에디터·지도 컴포넌트**: 라이브러리 특성상 번들이 큰 경우, `next/dynamic`으로 lazy load 처리 후 패스 처리한다.
+3. **개발 환경 측정값**: Lighthouse는 반드시 `npm run build && npm start` 이후 프로덕션 빌드 기준으로 측정한다. 개발 서버(`npm run dev`) 측정값은 참고용으로만 사용한다.
+
+---
+
+## 관련 스킬
+
+- `verify-code`: 코드 품질 전반 리뷰
+- `verify-security`: 보안 취약점 점검
+- `rules-dev`: 렌더링 전략·코드 스플리팅 컨벤션 기준
+- `verify-implementation`: 전체 verify-* 통합 실행 시 포함 대상

package/verify-security/SKILL.md

@@ -0,0 +1,205 @@
+---
+name: verify-security
+description: 코드베이스의 보안 취약점을 점검합니다. OWASP Top 10 기준으로 인증·인가, 입력 검증, 시크릿 노출, SQL/XSS/CSRF 등 핵심 보안 이슈를 체계적으로 검증합니다. 보안 점검 요청, PR 전 보안 리뷰, 또는 "보안 확인해줘" 요청 시 사용합니다.
+argument-hint: "[선택사항: 점검할 파일 경로, 기능명, 또는 집중 영역(예: auth, api, db)]"
+---
+
+# 보안 점검 스킬 (verify-security)
+
+OWASP Top 10 및 프로젝트 공통 보안 기준에 따라 코드베이스의 보안 취약점을 검증합니다. 발견된 이슈를 심각도와 함께 보고하고 수정 방향을 제시합니다.
+
+---
+
+## 실행 시점
+
+- PR 전 보안 최종 검토
+- 인증·인가·API·DB 관련 코드 변경 후
+- 새 외부 입력 처리 경로(폼, URL 파라미터, 파일 업로드) 추가 시
+- `rules-workflow` Step 7 (버그·크리티컬·보안 검토) 수행 시
+- "보안 점검해줘", "취약점 확인해줘" 요청 시
+
+---
+
+## Step 0: 점검 범위 확정
+
+인자가 주어진 경우 해당 영역에 집중한다. 없으면 아래 명령으로 변경 파일을 확인하고 보안 관련 파일(auth, api, middleware, db, env)을 우선 점검한다.
+
+```bash
+git diff --name-only HEAD
+```
+
+보안 관련 파일 빠른 탐색:
+```bash
+# 인증·인가 관련
+grep -rn "session\|token\|cookie\|jwt\|auth" src/ --include="*.ts" --include="*.tsx" -l
+
+# 환경변수·시크릿 관련
+grep -rn "process\.env\|NEXT_PUBLIC_" src/ --include="*.ts" --include="*.tsx" -l
+
+# DB 쿼리 관련
+grep -rn "sql\|query\|execute\|prepare" src/ --include="*.ts" -l
+```
+
+---
+
+## Check 1: 시크릿 및 민감 정보 노출
+
+**OWASP A02: Cryptographic Failures**
+
+- 소스코드에 API 키, 비밀번호, JWT 시크릿 등이 하드코딩되어 있는지 확인한다.
+- `NEXT_PUBLIC_` 접두어가 붙은 환경변수에 민감 정보가 포함되어 있는지 확인한다 (클라이언트에 노출됨).
+- `.env*` 파일이 `.gitignore`에 포함되어 있는지 확인한다.
+
+```bash
+# 하드코딩 시크릿 탐지
+grep -rn "sk-\|API_KEY\|SECRET\|PASSWORD\|private_key" src/ --include="*.ts" --include="*.tsx"
+grep -rn "NEXT_PUBLIC_.*SECRET\|NEXT_PUBLIC_.*KEY\|NEXT_PUBLIC_.*TOKEN" src/
+```
+
+- 체크:
+  - [ ] 코드에 하드코딩된 시크릿이 없는가?
+  - [ ] 민감 정보가 `NEXT_PUBLIC_` 환경변수에 없는가?
+  - [ ] `.env*`가 `.gitignore`에 포함되어 있는가?
+
+---
+
+## Check 2: 인증 및 인가
+
+**OWASP A01: Broken Access Control**
+
+- 보호된 API 라우트·페이지에서 세션/토큰 검증이 수행되는지 확인한다.
+- 사용자 ID, 역할(role)을 클라이언트 파라미터로 받아 신뢰하지 않는지 확인한다 (서버에서 세션 기반으로 결정해야 함).
+- 관리자 전용 기능에 역할 검증이 적용되어 있는지 확인한다.
+- 체크:
+  - [ ] 모든 보호 라우트에 인증 미들웨어·검증이 있는가?
+  - [ ] 역할·권한을 서버 세션에서 결정하는가? (클라이언트 파라미터 신뢰 금지)
+  - [ ] 인증되지 않은 요청이 데이터를 반환하지 않는가?
+
+---
+
+## Check 3: 입력 검증 및 XSS
+
+**OWASP A03: Injection / A07: XSS**
+
+- 외부 입력(폼, URL 파라미터, 헤더)에 Zod 등 스키마 검증이 적용되었는지 확인한다.
+- `dangerouslySetInnerHTML` 사용 여부를 확인하고 입력값이 그대로 주입되지 않는지 점검한다.
+- URL 파라미터를 URL 생성이나 리다이렉트에 사용할 때 검증 없이 넣지 않는지 확인한다.
+
+```bash
+grep -rn "dangerouslySetInnerHTML" src/ --include="*.tsx"
+grep -rn "innerHTML\|document\.write" src/ --include="*.ts" --include="*.tsx"
+```
+
+- 체크:
+  - [ ] 모든 외부 입력에 런타임 스키마 검증이 적용되었는가?
+  - [ ] `dangerouslySetInnerHTML` 사용 시 값이 sanitize되었는가?
+  - [ ] XSS 주입이 가능한 경로가 없는가?
+
+---
+
+## Check 4: SQL 인젝션 및 DB 안전성
+
+**OWASP A03: Injection**
+
+- 사용자 입력을 SQL 쿼리 문자열에 직접 삽입하는지 확인한다. ORM(Drizzle 등)의 파라미터 바인딩을 사용해야 한다.
+- Raw query 사용 시 파라미터가 바인딩 방식으로 전달되는지 점검한다.
+- 삭제·대량 업데이트 쿼리에 `WHERE` 조건이 누락되지 않았는지 확인한다.
+
+```bash
+grep -rn "sql\`\|execute(\|query(" src/ --include="*.ts" -A 3
+```
+
+- 체크:
+  - [ ] 사용자 입력이 쿼리 문자열에 직접 삽입되지 않는가?
+  - [ ] Raw query 사용 시 파라미터 바인딩이 적용되었는가?
+  - [ ] 삭제·업데이트 쿼리에 WHERE 조건이 있는가?
+
+---
+
+## Check 5: CSRF 및 API 보안
+
+**OWASP A01: Broken Access Control**
+
+- 상태 변경(POST/PUT/DELETE) API에 CSRF 토큰 또는 SameSite 쿠키 설정이 적용되어 있는지 확인한다.
+- API 라우트에서 HTTP 메서드 제한이 적용되어 있는지 확인한다 (GET 라우트가 쓰기 동작을 하지 않는가).
+- Rate limiting이 없는 인증·OTP·비밀번호 변경 API가 있는지 확인한다.
+- 체크:
+  - [ ] 상태 변경 API에 CSRF 방어가 적용되었는가?
+  - [ ] GET 라우트가 데이터를 변경하지 않는가?
+  - [ ] 민감 API에 rate limiting이 적용되었는가?
+
+---
+
+## Check 6: 의존성 취약점
+
+**OWASP A06: Vulnerable and Outdated Components**
+
+- 알려진 취약점이 있는 패키지가 있는지 확인한다.
+
+```bash
+npm audit --audit-level=high
+```
+
+- 체크:
+  - [ ] `npm audit` 결과 high/critical 취약점이 없는가?
+  - [ ] 사용하지 않는 패키지가 정리되었는가?
+
+---
+
+## Check 7: 로깅 및 에러 노출
+
+**OWASP A09: Security Logging and Monitoring Failures**
+
+- 에러 응답에 스택 트레이스, DB 쿼리, 내부 경로 등 민감 정보가 포함되지 않는지 확인한다.
+- 클라이언트에 반환하는 에러 메시지가 내부 구현을 노출하지 않는지 점검한다.
+
+```bash
+grep -rn "catch.*console\|catch.*res\.json\|catch.*res\.send" src/ --include="*.ts" -A 2
+```
+
+- 체크:
+  - [ ] 에러 응답에 스택 트레이스가 포함되지 않는가?
+  - [ ] 에러 메시지가 내부 구현을 노출하지 않는가?
+
+---
+
+## 보고 형식
+
+점검 결과는 다음 형식으로 보고한다:
+
+```
+## 보안 점검 결과
+
+### PASS 항목
+- (문제 없는 체크 요약)
+
+### 취약점 발견 항목
+| 위치 | OWASP | 내용 | 심각도 |
+|------|-------|------|:------:|
+| src/api/user.ts:30 | A01 | 역할 검증 없이 관리자 데이터 반환 | 높음 |
+| src/components/Post.tsx:12 | A03 | dangerouslySetInnerHTML에 미검증 값 삽입 | 높음 |
+| .env.local | A02 | .gitignore 미등록 | 높음 |
+
+### 수정 방향
+1. [높음] ...
+2. [중] ...
+```
+
+심각도 기준: **높음** (즉시 수정 필요, 배포 차단) / **중** (배포 전 수정 권장) / **낮음** (보완 권장)
+
+---
+
+## Exceptions
+
+1. **Third-party auth providers**: NextAuth, Clerk 등 외부 인증 라이브러리의 내부 구현은 점검 대상에서 제외한다.
+2. **개발 환경 전용 코드**: `NODE_ENV === 'development'` 조건 내 디버그 로그는 심각도 낮음으로 처리한다.
+3. **의도적 Public 엔드포인트**: 인증 없이 공개된 API가 설계상 의도된 경우, AGENTS.md 또는 API_SPECS.md에 명시된 근거가 있으면 패스 처리한다.
+
+---
+
+## 관련 스킬
+
+- `verify-code`: 보안 외 코드 품질 전반 리뷰
+- `rules-dev`: 환경변수·DB 안전성 컨벤션 기준
+- `rules-workflow`: Step 7 보안 검토와 연동
+- `verify-implementation`: 전체 verify-* 통합 실행 시 포함 대상

package/design-md/README.md

@@ -1,34 +0,0 @@
-# Stitch Design System Documentation Skill
-
-## Install
-
-```bash
-npx add-skill google-labs-code/stitch-skills --skill design-md --global
-```
-
-## Example Prompt
-
-```text
-Analyze my Furniture Collection project's Home screen and generate a comprehensive DESIGN.md file documenting the design system.
-```
-
-## Skill Structure
-
-This repository follows the **Agent Skills** open standard. Each skill is self-contained with its own logic, workflow, and reference materials.
-
-```text
-design-md/
-├── SKILL.md           — Core instructions & workflow
-├── examples/          — Sample DESIGN.md outputs
-└── README.md          — This file
-```
-
-## How it Works
-
-When activated, the agent follows a structured design analysis pipeline:
-
-1. **Retrieval**: Uses the Stitch MCP Server to fetch project screens, HTML code, and design metadata.
-2. **Extraction**: Identifies design tokens including colors, typography, spacing, and component patterns.
-3. **Translation**: Converts technical CSS/Tailwind values into descriptive, natural design language.
-4. **Synthesis**: Generates a comprehensive DESIGN.md following the semantic design system format.
-5. **Alignment**: Ensures output follows Stitch Effective Prompting Guide principles for optimal screen generation.

package/design-md/SKILL.md

@@ -1,172 +0,0 @@
----
-name: design-md
-description: Analyze Stitch projects and synthesize a semantic design system into DESIGN.md files
-allowed-tools:
-  - "stitch*:*"
-  - "Read"
-  - "Write"
-  - "web_fetch"
----
-
-# Stitch DESIGN.md Skill
-
-You are an expert Design Systems Lead. Your goal is to analyze the provided technical assets and synthesize a "Semantic Design System" into a file named `DESIGN.md`.
-
-## Overview
-
-This skill helps you create `DESIGN.md` files that serve as the "source of truth" for prompting Stitch to generate new screens that align perfectly with existing design language. Stitch interprets design through "Visual Descriptions" supported by specific color values.
-
-## Prerequisites
-
-- Access to the Stitch MCP Server
-- A Stitch project with at least one designed screen
-- Access to the Stitch Effective Prompting Guide: https://stitch.withgoogle.com/docs/learn/prompting/
-
-## The Goal
-
-The `DESIGN.md` file will serve as the "source of truth" for prompting Stitch to generate new screens that align perfectly with the existing design language. Stitch interprets design through "Visual Descriptions" supported by specific color values.
-
-## Retrieval and Networking
-
-To analyze a Stitch project, you must retrieve screen metadata and design assets using the Stitch MCP Server tools:
-
-1. **Namespace discovery**: Run `list_tools` to find the Stitch MCP prefix. Use this prefix (e.g., `mcp_stitch:`) for all subsequent calls.
-
-2. **Project lookup** (if Project ID is not provided):
-   - Call `[prefix]:list_projects` with `filter: "view=owned"` to retrieve all user projects
-   - Identify the target project by title or URL pattern
-   - Extract the Project ID from the `name` field (e.g., `projects/13534454087919359824`)
-
-3. **Screen lookup** (if Screen ID is not provided):
-   - Call `[prefix]:list_screens` with the `projectId` (just the numeric ID, not the full path)
-   - Review screen titles to identify the target screen (e.g., "Home", "Landing Page")
-   - Extract the Screen ID from the screen's `name` field
-
-4. **Metadata fetch**: 
-   - Call `[prefix]:get_screen` with both `projectId` and `screenId` (both as numeric IDs only)
-   - This returns the complete screen object including:
-     - `screenshot.downloadUrl` - Visual reference of the design
-     - `htmlCode.downloadUrl` - Full HTML/CSS source code
-     - `width`, `height`, `deviceType` - Screen dimensions and target platform
-     - Project metadata including `designTheme` with color and style information
-
-5. **Asset download**:
-   - Use `web_fetch` or `read_url_content` to download the HTML code from `htmlCode.downloadUrl`
-   - Optionally download the screenshot from `screenshot.downloadUrl` for visual reference
-   - Parse the HTML to extract Tailwind classes, custom CSS, and component patterns
-
-6. **Project metadata extraction**:
-   - Call `[prefix]:get_project` with the project `name` (full path: `projects/{id}`) to get:
-     - `designTheme` object with color mode, fonts, roundness, custom colors
-     - Project-level design guidelines and descriptions
-     - Device type preferences and layout principles
-
-## Analysis & Synthesis Instructions
-
-### 1. Extract Project Identity (JSON)
-- Locate the Project Title
-- Locate the specific Project ID (e.g., from the `name` field in the JSON)
-
-### 2. Define the Atmosphere (Image/HTML)
-Evaluate the screenshot and HTML structure to capture the overall "vibe." Use evocative adjectives to describe the mood (e.g., "Airy," "Dense," "Minimalist," "Utilitarian").
-
-### 3. Map the Color Palette (Tailwind Config/JSON)
-Identify the key colors in the system. For each color, provide:
-- A descriptive, natural language name that conveys its character (e.g., "Deep Muted Teal-Navy")
-- The specific hex code in parentheses for precision (e.g., "#294056")
-- Its specific functional role (e.g., "Used for primary actions")
-
-### 4. Translate Geometry & Shape (CSS/Tailwind)
-Convert technical `border-radius` and layout values into physical descriptions:
-- Describe `rounded-full` as "Pill-shaped"
-- Describe `rounded-lg` as "Subtly rounded corners"
-- Describe `rounded-none` as "Sharp, squared-off edges"
-
-### 5. Describe Depth & Elevation
-Explain how the UI handles layers. Describe the presence and quality of shadows (e.g., "Flat," "Whisper-soft diffused shadows," or "Heavy, high-contrast drop shadows").
-
-## Output Guidelines
-
-- **Language:** Use descriptive design terminology and natural language exclusively
-- **Format:** Generate a clean Markdown file following the structure below
-- **Precision:** Include exact hex codes for colors while using descriptive names
-- **Context:** Explain the "why" behind design decisions, not just the "what"
-
-## Output Format (DESIGN.md Structure)
-
-```markdown
-# Design System: [Project Title]
-**Project ID:** [Insert Project ID Here]
-
-## 1. Visual Theme & Atmosphere
-(Description of the mood, density, and aesthetic philosophy.)
-
-## 2. Color Palette & Roles
-(List colors by Descriptive Name + Hex Code + Functional Role.)
-
-## 3. Typography Rules
-(Description of font family, weight usage for headers vs. body, and letter-spacing character.)
-
-## 4. Component Stylings
-* **Buttons:** (Shape description, color assignment, behavior).
-* **Cards/Containers:** (Corner roundness description, background color, shadow depth).
-* **Inputs/Forms:** (Stroke style, background).
-
-## 5. Layout Principles
-(Description of whitespace strategy, margins, and grid alignment.)
-```
-
-## Usage Example
-
-To use this skill for the Furniture Collection project:
-
-1. **Retrieve project information:**
-   ```
-   Use the Stitch MCP Server to get the Furniture Collection project
-   ```
-
-2. **Get the Home page screen details:**
-   ```
-   Retrieve the Home page screen's code, image, and screen object information
-   ```
-
-3. **Reference best practices:**
-   ```
-   Review the Stitch Effective Prompting Guide at:
-   https://stitch.withgoogle.com/docs/learn/prompting/
-   ```
-
-4. **Analyze and synthesize:**
-   - Extract all relevant design tokens from the screen
-   - Translate technical values into descriptive language
-   - Organize information according to the DESIGN.md structure
-
-5. **Generate the file:**
-   - Create `DESIGN.md` in the project directory
-   - Follow the prescribed format exactly
-   - Ensure all color codes are accurate
-   - Use evocative, designer-friendly language
-
-## Best Practices
-
-- **Be Descriptive:** Avoid generic terms like "blue" or "rounded." Use "Ocean-deep Cerulean (#0077B6)" or "Gently curved edges"
-- **Be Functional:** Always explain what each design element is used for
-- **Be Consistent:** Use the same terminology throughout the document
-- **Be Visual:** Help readers visualize the design through your descriptions
-- **Be Precise:** Include exact values (hex codes, pixel values) in parentheses after natural language descriptions
-
-## Tips for Success
-
-1. **Start with the big picture:** Understand the overall aesthetic before diving into details
-2. **Look for patterns:** Identify consistent spacing, sizing, and styling patterns
-3. **Think semantically:** Name colors by their purpose, not just their appearance
-4. **Consider hierarchy:** Document how visual weight and importance are communicated
-5. **Reference the guide:** Use language and patterns from the Stitch Effective Prompting Guide
-
-## Common Pitfalls to Avoid
-
-- ❌ Using technical jargon without translation (e.g., "rounded-xl" instead of "generously rounded corners")
-- ❌ Omitting color codes or using only descriptive names
-- ❌ Forgetting to explain functional roles of design elements
-- ❌ Being too vague in atmosphere descriptions
-- ❌ Ignoring subtle design details like shadows or spacing patterns