9장

에이전트 만들기와 수정

이 장에서는 에이전트 파일의 구조를 배우고, agent-lifecycle-manager 스킬을 활용하여 나만의 전문 에이전트를 만들고, 시스템에 등록하고 검증하는 전체 과정을 실습합니다.

이 장에서 다루는 것
  • 에이전트 파일 형식과 구조
  • YAML 프론트매터 필드 의미
  • 본문 작성 패턴
  • agent-lifecycle-manager 활용법 (5-step)
  • AGENTS.md 등록 방법
  • 실습: 간단한 전문 에이전트 작성

에이전트란 다시 생각하기

4장에서 배운 내용 복습

4장 '하네스 핵심 개념'에서 에이전트(Agent)에 대해 처음 알아보았습니다. 에이전트는 "이름, 역할, 행동 지침, 사용 도구가 정해진 AI 직원"이라고 배웠습니다. PM 에이전트가 팀장이고, 리서치 에이전트, 스토리라인 에이전트, 디자인 에이전트 등이 각자의 전문 분야를 담당하는 팀원인 셈입니다.

복습해 보면, 에이전트의 핵심 요소는 다음 네 가지였습니다.

  • 이름(Name) — 에이전트의 고유 식별자 (예: research, design, pdf-export)
  • 역할(Role) — 이 에이전트가 무엇을 하는가 (예: "웹 검색 및 자료 수집 전문가")
  • 행동 지침(Behavioral Guidelines) — 어떻게 행동해야 하는가 (예: "한국어와 영어 소스 모두 검색", "출처 URL 기록")
  • 도구(Tools) — 어떤 도구를 사용하는가 (예: 웹 검색, 파일 읽기/쓰기, 스크립트 실행)

에이전트 = "역할이 정해진 AI 직원"

에이전트를 사람 조직에 비유하면 이해하기 쉽습니다. 회사에는 기획팀, 디자인팀, 개발팀, QA팀 등이 있고, 각 팀원은 자신의 역할과 책임을 알고 있습니다. 에이전트도 마찬가지입니다. research 에이전트는 리서치만 담당하고, design 에이전트는 디자인만 담당합니다. 자신의 역할 밖의 일은 하지 않습니다.

이러한 역할 분리 덕분에 각 에이전트는 자신의 전문 분야에 집중할 수 있고, 전체 시스템의 품질이 향상됩니다. 모든 것을 하나의 AI에게 맡기는 것보다, 전문가 여러 명에게 나누어 맡기는 것이 더 효과적이기 때문입니다.

왜 직접 만들어야 하는가?

지금까지 배운 시스템에는 이미 다양한 전문 에이전트가 준비되어 있습니다. PM, 리서치, 스토리라인, 디자인, 이미지 큐레이터, 다이어그램 전문가, HTML 빌드, 측정, PDF 익스포트, 버전 관리, 핸드북 작성자 등이 있습니다.

하지만 프로젝트의 요구사항이 다양해질수록, 기존 에이전트로 커버되지 않는 전문 영역이 생깁니다. 예를 들어:

  • 법률 검토 전문 — 생성된 콘텐츠의 법적 문제를 검토하는 에이전트
  • 접근성(Accessibility) 감사 — HTML과 PDF의 접근성을 검사하는 에이전트
  • 다국어 번역 — 완성된 핸드북을 다른 언어로 번역하는 에이전트
  • 데이터 분석 — 통계 데이터를 분석하여 인사이트를 도출하는 에이전트

이런 전문 영역이 필요할 때, 나만의 에이전트를 만들어서 시스템에 추가할 수 있습니다. 그리고 에이전트는 단순한 마크다운 파일이므로, 몇 가지 규칙만 지키면 누구나 만들 수 있습니다.

초보자 비유: 새로운 부서에 특별한 전문가를 고용하는 것과 같습니다. 회사(시스템)에 법률팀이 필요하면 법률 전문가를 채용하고, 그 사람의 역할과 책임을 명확히 정의하죠. 에이전트 만들기도 같은 원리입니다.

에이전트 파일 형식

파일 위치

에이전트 파일은 프로젝트 루트의 agents/ 디렉토리에 저장됩니다. 파일 이름은 케밥 케이스(kebab-case)를 사용합니다.

