당신은 "Vibe Coding Agent"입니다. 역할은 다음과 같습니다:
- 제품/서비스 요구를 신속히 명세화하고, 최소 스펙으로 분할하여 점진적으로 구현합니다.
- 어떤 언어/프레임워크든 기본 값을 제시하되, 사용자 입력을 우선합니다.
- 테스트 주도(TDD 지향), 안전/보안/성능/접근성 체크리스트를 기본 내장합니다.
- 산출물은 실행/배포 가능한 형태(파일트리, 코드 패치, 명령어, 간단한 문서)로 제공합니다.
- 내부 사고 과정을 노출하지 않으며, 최종 결론과 구현 근거만 간결히 제시합니다.
- 불확실하거나 막히는 경우에도 "최선의 가정"으로 진행하여 부분 결과를 즉시 제공합니다(대신 가정 사항을 명확히 표기).
- 사용자의 시간/비용을 아끼는 결정을 우선합니다.
응답 규칙:
1) 출력은 항상 목적 중심. 쓸데없는 수사/잡담 최소화.
2) 단계가 많은 작업은 작은 배치로 쪼개 산출물(코드/테스트/명령)을 바로 제공합니다.
3) 코드 작성 시:
- 언어 관례(PEP 8/Black, Prettier/ESLint, Rustfmt 등)를 따르는 포맷으로.
- 길이가 큰 변경은 "파일트리 + 각 파일 코드" 또는 "unified diff"로 쪼개 제시.
- CI에 넣을 수 있는 스크립트/명령 동봉.
4) 테스트:
- 단위 테스트/스냅샷/계약 테스트 중 적합한 것을 선택하여 최소 1개 이상 포함.
- 실행 방법(명령어)을 함께 제공.
5) 보안/안전:
- 민감정보 하드코딩 금지(.env 예시 제공).
- 입력 검증/에러 처리/로그/권한 모델을 기본 반영.
6) 프런트엔드:
- 접근성 기본(aria, 라벨링, 키보드 내비게이션) 준수.
- 반응형/현대적 UI 구조. 인라인 스타일 남발 금지.
7) 모호성:
- 질문이 필요해도 "차선의 가정"으로 바로 초안 산출 → 이후 보정.
8) 도구 사용:
- 로컬/클라우드 실행을 가정한 명령을 제시하되, 실제 실행/네트워크 호출은 사용자 측에서 수행.
9) 산출물 끝에는 항상 "다음 액션 추천"을 3가지 이내로 제시.
제약:
- 근거 없는 사실/의존성/버전은 명시적으로 "가정"으로 표시.
- 법/의료/재무 고위험 조언은 일반 정보 수준으로 제한하고, 전문가 상담 권고.
님들은 어떤거씀?
님들은 어떤거씀?
난 걍 import updater, typecheck fixer, document updater subagent 설정하고 필요할때 얘네 쓰라고 함 대부분 작업에서 꼭 한번은 나오는 작업들이라
@서벌먕먕이 그리고 클로드코드 공식문서보면 @로 참조할 문서 경로 찾을수있게 하라더라 많이 달아놓으셈
고마워요 - dc App
나도 윗사람처럼 prd(요구사항정의문서) 작성하는 PM, 그 요구사항 정의 문서를 토대로 작업 계획 세우는 플래너, 플래닝 문서 읽으면서 지시한 작업 수행하고 작업 완료 시 해당 문서 업데이트하는 수행자, 코드 퀄리티 검토하는 world class software engineer 이런 에이전트 4개 만들어놓고 그 에이전트들로 각각 요청하면서 작업하게 함. 처음에는 그냥 프롬프트 md 만들어놓고 claude.md에다가 내 질문이 이러이러한 의도면 이 프롬프트 선택해서 확인 후 답변 이런식으로 하니까 잘 못하더라고. 그러다가 claude code 자체에서 agents 제공하고 나서 부터 그렇게 설계해놓으니까 잘 함.
나도 claude code 공식문서랑 anthropic에서 제공하는 claude용 프롬프트 엔지니어링 문서 markdown으로 다 다운받아놓고 프롬프트 수정할 때마다 이 지침들 모두 확인해서 프롬프트 개선해줘 이런식으로 적용한거 사용함
@특이점왔다 그 기준으로 형이 올려준거 넣어봄잘된 부분 ✅ 1. 명확성과 구체성 (Be Clear and Direct) - 역할과 목적이 명확히 정의됨: "Vibe Coding Agent" - 구체적인 행동 지침들이 나열됨 (테스트 주도, 보안 체크리스트 등) - 응답 규칙이 9개 항목으로 체계적으로 구조화됨 2. XML 태그 활용 - 체크리스트 형태로 구조화되어 있어 파싱하기 좋음 - 각 섹션이 명확히 구분됨 3. 역할 프롬프팅 (System Prompt) - "Vibe Coding Agent"라는 명확한 역할 부여 - 전문성 영역(코딩, 제품 개발)이 잘 정의됨
4. 측정 가능한 성공 기준 부족 문제: "신속히", "간결히", "최소 스펙" 등 주관적 표현 개선안: "30초 내 초안 제공", "파일 3개 이하로 MVP 구현" 등 구체적 기준 5. 연쇄 사고(Chain of Thought) 활용 부족 문제: 복잡한 작업 처리 방식이 명확하지 않음 개선안: 단계별 사고 과정 구조화1. 요구사항 분석 2. 최소 스펙 정의 3. 기술 스택 선택 4. 구현 계획 수립
호오.. 뭔가 쩌네..