1. What task should this agent handle?
2. What expertise/role should it have?
3. Who will use it — team or personal?
4. What should it be able to do vs NOT do?
5. How should it present results?

What specific task should this agent handle?
├── Code review (quality, security, style)
├── Debugging (error investigation, root cause)
├── Testing (run tests, fix failures)
├── Documentation (generate, verify, update)
└── Other: [describe]

Who will use this agent?
├── Just me (personal: ~/.claude/agents/)
├── My team (project: .claude/agents/)

[Role/Expertise] + [What it does] + [When to invoke] + [Trigger terms]

description: Helps with code

description: Expert code reviewer specializing in security and quality. Reviews code changes for vulnerabilities, best practices, and maintainability. Use when reviewing code, checking PRs, or when the user mentions code review, pull request review, or security audit.

1. Role/Expertise: "Expert code reviewer specializing in security and quality"
2. What it does: "Reviews code changes for vulnerabilities, best practices, and maintainability"
3. When to invoke: "Use when reviewing code, checking PRs"
4. Trigger terms: "code review, pull request review, or security audit"

• "Use PROACTIVELY after code changes"
• "MUST be invoked when tests fail"
• "Automatically use when user mentions..."

• Actions: review, analyze, debug, fix, test, check, audit
• Objects: code, PR, tests, errors, performance, security
• Contexts: before deploy, after changes, when failing, during review

1. [First action — gather context]
2. [Second action — analyze/process]
3. [Third action — produce output]
4. [Fourth action — verify/validate]

• Specific thing to check
• Another thing to verify
• Important consideration

• What NOT to do
• Boundaries to respect

**System Prompt Patterns**:

**1. Role Definition**:
```markdown
You are a senior code reviewer specializing in security vulnerabilities.
Your primary focus is identifying OWASP Top 10 risks.

undefined

1. Run

   git diff HEAD

   to see recent changes
2. Identify modified files and their purpose
3. Review each change against security checklist
4. Present findings with severity levels

**3. Checklist Pattern**:
```markdown

• No SQL injection vulnerabilities
• Input validation on all boundaries
• No exposed secrets or credentials
• Proper authentication checks
• Authorization verified for each endpoint

**4. Output Format**:
```markdown

• Do NOT modify code unless explicitly asked
• Do NOT change API contracts
• Focus ONLY on security-related issues
• ALWAYS explain WHY something is a risk

**6. Decision Tree (for branching logic)**:
```markdown

Review my recent code changes Check this PR for security issues Audit the authentication module

Use the code-reviewer agent to check this

**Verify Tool Access**:
```bash

• code-reviewer: Systematic code review for quality and style
• security-auditor: OWASP-focused vulnerability detection
• performance-analyzer: Identify bottlenecks and inefficiencies
• architecture-reviewer: Assess design patterns and structure

• debugger: Root cause analysis for errors
• test-runner: Execute tests and fix failures
• refactorer: Safe code restructuring
• pr-reviewer: Pull request analysis

• codebase-explorer: Navigate and understand code structure
• dependency-auditor: Check for outdated/vulnerable packages
• documentation-checker: Verify docs match implementation

• commit-helper: Generate meaningful commit messages
• deploy-checker: Pre-deployment verification
• migration-assistant: Framework/version upgrade help

1. Run

   git diff HEAD

   to see recent changes
2. Focus on modified files
3. Review systematically

undefined

• Critical: [must fix]
• Warning: [should fix]
• Suggestion: [nice to have]

---

• Task is complex and multi-step
• Task benefits from fresh, focused context
• You want to restrict available tools
• Task doesn't need full conversation history
• You want consistent, reusable behavior

• Templates: See

  templates/

  for progressive examples
• Examples: See

  examples/

  for 18 complete working agents
• Reference: See

  reference/

  for syntax guide, best practices, troubleshooting

1. [First step]
2. [Second step]
3. [Third step]

**3. Test**:

[Natural language request matching description]

**4. Iterate**:
- Not discovered? → Make description more specific
- Wrong output? → Clarify output format
- Can't do something? → Add necessary tools