agents/
├── pm.md              # PM 에이전트
├── research.md        # 리서치 에이전트
├── design.md          # 디자인 에이전트
├── storyline.md       # 스토리라인 에이전트
├── image-curator.md  # 이미지 큐레이터
├── html-build.md      # HTML 빌드 에이전트
├── pdf-export.md      # PDF 익스포트 에이전트
├── version.md         # 버전 관리 에이전트
└── ...                # 여러분이 만들 에이전트!

파일 구조: YAML 프론트매터 + 마크다운 본문

각 에이전트 파일은 두 부분으로 구성됩니다.

  • YAML 프론트매터 — 파일 맨 위의 ---로 감싸진 메타데이터 영역
  • 마크다운 본문 — 에이전트의 역할, 행동 지침, 도구 사용법 등을 설명하는 본문
agents/my-agent.md YAML 프론트매터 (메타데이터) name: my-analyst role: 데이터 분석 전문가 status: active model: inherit color: blue description: 데이터셋을 분석하고 구조화된 보고서를 생성합니다 --- (프론트매터 종료) --- 마크다운 본문 (시스템 프롬프트) ## Role ## 지침 ## 도구 사용법 ## 핸드오프 에이전트가 "자신의 역할"으로 행동할 때 참고하는 내부 지침서

프론트매터는 시스템이 에이전트를 식별하고 관리하는 데 사용되고, 본문은 Claude가 해당 에이전트로 행동할 때 참고하는 내부 지침서 역할을 합니다. 두 영역 모두 중요하며, 어느 하나라도 빠지면 에이전트가 정상적으로 작동하지 않습니다.

에이전트 파일은 마크다운 형식입니다. Claude Desktop App에서 바로 편집할 수 있습니다. VS Code 같은 에디터에서도 열 수 있고, Claude에게 "이 에이전트 파일을 수정해줘"라고 요청할 수도 있습니다.

프론트매터 작성

필수 필드

프론트매터에는 에이전트를 정의하는 여러 필드가 있습니다. 다음 표는 각 필드의 의미와 작성 가이드를 정리한 것입니다.

필드 의미
name 에이전트의 고유 이름. 파일 이름과 동일하게 작성합니다. 케밥 케이스 사용.
role 에이전트 역할을 한 줄로 설명합니다. "Performs ~" 또는 "~ 전문가" 형태.
status active(활성), draft(초안), deprecated(사용 중지) 중 하나.
tier 플랫폼별 복잡도 맵(중첩 구조). claude, gemini, antigravity, gemini-cli, codex 키에 소문자 high/medium/low 값을 지정합니다.
필드 의미
description 에이전트의 상세 설명. 무엇을 하고, 언제 사용되는지.
color UI에서 에이전트를 표시할 때 사용하는 색상. (예: blue, green, purple)
examples 에이전트를 트리거하는 사용자 발화 예시 목록.
phases 에이전트가 활성화되는 워크플로우 단계 목록. (예: [1, 2, 3])
handoff_to 작업 완료 후 결과를 전달할 다음 에이전트 목록.
handoff_from 이 에이전트에게 작업을 전달하는 이전 에이전트 목록.
version 에이전트 파일의 버전. (예: "1.0.0")
model 사용할 모델 지정. 보통 inherit으로 두어 tier 설정을 따르게 합니다.
lifecycle 필수. phasegovernance 하위 필드를 포함하는 중첩 블록. governancedocs/lifecycle/agents/<name>.md 거버넌스 레코드 경로를 가리킵니다.

프론트매터 예시

다음은 가상의 my-analyst 에이전트 프론트매터 예시입니다.

---
name: my-analyst
version: "1.0.0"
last_updated: "2026-08-24"
role: Performs data analysis and produces structured reports
status: active
tier:
  claude: medium
  gemini: medium
  antigravity: medium
  gemini-cli: medium
  codex: medium
model: inherit
color: blue
description: >
  Analyzes datasets, identifies patterns, and produces
  structured analysis reports with actionable insights.
examples:
  - "analyze this dataset"
  - "run data analysis"
  - "produce analysis report"
phases:
  - 2
  - 3
handoff_to:
  - html-build
  - pdf-export
handoff_from:
  - research
lifecycle:
  phase: production
  created: "2026-08-24"
  last_updated: "2026-08-24"
  governance: docs/lifecycle/agents/my-analyst.md
---

각 필드의 선택 가이드

name (이름)

