Files
arasystem/.claude/agents
ttipo 3c9b3727c6
CI / Backend (lint · type-check · test · e2e · build) (pull_request) Successful in 13m49s
CI / Frontend (lint · type-check · test · build) (pull_request) Successful in 13m45s
CI / Infra (compose · Dockerfile · nginx · 운영 스크립트) (pull_request) Successful in 1m55s
CI / 에러 코드 SSOT 동기화 검사 (pull_request) Successful in 11m12s
docs: 저장소 소개를 ARA SYSTEM 의 지금 구성에 맞게 고치고 로드맵을 더한다
루트 README · CLAUDE.md · 점검 목록이 아직 "풀스택 모노레포 템플릿"으로 소개하고 있었다 — 사내 그룹웨어(메일 운영 중)에 맞게
지금 상태 · 구성(메일 엔진 · 리졸버 · ClamAV · 운영 스크립트 포함) · 문서 지도 · 디렉터리 구조로 다시 쓰고,
백엔드를 호스트에서 npm ci 하라던 옛 안내(컨테이너 안에서만 — 규칙과 반대)를 뺐다.
docs/roadmap.md 에 메일 1~16단계 상태(16단계 첫 항목: 주소록 가져오기 · 내보내기) · 공통 기반 · 2부 · 앱 · 추후 후보 모음을 둔다.
backend · frontend README 는 프레임워크가 만든 영어 안내 대신 이 저장소의 실행 · 검사 · 참고 문서로,
규칙 · 스킬 · 역할 문서의 "템플릿" 표현("템플릿 기본 제공 골격" 등)은 "기본 골격"으로 바꿨다(nginx 설정 템플릿은 그대로).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-09 20:19:20 +09:00
..
2026-10-26 12:28:48 +09:00
2026-10-26 12:28:48 +09:00
2026-10-26 12:28:48 +09:00
2026-10-26 12:28:48 +09:00
2026-10-26 12:28:48 +09:00
2026-10-26 12:28:48 +09:00

에이전트 팀원 규칙

이 디렉터리는 역할(누가 무엇까지 책임지는가) 을 정의한다. 어떻게 만드는가는 .claude/skills/, 무엇을 지키는가는 .claude/rules/ 가 담당한다.

.claude/rules/    무엇을 지키는가   (응답 포맷·에러 코드·보안 …)   — 전원 공통
.claude/skills/   어떻게 만드는가   (nestjs·vue3·flutter·docker)  — 스택별
.claude/agents/   누가 맡는가       (이 디렉터리)                  — 역할별

역할 목록

역할 파일 주 책임 코드 수정
백엔드 개발 backend-dev.md backend/ API·도메인 로직 O
프론트엔드 개발 frontend-dev.md frontend/ 화면·상태·API 연동 O
모바일 개발 mobile-dev.md flutter/ 화면·상태·API 연동 O
테스터 tester.md 테스트 작성·실행, 계약 테스트 유지 O (테스트 한정)
리뷰어 reviewer.md 공유 계약 위반·규칙 드리프트 점검 X
인프라/릴리스 release-ops.md compose·env·마이그레이션·배포 O (인프라 한정)
사용자 관점 persona-user.md 일반 사용자 입장의 수용 기준 검토 X
관리자 관점 persona-admin.md 운영 담당자 입장의 수용 기준 검토 X

호출

"backend-dev 로 사용자 목록 API 추가해줘"
"reviewer 로 지금 변경분 검토해줘"

역할을 지정하지 않으면 평소대로 동작한다. 역할은 필요할 때 부르는 것이지, 모든 작업을 역할로 나눠야 하는 것은 아니다.

전원 공통 규칙

  1. 규칙을 복사하지 않는다. 역할 파일은 규칙을 참조만 한다. 응답 포맷·에러 코드·코딩 규칙의 SSOT 는 .claude/rules/ 와 .claude/skills/ 다. 역할 파일에 같은 내용을 옮겨 적으면 진실 공급원이 둘로 갈라진다 (error-codes 와 같은 이유).
  2. 경계를 넘지 않는다. 담당 범위 밖의 파일이 고쳐져야 한다면, 직접 고치지 말고 무엇이 왜 필요한지 적어 인계한다. 남의 영역을 조용히 고치면 그 영역의 규칙 검토를 건너뛰게 된다.
  3. 공유 계약은 단독으로 바꾸지 않는다. 응답 포맷·에러 코드·API 규약은 세 클라이언트가 함께 쓰는 계약이다. 변경이 필요하면 checklist 5절 절차를 따르고 영향 범위를 보고한다.
  4. 완료를 스스로 판정하지 않는다. 각 역할의 "완료 기준"에 적힌 명령을 실제로 실행하고 그 결과를 보고한다. 실행하지 않았으면 "실행하지 않음"이라고 적는다.
  5. 모든 산출물(주석·커밋·보고)은 한국어 (coding-common).

인계 형식

작업을 마치면 아래 4줄로 보고한다. 길게 쓰지 않는다.

- 한 일:
- 건드린 파일:
- 확인한 것:      (실행한 명령과 결과. 실행 못 했으면 그 이유)
- 남은 것/인계:   (다음 역할과 넘기는 이유)