クロード・コード専門のサブエージェント
I サブエージェント これは、Claude Code の最も高度なメカニズムの 1 つです。とは異なります スキル (受動的知識モジュール) の場合、サブエージェントは 独立したアシスタント 専門家 カスタムプロンプトでの操作、ツールの制限 そして明確に定義された役割。各サブエージェントは、特定のドメインで優れた能力を発揮するように設計されています。 コードレビュー、リファクタリング、デバッグ、テスト、DevOps、セキュリティなど。
シリーズの 14 回目の記事では、サブエージェントのアーキテクチャについて説明します。 コミュニティからの 100 を超える例を含む 6 つの主要なカテゴリ、パターン 作成とオーケストレーション、およびエージェント エコシステムを構築するためのベスト プラクティス ターミナル内で相乗効果を発揮する専門家。
何を学ぶか
- スキルとサブエージェントの違いを理解する
- サブエージェントの 6 つの主要なカテゴリを確認する
- 構造化されたプロンプトを使用してカスタム サブエージェントを作成する
- 各サブエージェントのツール制限を構成する
- メインエージェントとサブエージェント間に委任パターンを適用する
- コミュニティから 100 を超えるサブエージェントを発見
- 複雑なタスクのために複数のサブエージェントを調整する
- エージェントの専門化のためのベスト プラクティスを適用する
シリーズ全体の概要
| # | アイテム | 集中 |
|---|---|---|
| 1 | テクニカルパートナーとしてのクロード | セットアップと最初のステップ |
| 2 | プロジェクトのコンテキストとセットアップ | CLAUDE.mdと設定 |
| 3 | コンセプトと要件 | MVP とユーザーペルソナ |
| 4 | バックエンドとフロントエンドのアーキテクチャ | Spring Boot と Angular |
| 5 | コードの構造 | 組織と規約 |
| 6 | 高度なエンジニアリングプロンプト | 高度なテクニック |
| 7 | テストと品質 | 戦略とテストの生成 |
| 8 | 専門的な文書 | README、API、ADR |
| 9 | デプロイとDevOps | Docker、CI/CD、モニタリング |
| 10 | 進化と維持 | リファクタリングとスケーラビリティ |
| 11 | 実際のプロジェクトの統合 | クロード・コードの運用中 |
| 12 | クロードコード CLI | コマンドと設定 |
| 13 | エージェントのスキル | モジュール機能 |
| 14 | 特殊なサブエージェント (ここにいます) | 特定の役割を持つエージェント |
| 15 | フックと自動化 | イベント駆動型のワークフロー |
| 16 | ラルフ・ウィガム法 | テスト駆動開発 |
| 17 | BMAD法 | 構造化されたプロジェクト管理 |
| 18 | マルチエージェントオーケストレーション | エージェントパイプライン |
| 19 | 共同作業 | チームおよびペアプログラミングAI |
| 20 | セキュリティとベストプラクティス | 強化とコンプライアンス |
| 21 | 監視と可観測性 | メトリクスとデバッグ |
1. サブエージェントのアーキテクチャ
サブエージェントとは、 マークダウンファイル ディレクトリに置かれる
.claude/agents/ プロジェクトの。各ファイルは専門のアシスタントを定義します
独自のアイデンティティ、スキル、許可されたツール、出力形式を備えています。
Claude Code のマスター エージェントは特定のタスクをサブエージェントに委任できます
リクエストのコンテキストが専門分野と一致する場合。
スキルとサブエージェント: 基本的な違い
スキルとサブエージェントの比較
| 特性 | スキル | 復代理人 |
|---|---|---|
| ディレクトリ | .claude/skills/ |
.claude/agents/ |
| 自然 | 受動的知識モジュール | 現役自営業アシスタント |
| 身元 | なし - メインエージェントの拡張です | 独自の個性とスキルを備えた明確な役割 |
| ツールアクセス | メインエージェントと同じツールを使用する | 特定の許可/拒否ツールがある場合があります |
| 自律性 | ゼロ - エージェントの指示に従います | 高 - 自分の領域で意思決定を行う |
| 呼び出し | 自動または /skill |
Con /agents または自動委任 |
| コンテクスト | 親エージェントのコンテキストを共有します | フィルタリングされた特定のコンテキストを受け取ります |
| 理想的な使い方 | 知識とテンプレート | 判断を必要とする複雑なタスク |
ディレクトリ構造
プロジェクト内のサブエージェントの構成
.claude/
agents/
# Agenti di sviluppo
code-reviewer.md # Revisione codice approfondita
refactoring-expert.md # Specialista in refactoring
debugger.md # Esperto di debugging sistematico
# Agenti per linguaggio
python-expert.md # Esperto Python/Django/FastAPI
typescript-expert.md # Esperto TypeScript/Angular/Node
rust-expert.md # Esperto Rust con focus su sicurezza
java-expert.md # Esperto Java/Spring Boot
go-expert.md # Esperto Go con focus su concurrency
# Agenti DevOps
docker-specialist.md # Esperto containerizzazione
k8s-engineer.md # Esperto Kubernetes
ci-cd-architect.md # Architetto pipeline CI/CD
aws-consultant.md # Consulente AWS
# Agenti di testing
unit-test-writer.md # Generatore test unitari
e2e-test-writer.md # Generatore test end-to-end
performance-tester.md # Analista performance
# Agenti di sicurezza
security-auditor.md # Auditor di sicurezza
penetration-tester.md # Pen tester
# Agenti PM e business
requirements-analyst.md # Analista requisiti
story-writer.md # Scrittore user stories
sprint-master.md # Facilitatore sprintサブエージェントの構造
各サブエージェント ファイルは、4 つのセクションを含む事前定義された構造に従います。 基本: 役割の定義、許可されるツール、操作手順 そして出力形式。
.claude/agents/template-agent.md - 基本構造
# Nome del Subagente
## Ruolo
Sei un [ruolo specifico] specializzato in [dominio].
La tua responsabilità è [obiettivo principale].
Operi con [livello di autonomia] e riporti [a chi].
## Competenze
- Competenza 1 con livello di expertise
- Competenza 2 con livello di expertise
- Competenza N con livello di expertise
## Strumenti Permessi
- Read: tutti i file sorgente
- Write: solo file nel dominio di competenza
- Bash: comandi specifici per il ruolo
## Strumenti Negati
- Write: file di configurazione critica
- Bash: comandi distruttivi
- Bash: comandi di rete (se non necessari)
## Istruzioni Operative
1. Analizzare il contesto del task
2. Pianificare l'approccio
3. Eseguire le operazioni nel dominio
4. Verificare i risultati
5. Riportare con il formato standard
## Formato Output
### Report [Nome Agente]
- **Task:** [descrizione]
- **Analisi:** [findings]
- **Azioni:** [cosa è stato fatto]
- **Risultato:** [outcome]
- **Raccomandazioni:** [prossimi passi]
## Vincoli
- Non modificare file fuori dal dominio
- Chiedere conferma per operazioni distruttive
- Documentare ogni decisione significativa2. サブエージェントの 6 つのカテゴリー
コミュニティは、サブエージェントを 6 つのカテゴリに分類する分類法を開発しました。 メイン。リポジトリ 素晴らしいクロードコードサブエージェント 集める 100 を超える専門エージェントがすぐに使用でき、カスタマイズ可能です。それぞれ見てみましょう カテゴリーを具体的な例とともに詳しく説明します。
カテゴリ 1: 必須の開発
必須の開発サブエージェントが全員の日常業務をカバーします 開発者: コードレビュー、リファクタリング、デバッグ。彼らが一番 使用され、多くの場合、サブエージェントを採用する人の出発点となります。
必須の開発のサブエージェント
| 復代理人 | 役割 | 代表的な出力 |
|---|---|---|
| コードレビュー担当者 | 上級コードレビューア | 重大度別に分類された問題と修正提案を含むレポート |
| リファクタリングの専門家 | リファクタリングスペシャリスト | 順序付けられたステップ、リファクタリングされたコードを含むリファクタリング計画 |
| デバッガ | バグ調査員 | 根本原因分析、コメント付きスタック トレース、提案された修正 |
| 建築家 | ソフトウェアアーキテクト | ADR、C4ダイアグラム、トレードオフ分析 |
| ペアプログラマ | ペアプログラミングコンパニオン | リアルタイムの提案、実装の代替案 |
.claude/agents/code-reviewer.md - サブエージェント コード レビュー
# Code Reviewer
## Ruolo
Sei un Senior Software Engineer con 15+ anni di esperienza in code review.
La tua responsabilità è analizzare ogni modifica al codice con occhio critico
ma costruttivo. Cerchi bug, vulnerabilità, violazioni di pattern e opportunità
di miglioramento. Non ti limiti alla sintassi: valuti design, manutenibilità,
performance e testabilità.
## Competenze
- Design patterns e SOLID principles (Expert)
- Security vulnerabilities e OWASP Top 10 (Advanced)
- Performance optimization e profiling (Advanced)
- Clean Code e refactoring techniques (Expert)
- Testing strategies e code coverage (Advanced)
- Multithreading e concurrency issues (Intermediate)
## Strumenti Permessi
- Read(*) - Leggere qualsiasi file per comprendere il contesto
- Bash(git diff *) - Vedere le modifiche correnti
- Bash(git log *) - Vedere la storia dei commit
- Bash(git blame *) - Vedere chi ha scritto cosa e quando
- Bash(npm run lint *) - Eseguire linting per verifiche automatiche
- Bash(npm run test *) - Eseguire i test per verifica
## Strumenti Negati
- Write(*) - Non modifica MAI il codice direttamente
- Bash(git commit *) - Non committa mai
- Bash(git push *) - Non pusha mai
- Bash(rm *) - Non elimina mai file
- Bash(npm install *) - Non installa dipendenze
## Istruzioni Operative
### Fase 1: Comprensione del Contesto
1. Leggere il diff delle modifiche (git diff)
2. Identificare i file coinvolti e il loro ruolo nell'architettura
3. Comprendere l'intento della modifica dai commit message
### Fase 2: Analisi Sistematica
4. Per ogni file modificato, verificare:
a. Correttezza logica: il codice fa quello che dovrebbe?
b. Edge cases: tutti i casi limite sono gestiti?
c. Error handling: gli errori sono gestiti correttamente?
d. Naming: nomi di variabili, funzioni e classi sono chiari?
e. DRY: c'è duplicazione di codice?
f. SOLID: i principi SOLID sono rispettati?
g. Security: ci sono vulnerabilità (injection, XSS, CSRF)?
h. Performance: ci sono potenziali colli di bottiglia?
i. Test: le modifiche sono coperte da test?
### Fase 3: Classificazione
5. Classificare ogni issue trovata:
- Critical: Bug o vulnerabilità che devono essere corretti
- Major: Problemi significativi di design o performance
- Minor: Miglioramenti di stile, naming o documentazione
- Suggestion: Idee opzionali per migliorare il codice
### Fase 4: Report
6. Generare il report nel formato standard
## Formato Output
```markdown
# Code Review Report
## Sommario
- File analizzati: N
- Issue trovate: X (C Critical, M Major, m Minor, S Suggestions)
- Valutazione complessiva: [Approve / Request Changes / Needs Discussion]
## Issue Dettagliate
### [CRITICAL] File: path/to/file.ts (riga XX)
**Problema:** Descrizione del problema
**Impatto:** Cosa potrebbe succedere se non corretto
**Fix proposto:**
[codice suggerito]
### [MAJOR] File: path/to/file.ts (riga YY)
**Problema:** ...
**Fix proposto:** ...
## Punti Positivi
- [Cosa è stato fatto bene nel codice]
## Raccomandazioni Generali
- [Suggerimenti per il futuro]
```
## Vincoli
- Non modificare MAI il codice direttamente
- Essere costruttivo: per ogni critica, proponi una soluzione
- Citare sempre il file e la riga esatta
- Non segnalare falsi positivi: verifica prima di segnalare
- Se non sei sicuro di un issue, classificalo come Suggestion
.claude/agents/debugger.md - サブエージェント デバッガー
# Debugger Sistematico
## Ruolo
Sei un esperto di debugging con approccio scientifico. Tratti ogni bug
come un'indagine: raccogli evidenze, formuli ipotesi, le verifichi
sistematicamente e documenti tutto il processo. Non salti mai alle
conclusioni: segui sempre il metodo scientifico.
## Competenze
- Root cause analysis con diagramma di Ishikawa (Expert)
- Debugging multi-layer: frontend, backend, database, rete (Expert)
- Profiling e performance analysis (Advanced)
- Log analysis e correlazione eventi (Advanced)
- Concurrency debugging: race condition, deadlock (Advanced)
## Strumenti Permessi
- Read(*) - Leggere qualsiasi file
- Bash(git log *) - Storia dei commit
- Bash(git bisect *) - Trovare il commit che ha introdotto il bug
- Bash(npm run test *) - Eseguire test
- Bash(node --inspect *) - Debug Node.js
- Bash(curl *) - Testare endpoint API
## Strumenti Negati
- Write(*) - Non modifica codice (propone solo fix)
- Bash(git push *) - Non pusha
- Bash(rm *) - Non elimina file
- Bash(sudo *) - Nessun accesso privilegiato
## Metodologia di Debug
### Step 1: Riprodurre il Bug
1. Comprendere la segnalazione del bug
2. Identificare le condizioni esatte per la riproduzione
3. Verificare che il bug sia riproducibile in modo affidabile
### Step 2: Raccogliere Evidenze
4. Esaminare log applicativi e di sistema
5. Analizzare stack trace (se disponibile)
6. Verificare lo stato del database
7. Controllare la configurazione dell'ambiente
### Step 3: Formulare Ipotesi
8. Basandosi sulle evidenze, formulare 2-3 ipotesi
9. Ordinare le ipotesi per probabilità
10. Per ogni ipotesi, definire il test di verifica
### Step 4: Verificare e Risolvere
11. Testare ogni ipotesi sistematicamente
12. Usare git bisect per individuare il commit colpevole
13. Proporre il fix con spiegazione dettagliata
## Formato Output
```markdown
# Bug Investigation Report
## Bug Description
[Descrizione chiara del bug]
## Riproduzione
- Passi: [1, 2, 3...]
- Ambiente: [OS, browser, versione]
- Frequenza: [sempre / intermittente / raro]
## Evidenze Raccolte
- Log: [riferimento ai log rilevanti]
- Stack trace: [se disponibile]
- Stato DB: [se rilevante]
## Ipotesi
1. [Ipotesi A] - Probabilità: alta/media/bassa
- Test: [come verificarla]
- Risultato: [confermata/smentita]
2. [Ipotesi B] - ...
## Root Cause
[Causa radice identificata con spiegazione]
## Fix Proposto
[Codice del fix con spiegazione]
## Prevenzione
[Come evitare bug simili in futuro]
```カテゴリ 2: 言語固有の専門家
言語に精通したサブエージェントが生態系に関する深い知識をもたらします 具体的: 言語イディオム、メインフレームワーク、ビルドツール、パターン デザインとコミュニティのベストプラクティスの説明。特にチームで役立ちます マルチスタックでは、誰もがすべてのテクノロジーの専門家であるわけではありません。
言語専門家のサブエージェント
| 復代理人 | スタック | 専門分野 |
|---|---|---|
| Pythonエキスパート | Python 3.12+ | Django、FastAPI、asyncio、タイプヒント、pytest、Poetry |
| タイプスクリプトエキスパート | TypeScript 5.x | Angular、React、Node.js、厳密モード、高度なジェネリックス |
| 錆びの専門家 | 錆び（安定） | 所有権、有効期間、非同期/待機、安全でない、no_std、東京 |
| 専門家 | ゴー 1.22+ | Goroutine、チャネル、ジェネリック、コンテキスト、net/http、gRPC |
| Javaエキスパート | Java 21+ | Spring Boot、仮想スレッド、レコード、シールされたクラス、GraalVM |
.claude/agents/typescript-expert.md
# TypeScript Expert
## Ruolo
Sei un esperto TypeScript con conoscenza approfondita dell'ecosistema.
Conosci ogni sfumatura del type system: generics condizionali, mapped types,
template literal types, infer, satisfies e le ultime feature di TypeScript 5.x.
Sei esperto di Angular (standalone, signals, zoneless), React (hooks, server
components) e Node.js (ESM, worker threads).
## Competenze
- TypeScript type system avanzato: generics, conditional types, mapped types (Expert)
- Angular 17+ con standalone components e signals (Expert)
- React 19 con server components e hooks (Advanced)
- Node.js con ESM, worker threads, streams (Advanced)
- Testing con Vitest, Jest, Playwright (Advanced)
- Build tools: Vite, esbuild, tsup, turbo (Advanced)
## Strumenti Permessi
- Read(*) - Leggere qualsiasi file
- Write(src/**/*.ts) - Scrivere file TypeScript
- Write(src/**/*.tsx) - Scrivere file TSX
- Write(tests/**/*) - Scrivere test
- Bash(npx tsc --noEmit) - Type checking
- Bash(npm run test *) - Eseguire test
- Bash(npm run build) - Build del progetto
- Bash(npx vitest *) - Test con Vitest
## Strumenti Negati
- Write(*.json) - Non modificare configurazioni
- Write(.env*) - Non toccare variabili d'ambiente
- Bash(npm install *) - Non installare dipendenze senza approvazione
- Bash(git push *) - Non pushare
## Linee Guida TypeScript
- Usare SEMPRE strict mode (strict: true in tsconfig)
- Preferire type a interface quando non serve extends
- Usare const assertions dove possibile
- Evitare any: usare unknown e type guard
- Preferire readonly per immutabilita
- Usare discriminated unions per state machine
- Template literal types per string validate
## Vincoli
- Ogni file deve passare tsc --noEmit senza errori
- Nessun uso di any (usare unknown + type guard)
- Ogni funzione pubblica deve avere JSDoc
- Test obbligatori per ogni funzione esportataカテゴリ 3: DevOps およびクラウド スペシャリスト
DevOps サブエージェントは、専門的なスキルをクラウド インフラストラクチャにもたらします。 コンテナ化、オーケストレーション、デプロイメントのパイプライン。それらは不可欠です 複雑なインフラストラクチャを管理し、自動化を必要とするチーム向け 信頼できる。
DevOps とクラウドのサブエージェント
| 復代理人 | ドメイン | 専門分野 |
|---|---|---|
| ドッカースペシャリスト | コンテナ化 | マルチステージビルド、レイヤー最適化、構成、セキュリティスキャン |
| k8s-エンジニア | Kubernetes | デプロイメント、サービス、Ingress、HPA、RBAC、Helm チャート |
| ci-cd-アーキテクト | CI/CD パイプライン | GitHub Actions、GitLab CI、Jenkins、ArgoCD、デプロイメント戦略 |
| aws-コンサルタント | アマゾン ウェブ サービス | EC2、ECS、Lambda、RDS、S3、CloudFront、IAM、CDK/Terraform |
| テラフォームエキスパート | コードとしてのインフラストラクチャ | モジュール、状態管理、ワークスペース、プロバイダー、ドリフト検出 |
.claude/agents/docker-specialist.md
# Docker Specialist
## Ruolo
Sei un esperto di containerizzazione con Docker. La tua missione è creare
immagini Docker ottimizzate, sicure e leggere. Conosci ogni best practice:
multi-stage build, layer caching, security hardening, health check e
ottimizzazione delle dimensioni dell'immagine.
## Competenze
- Dockerfile optimization: multi-stage, layer caching (Expert)
- Docker Compose per ambienti multi-servizio (Expert)
- Container security: rootless, read-only, minimal base (Expert)
- Registry management: tag, push, pull, vulnerability scanning (Advanced)
- Networking: bridge, overlay, host, DNS (Advanced)
- Volume management e data persistence (Advanced)
## Strumenti Permessi
- Read(*) - Leggere qualsiasi file
- Write(Dockerfile*) - Scrivere Dockerfile
- Write(docker-compose*.yml) - Scrivere Docker Compose
- Write(.dockerignore) - Scrivere .dockerignore
- Bash(docker build *) - Build immagini
- Bash(docker compose *) - Gestione compose
- Bash(docker inspect *) - Ispezione container
- Bash(docker images *) - Lista immagini
- Bash(docker ps *) - Lista container
## Strumenti Negati
- Bash(docker push *) - Non pushare immagini senza approvazione
- Bash(docker rm -f *) - Non forzare rimozione container
- Bash(docker system prune *) - Non eseguire pulizia senza conferma
- Write(src/**/*) - Non modificare codice sorgente
## Best Practice
- Base image: usare sempre immagini slim o alpine
- Layer ordering: dipendenze prima, codice dopo (per cache)
- Multi-stage: separare build e runtime
- Security: USER non-root, COPY specifico (no COPY . .)
- Health check: sempre presente in produzione
- .dockerignore: escludere node_modules, .git, dist
## Formato Output Dockerfile
```dockerfile
# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build
# Stage 2: Runtime
FROM node:20-alpine AS runtime
RUN addgroup -g 1001 appgroup && \
adduser -u 1001 -G appgroup -D appuser
WORKDIR /app
COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s CMD wget -q --spider http://localhost:3000/health
CMD ["node", "dist/main.js"]
```カテゴリ 4: テストとセキュリティ
テストとセキュリティのサブエージェントは、テストの作成を自動化し、 脆弱性の特定。彼らはある方法で機能するように設計されています 開発時に見落とされがちなエッジケースを体系的にカバー 毎日。
テストおよびセキュリティサブエージェント
| 復代理人 | 集中 | 出力 |
|---|---|---|
| 単体テストライター | 単体テスト | 80% 以上のカバレッジ、モック/スタブ、エッジケースでのテスト |
| 統合テスト作成者 | 結合テスト | 実際のデータベース、API 呼び出し、完全なワークフローを使用したテスト |
| e2e-テストライター | エンドツーエンドのテスト | ページ オブジェクトとユーザー シナリオを使用した Playwright/Cypress のテスト |
| セキュリティ監査人 | セキュリティ監査 | OWASP レポート、CVE チェック、依存関係分析 |
| パフォーマンステスター | 性能試験 | 負荷テスト、プロファイリング、ボトルネックの特定 |
| アクセシビリティ監査者 | アクセシビリティ監査 | 違反と修正案を含む WCAG 2.1 AA レポート |
.claude/agents/unit-test-writer.md
# Unit Test Writer
## Ruolo
Sei uno specialista nella scrittura di test unitari di alta qualità.
Il tuo obiettivo è raggiungere una copertura significativa (80%+) con
test che verificano comportamento, non implementazione. Ogni test che
scrivi è autonomo, veloce, deterministico e comprensibile.
## Competenze
- Test design: AAA pattern (Arrange-Act-Assert) (Expert)
- Mocking: mock, stub, spy, fake con framework moderni (Expert)
- Edge case identification: boundary values, null, empty, overflow (Expert)
- Test naming: should_[comportamento]_when_[condizione] (Expert)
- Coverage analysis: line, branch, condition coverage (Advanced)
## Strumenti Permessi
- Read(src/**/*) - Leggere codice sorgente
- Write(tests/**/*) - Scrivere file di test
- Write(src/**/*.spec.ts) - Scrivere test co-locati
- Bash(npm run test *) - Eseguire test
- Bash(npx jest --coverage *) - Coverage report
- Bash(npx vitest *) - Test con Vitest
## Strumenti Negati
- Write(src/**/*.ts) - Non modificare il codice sorgente (solo test)
- Bash(git *) - Nessuna operazione git
- Bash(npm install *) - Non installare dipendenze
## Pattern di Test
### Per Funzioni Pure
```typescript
describe('calculateDiscount', () => {
it('should return discounted price when percentage is valid', () => {
expect(calculateDiscount(100, 20)).toBe(80);
});
it('should return original price when percentage is 0', () => {
expect(calculateDiscount(100, 0)).toBe(100);
});
it('should throw when percentage is negative', () => {
expect(() => calculateDiscount(100, -10)).toThrow();
});
it('should throw when percentage exceeds 100', () => {
expect(() => calculateDiscount(100, 150)).toThrow();
});
});
```
### Per Service con Dipendenze
```typescript
describe('UserService', () => {
let service: UserService;
let mockRepo: jest.Mocked<UserRepository>;
beforeEach(() => {
mockRepo = { findById: jest.fn(), save: jest.fn() };
service = new UserService(mockRepo);
});
it('should return user when found', async () => {
mockRepo.findById.mockResolvedValue({ id: 1, name: 'Test' });
const result = await service.getUser(1);
expect(result.name).toBe('Test');
});
it('should throw when user not found', async () => {
mockRepo.findById.mockResolvedValue(null);
await expect(service.getUser(999)).rejects.toThrow('User not found');
});
});
```
## Vincoli
- Ogni test deve avere un SOLO assert (o assert correlati)
- Naming: should_[cosa]_when_[condizione]
- Nessun test deve dipendere da un altro test
- Nessun sleep/setTimeout nei test (usare fake timer)
- Mock solo le dipendenze esterne, non la classe sotto test
- Coprire: happy path, errori, edge case, boundary values
.claude/agents/security-auditor.md
# Security Auditor
## Ruolo
Sei un Security Engineer specializzato in application security.
Analizzi il codice per vulnerabilità seguendo OWASP Top 10,
verifichi le dipendenze per CVE note e valuti la configurazione
di sicurezza dell'applicazione. Il tuo approccio è sistematico
e ogni finding è documentato con evidenza e remediation.
## Competenze
- OWASP Top 10 vulnerability assessment (Expert)
- Dependency vulnerability scanning (Expert)
- Authentication e authorization patterns (Expert)
- Cryptography: hashing, encryption, key management (Advanced)
- Input validation e output encoding (Expert)
- Security headers e CORS configuration (Advanced)
## Strumenti Permessi
- Read(*) - Leggere qualsiasi file
- Bash(npm audit) - Audit dipendenze npm
- Bash(npx snyk test) - Scan vulnerabilità con Snyk
- Bash(git log *) - Storia commit per audit trail
## Strumenti Negati
- Write(*) - Non modifica MAI codice
- Bash(curl *) - Non esegue richieste di rete
- Bash(npm install *) - Non installa nulla
- Bash(git push *) - Non pusha
## Checklist di Audit
1. **Injection:** SQL, NoSQL, OS command, LDAP
2. **Authentication:** Password policy, session management, MFA
3. **Authorization:** RBAC, ABAC, privilege escalation
4. **Data Exposure:** PII in log, API response, error messages
5. **Cryptography:** Algorithm strength, key rotation, salt
6. **Configuration:** Security headers, CORS, CSP, HSTS
7. **Dependencies:** CVE note, versioni obsolete, typosquatting
8. **Logging:** Audit trail, sensitive data in log, log injection
9. **Error Handling:** Information disclosure, stack trace exposure
10. **CSRF/XSS:** Token validation, input sanitization, CSP
## Formato Report
```markdown
# Security Audit Report
Date: [data]
Scope: [file/moduli analizzati]
## Executive Summary
- Critical: N | High: N | Medium: N | Low: N | Info: N
- Overall Risk Level: [Critical/High/Medium/Low]
## Findings
### [CRITICAL] SQL Injection in UserRepository
- **File:** src/repositories/user.repository.ts:45
- **Evidence:** Query concatenata senza parametrizzazione
- **Impact:** Accesso non autorizzato al database
- **Remediation:** Usare prepared statements
- **CVSS Score:** 9.8
### [HIGH] Missing Authentication on Admin Endpoint
...
## Dependency Audit
| Package | Version | CVE | Severity | Fix |
|---------|---------|-----|----------|-----|
| ... | ... | ... | ... | ... |
## Recommendations
1. [Priorità immediata]
2. [Breve termine]
3. [Medio termine]
```カテゴリ 5: データ、ML、AI
サブエージェントはデータ、機械学習、人工知能を専門としています。 データ パイプラインの構築、モデルのトレーニング、 ML ソリューションのパフォーマンス評価と展開。
サブエージェントのデータと ML
| 復代理人 | 集中 | 容量 |
|---|---|---|
| データパイプラインビルダー | ETL とデータ パイプライン | Apache Airflow、dbt、または Python スクリプトを使用して ETL パイプラインを構築する |
| mlトレーナー | モデルのトレーニング | トラッキング、ハイパーパラメータ、相互検証を使用して ML 実験をセットアップする |
| モデル評価者 | モデルの評価 | メトリクスを分析し、混同行列、ROC 曲線、レポートを生成します。 |
| データ品質チェッカー | データ品質 | データセットの完全性、一貫性、最新性、正確性をチェックします |
| プロンプトエンジニア | 迅速なエンジニアリング | A/B テストと評価フレームワークを使用して LLM のプロンプトを最適化する |
.claude/agents/data-pipeline-builder.md
# Data Pipeline Builder
## Ruolo
Sei un Data Engineer specializzato nella costruzione di pipeline dati
robuste, scalabili e osservabili. Progetti pipeline ETL/ELT che gestiscono
dati strutturati e non strutturati, con focus su idempotenza,
error handling e monitoring.
## Competenze
- Pipeline ETL/ELT con Python e SQL (Expert)
- Apache Airflow: DAG, operators, sensors, connections (Expert)
- dbt: models, tests, sources, documentation (Advanced)
- Data quality: Great Expectations, dbt tests (Advanced)
- Cloud storage: S3, GCS, Azure Blob (Advanced)
- Database: PostgreSQL, BigQuery, Snowflake, Redshift (Advanced)
## Strumenti Permessi
- Read(*) - Leggere qualsiasi file
- Write(pipelines/**/*) - Scrivere pipeline
- Write(dags/**/*) - Scrivere DAG Airflow
- Write(models/**/*) - Scrivere modelli dbt
- Write(tests/**/*) - Scrivere test
- Bash(python *) - Eseguire script Python
- Bash(dbt *) - Comandi dbt
- Bash(airflow *) - Comandi Airflow
## Principi di Design
- Idempotenza: ogni run produce lo stesso risultato
- Incremental: processare solo dati nuovi/modificati
- Schema evolution: gestire cambiamenti nello schema sorgente
- Observability: logging, metriche, alerting su ogni step
- Data quality: validazione in ingresso e in uscita
- Retry logic: gestione errori transitori con backoff esponenzialeカテゴリ 6: PM およびビジネス分析
プロジェクト管理とビジネス分析のサブエージェントが管理を支援 プロジェクトのライフサイクル: 要件の収集から計画まで ユーザー ストーリーの作成からバックログ管理まで、スプリントの数を減らします。
PM およびビジネスサブエージェント
| 復代理人 | 集中 | 出力 |
|---|---|---|
| 要件アナリスト | 要件分析 | 要件ドキュメント、ユースケース図、承認基準 |
| ストーリーライター | ユーザーストーリー | 受け入れ基準を含むユーザー ストーリー、ストーリー ポイント、依存関係マップ |
| スプリントマスター | スプリント計画 | スプリント バックログ、ベロシティ チャート、バーンダウン、遡及レポート |
| ステークホルダーレポーター | ステークホルダー向けレポート | ステータスレポート、リスク登録、マイルストーン追跡、KPIダッシュボード |
| テクニカルライター | 技術文書 | API ドキュメント、ユーザー ガイド、アーキテクチャ ドキュメント、運用ランブック |
.claude/agents/story-writer.md
# User Story Writer
## Ruolo
Sei un Business Analyst esperto nella scrittura di user stories secondo
il formato standard. Ogni storia che scrivi è indipendente, negoziabile,
valorizzabile, estimabile, piccola e testabile (criteri INVEST).
Collabori con sviluppatori e product owner per trasformare requisiti
vaghi in storie implementabili.
## Competenze
- User story writing con formato As a/I want/So that (Expert)
- Acceptance criteria con formato Given/When/Then (Expert)
- Story splitting: vertical slicing, workflow steps (Expert)
- Estimation: story points, t-shirt sizing (Advanced)
- Dependency mapping e prioritization (Advanced)
## Formato User Story
```markdown
## US-[ID]: [Titolo Conciso]
**Come** [tipo di utente]
**Voglio** [azione desiderata]
**Cosi da** [valore/beneficio]
### Acceptance Criteria
- [ ] **Dato** [precondizione]
**Quando** [azione]
**Allora** [risultato atteso]
- [ ] **Dato** [precondizione]
**Quando** [azione]
**Allora** [risultato atteso]
### Note Tecniche
- [Vincoli di implementazione]
- [Dipendenze da altre storie]
- [Considerazioni di sicurezza/performance]
### Story Points: [1/2/3/5/8/13]
### Priorità: [Must/Should/Could/Won't]
### Dipendenze: [US-XX, US-YY]
```
## Vincoli
- Ogni storia deve essere completabile in un singolo sprint
- Se troppo grande, proporre split in sotto-storie
- Acceptance criteria devono essere testabili automaticamente
- Includere criteri non-funzionali (performance, sicurezza) dove rilevante
- Usare linguaggio business, non tecnico3. カスタムサブエージェントの作成
効果的なサブエージェントを作成するには、ドメインを明確に理解する必要があります 能力と運用上の限界。適切に設計されたサブエージェントは次のようになります。 チームメンバー: 明確な役割を持ち、自分にできることとできないことを知っています。 そして構造化された方法でコミュニケーションします。
サブエージェントのフレームワークの設計
5 つの基本的な質問
- 誰ですか？ エージェントの役割、経験、性格を定義する
- 彼に何ができるでしょうか？ スキルを専門レベルとともにリスト化する
- どのように機能するのでしょうか? 意思決定のプロセスと方法論を説明する
- どこで動作しますか? 境界の定義: 許可されるツール、アクセス可能なファイル
- それは何を生み出すのでしょうか？ 出力形式と構造を指定する
実践例: データベース移行のサブエージェント
.claude/agents/migration-specialist.md
# Database Migration Specialist
## Ruolo
Sei un Database Administrator specializzato in migrazioni di schema.
Ogni migrazione che crei è reversibile, idempotente e sicura per
l'esecuzione in produzione. Consideri sempre l'impatto su tabelle
con milioni di righe e pianifichi migrazioni zero-downtime.
## Competenze
- Schema design: normalizzazione, indici, vincoli (Expert)
- Migration tools: Flyway, Liquibase, Prisma Migrate, TypeORM (Expert)
- Zero-downtime migrations: expand-contract pattern (Expert)
- Performance: lock analysis, index optimization (Advanced)
- Multi-database: PostgreSQL, MySQL, SQLite, MongoDB (Advanced)
- Backup e disaster recovery (Advanced)
## Strumenti Permessi
- Read(*) - Leggere qualsiasi file
- Write(migrations/**/*) - Scrivere file di migrazione
- Write(prisma/migrations/**/*) - Migrazioni Prisma
- Write(src/database/**/*) - File database layer
- Bash(npx prisma *) - Comandi Prisma
- Bash(npx typeorm migration:*) - Comandi TypeORM
- Bash(psql *) - Query PostgreSQL di sola lettura
## Strumenti Negati
- Bash(DROP *) - Mai eseguire DROP in produzione
- Bash(DELETE FROM *) - Mai cancellare dati senza WHERE
- Bash(ALTER TABLE * DROP COLUMN *) - Mai droppare colonne direttamente
- Write(src/**/*.ts) - Non modificare codice applicativo
## Pattern Expand-Contract per Zero-Downtime
### Fase 1: Expand (aggiungere)
1. Aggiungere la nuova colonna (nullable o con default)
2. Deployare il codice che scrive sia nella vecchia che nella nuova colonna
3. Migrare i dati dalla vecchia alla nuova colonna (batch)
### Fase 2: Contract (rimuovere)
4. Deployare il codice che legge dalla nuova colonna
5. Rimuovere la scrittura sulla vecchia colonna
6. Rimuovere la vecchia colonna (in una migrazione successiva)
## Vincoli
- OGNI migrazione deve avere una migration DOWN (rollback)
- Per tabelle grandi (1M+ righe): usare batch processing
- Non usare MAI ALTER TABLE con lock esclusivo su tabelle grandi
- Testare la migrazione su un dump del database di produzione
- Documentare ogni migrazione con commento SQL4. メインエージェントとサブエージェント間の委任パターン
Claude Code のメイン エージェントとサブエージェント間のオーケストレーションは次のとおりです。 明確に定義された委任パターン。これらのパターンを理解することが重要です サブエージェントの可能性を最大限に引き出します。
パターン 1: 直接委任
ユーザーは次のコマンドを使用してサブエージェントを明示的に呼び出します。 /agents
そしてそれに特定のタスクを割り当てます。サブエージェントは自分の中で自律的に動作します
ドメインを指定して結果を報告します。
直接委任の例
# L'utente invoca il subagente code-reviewer
> /agents code-reviewer
# Il subagente analizza le modifiche correnti
> Analizza le modifiche del branch feature/user-profile
# Output: Report strutturato con issue classificate
# Il subagente non modifica codice, solo analizza e riportaパターン 2: 自動ルーティング
マスターエージェントはユーザーのプロンプトを解析し、自動的に委任します。 最も適切なサブエージェントに転送します。このパターンは、サブエージェントが存在する場合に機能します。 それらは明確に異なるドメインを持っています。
自動ルーティングの例
# L'utente chiede qualcosa di specifico
> Scrivi i test unitari per il modulo di pagamento
# Claude riconosce il dominio e delega a unit-test-writer
# Il subagente genera i test seguendo le sue istruzioni
# Altro esempio
> Analizza la sicurezza dell'endpoint /api/auth/login
# Claude delega a security-auditor
# Il subagente esegue l'audit seguendo la sua checklistパターン 3: パイプラインの委任
複数のサブエージェントが順番に呼び出され、1 つのサブエージェントの出力が 次の入力になります。このパターンはワークフローに最適です 複数のドメインにまたがる複合体。
新機能のサブエージェント パイプライン
# Step 1: requirements-analyst
> Analizza i requisiti per il sistema di notifiche push
# Output: Documento requisiti con acceptance criteria
# Step 2: story-writer
> Crea le user stories basandoti sui requisiti appena definiti
# Output: User stories con story points e dipendenze
# Step 3: architect
> Progetta l'architettura per il sistema di notifiche
# Output: ADR + diagrammi C4
# Step 4: typescript-expert
> Implementa il NotificationService seguendo l'architettura
# Output: Codice implementato
# Step 5: unit-test-writer
> Scrivi i test per il NotificationService
# Output: File di test con 80%+ coverage
# Step 6: code-reviewer
> Revisiona tutto il codice prodotto per le notifiche
# Output: Report di code reviewパターン 4: 並列委任
タスクが互いに独立している場合、複数のサブエージェントが動作できます 並行して。このパターンにより、合計時間が大幅に短縮されます 複雑なタスクに。
委任パターンの比較
| パターン | いつ使用するか | 利点 | 制限事項 |
|---|---|---|---|
| 直接 | 特定のドメイン内の単一タスク | 完全な制御、予測可能 | サブエージェントの知識が必要です |
| 自動 | 1 つのドメインに分類されるタスクをクリアする | ユーザーにとって透過的 | 誤ったルーティングの可能性 |
| パイプライン | 依存関係のある複数ステップのワークフロー | 高品質、各フェーズに特化した | 逐次実行時間 |
| 平行 | 同時に実行する独立したタスク | スピード、効率 | 共有ファイルで競合が発生する可能性がある |
5. コミュニティ エコシステム: 100 以上のサブエージェント
リポジトリ 素晴らしいクロードコードサブエージェント 1つを集めます コミュニティで開発された 100 を超えるサブエージェントの厳選されたコレクション。ここ 最も使用されるリソースのドメインごとにまとめられた概要。
コミュニティ サブエージェント カタログ - 上位 50
| # | 復代理人 | カテゴリ | 説明 |
|---|---|---|---|
| 1 | 上級査読者 | 発達 | 20以上の自動チェックによるコードレビュー |
| 2 | バグハンター | 発達 | git bisect を使用した体系的なデバッグ |
| 3 | 大顧問 | 発達 | ADRによる建築コンサルティング |
| 4 | クリーンコーダー | 発達 | クリーンなコードに基づいたリファクタリング |
| 5 | APIデザイナー | 発達 | OpenAPI を使用した RESTful API 設計 |
| 6 | Pythonの第一人者 | 言語 | 型ヒントを備えた慣用的な Python |
| 7 | TSウィザード | 言語 | 高度な TypeScript と文字体操 |
| 8 | 錆びたセンチネル | 言語 | 安全性と性能を重視したRust |
| 9 | ビルダーに行く | 言語 | 同時実行パターンを慣用的に使用する |
| 10 | Javaアーキテクト | 言語 | 仮想スレッドとレコードを備えた Java 21+ |
| 11 | 迅速なエキスパート | 言語 | iOS開発用のSwift/SwiftUI |
| 12 | kotlin エキスパート | 言語 | コルーチンと Compose を備えた Kotlin |
| 13 | ドッカーマスター | DevOps | マルチステージで最適化された Dockerfile |
| 14 | k8s-ナビゲーター | DevOps | Kubernetes マニフェストと Helm チャート |
| 15 | テラフォームプランナー | DevOps | モジュールと状態管理を備えた IaC |
| 16 | gh-アクションビルダー | DevOps | GitHub Actions で最適化されたワークフロー |
| 17 | aws-アーキテクト | DevOps | CDK を使用して適切に設計された AWS |
| 18 | gcp コンサルタント | DevOps | Google Cloud と Terraform |
| 19 | テスト職人 | テスト | 高度なパターンを使用した単体テスト |
| 20 | e2e-オートマタ | テスト | ページ オブジェクトを使用した Playwright e2e |
| 21 | 負荷試験機 | テスト | k6と自走砲による負荷テスト |
| 22 | ペンテスター | 安全 | 自動侵入テスト |
| 23 | 脆弱性スキャナー | 安全 | trivy と snyk で脆弱性をスキャンする |
| 24 | コンプライアンスチェッカー | 安全 | GDPR、SOC2、HIPAA準拠 |
| 25 | データエンジニア | 日付/ミリリットル | Airflow と dbt を使用したパイプライン ETL |
コミュニティ サブエージェント カタログ - 26-50
| # | 復代理人 | カテゴリ | 説明 |
|---|---|---|---|
| 26 | mlエンジニア | 日付/ミリリットル | MLflow トラッキングを使用したモデルのトレーニング |
| 27 | データ品質 | 日付/ミリリットル | データ検証に対する大きな期待 |
| 28 | プロンプトオプティマイザー | 日付/ミリリットル | LLM プロンプトの最適化 |
| 29 | SQLエキスパート | 日付/ミリリットル | Explain プランを使用した最適化された SQL クエリ |
| 30 | プロダクトオーナー | PM | バックログの管理と優先順位付け |
| 31 | スクラムマスター | PM | スプリントの計画と振り返り |
| 32 | テックライター | PM | 専門的な技術文書 |
| 33 | UXレビュアー | PM | ヒューリスティック評価インターフェイス |
| 34 | オンボーディングガイド | PM | 新しい開発者向けのオンボーディング ガイド |
| 35 | 反応エキスパート | 言語 | React 19 とサーバー コンポーネント |
| 36 | 角度の専門家 | 言語 | Angular 18+ スタンドアロンとシグナル |
| 37 | vue-エキスパート | 言語 | Vue 3 構成 API |
| 38 | nextjs-エキスパート | 言語 | Next.js アプリルーターと RSC |
| 39 | グラフキュールアーキテクト | 発達 | GraphQL スキーマとリゾルバーの設計 |
| 40 | マイクロサービスデザイナー | 発達 | DDD を使用したマイクロサービス アーキテクチャ |
| 41 | イベントソーシングエキスパート | 発達 | イベントソーシングとCQRS |
| 42 | 正規表現マスター | 発達 | テストを使用した複雑な正規表現パターン |
| 43 | gitヒストリアン | 発達 | Git 履歴分析とコード考古学 |
| 44 | モニタリングエンジニア | DevOps | プロメテウス、グラファナ、アラート |
| 45 | nginx コンフィギュレーター | DevOps | 最適化されたNginx構成 |
| 46 | SSLマネージャー | 安全 | SSL、Let's Encrypt、TLS 証明書 |
| 47 | a11y-監査人 | テスト | WCAG 2.1 AA アクセシビリティ監査 |
| 48 | seoオプティマイザー | 発達 | 技術的なSEOの最適化 |
| 49 | i18n スペシャリスト | 発達 | 国際化とローカリゼーション |
| 50 | 移行プランナー | 発達 | フレームワークの移行とバージョン |
これら 50 に加えて、リポジトリには数十のより特殊なサブエージェントが含まれています ニッチな分野: ブロックチェーン、IoT、ゲーム開発、リアルタイム システム、 モバイル開発など。各サブエージェントはダウンロードしてカスタマイズできます プロジェクトの特定のニーズに合わせて。
6. 複数のサブエージェント間のオーケストレーション
複数のサブエージェントのオーケストレーションは、最も高度なレベルの使用法です クロード・コード著。それはあなたが作成することができます 仮想チーム 各メンバーがどこに 特定の役割を持ち、共通の目標に貢献します。
パターン チーム: 完全なコード レビュー
マルチアスペクトコードレビューのためのオーケストレーション
# Scenario: Review completa prima di un merge in main
# Step 1: code-reviewer analizza la qualità del codice
> /agents code-reviewer
> Analizza le modifiche del branch feature/payments
# Step 2: security-auditor verifica la sicurezza
> /agents security-auditor
> Esegui audit di sicurezza sul modulo pagamenti
# Step 3: performance-tester identifica bottleneck
> /agents performance-tester
> Analizza le performance del PaymentService
# Step 4: accessibility-auditor (se ci sono modifiche UI)
> /agents a11y-auditor
> Verifica accessibilità dei nuovi componenti UI
# Step 5: Sintesi finale
> Combina i risultati di tutti i review e genera
> un report unificato con priorità di azioneパターンチーム: スプリント計画
スプリント計画のためのオーケストレーション
# Scenario: Pianificazione di un nuovo sprint
# Step 1: requirements-analyst esamina il backlog
> /agents requirements-analyst
> Analizza i requisiti in backlog e identifica i più pronti
# Step 2: story-writer crea le user stories
> /agents story-writer
> Trasforma i requisiti selezionati in user stories
# Step 3: architect valuta la fattibilità tecnica
> /agents architect
> Valuta la complessità tecnica di ogni storia
# Step 4: sprint-master pianifica lo sprint
> /agents sprint-master
> Pianifica lo sprint con velocity 40 story points
> e capacità del team di 3 sviluppatori7. エージェントの専門化のベスト プラクティス
数十のサブエージェントと協力した後、次のことについて明確なパターンが明らかになりました。 効果的なサブエージェントを作成し、よくある落とし穴を回避する方法を説明します。
基本原則
| 原理 | 説明 | Esempio |
|---|---|---|
| 最低特権 | 各エージェントには絶対に必要なツールのみを与えます | コードレビューアはファイルの書き込みはできず、読み取りのみです |
| 明確な境界線 | エージェントドメイン間の明確な境界を定義する | デバッガはテストを作成せず、テスト作成者はデバッグを行いません |
| 明示的な役割 | 役割は一般的なものではなく、具体的なものでなければなりません | 「開発者」ではなく「上級 Python 開発者」 |
| 構造化された出力 | 各エージェントは事前定義された形式で出力を生成します | 標準セクションを含むマークダウン テンプレート |
| べき等アクション | エージェントのアクションは再現可能でなければなりません | 監査を再実行すると同じ結果が得られるはずです |
| プログレッシブディテール | まずは概要、詳細はお問い合わせください | エグゼクティブサマリー + 詳細な調査結果 |
避けるべきアンチパターン
サブエージェントに関するよくある間違い
- ゴッドエージェント: 全てをこなすエージェント。ファイルが 200 行を超える場合は、一般的すぎます。
- ツールの過負荷: エージェントに提供するツールが多すぎると、エージェントの動作の予測可能性が低下します
- あいまいな役割: 「一般専門家」は機能しません。専門性が鍵です
- 出力フォーマットなし: 標準形式がないと、実行ごとに異なる結果が生成されます
- 競合するエージェント: 同じファイルに対する書き込みツールを使用する 2 つのエージェントにより競合が発生する
- 欠落している制約: 明示的な制約がないと、エージェントは予期しない決定を下す可能性があります
- コピー＆ペースト エージェント: 名前を変更するだけではエージェントのクローンを作成できない - すべてをカスタマイズする
サブエージェントの品質指標
サブエージェントを評価する方法
| メトリック | 説明 | ターゲット |
|---|---|---|
| 正確さ | 正しく有用な出力の割合 | > 90% |
| 一貫性 | 異なる実行間で一貫した出力 | > 95% |
| 境界の尊重 | 定義されたツールと境界の尊重 | 100% |
| フォーマットの準拠 | 定義された出力形式の遵守 | > 95% |
| 有用性 | ユーザーにとっての出力の実用的な価値 | > 85% |
結論
特殊なサブエージェントは、クロード コードを 1 人のアシスタントから 1 人のアシスタントに変換します。 仮想専門家のチーム ターミナルで利用可能です。 6つのカテゴリー - 重要な開発、言語、DevOps、テストおよびセキュリティの専門家、 データと ML、プロジェクト管理 - スキル範囲全体をカバーします 現代のソフトウェア開発では必要です。
重要なポイント
- サブエージェント vs スキル: サブエージェントは独自の役割とツールを持つ自律的なアシスタントであり、スキルは受動的知識モジュールです
- マークダウン ファイル
.claude/agents/: 作成、バージョンアップ、共有が簡単 - 6 つのカテゴリであらゆるニーズをカバーします。 開発、言語、DevOps、テスト、データ/ML、PM
- 最低特権: 各エージェントには絶対に必要なツールのみを与えます
- 4 つの委任パターン: 各シナリオの直接、自動、パイプライン、並列
- コミュニティからの 100 人以上のサブエージェント: 出発点としてのawesome-claude-code-subagentsリポジトリ
- マルチエージェントオーケストレーション: レビュー、スプリント計画、監査などの複雑なタスクのための仮想チーム
- 構造化された出力: 各エージェントはデフォルト形式でレポートを作成する必要があります
Nel 次の記事 私たちはそれらを探索します フックと自動化: 応答して自動アクションを実行できるようにするイベント駆動型のメカニズム クロード コードのワークフロー内の特定のイベントに適用されます。フックを作成する方法を見ていきます。 コミット前、ビルド後、デプロイ前など、パイプラインの構築 手動介入を必要としない高度な自動化を実現します。