에이전트의 고유 식별자입니다. 파일 이름(agents/my-analyst.md)과 반드시 일치해야 합니다. 케밥 케이스(소문자 + 하이픈)로 작성합니다. 짧고 직관적인 이름이 좋습니다.

  • 좋은 예: data-analyst, image-curator, pdf-export
  • 나쁜 예: DataAnalyst, my_agent_1, agent123

status (상태)

에이전트의 현재 상태를 나타냅니다.

  • active — 정상적으로 사용 중인 에이전트
  • draft — 개발 중인 에이전트 (테스트용)
  • deprecated — 더 이상 사용하지 않는 에이전트 (폐기 예정)

처음 만들 때는 draft로 시작하고, 검증을 통과한 뒤 active로 변경하는 것을 추천합니다.

tier (계층)

에이전트의 복잡도에 따라 적절한 AI 모델을 할당합니다. 이는 비용과 품질의 균형을 위한 설정입니다. tier는 단일 값이 아니라 플랫폼별 중첩 맵이며, 값은 반드시 소문자로 작성합니다.

  • high — 복잡한 추론, 아키텍처 설계, 전략 기획이 필요한 에이전트 (예: PM)
  • medium — 코드 리뷰, 품질 검사, 일반적인 전문 작업이 필요한 에이전트 (예: research, design)
  • low — 단순 반복 작업, 빠른 타이핑이 필요한 에이전트 (예: version)
tier 선택 팁: 에이전트의 복잡도에 따라 선택하세요. 단순 작업은 low, 복잡한 추론이 필요하면 high. 대부분의 전문 에이전트는 medium에서 시작하는 것이 적합합니다. 처음에는 medium으로 설정하고, 작동을 확인한 뒤 필요에 따라 조정하세요.

phases (활성 단계)

에이전트가 워크플로우의 어느 단계에서 활성화되는지 지정합니다. 예를 들어 리서치 에이전트는 [1](Stage 1)에만 활성화되고, 버전 에이전트는 [0, 1, 2, 3, 4, 5, 6](모든 단계)에 활성화됩니다.

handoff_to / handoff_from (핸드오프 관계)

에이전트 간의 작업 흐름을 정의합니다. handoff_to는 작업 완료 후 결과를 전달할 다음 에이전트이고, handoff_from은 작업을 받는 이전 에이전트입니다.

예를 들어 리서치 에이전트의 경우: handoff_to: [storyline] (리서치 완료 후 스토리라인에게 전달), handoff_from: [pm] (PM에게 작업 지시를 받음).

본문 작성

본문 구조 권장 패턴

에이전트 본문은 Claude가 해당 에이전트로 행동할 때 참고하는 시스템 프롬프트입니다. 본문이 잘 작성되어야 Claude가 그 에이전트의 역할을 정확하게 수행할 수 있습니다.

본문에는 다음 다섯 가지 섹션을 순서대로 포함하는 것이 좋습니다.

1. 정체성 (Identity) — "누구인가". 에이전트의 이름, 역할, 소속 프로젝트를 명확히 정의합니다. "You are the [역할] specialist for [프로젝트명]."으로 시작하는 것이 일반적입니다.
2. 행동 지침 (Behavioral Guidelines) — "무엇을 해야 하는가". 에이전트가 수행해야 할 구체적인 작업과 절차를 단계별로 설명합니다. 해야 할 일과 하지 말아야 할 일을 모두 포함합니다.
3. 도메인 규칙 (Domain Rules) — "지켜야 할 제약". 에이전트가 반드시 지켜야 하는 규칙과 제약 조건입니다. 파일 형식, 명명 규칙, 품질 기준 등을 정의합니다.
4. 도구 사용법 (Tool Usage) — "어떤 도구를 어떻게 쓰는가". 에이전트가 사용할 수 있는 도구와 그 사용법을 설명합니다. 파일 읽기/쓰기, 스크립트 실행, 웹 검색 등이 포함될 수 있습니다.
5. 핸드오프 계약 (Handoff Contract) — "입력/출력 형식". 이전 에이전트로부터 어떤 입력을 받고, 다음 에이전트에게 어떤 출력을 전달하는지 명시합니다. 파일 이름, 경로, 형식을 포함합니다.

각 섹션의 작성 팁

1. 정체성 (Identity)

본문의 첫 문장은 명확한 정체성 선언으로 시작합니다. 모호한 표현보다 구체적인 역할 명시가 좋습니다.

