Advanced Workflows

> Create a function to fetch user data from the API and cache it.
> Focus on making it work. Don't worry about edge cases yet.

> Now add tests for this function. Cover:
> - Successful fetch
> - Network error
> - Invalid response
> - Cache hit

> Now improve the implementation:
> - Handle rate limiting
> - Add retry logic with backoff
> - Handle partial responses

> Review for production readiness:
> - Proper error messages
> - Logging
> - Type safety
> - Documentation

/add $(git diff --name-only main)
> Review these changes as if you were a senior developer.
> Focus on:
> - Logic errors
> - Edge cases that might be missed
> - Performance concerns
> - Security issues
> Flag anything that concerns you.

> Good catch on the SQL injection risk. Fix it.

> That edge case you mentioned—add a test for it.

> Add error handling for the scenarios you identified.

> We need to convert all callback-based async code to async/await.
> First, scan the codebase and list all files that need changing.
> Group them by complexity (simple, moderate, complex).

> Create a markdown file showing before/after examples for our patterns.
> This will be the reference for the refactor.

# Session 1
/add src/utils/*.js
> Convert these files to async/await. Follow the migration guide.

# Verify
> Run the tests for these files.

# Session 2
/clear
/add src/services/*.js
> Convert these files to async/await. Same patterns.

# Continue chunk by chunk...

> Search the codebase for remaining callback patterns.
> List any files we missed.

> We're adding a shopping cart total calculator.
> First, write the tests. Consider:
> - Empty cart
> - Single item
> - Multiple items
> - Discounts
> - Tax calculation
> - Currency rounding
> Don't implement yet—just tests.

> Now implement to make all tests pass.

> Run the tests. Fix any failures.

/add README.md package.json src/index.js
> Give me a high-level overview of this project.
> What's the tech stack? What's the main purpose?

/add src/*.js
> Map out the architecture. What are the main modules?
> How do they connect?

/add src/core/*.js
> This seems to be the core logic. Walk me through how it works.

> Create a ARCHITECTURE.md documenting what we've discovered.

> Implement the new search feature behind a feature flag.
> Requirements:
> - Flag name: NEW_SEARCH_ENABLED
> - Default: false
> - Gradually rollout-able
> - Easy to remove later when fully launched

> The feature flag NEW_SEARCH_ENABLED is now 100% rolled out.
> Remove the flag and clean up the old code path.

> I'm stuck on this authentication bug.
> Let me explain what I think is happening, and you tell me if my logic has gaps.

[Explain your understanding]

> What am I missing? Where could my assumptions be wrong?

/add src/complex-logic.js
> Walk through this code as if explaining to a junior developer.
> I want to verify I understand it correctly.

> We have a production issue. Users are seeing 500 errors on checkout.
> Help me investigate. Here's what we know:
> [Paste error logs]

/add src/checkout/*.js
> What could cause this error?

> Let's test hypothesis 1: database connection issue.
> What commands should I run to verify?

> That checks out. Now hypothesis 2: race condition in inventory check.
> Walk me through how this could happen.

# In API repo
> We're adding a new field "phoneNumber" to the User response.
> Update the API to include this.

# In frontend repo (new session)
/clear
> The API now returns "phoneNumber" in the User object.
> Update the frontend to display it in the profile page.

# In mobile repo (new session)
/clear
> The API now returns "phoneNumber" in the User object.
> Update the mobile app to handle it.