프리셋 예시

# 프로젝트 목적
- 프로젝트 이름: Next.js 정적 export
- 목적: 명시적인 에이전트 규칙을 갖춘 집중형 Next.js 정적 코드베이스를 생성하고 유지합니다.
- 프리셋: nextjs-static
- 주요 런타임: TypeScript + Next.js App Router
- 패키지 매니저: npm

# 핵심 제약 사항
- API routes, server actions, middleware를 추가하지 않습니다.
- 원격 AI 호출이나 저장소 자동 스캔을 추가하지 않습니다.
- 편의 기능 때문에 static export 제약을 완화하지 않습니다.

# 설정 및 검증 명령어
- 설치: `npm install`
- 개발: `npm run dev`
- 린트: `npm run lint`
- 타입체크: `npm run typecheck`
- 빌드: `npm run build`
- 테스트: `npm run test`

## 테스트 지침
- Markdown 섹션 순서와 생략 동작은 Vitest로 검증합니다.
- 누락된 규칙, 중복 명령, placeholder 텍스트 같은 lint 휴리스틱은 테스트로 덮습니다.

# 코드 규칙
- TypeScript strict mode를 유지하고 export되는 타입은 명시적으로 작성합니다.
- 생성 및 린트 로직은 결정적이고 부작용 없이 유지합니다.
- 무거운 추상화보다 작은 컴포넌트와 plain CSS를 우선합니다.

# 안전 규칙
- 모든 draft 데이터는 브라우저 메모리와 localStorage에만 보관합니다.
- 런타임 원격 fetch, cookies, auth, analytics SDK를 추가하지 않습니다.

# Git 워크플로 규칙
## 커밋 규칙
- Conventional Commits를 사용합니다.
- lint, typecheck, test, build가 모두 통과한 뒤에만 커밋합니다.

## 브랜치 규칙
- 기본 브랜치에서 파생한 feature 또는 fix 브랜치에서 비사소한 작업을 진행합니다.
- 브랜치 하나에는 논리적 작업 단위 하나만 담습니다.

## 풀 리퀘스트 규칙
- 변경된 프리셋 또는 라우트 동작을 요약하고 검증 명령을 함께 적습니다.
- SEO, localStorage, static export 영향이 있으면 명시합니다.

# 디렉터리 및 아키텍처 메모
- 라우트는 /app, 재사용 UI는 /components, 정적 프리셋 및 템플릿 텍스트는 /content, 순수 생성 및 린트 헬퍼는 /lib에 둡니다. 모든 라우트에서 static export 호환성을 유지하세요.

# 선택 프로젝트 메모
- 랜딩 페이지 CTA는 `/?preset=nextjs-static` 같은 query-param 진입점을 우선 사용합니다.

# 프로젝트 목적
- 프로젝트 이름: Vite React 앱
- 목적: 명시적인 에이전트 규칙을 갖춘 집중형 Vite React 코드베이스를 생성하고 유지합니다.
- 프리셋: vite-react
- 주요 런타임: TypeScript + React + Vite
- 패키지 매니저: npm

# 핵심 제약 사항
- 백엔드 proxy endpoint나 hosted prompt service를 추가하지 않습니다.
- 승인 없이 전역 상태 라이브러리를 추가하지 않습니다.
- 단순 구조화 입력에 form framework를 도입하지 않습니다.

# 설정 및 검증 명령어
- 설치: `npm install`
- 개발: `npm run dev`
- 린트: `npm run lint`
- 타입체크: `npm run typecheck`
- 빌드: `npm run build`
- 테스트: `npm run test`

## 테스트 지침
- 결정적인 builder와 linter는 UI shell과 분리해서 테스트합니다.
- 무거운 snapshot보다 작고 fixture 중심인 테스트를 우선합니다.

# 코드 규칙
- strict TypeScript를 사용하고 export되는 컴포넌트의 props는 명시적으로 작성합니다.
- 브라우저 전용 상태는 client hooks에 두고, 순수 텍스트 생성은 utilities로 분리합니다.
- 작은 UI 흐름은 과도하게 추상화하지 않습니다.

# 안전 규칙
- 사용자 입력 데이터는 브라우저 저장소에만 둡니다.
- telemetry, tracking pixel, 런타임 데이터 동기화를 추가하지 않습니다.