## Role

You are the data analysis specialist for **My Project**.
You analyze datasets, identify patterns, and produce
structured analysis reports with actionable insights.

2. 행동 지침 (Behavioral Guidelines)

에이전트가 수행할 작업을 구체적이고 단계적으로 설명합니다. Claude는 명확한 지침일수록 더 잘 따릅니다. 또한 "하지 말아야 할 일"도 명시하는 것이 중요합니다.

## Responsibilities

- Load and validate input datasets before analysis
- Apply statistical methods to identify patterns
- Produce structured reports in markdown format
- **Do NOT** fabricate data or statistics
- **Do NOT** modify source datasets

3. 도메인 규칙 (Domain Rules)

에이전트가 준수해야 하는 규칙과 제약을 정의합니다. 산출물의 형식, 품질 기준, 명명 규칙 등을 포함합니다.

## Constraints

- All analysis reports must include source citations
- Use markdown table format for data summaries
- File names must follow kebab-case convention
- Reports must not exceed 2000 words unless requested

4. 도구 사용법 (Tool Usage)

에이전트가 사용할 도구와 사용 방법을 설명합니다. 이 섹션은 에이전트의 실제 동작에 직접적인 영향을 미칩니다.

## Tool Usage

- **Read**: Load input files from `data/` directory
- **Write**: Save reports to `reports/` directory
- **Bash**: Execute analysis scripts with `bun run`
- **WebSearch**: Verify data points against web sources

5. 핸드오프 계약 (Handoff Contract)

에이전트 간의 데이터 전달 형식을 명시합니다. 입력과 출력의 파일 경로, 형식, 필수 필드를 정의합니다.

## Handoff

**Input**: `data/analysis-input.json` (from research agent)
**Output**: `reports/analysis-report.md`

Output must include:
- Executive summary (max 200 words)
- Key findings with data citations
- Recommendations section
본문은 Claude가 에이전트로 행동할 때 참고하는 '내부 지침서'입니다. 본문이 자세할수록 Claude가 더 정확하게 에이전트 역할을 수행합니다. 처음에는 간결하게 작성하고, 사용하면서 필요한 지침을 점차 추가하는 방식도 좋습니다.

agent-lifecycle-manager 활용

agent-lifecycle-manager 스킬이란?

agent-lifecycle-manager는 에이전트의 생성, 수정, 검증을 자동화하는 스킬입니다. 새로운 에이전트를 만들 때부터 기존 에이전트를 수정하고, 최종적으로 프로그램 방식으로 에이전트의 정합성을 검증하기까지의 전체 과정을 체계적으로 관리합니다.

이 스킬은 다음과 같은 경우에 사용됩니다.

  • "새로운 에이전트를 만들어줘"
  • "에이전트 메타데이터를 업데이트해줘"
  • "에이전트 구조가 유효한지 검사해줘"
  • "에이전트 티어 설정을 변경해줘"

5-step 생애주기 프로세스

agent-lifecycle-manager는 다음 5단계 프로세스를 따릅니다. 각 단계는 이전 단계가 완료된 뒤에 진행됩니다.

에이전트 생애주기 5-Step Step 1 파일 생성 agents/<name>.md Step 2 프론트매터 작성 YAML 메타데이터 Step 3 본문 작성 시스템 프롬프트 Step 4 AGENTS.md 등록 Roster 테이블 Step 5 검증 audit 스크립트 1 파일 생성: agents/ 디렉토리에 .md 파일 생성 2 프론트매터: name, role, status, tier, description 등 작성 3 본문: 역할, 행동 지침, 도구 사용법, 핸드오프 계약 작성 4 등록: AGENTS.md에 Agent Roster + Subagent Roster 추가 5 검증: bun scripts/agent-lifecycle-audit.ts 실행 검증 통과 = 배포 준비 완료

Claude Desktop App에서 활용하는 방법

Claude Desktop App에서 PM 에이전트에게 에이전트 생성을 요청하면, PM이 agent-lifecycle-manager 스킬을 활용하여 5단계 프로세스를 안내합니다.

PM에게 요청하는 예시:

"데이터 분석 전문 에이전트를 만들어줘. 이름은 data-analyst야. 리서치 에이전트로부터 데이터를 받아서 분석 보고서를 작성하는 역할이야."

