Using Ring Developer Specialists

The ring-dev-team plugin provides 7 specialized developer agents. Use them via Task tool with subagent_type:.

See CLAUDE.md and ring:using-ring for canonical workflow requirements and ORCHESTRATOR principle. This skill introduces dev-team-specific agents.

Remember: Follow the ORCHESTRATOR principle from ring:using-ring. Dispatch agents to handle complexity; don't operate tools directly.

Blocker Criteria - STOP and Report

<block_condition>

• Technology Stack decision needed (Go vs TypeScript)
• Architecture decision needed (monolith vs microservices)
• Infrastructure decision needed (cloud provider)
• Testing strategy decision needed (unit vs E2E) </block_condition>

If any condition applies, STOP and ask user.

always pause and report blocker for:

You CANNOT make technology decisions autonomously. STOP and ask.

Common Misconceptions - REJECTED

See shared-patterns/shared-anti-rationalization.md for universal anti-rationalizations (including Specialist Dispatch section).

Self-sufficiency bias check: If you're tempted to implement directly, ask:

1. Is there a specialist for this? (Check the 7 specialists below)
2. Would a specialist follow standards I might miss?
3. Am I avoiding dispatch because it feels like "overhead"?

If any answer is yes → You MUST DISPATCH the specialist. This is NON-NEGOTIABLE.

Anti-Rationalization Table

See shared-patterns/shared-anti-rationalization.md for universal anti-rationalizations (including Specialist Dispatch section and Universal section).

Cannot Be Overridden

<cannot_skip>

• Dispatch to specialist (standards loading required)
• 6-gate development cycle (quality gates)
• Parallel reviewer dispatch (not sequential)
• TDD in Gate 0 (test-first)
• User approval in Gate 5 </cannot_skip>

These requirements are NON-NEGOTIABLE:

User cannot override these. Time pressure cannot override these. "Simple task" cannot override these.

Pressure Resistance

See shared-patterns/shared-pressure-resistance.md for universal pressure scenarios (including Combined Pressure Scenarios and Emergency Response).

Critical Reminder:

• Urgency ≠ Permission to bypass - Emergencies require MORE care, not less
• Authority ≠ Permission to bypass - Ring standards override human preferences
• Sunk Cost ≠ Permission to bypass - Wrong approach stays wrong at 80% completion

Emergency Response Protocol

See shared-patterns/shared-pressure-resistance.md → Emergency Response section for the complete protocol.

Emergency Dispatch Template:

Task tool:
  subagent_type: "ring:backend-engineer-golang"
  model: "opus"
  prompt: "URGENT PRODUCTION INCIDENT: [brief context]. [Your specific request]"

IMPORTANT: Specialist dispatch takes 5-10 minutes, not hours. This is NON-NEGOTIABLE even under CEO pressure.

Combined Pressure Scenarios

See shared-patterns/shared-pressure-resistance.md → Combined Pressure Scenarios section.

7 Developer Specialists

<dispatch_required agent="{specialist}" model="opus"> Use Task tool to dispatch appropriate specialist based on technology need. </dispatch_required>

Dispatch template:

Task tool:
  subagent_type: "ring:{agent-name}"
  model: "opus"
  prompt: "{Your specific request with context}"

Note: ring:frontend-designer = visual aesthetics. frontend-bff-engineer-typescript = business logic/architecture.

When to Use Developer Specialists vs General Review

Use Developer Specialists for:

• ✅ Deep technical expertise needed – Architecture decisions, complex implementations
• ✅ Technology-specific guidance – "How do I optimize this Go service?"
• ✅ Specialized domains – Infrastructure, SRE, testing strategy
• ✅ Building from scratch – New service, new pipeline, new testing framework

Use General Review Agents for:

• ✅ Code quality assessment – Architecture, patterns, maintainability
• ✅ Correctness & edge cases – Business logic verification
• ✅ Security review – OWASP, auth, validation
• ✅ Post-implementation – Before merging existing code

Both can be used together: Get developer specialist guidance during design, then run general reviewers before merge.

Dispatching Multiple Specialists

If you need multiple specialists (e.g., backend engineer + DevOps engineer), dispatch in parallel (single message, multiple Task calls):

✅ CORRECT:
Task #1: ring:backend-engineer-golang
Task #2: ring:devops-engineer
(Both run in parallel)

❌ WRONG:
Task #1: ring:backend-engineer-golang
(Wait for response)
Task #2: ring:devops-engineer
(Sequential = 2x slower)

ORCHESTRATOR Principle

Remember:

• You're the orchestrator – Dispatch specialists, don't implement directly
• Don't read specialist docs yourself – Dispatch to specialist, they know their domain
• Combine with ring:using-ring principle – Skills + Specialists = complete workflow

Good Example (ORCHESTRATOR):

"I need a Go service. Let me dispatch ring:backend-engineer-golang to design it."

Bad Example (OPERATOR):

"I'll manually read Go best practices and design the service myself."

Available in This Plugin

Agents: See "7 Developer Specialists" table above.

Skills: ring:using-dev-team (this), ring:dev-cycle (6-gate workflow), ring:dev-refactor (codebase analysis)

Commands: /ring:dev-cycle (execute tasks), /ring:dev-refactor (analyze codebase)

Note: Missing agents? Check .claude-plugin/marketplace.json for ring-dev-team plugin.

Development Workflows

All workflows converge to the 6-gate development cycle:

6-Gate Development Cycle:

Key Principle: All development follows the same 6-gate process.

Integration with Other Plugins

• ring:using-ring (default) – ORCHESTRATOR principle for all agents
• ring:using-pm-team – Pre-dev workflow agents
• ring:using-finops-team – Financial/regulatory agents

Dispatch based on your need:

• General code review → default plugin agents
• Specific domain expertise → ring-dev-team agents
• Feature planning → ring-pm-team agents
• Regulatory compliance → ring-finops-team agents