Expert Technical Bot

Your general-purpose technical advisor agent for software engineering guidance, code reviews, architecture decisions, and best practices across languages and frameworks.

When to Use This Agent

Choose Expert Technical Bot when:

• Seeking broad technical advice across multiple domains
• Reviewing code for quality, performance, and best practices
• Making technology selection decisions for new projects
• Getting second opinions on architectural approaches
• Learning new technologies with guided recommendations

Consider alternatives when:

• You need deep expertise in a specific domain — use a specialized agent (Azure, Terraform, React, etc.)
• You need to write production code — use a language or framework-specific agent
• You need operational support (deployment, monitoring) — use a DevOps or SRE agent

Quick Start

Copy
# .claude/agents/technical-expert.yml
name: Expert Technical Bot
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: General-purpose technical advisor for code review, architecture decisions, and engineering best practices

Example invocation:

claude "Review our service architecture and recommend whether we should adopt an event-driven pattern for our order processing pipeline, considering our team size of 8 and current monolithic Node.js backend"

Core Concepts

Technical Decision Framework

Factor	Questions to Ask	Trade-offs
Team	What's the team size and skill set?	Familiar tech vs optimal tech
Scale	What's the current and projected scale?	Simplicity vs scalability
Timeline	When does this need to ship?	Speed vs thoroughness
Maintenance	Who maintains this long-term?	Build vs buy
Integration	What existing systems must it work with?	Compatibility vs ideal design
Budget	What are the infrastructure cost constraints?	Performance vs cost

Code Review Priorities

Priority 1: Correctness
  └─ Does it work? Are there logic errors, race conditions, edge cases?

Priority 2: Security
  └─ Input validation, auth checks, injection prevention, data exposure?

Priority 3: Performance
  └─ Unnecessary allocations, N+1 queries, missing caching, blocking I/O?

Priority 4: Maintainability
  └─ Readable code, clear naming, appropriate abstractions, test coverage?

Priority 5: Style
  └─ Consistent formatting, idiomatic patterns, documentation?

Configuration

Parameter	Description	Default
expertise_areas	Focus domains (backend, frontend, devops, data)	all
review_depth	Review thoroughness (quick, standard, thorough)	standard
language_focus	Primary languages for advice	auto-detect
risk_tolerance	Approach to recommendations (conservative, balanced, progressive)	balanced
context_level	How much context to consider (local, service, system)	service

Best Practices

1. Evaluate technology choices by team capability, not just technical merit. The best technology is the one your team can effectively build, debug, and maintain. A "perfect" architecture in an unfamiliar stack will be slower and buggier than a "good enough" solution in a technology your team knows well.

2. Prioritize correctness and security over performance in code reviews. A fast function with a security vulnerability or logic error is worse than a slow function that works correctly. Optimize for correctness first, then profile to find actual bottlenecks — premature optimization is still the root of most evil.

3. Give specific, actionable review feedback with examples. "This could be improved" is unhelpful. "Extract this 50-line method into three focused methods — here's how the split would look" gives the developer a clear path forward. Include code snippets when suggesting changes.

4. Consider the reversibility of decisions. Two-way door decisions (easily reversed) can be made quickly. One-way door decisions (hard to reverse — database schema, API contracts, framework choice) deserve more analysis and discussion. Calibrate your decision-making effort accordingly.

5. Recommend the simplest solution that solves the current problem. Adding Kafka for a system that processes 100 events per day is over-engineering. Start with the simplest viable approach (a database queue, a cron job) and evolve when the actual scale demands it.

Common Issues

Analysis paralysis on technology selection. Too many options and too much evaluation creates decision deadlock. Set a time-box (2-3 days max), evaluate no more than 3 options against your specific requirements, build a quick prototype with the top candidate, and decide.

Code reviews become style debates instead of quality checks. Enforce style through automated tooling (Prettier, ESLint, Black) so reviewers focus on logic, security, and architecture. If the formatter doesn't flag it, it's not a style issue worth debating in review.

Technical recommendations don't account for organizational context. A technically optimal solution that requires cross-team coordination in a siloed organization will fail. Consider organizational structure, team boundaries, approval processes, and political dynamics when making recommendations.