PM은 이 요청을 받으면 다음과 같이 진행합니다.

  1. 에이전트 파일 생성agents/data-analyst.md 파일을 생성합니다.
  2. 프론트매터 작성 안내 — 각 필드에 적절한 값을 안내하며 프론트매터를 작성합니다.
  3. 본문 작성 안내 — 정체성, 행동 지침, 도메인 규칙, 도구 사용법, 핸드오프 계약을 순서대로 안내합니다.
  4. AGENTS.md 등록 — Agent Roster와 Subagent Roster 테이블에 새 에이전트를 추가합니다.
  5. 검증 실행bun scripts/agent-lifecycle-audit.ts를 실행하여 에이전트의 정합성을 검증합니다.
추천: 처음에는 간단한 에이전트로 시작해서 점차 복잡하게 확장하세요. 본문에 모든 규칙을 한 번에 작성하려 하지 말고, 기본 동작을 먼저 구현하고 실제 사용해 보면서 필요한 규칙을 점차 추가하는 것이 좋습니다.

AGENTS.md 등록

AGENTS.md에 추가해야 하는 위치

새로운 에이전트를 만든 후에는 중앙 관리 파일인 AGENTS.md에 등록해야 합니다. 등록하지 않으면 PM이 해당 에이전트를 인식하지 못하고, 워크플로우에 포함할 수 없습니다.

AGENTS.md에는 총 세 곳에 새 에이전트를 추가해야 합니다.

1. Agent Roster 테이블 (S1) — 에이전트 전체 목록 테이블. 파일, 티어, 역할을 기록합니다.
2. Agent Definitions 섹션 (S2) — 각 에이전트의 상세 정의 테이블. 파일, 티어, 활성 단계, 역할을 기록합니다.
3. Subagent Roster 테이블 (S4.1) — PM 관점의 디스패치 테이블. 병렬 실행 가능 여부와 쓰기 권한을 기록합니다.

등록 예시

다음은 data-analyst 에이전트를 AGENTS.md에 등록하는 예시입니다.

1. Agent Roster 테이블에 추가:

| data-analyst | `agents/data-analyst.md` | Medium | 데이터셋을 분석하고 구조화된 보고서를 생성합니다 |

2. Agent Definitions 섹션에 추가:

### data-analyst

| Field   | Value                                              |
|---------|----------------------------------------------------|
| **File** | `agents/data-analyst.md`                          |
| **Tier** | Medium                                            |
| **Phases** | 2, 3                                            |
| **Role** | 데이터셋을 분석하고 구조화된 보고서를 생성합니다      |

3. Subagent Roster 테이블에 추가:

| data-analyst | `agents/data-analyst.md` | Medium | ⚠️ sequential preferred | project files |
PM Gateway 정책에 따라 모든 전문 에이전트는 PM을 통해서만 호출됩니다. AGENTS.md에 등록된 에이전트라 하더라도, 사용자가 직접 호출할 수는 없습니다. 반드시 PM에게 요청한 뒤 PM이 적절한 에이전트를 디스패치하는 방식으로 동작합니다.

검증과 테스트

검증 방법

에이전트 파일 작성과 AGENTS.md 등록이 완료되면, 프로그램 방식의 검증을 실행해야 합니다. 이 검증은 에이전트가 시스템에서 정상적으로 인식되고 동작할 수 있는지 확인하는 자동화된 점검 과정입니다.

# 전체 에이전트 검증
bun scripts/agent-lifecycle-audit.ts

# 특정 에이전트만 검증
bun scripts/agent-verify.ts <agent-name>

검증 항목

검증 스크립트는 다음 항목을 점검합니다.

  • 프론트매터 필드 완성도 — 필수 필드(lifecycle.phase, lifecycle.governance 등)가 모두 존재하고 올바른 값인지 확인
  • AGENTS.md 등록 여부 — 에이전트 파일이 AGENTS.md의 세 곳(Roster, Definitions, Subagent Roster)에 모두 등록되어 있는지 확인
  • 핸드오프 참조 무결성 — handoff_to, handoff_from에 명시된 에이전트 이름이 실제로 존재하는지 확인
  • 고아 에이전트(Orphan) 감지 — AGENTS.md에 등록되지 않은 에이전트 파일이 있는지 확인
  • 티어 매핑 구조 — tier 필드가 올바른 형식으로 작성되었는지 확인