# Git 워크플로 규칙
## 커밋 규칙
- Conventional Commits를 사용합니다.
- 커밋은 기능 하나 또는 버그 수정 하나에만 집중합니다.

## 브랜치 규칙
- 동작 변경은 `feature/` 또는 `fix/` 브랜치에서 진행합니다.
- 서로 무관한 UI 변경과 로직 변경을 한 브랜치에 섞지 않습니다.

## 풀 리퀘스트 규칙
- 프리셋 또는 lint 가이드를 왜 바꿨는지 설명합니다.
- 시각적 동작이 바뀌면 직접 확인한 UI 경로를 적습니다.

# 디렉터리 및 아키텍처 메모
- 엔트리 wiring은 /src/main 근처에 두고, 기능별 UI는 도메인별로 묶고, 공용 컴포넌트는 쉽게 찾을 수 있게 유지하며, 순수 유틸리티는 브라우저 의존 hook과 분리합니다.

# 선택 프로젝트 메모
- 드래그 앤 드롭 빌더보다 plain inputs와 반복 가능한 row 구성을 우선합니다.

# 프로젝트 목적
- 프로젝트 이름: Chrome 확장 프로그램 MV3
- 목적: 명시적인 에이전트 규칙을 갖춘 집중형 Chrome 확장 코드베이스를 생성하고 유지합니다.
- 프리셋: chrome-extension-mv3
- 주요 런타임: TypeScript + Chrome Extension Manifest V3
- 패키지 매니저: npm

# 핵심 제약 사항
- 원격 코드 로딩이나 eval류 동작을 추가하지 않습니다.
- 기능에 필요한 범위를 넘는 host permissions를 요청하지 않습니다.
- 권한 변경을 무관한 커밋 속에 숨기지 않습니다.

# 설정 및 검증 명령어
- 설치: `npm install`
- 개발: `npm run dev`
- 린트: `npm run lint`
- 타입체크: `npm run typecheck`
- 빌드: `npm run build:extension`
- 테스트: `npm run test`

## 테스트 지침
- manifest에 민감한 builder나 guard는 unit test로 검증합니다.
- 명령어나 surface가 바뀌면 permission 관련 lint 규칙도 함께 검증합니다.

# 코드 규칙
- 확장 권한은 최소한으로, 그리고 명시적으로 유지합니다.
- 브라우저 API wrapper는 view components와 분리합니다.
- 각 스크립트가 어떤 extension context에서 실행되는지 문서화합니다.

# 안전 규칙
- 원격 스크립트나 원격 config fetch를 추가하지 않습니다.
- 확장 권한과 저장소 사용 범위는 최소한으로 유지합니다.

# Git 워크플로 규칙
## 커밋 규칙
- Conventional Commits를 사용합니다.
- manifest 또는 권한 변경이 있으면 필요 시 commit body에서 분명히 밝힙니다.

## 브랜치 규칙
- popup, content script, manifest 변경은 분리된 브랜치에서 진행합니다.
- 권한 변경과 무관한 UX polish를 한 브랜치에 묶지 않습니다.

## 풀 리퀘스트 규칙
- manifest 또는 권한 변경은 요약 상단에서 먼저 드러냅니다.
- 직접 확인한 extension surface를 목록으로 적습니다.

# 디렉터리 및 아키텍처 메모
- popup, options, background, content script surface를 명확히 분리하고, manifest 생성 및 권한 선언은 쉽게 감사할 수 있게 유지합니다.

# 선택 프로젝트 메모
- 생성되는 AGENTS 규칙에는 popup, background, content-script 경계를 분명히 적습니다.

# 프로젝트 목적
- 프로젝트 이름: TypeScript Node CLI
- 목적: 명시적인 에이전트 규칙을 갖춘 집중형 Node CLI 코드베이스를 생성하고 유지합니다.
- 프리셋: node-cli-ts
- 주요 런타임: TypeScript + Node.js CLI
- 패키지 매니저: npm

# 핵심 제약 사항
- 백그라운드 서비스나 daemon을 추가하지 않습니다.
- 핵심 동작을 hosted API에 의존하게 만들지 않습니다.
- 파일 쓰기나 파괴적 명령에서 검증을 우회하지 않습니다.

# 설정 및 검증 명령어
- 설치: `npm install`
- 개발: `npm run dev`
- 린트: `npm run lint`
- 타입체크: `npm run typecheck`
- 빌드: `npm run build`
- 테스트: `npm run test`

