csp-context-engineeringlisted

| MCP Server | Value | |------------|-------| | **Context7** | Auto-fetches relevant documentation for libraries | | **Chrome DevTools** | Live browser state, DOM, console, network | | **PostgreSQL** | Direct database schema and query results | | **Filesystem** | Project file access and search | | **GitHub** | Issue, PR, and repository context | ## Confusion Management Even with good context, you will encounter ambiguity. How you handle it determines outcome quality. ### When Context Conflicts ``` Spec says: "Use REST for all endpoints" Existing code has: GraphQL for the user profile query ``` **Do NOT** silently pick one interpretation. Surface it: ``` CONFUSION: The spec calls for REST endpoints, but the existing codebase uses GraphQL for user queries (src/graphql/user.ts). Options: A) Follow the spec — add REST endpoint, potentially deprecate GraphQL later B) Follow existing patterns — use GraphQL, update the spec C) Ask — this seems like an intentional decision I shouldn't override → Which approach should I take? ``` ### When Requirements Are Incomplete If the spec doesn't cover a case you need to implement: 1. Check existing code for precedent 2. If no precedent exists, **stop and ask** 3. Don't invent requirements — that's the human's job ``` MISSING REQUIREMENT: The spec defines task creation but doesn't specify what happens when a user creates a task with a duplicate title. Options: A) Allow duplicates (simplest) B) Reject with validation error (s