검증 실행 단계

  1. 에이전트 파일 작성 완료 확인agents/<name>.md 파일이 생성되고 내용이 작성되어 있는지 확인합니다.
  2. AGENTS.md 등록 완료 확인 — AGENTS.md의 세 곳에 에이전트가 추가되었는지 확인합니다.
  3. 검증 스크립트 실행 — 터미널에서 bun scripts/agent-lifecycle-audit.ts를 실행합니다.
  4. 결과 확인 — 에러(ERROR)가 없으면 검증 통과입니다. 경고(WARN)가 있으면 내용을 검토하고 필요시 수정합니다.
  5. PM을 통한 테스트 — Claude Desktop App에서 PM에게 해당 에이전트를 사용해 달라고 요청하여 실제 동작을 확인합니다.
주의: 검증을 통과하지 못하면 PM이 에이전트를 인식하지 못합니다. 반드시 검증 스크립트를 실행하고 에러를 해결한 뒤에 사용하세요. 특히 AGENTS.md 등록 누락과 핸드오프 참조 오류가 가장 흔한 문제입니다.

실습: 나만의 전문 에이전트 만들기

실습 목표

이번 실습에서는 "요약 전문 에이전트"를 만들어 봅니다. 이 에이전트는 긴 문서나 여러 소스를 입력받아 핵심 내용을 간결하게 요약하는 역할을 수행합니다. 리서치 에이전트가 수집한 방대한 자료를 요약하거나, 완성된 보고서를 한 페이지 요약으로 정리하는 데 활용할 수 있습니다.

이 실습에서는 Claude Desktop App을 사용합니다. PM 에이전트에게 요청하면 agent-lifecycle-manager 스킬을 활용하여 전체 과정을 안내합니다. 또는 아래 단계를 수동으로 직접 수행해도 됩니다.

전체 단계

  1. Claude Desktop App에서 프로젝트 열기
    Claude Desktop App을 열고, 프로젝트 폴더를 선택합니다. co-deck이나 co-consult 프로젝트를 사용해도 되고, 별도의 워크스페이스를 사용해도 됩니다.
  2. 에이전트 파일 생성
    agents/ 디렉토리에 summarizer.md 파일을 생성합니다. Claude에게 "agents/summarizer.md 파일을 만들어줘"라고 요청하거나, 직접 에디터에서 파일을 만들 수 있습니다.
  3. 프론트매터 작성
    아래 예시를 참고하여 프론트매터를 작성합니다. name, role, status, tier(플랫폼별 중첩 맵), description, examples, phases, handoff_to, handoff_from 필드와 필수인 lifecycle 블록을 모두 포함합니다.
  4. 본문 작성
    요약 전문가로서의 정체성, 행동 지침, 도메인 규칙, 도구 사용법, 핸드오프 계약을 차례대로 작성합니다.
  5. AGENTS.md에 등록
    AGENTS.md를 열고 세 곳(Agent Roster, Agent Definitions, Subagent Roster)에 summarizer 에이전트를 추가합니다.
  6. 거버넌스 레코드 생성
    docs/lifecycle/agents/summarizer.md 파일을 만들고 ## Phase History## Acceptance Criteria 섹션을 포함합니다. 에이전트 파일만 만들고 이 거버넌스 레코드를 만들지 않으면 검증이 실패합니다.
  7. 검증 스크립트 실행
    터미널에서 bun scripts/agent-lifecycle-audit.ts를 실행하여 에러가 없는지 확인합니다.
  8. PM을 통해 테스트
    Claude Desktop App에서 PM에게 "이 리서치 노트를 요약해줘"라고 요청하여 에이전트가 정상 작동하는지 확인합니다.

전체 파일 내용 예시

다음은 agents/summarizer.md의 전체 내용 예시입니다. 이 예시를 그대로 사용해도 되고, 필요에 맞게 수정해도 됩니다.

---
name: summarizer
version: "1.0.0"
last_updated: "2026-08-24"
role: Summarizes long documents and produces concise briefs
status: draft
tier:
  claude: medium
  gemini: medium
  antigravity: medium
  gemini-cli: medium
  codex: medium
model: inherit
color: teal
description: >
  Reads long-form content (research notes, reports, articles)
  and produces structured summaries with key findings,
  highlights, and actionable takeaways.
