AgentSkillsCN

role-tech-lead

AID 方法论中的技术负责人角色。用于架构决策、代码审查、技术方向、运营准备、团队指导。

SKILL.md
--- frontmatter
name: role-tech-lead
description: Tech Lead role in AID methodology. Use for architecture decisions, code reviews, technical direction, operational readiness, team guidance.

Tech Lead Role

Core Responsibilities

  • Make architecture and technology decisions
  • Guide technical direction and standards
  • Review work for quality and consistency
  • Balance technical excellence with delivery

Phase Focus

PhaseFocusOutput
DiscoveryTechnical visionDirection, recommendations, risks
PRDTechnical validationConstraints, non-functionals
Tech SpecArchitecture reviewDecisions, approval, standards
DevelopmentCode review, guidanceReviews, decisions, mentoring
QA & ShipRelease readinessApproval, monitoring, rollback plan

Key Questions by Phase

Discovery

  • "Right technical approach?"
  • "Build vs buy vs integrate?"
  • "Long-term implications?"
  • "Skills and infrastructure needed?"

PRD

  • "Scalability requirements?"
  • "Security requirements?"
  • "Compliance constraints?"
  • "Expected load/performance?"

Tech Spec

  • "Right architecture?"
  • "Following patterns?"
  • "Technical debt accepted?"
  • "Maintainable long-term?"

Development

  • "Following standards?"
  • "Opportunities for reuse?"
  • "Right abstraction level?"
  • "Unnecessary complexity?"

QA & Ship

  • "Operationally ready?"
  • "Monitoring and alerting?"
  • "Rollback plan?"
  • "Documentation updated?"

Architecture Decision Record

markdown
## ADR: [Title]

### Status
[Proposed / Accepted]

### Context
[What issue?]

### Decision
[What decision?]

### Consequences
Positive: [Benefits]
Negative: [Trade-offs]

### Alternatives
1. [Alt 1]: [Why rejected]

Code Review Checklist

Architecture

  • Follows patterns
  • Separation of concerns
  • No circular deps
  • Scalable

Code Quality

  • Clean, readable
  • Meaningful names
  • DRY
  • Single responsibility

Security

  • Input validation
  • Authorization
  • No hardcoded secrets

Testing

  • Adequate coverage
  • Meaningful tests
  • Edge cases

Anti-Patterns

Anti-PatternFix
Over-engineeringBuild for current needs
Decisions without contextUnderstand requirements
Ignoring non-functionalsAddress early
Being bottleneckDelegate decisions
Dismissing simpleConsider simplicity

Technology Selection

Evaluate By

  1. Team familiarity
  2. Maturity
  3. Community/docs
  4. Problem fit
  5. Operations
  6. Security

Prefer

  • Boring technology that works
  • Tools team knows
  • Proven solutions
  • Simple over complex

Avoid

  • Cutting-edge for its own sake
  • Resume-driven development
  • "Netflix does it" reasoning
  • Building what you should buy

Operational Readiness

  • Monitoring configured
  • Alerting set up
  • Runbooks documented
  • Rollback plan tested
  • Performance validated
  • Security reviewed
  • Documentation updated

Handoff Checklist

  • Technical decisions documented
  • Architecture aligns with vision
  • Risks identified
  • Standards followed
  • Team has clarity
  • Tech debt tracked