## 테스트 지침
- builder와 linter는 순수 함수로 테스트합니다.
- 동작이 바뀌면 명령 파싱이나 출력 포맷에 대한 fixture 크기의 테스트를 추가합니다.

# 코드 규칙
- CLI 부작용은 명시적이고 추적 가능하게 유지합니다.
- 순수 헬퍼는 내부에서 출력하지 말고 구조화된 결과를 반환합니다.
- 큰 switch 기반 엔트리포인트보다 작은 command 모듈을 선호합니다.

# 안전 규칙
- 검증되지 않은 입력을 그대로 shell execution에 사용하지 않습니다.
- CLI 흐름에 숨겨진 네트워크 호출이나 telemetry를 넣지 않습니다.

# Git 워크플로 규칙
## 커밋 규칙
- Conventional Commits를 사용합니다.
- 커밋은 명령 하나 또는 출력 동작 하나에만 집중합니다.

## 브랜치 규칙
- CLI 동작 변경은 `feature/` 또는 `fix/` 브랜치에서 진행합니다.
- 서로 무관한 명령 변경을 한 브랜치에 모으지 않습니다.

## 풀 리퀘스트 규칙
- 영향받는 CLI 명령과 검증 명령을 정확히 적습니다.
- 파일시스템 또는 출력 형식 변경이 있으면 분명히 밝힙니다.

# 디렉터리 및 아키텍처 메모
- 명령 엔트리포인트는 작게 유지하고, 인자 파싱 및 검증은 CLI 경계 근처에 두며, 텍스트 포맷팅과 파일시스템 로직은 가능하면 순수 유틸리티로 분리합니다.

# 선택 프로젝트 메모
- CLI 저장소는 스캔하기 쉬운 AGENTS 파일이 특히 중요하므로, 짧고 명령형인 가이드를 유지합니다.

# 프로젝트 목적
- 프로젝트 이름: Python CLI
- 목적: 명시적인 에이전트 규칙을 갖춘 집중형 Python CLI 코드베이스를 생성하고 유지합니다.
- 프리셋: python-cli
- 주요 런타임: Python CLI
- 패키지 매니저: uv

# 핵심 제약 사항
- 웹 백엔드, auth, hosted sync 기능을 추가하지 않습니다.
- 핵심 흐름에 숨겨진 네트워크 접근을 넣지 않습니다.
- 결정적 builder를 AI 생성으로 대체하지 않습니다.

# 설정 및 검증 명령어
- 설치: `uv sync`
- 개발: `uv run python -m your_package`
- 린트: `uv run ruff check .`
- 타입체크: `uv run pyright`
- 빌드: `uv run python -m build`
- 테스트: `uv run pytest`

## 테스트 지침
- builder와 linter 회귀 케이스는 pytest로 검증합니다.
- fixture는 작고 결정적으로 유지합니다.

# 코드 규칙
- 타입이 있는 함수와 명시적인 반환값을 선호합니다.
- CLI 파싱은 엔트리포인트 근처에 두고 비즈니스 로직은 모듈로 이동합니다.
- 숨은 전역 상태나 환경 의존 기본값을 피합니다.

# 안전 규칙
- 사용자 콘텐츠를 원격 API로 보내지 않습니다.
- 파일시스템과 subprocess 입력은 사용 전에 검증합니다.

# Git 워크플로 규칙
## 커밋 규칙
- Conventional Commits를 사용합니다.
- Python 환경 또는 패키징 변경은 기능 작업과 분리합니다.

## 브랜치 규칙
- 집중된 feature 또는 fix 브랜치에서 작업합니다.
- CLI UX 변경과 패키징 개편을 한 브랜치에 섞지 않습니다.

## 풀 리퀘스트 규칙
- 검증에 사용한 `uv` 명령을 적습니다.
- 패키징 또는 엔트리포인트 변경을 분명히 밝힙니다.

# 디렉터리 및 아키텍처 메모
- 패키지 코드는 하나의 import root 아래에 두고, CLI 엔트리포인트는 얇게 유지하며, 포맷팅과 파싱 헬퍼는 빠른 단위 테스트가 가능할 만큼 순수하게 유지합니다.

# 선택 프로젝트 메모
- 최종 export 전에 `your_package` 같은 placeholder 모듈명은 실제 이름으로 바꿉니다.