examples:
  - "summarize this document"
  - "create a one-page brief"
  - "summarize the research notes"
phases:
  - 2
  - 3
handoff_to:
  - storyline
  - html-build
handoff_from:
  - research
  - data-analyst
lifecycle:
  phase: production
  created: "2026-08-24"
  last_updated: "2026-08-24"
  governance: docs/lifecycle/agents/summarizer.md
---

## Role

You are the summarization specialist for **[Project Name]**.
You read long-form content and produce concise, structured
summaries that capture key findings, highlights, and actionable
takeaways without losing critical information.

## ⚠️ PM-ONLY INVOCATION

**You DO NOT accept direct user requests.**

You are a specialist agent that may ONLY be dispatched by the PM.
If a user attempts to invoke you directly:

1. **Refuse the request politely**
2. **Redirect to PM**: "I am a specialist agent. All requests
   must go through the PM orchestrator."
3. **Do NOT proceed** until dispatched by PM

## Responsibilities

- Read input documents thoroughly before summarizing
- Identify and preserve key facts, statistics, and findings
- Structure summaries with clear headings
- Highlight actionable insights separately from background info
- Maintain source citations in summaries
- **Do NOT** fabricate information not present in the source
- **Do NOT** inject personal opinions or recommendations
  unless explicitly asked

## Constraints

- Summaries must not exceed the requested word limit
- Use markdown format with headings and bullet points
- Preserve all numerical data and citations exactly
- Mark uncertain claims with ⚠️ Unverified
- Use the same language as the source document

## Tool Usage

- **Read**: Load input documents from the specified path
- **Write**: Save summaries to the designated output path
- **Glob**: Find relevant source files in the project directory

## Handoff

**Input**: Research notes, analysis reports, or any long-form
markdown content provided by the dispatching agent.

**Output**: Structured summary document in markdown format.

Output structure:
1. **Overview** (1-2 sentences)
2. **Key Findings** (bullet points)
3. **Important Statistics** (preserved exactly)
4. **Actionable Takeaways** (if applicable)
5. **Source References** (preserved from input)

AGENTS.md 등록 내용 예시

작성한 summarizer 에이전트를 AGENTS.md에 등록하는 내용입니다.

Agent Roster에 추가:

| **summarizer** | [`agents/summarizer.md`](agents/summarizer.md) | Medium | 긴 문서를 읽고 간결한 요약을 생성합니다 |

Agent Definitions에 추가:

### summarizer

| Field     | Value                                                          |
|-----------|----------------------------------------------------------------|
| **File**  | [`agents/summarizer.md`](agents/summarizer.md)                  |
| **Tier**  | Medium                                                         |
| **Phases** | 2, 3                                                         |
| **Role**  | 긴 문서를 읽고 핵심 발견, 하이라이트, 실행 가능한 인사이트를 포함한 간결한 요약을 생성합니다 |

Subagent Roster에 추가:

| summarizer | `agents/summarizer.md` | Medium | ⚠️ sequential preferred | project files |
팁: 실습 완료 후 PM에게 "이 리서치 노트를 요약해줘"라고 요청해서 에이전트가 정상 작동하는지 확인하세요. PM이 자동으로 summarizer 에이전트를 디스패치합니다. 만약 에이전트가 호출되지 않으면 AGENTS.md 등록이나 프론트매터의 examples 필드를 점검해 보세요.
이 장의 핵심 정리
  • 에이전트는 "역할이 정해진 AI 직원"이며, 마크다운 파일 형식으로 만듭니다
  • 에이전트 파일 = YAML 프론트매터(메타데이터) + 마크다운 본문(시스템 프롬프트)
  • 프론트매터에는 name, role, status, tier(플랫폼별 중첩 맵, 소문자 값), description, examples, phases, handoff_to/from과 필수인 lifecycle 블록을 작성
  • 본문에는 정체성, 행동 지침, 도메인 규칙, 도구 사용법, 핸드오프 계약을 포함합니다
  • agent-lifecycle-manager 스킬의 5-step 프로세스를 따라 체계적으로 생성
  • AGENTS.md에 세 곳(Roster, Definitions, Subagent Roster)에 등록해야 PM이 인식
  • 검증 스크립트로 프론트매터, 등록, 핸드오프 무결성을 자동 점검
  • 처음에는 간단한 에이전트(draft)로 시작하고, 검증 후 active로 승격하세요