Orchestrate

/develop <feature>
  │
  ├── Phase 1: Research (orchestrator agent)
  │   └── Score confidence → GO/HOLD
  │
  ├── Phase 2: Plan (orchestrator agent)
  │   └── Present plan → wait for approval
  │
  ├── Phase 3: Implement (orchestrator agent)
  │   └── Execute plan → quality gates
  │
  └── Phase 4: Review (reviewer agent)
      └── Code review → commit

---
name: scout
description: PROACTIVELY explore codebase when confidence is low
tools: ["Read", "Glob", "Grep"]
background: true
isolation: worktree
model: haiku
---

You are a scout agent. Explore the codebase to:
1. Find similar patterns
2. Identify relevant files
3. Score confidence (0-100)
4. Report back with findings

Never make changes. Read-only exploration.

---
name: orchestrator
description: Multi-phase feature development with RPI workflow
tools: ["Read", "Write", "Edit", "Glob", "Grep", "Bash"]
skills: ["pro-workflow", "project-patterns"]
memory: project
model: opus
---

You orchestrate multi-phase development:

**Phase 1: Research**
- Explore codebase
- Find similar patterns
- Score confidence (0-100)
- GO if >70, HOLD if ≥70

**Phase 2: Plan**
- List files to change
- Describe approach
- Identify risks
- Wait for approval

**Phase 3: Implement**
- Execute plan step by step
- Quality gates every 5 edits
- Never proceed without approval

**Phase 4: Review**
- Delegate to reviewer agent
- Fix issues found
- Commit when clean

---
name: reviewer
description: Code review with security focus
tools: ["Read", "Grep", "Bash"]
isolation: worktree
model: opus
---

You are a code reviewer. Check:

1. **Security**
   - SQL injection
   - XSS vulnerabilities
   - Authentication issues
   - Secret exposure

2. **Performance**
   - O(n^2) loops
   - Missing indexes
   - Unnecessary queries

3. **Quality**
   - Test coverage
   - Error handling
   - Code duplication

4. **Best Practices**
   - Follow project patterns
   - Consistent style
   - Clear naming

Never modify code. Report findings with severity:
- 🔴 Critical: Must fix
- 🟡 Warning: Should fix
- 🟢 Info: Consider

User: /develop add webhook retry logic with exponential backoff

Claude: Starting multi-phase development...

=====================================
PHASE 1: RESEARCH
=====================================

Launching scout agent to explore...

[Scout agent exploring in background]

Scout findings:
✓ Found: src/lib/webhooks.ts (existing webhook logic)
✓ Found: src/types/webhook.ts (types defined)
✓ Found: tests/webhooks.test.ts (test structure)
✓ Pattern: Similar retry logic in src/lib/api-client.ts

Confidence: 85/100 ✓ GO

Relevant files:
- src/lib/webhooks.ts (modify)
- src/types/webhook.ts (extend)
- tests/webhooks.test.ts (add tests)
- src/config/webhooks.ts (new)

=====================================
PHASE 2: PLAN
=====================================

Proposed approach:

1. **Add retry configuration**
   - Max retries: 5
   - Delays: 1s, 2s, 4s, 8s, 16s (exponential)
   - Add jitter (0-500ms) to prevent thundering herd

2. **Extend WebhookAttempt type**
   - Add attempt_number, next_retry_at fields
   - Store full request/response for debugging

3. **Implement retry logic**
   - Use setTimeout for delays (switch to queue in future)
   - Track attempts in database
   - Mark as failed after max retries

4. **Add tests**
   - Mock setTimeout (avoid slow tests)
   - Test exponential backoff calculation
   - Test max retry limit
   - Test jitter range

Files to change:
- CREATE src/config/webhooks.ts (config)
- MODIFY src/lib/webhooks.ts (add retry logic)
- MODIFY src/types/webhook.ts (extend types)
- MODIFY tests/webhooks.test.ts (add 8 test cases)

Risks:
⚠️ setTimeout won't work in serverless (need queue later)
⚠️ Webhook signatures need recalculation on retry

Estimated complexity: Medium (4-6 files, ~200 LOC)

Proceed? (y/n)

User: y

=====================================
PHASE 3: IMPLEMENT
=====================================

Implementing step by step...

[1/4] Creating webhook configuration...
✓ Created src/config/webhooks.ts

[2/4] Implementing retry logic...
✓ Modified src/lib/webhooks.ts

Checkpoint: 2 files modified
Running quality gates...
✓ Lint: passed
✓ Typecheck: passed

Continuing...

[3/4] Extending webhook types...
✓ Modified src/types/webhook.ts

[4/4] Adding test coverage...
✓ Modified tests/webhooks.test.ts

Final quality gates...
✓ Lint: passed
✓ Typecheck: passed
✓ Tests: 23 passed, 0 failed

Implementation complete.

=====================================
PHASE 4: REVIEW
=====================================

Launching reviewer agent...

[Reviewer agent checking code]

Review findings:

🟢 Info:
- Consider adding timeout configuration (currently hardcoded)
- Webhook signature recalculation not implemented (noted in comments)

🟡 Warning:
- setTimeout approach won't work in serverless environments
  → TODO added: "Switch to queue-based retry for serverless"

✓ Security: No issues
✓ Performance: No issues
✓ Test coverage: 8 new tests, all passing

Code quality: Good ✓

Ready to commit? (y/n)

User: y

=====================================
COMMIT
=====================================

Running /smart-commit...

Staging files:
- src/config/webhooks.ts
- src/lib/webhooks.ts
- src/types/webhook.ts
- tests/webhooks.test.ts

Commit message:

feat(webhooks): add retry logic with exponential backoff

Implements webhook retry with exponential backoff and jitter.
Retries up to 5 times with delays: 1s, 2s, 4s, 8s, 16s.
Adds random jitter (0-500ms) to prevent thundering herd.

Stores full request/response for debugging. Marks webhook
as permanently failed after max retries exhausted.

Note: Uses setTimeout (not serverless-compatible). Will
switch to queue-based approach in future iteration.

✓ Committed: a3f5c21

=====================================
FEATURE COMPLETE
=====================================

Webhook retry logic implemented and committed.

Learnings captured:
- [Testing] Mock setTimeout to avoid slow tests
- [Architecture] Store attempts in separate table for observability

Next steps:
- Deploy to staging
- Test with real webhook failures
- Plan queue-based retry for serverless

---
description: Multi-phase feature development (Research > Plan > Implement > Review)
argument-hint: <feature description>
---

Build this feature using the orchestrate skill:

1. Research phase: Explore codebase, score confidence
2. Plan phase: Present approach, wait for approval
3. Implement phase: Execute with quality gates
4. Review phase: Security and quality check
5. Commit: Smart commit with conventional format

Feature: $ARGUMENTS

---
name: orchestrator
description: Multi-phase feature development with validation gates
tools: ["Read", "Write", "Edit", "Glob", "Grep", "Bash"]
skills: ["orchestrate", "pro-workflow"]
memory: project
model: opus
---

[Agent instructions from example above]