# 레포의 AI 기능을 위한 LangGPT 스타일 프롬프트 라이브러리 ## 개요 이 라이브러리는 레포지토리의 AI 기반 기능을 위해 설계된 LangGPT 스타일 프롬프트 템플릿 모음입니다. 각 프롬프트는 구조화된 역할, 목표, 제약 조건, 출력 형식을 따르며, 일관되고 재사용 가능한 방식으로 LLM과 상호작용하도록 돕습니다. ## 프롬프트 구조 모든 프롬프트는 다음 섹션을 포함합니다: - **Role**: AI가 수행할 역할 - **Profile**: 역할의 배경과 전문성 - **Goals**: 달성해야 할 목표 - **Constraints**: 준수해야 할 제약 조건 - **Output Format**: 기대되는 출력 형식 - **Workflow**: 작업 수행 단계 ## 프롬프트 템플릿 ### 1. 코드 리뷰 어시스턴트 ``` # Role: 시니어 코드 리뷰어 ## Profile - Language: TypeScript, Python - Description: 보안, 성능, 유지보수성을 중시하는 시니어 엔지니어 ## Goals 1. 코드 변경 사항의 잠재적 버그 식별 2. 보안 취약점 탐지 3. 성능 개선 제안 4. 가독성 및 유지보수성 피드백 제공 ## Constraints - 건설적이고 구체적인 피드백 제공 - 심각도(높음/중간/낮음)로 이슈 분류 - 스타일 선호도보다 실제 문제에 집중 ## Output Format - 요약 - 이슈 목록 (심각도, 위치, 설명, 제안) - 승인 여부 ``` ### 2. 문서 생성기 ``` # Role: 기술 문서 작성자 ## Profile - Description: 개발자를 위한 명확하고 간결한 문서를 작성하는 전문가 ## Goals 1. 공개 API에 대한 사용 예제 생성 2. 함수 및 클래스 문서화 3. README 및 가이드 작성 ## Constraints - 실제 동작하는 코드 예제만 포함 - 간결하고 실용적인 설명 유지 - 기존 문서 스타일과 일관성 유지 ## Output Format - Markdown 형식 - 코드 블록에 언어 명시 ``` ### 3. 이슈 분류기 ``` # Role: 이슈 트리아지 어시스턴트 ## Profile - Description: GitHub 이슈를 분석하고 분류하는 도우미 ## Goals 1. 이슈 유형 분류 (버그, 기능 요청, 질문, 문서) 2. 우선순위 제안 3. 관련 레이블 추천 4. 중복 가능성 표시 ## Constraints - 추측이 아닌 이슈 내용에 근거 - 불확실한 경우 명시 ## Output Format - 유형 - 우선순위 - 레이블 - 요약 ``` ### 4. RAG 기반 Q&A 어시스턴트 ``` # Role: 레포지토리 지식 어시스턴트 ## Profile - Description: 레포지토리 문서와 코드베이스를 기반으로 질문에 답변 ## Goals 1. 제공된 컨텍스트 내에서 정확한 답변 제공 2. 관련 파일 및 라인 참조 3. 컨텍스트에 없는 내용은 명확히 표시 ## Constraints - 제공된 컨텍스트만 사용 - 출처 인용 필수 - 추측 금지 ## Output Format - 답변 - 출처 (파일 경로, 라인 번호) ``` ### 5. MCP 도구 설명 생성기 ``` # Role: MCP 도구 문서화 전문가 ## Profile - Description: MCP 서버 도구의 스키마와 설명을 작성 ## Goals 1. 도구 설명 및 파라미터 문서화 2. 사용 예제 생성 3. 에러 케이스 명시 ## Constraints - JSON Schema 형식 준수 - 명확하고 간결한 설명 - 실제 사용 사례 반영 ## Output Format - 도구 이름 - 설명 - 파라미터 스키마 - 예제 ``` ## 사용 가이드 1. **템플릿 선택**: 작업에 맞는 프롬프트 템플릿 선택 2. **컨텍스트 주입**: 레포지토리별 컨텍스트 추가 3. **변수 치환**: 플레이스홀더를 실제 값으로 대체 4. **반복 개선**: 출력 결과를 바탕으로 프롬프트 개선 ## 통합 예시 ```typescript import { loadPrompt } from './prompt-library'; const prompt = loadPrompt('code-review', { language: 'TypeScript', diff: pullRequestDiff, }); const review = await llm.complete(prompt); ``` ## 기여 가이드 - 새로운 프롬프트는 LangGPT 구조 준수 - 각 프롬프트에 테스트 케이스 포함 - 변경 사항은 PR을 통해 제안 - Claude, Cursor 등 다양한 도구와 호환성 유지
README 링크에서 발견 · yesterday
LangGPT를 사용해 저장소의 AI 기능을 위한 재사용 가능한 구조화 프롬프트를 구축했습니다.
What they did
그들은 저장소의 모든 AI 관련 기능이 파일 곳곳에 흩어진 즉흥적인 문자열 대신 일관되고 검토 가능한 프롬프트를 사용하기를 원했다. LangGPT README에서 시작하여 Role/Profile/Goal/Skills/Rules/Workflow/Initialization 템플릿을 하우스 스타일로 채택했다. 세 가지 기능(코드 리뷰 어시스턴트, 체인지로그 작성기, 지원 트리아지 봇)에 대한 프롬프트 초안을 작성한 뒤, 각 초안을 prompt-optimizer로 돌려 문구를 다듬고 모순을 제거하며 명시적인 완료 기준과 비목표를 추가했다. 더 까다로운 역할의 경우 wonderful-prompts의 패턴 — 퓨샷 예시, 출력 스키마, 거부 규칙 — 을 차용하여 새로운 구조를 만들어내는 대신 LangGPT 섹션에 접어 넣었다. 각 프롬프트는 prompts/ 아래에 프런트매터(name, version, owner, model targets)와 함께 마크다운 파일로 저장되었고, 짧은 README가 이들을 호출하는 방법을 설명했다. 또한 프롬프트마다 가벼운 평가 체크리스트를 추가했다: 캐릭터를 유지하는가, 환각을 거부하는가, 출력이 선언된 스키마와 일치하는가. 마지막으로 빌드 시점에 프롬프트 파일을 로드하도록 앱에 연결하여, 제품 코드가 원시 문자열이 아닌 프롬프트 id를 참조하도록 했다.
How it went
그들은 결국 리뷰어들이 코드처럼 diff할 수 있는 작고 버전 관리되는 프롬프트 라이브러리를 갖게 되었다. LangGPT 구조 덕분에 의도가 한눈에 명확해졌고, prompt-optimizer 패스를 통해 모호한 지시문이 눈에 띄게 줄었다. changelog와 triage 프롬프트는 두 번의 반복 후 사용 가능했지만, code-review 프롬프트는 출력이 일관되기까지 더 많은 few-shot 예시가 필요했다. 전반적으로 완성된 제품이라기보다 탄탄한 기반처럼 느껴졌다 — eval 체크리스트는 수동이고, 모델이 바뀌면 프롬프트가 여전히 흔들린다.
Worth knowing
LangGPT는 문서 및 템플릿 프레임워크이지 런타임 라이브러리가 아니므로, 모든 연결과 버전 관리는 직접 구현해야 합니다. prompt-optimizer와 wonderful-prompts는 각자의 관례를 가진 별도의 커뮤니티 리소스이며, 결과는 모델과 언어에 따라 달라집니다. 자동화된 평가 하네스가 포함되어 있지 않으므로 회귀는 눈으로 확인하여 잡아야 합니다. 모델별 특이사항(컨텍스트 제한, 명령 수행 방식의 차이)은 템플릿 자체에서 처리되지 않습니다.
Wiring
1) LangGPT README를 읽고 기본 템플릿을 prompts/_template.md에 복사합니다. 2) prompt/system/messages 문자열을 grep으로 검색해 기존 인라인 프롬프트를 목록화합니다. 3) 템플릿에 각 프롬프트를 작성하고, 기능별로 prompts/ 아래에 파일 하나씩 만듭니다. 4) 초안을 prompt-optimizer에 통과시킨 뒤, 출력이 구조화되어야 하는 곳에서는 wonderful-prompts의 few-shot 및 스키마 패턴을 차용합니다. 5) front-matter(name, version, owner, models)와 프롬프트별 eval 체크리스트를 추가합니다. 6) 빌드 시 prompts/*.md를 읽어 id로 노출하는 작은 로더를 추가합니다. 7) 앱 코드의 인라인 문자열을 prompt-id 조회로 교체합니다. 8) 어떤 프롬프트가 stable이고 어떤 것이 experimental인지 메모와 함께 커밋합니다.
Try it yourself
I can't do this one as specified, and I want to be upfront about why rather than produce something that looks like the work but isn't. **The core problem:** I don't have access to your repository. I can't see the code, so I can't find where prompts are built as raw strings, can't rewrite them faithfully, and can't refactor call sites to load by id. Anything I produced would be invented — fabricated prompt content, fabricated file paths, fabricated refactors. That's worse than nothing, because it would look plausible and you'd have to audit every line to discover none of it matches your code. **What I can do instead:** 1. **If you paste the relevant code** (the files or functions where prompts are constructed), I'll do the full task: identify each prompt, rewrite it in the LangGPT structure you specified, generate the `prompts/<feature>.md` files with front-matter, write `prompts/README.md`, and show the refactor to load-by-id — flagging any prompt that looks broken and listing which ones need few-shot examples. 2. **If you can share the repo contents** (file tree plus the prompt-building files), same as above. 3. **If you want a template first**, I can produce a canonical LangGPT prompt file (with the Role / Profile / Goal / Skills / Rules / Workflow / Initialization sections and the front-matter schema) plus a `prompts/README.md` and a small loader module in TypeScript or Python that resolves prompts by id. You'd then apply it to your actual prompts. This is useful groundwork but is *not* the repo-specific work you asked for, and I'd label it as such. A few things worth deciding before I start, since they affect the refactor: - **Loader design:** file-based (`prompts/<id>.md` read at startup, cached) vs. bundled (imported as strings at build time). The latter is safer for serverless/edge and avoids fs at runtime; the former allows hot-reload in dev. - **Front-matter parsing:** do you already have a YAML parser in the dependency tree, or should the loader stay dependency-free? - **Prompt id convention:** `feature.action` (e.g. `remingle.match_score`) vs. flat names — matters for the README and for how call sites read. - **Behavior parity:** for prompts that are "clearly broken," do you want the fix applied silently, or flagged in a `CHANGELOG`/comment so reviewers can see the diff? Tell me which path you want, and paste the code (or the file tree + prompt files) if you're going with option 1 or 2.