Prometheus Agent

{
  "model": "claude-opus-4-6",
  "variant": "max",
  "thinking": {
    "type": "enabled",
    "budgetTokens": 32000
  }
}

{
  "model": "gpt-5.2",
  "variant": "high",
  "reasoningEffort": "high"
}

{
  "model": "gemini-3.1-pro",
  "variant": "high"
}

## Interview Phase

I need to understand a few things before creating the plan:

1. **Architecture preference**: Do you want to use REST or GraphQL for the API?
   - Impact: Affects endpoint structure and data fetching patterns
   - Default: I'll assume REST based on existing codebase patterns

2. **Authentication approach**: Should we use JWT tokens or session-based auth?
   - Impact: Changes security model and client-side storage
   - Recommendation: JWT for stateless API

3. **Database migration**: Should I plan for backward-compatible schema changes?
   - Impact: Determines migration strategy and rollback complexity
   - Risk: Breaking changes require coordinated deployment

# Feature: User Authentication System

## Overview
Implement JWT-based authentication with role-based access control.

## Prerequisites
- [ ] Review existing user model
- [ ] Check for existing auth middleware
- [ ] Verify bcrypt installation

## Implementation Tasks

### Phase 1: Core Authentication
- [ ] **T1.1**: Create JWT token service (`src/services/auth/token.ts`)
  - Generate access tokens (15min expiry)
  - Generate refresh tokens (7day expiry)
  - Token validation and decoding
  
- [ ] **T1.2**: Implement auth middleware (`src/middleware/auth.ts`)
  - Extract token from Authorization header
  - Validate token signature
  - Attach user to request object
  - Handle expired tokens

### Phase 2: User Endpoints
- [ ] **T2.1**: POST /api/auth/register
  - Validate email format and password strength
  - Hash password with bcrypt
  - Create user record
  - Return access + refresh tokens
  
- [ ] **T2.2**: POST /api/auth/login
  - Verify credentials
  - Return tokens
  
- [ ] **T2.3**: POST /api/auth/refresh
  - Validate refresh token
  - Issue new access token

### Phase 3: Testing
- [ ] **T3.1**: Unit tests for token service
- [ ] **T3.2**: Integration tests for auth endpoints
- [ ] **T3.3**: E2E test for full auth flow

## Risk Mitigation

### Security
- Store JWT secret in environment variable
- Use httpOnly cookies for refresh tokens
- Implement rate limiting on auth endpoints
- Add CSRF protection

### Performance
- Cache token validation results (Redis)
- Use short access token expiry
- Implement token blacklist for logout

## Verification Checklist
- [ ] All tests passing
- [ ] Security review completed
- [ ] Documentation updated
- [ ] API documented in Swagger/OpenAPI

.sisyphus/
└── plans/
    ├── user-authentication.md
    ├── dark-mode-implementation.md
    └── api-rate-limiting.md

# {Feature Name}

## Overview
{High-level summary}

## Prerequisites
- [ ] {Prerequisite task 1}
- [ ] {Prerequisite task 2}

## Implementation Tasks

### Phase 1: {Phase Name}
- [ ] **T1.1**: {Task description}
  {Task details}
  
### Phase 2: {Phase Name}
...

## Risk Mitigation

### {Risk Category}
- {Mitigation strategy 1}
- {Mitigation strategy 2}

## Verification Checklist
- [ ] {Verification item 1}
- [ ] {Verification item 2}

// User invokes Prometheus via /start-work or explicitly
// Request: "Plan implementation of file upload feature with S3"

// Prometheus: Interview mode
"I need clarification on a few points before creating the plan:

1. **File size limits**: What's the maximum file size we should support?
   - Affects multipart upload strategy
   - Recommendation: 100MB for standard, 5GB for large files

2. **Access control**: Should uploaded files be public or private?
   - Public: Direct S3 URLs
   - Private: Pre-signed URLs with expiry
   
3. **File types**: Any restrictions on allowed file types?
   - Security consideration: Prevent executable uploads
   
4. **Storage strategy**: Should we organize files by user, date, or type?
   - Affects S3 bucket structure and retrieval patterns"

// User provides answers
// Prometheus generates detailed plan
"Plan saved to .sisyphus/plans/file-upload-s3.md

✓ 3 phases identified
✓ 12 atomic tasks defined
✓ 5 security mitigations documented
✓ 8 verification criteria established

Ready to execute with /start-work file-upload-s3"

// Request: "Create a plan to refactor the payment processing module"

// Prometheus: Analysis phase
"Analyzing existing payment module structure..."
// Searches codebase for payment-related code
// Identifies current architecture

"Found payment logic spread across:
- src/services/payment/stripe.ts (Stripe integration)
- src/services/payment/paypal.ts (PayPal integration) 
- src/routes/checkout.ts (Mixed business logic)
- src/utils/currency.ts (Scattered helpers)

Key issues identified:
1. No abstraction over payment providers
2. Business logic mixed with API routes
3. Missing error recovery patterns
4. No audit logging

Proposed approach: Payment Strategy Pattern
- Abstract payment provider interface
- Centralize business logic in service layer
- Add comprehensive error handling
- Implement audit trail"

// Generates comprehensive refactoring plan
"Plan saved to .sisyphus/plans/payment-refactor.md

✓ 4 phases (Extract, Abstract, Test, Migrate)
✓ 15 tasks with detailed steps
✓ Backward compatibility maintained
✓ Rollback strategy documented"

# 1. Generate plan with Prometheus
/start-work "implement user authentication"
# Prometheus creates .sisyphus/plans/user-authentication.md

# 2. Execute plan with Atlas
# Atlas reads the plan file
# Delegates tasks to appropriate agents/categories
# Tracks progress via todos
# Verifies completion

{
  "agents": {
    "prometheus": {
      "model": "anthropic/claude-opus-4-6",
      "variant": "max",
      "temperature": 0.1,
      "thinking": {
        "type": "enabled",
        "budgetTokens": 32000
      },
      "prompt_append": "Additional planning guidelines...",
      "disable": false
    }
  }
}