CRITICAL CONSTRAINTS:
- Do NOT modify any source files
- Do NOT write any code
- Your ONLY output must be a markdown file written to ./tmp/second-opinion-[topic].md
- The markdown file must contain: findings, analysis, recommendations, and suggested implementation approach
- Investigate thoroughly first, then write the summary file

mkdir -p ./tmp && codex exec --full-auto "
CRITICAL CONSTRAINTS:
- Do NOT modify any source files
- Do NOT write any code
- Your ONLY output must be a markdown file written to ./tmp/second-opinion-[bug-name].md
- Investigate thoroughly, then write the summary

PROBLEM:
[Clear description of the bug]

SYMPTOMS:
- [Observable behavior]
- [Error messages or logs]
- [Affected environments/scenarios]

INVESTIGATION SO FAR:
1. [What you checked]
2. [Debugging performed]
3. [Hypotheses ruled out]

RELEVANT CODE:
[Code snippets or file paths]

After thorough investigation, write ./tmp/second-opinion-[bug-name].md with:
1. Root cause analysis
2. Why it's happening
3. Recommended fix approach
4. Alternative approaches considered
5. Risks and trade-offs
"

mkdir -p ./tmp && codex exec --full-auto "
CRITICAL CONSTRAINTS:
- Do NOT modify any source files
- Do NOT write any code
- Your ONLY output must be a markdown file written to ./tmp/second-opinion-[feature-name].md
- Investigate the codebase thoroughly, then write the summary

FEATURE REQUEST:
[What needs to be implemented]

CURRENT ARCHITECTURE:
[Relevant system components and patterns]

PROPOSED APPROACH:
[Your initial design]

CONSTRAINTS:
- [Technical constraints]
- [Performance requirements]

CONCERNS:
- [What you're uncertain about]
- [Potential risks or trade-offs]

After thorough investigation, write ./tmp/second-opinion-[feature-name].md with:
1. Assessment of proposed approach
2. Recommended approach (may differ)
3. Key trade-offs
4. Implementation guidance
5. Risks to watch out for
"

# Include specific files for review
mkdir -p ./tmp && codex exec --full-auto -i /path/to/file1.go -i /path/to/file2.go "
CRITICAL CONSTRAINTS:
- Do NOT modify any source files
- Write findings to ./tmp/second-opinion-[topic].md only

Review these files and write your analysis of [issue] to ./tmp/second-opinion-[topic].md
"

# Execute in specific directory context
mkdir -p ./tmp && codex exec --full-auto -C /path/to/project "
CRITICAL CONSTRAINTS:
- Do NOT modify any source files
- Write findings to ./tmp/second-opinion-[topic].md only

Investigate [topic] and write your analysis to ./tmp/second-opinion-[topic].md
"

# Use specific model for deep analysis
mkdir -p ./tmp && codex exec --full-auto -m o3 "
CRITICAL CONSTRAINTS:
- Do NOT modify any source files
- Write findings to ./tmp/second-opinion-[topic].md only

[Your investigation request]
"

mkdir -p ./tmp && codex exec --full-auto "
CRITICAL CONSTRAINTS:
- Do NOT modify any source files
- Write findings to ./tmp/second-opinion-lambda-timeout.md only

PROBLEM:
Lambda function times out at 30s, but local tests complete in 2s. The function:
- Queries DynamoDB (5 items, takes ~100ms locally)
- Calls OpenAI API (takes ~3s locally)
- Writes to S3 (takes ~200ms locally)

CloudWatch logs show the function starts, logs 'Fetching from DynamoDB', then times out 30s later with no further logs.

Lambda is in a private subnet with VPC endpoints for DynamoDB and S3. Security groups allow all outbound. NAT Gateway is healthy.

Investigate the codebase, review the Lambda and VPC configuration, then write ./tmp/second-opinion-lambda-timeout.md with:
1. Root cause hypothesis
2. Evidence supporting it
3. Recommended fix approach
4. How to verify the fix
"

mkdir -p ./tmp && codex exec --full-auto "
CRITICAL CONSTRAINTS:
- Do NOT modify any source files
- Write findings to ./tmp/second-opinion-dynamo-migration.md only

CONTEXT:
We need to migrate from single DynamoDB table to separate tables for:
1. Job results (hot data, frequent reads)
2. Analysis metadata (cold data, infrequent reads)

Current table: 50GB, composite PK/SK pattern

Our philosophy (from PROJECT_KNOWLEDGE.md): delete aggressively, never preserve backwards compatibility.

Investigate the current table usage and access patterns in the codebase, then write ./tmp/second-opinion-dynamo-migration.md with:
1. Assessment of migration complexity
2. Recommended migration approach (aligned with no-backwards-compatibility philosophy)
3. Key risks
4. Suggested implementation order
"

mkdir -p ./tmp && codex exec --full-auto -C /Users/noy/Code/deway-main/backend-aws "
CRITICAL CONSTRAINTS:
- Do NOT modify any source files
- Write findings to ./tmp/second-opinion-retry-logic.md only

Review the async patterns in apps/ and modules/ and assess a proposed approach for adding retry logic:

PROPOSAL:
Add retry with exponential backoff for:
- External API calls (OpenAI, data sources)
- S3 uploads
- DynamoDB writes

Context: Lambdas are event-driven (EventBridge), no SQS queue, 5min timeout.

After investigation, write ./tmp/second-opinion-retry-logic.md with:
1. Assessment of whether retries belong at handler vs service level
2. Idempotency considerations for DynamoDB writes
3. Whether exponential backoff fits all cases
4. Recommended approach with rationale
"