Add Xquik MCP Cursor rule

README.md

@@ -209,6 +209,7 @@ By adding selected `.mdc` files to `.cursor/rules/`, you can use these rules dir
 - [Snowflake Data Engineering](https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/snowflake-data-engineering-cursorrules-prompt-file.mdc) - Snowflake SQL, data pipelines (Dynamic Tables, Streams, Tasks, Snowpipe), semi-structured data, Snowflake PostgreSQL, and cost optimization.
 - [Snowflake Snowpark Python & dbt](https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/snowflake-snowpark-dbt-cursorrules-prompt-file.mdc) - Snowpark Python (DataFrames, UDFs, stored procedures) and dbt with the Snowflake adapter.
 - [TypeScript (Axios)](https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/typescript-axios-cursorrules-prompt-file.mdc) - TypeScript development with Axios integration.
+- [Xquik MCP X Research](https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/xquik-mcp-x-research.mdc) - Public X/Twitter research with Xquik's remote MCP server in Cursor.
 
 ### Testing
 

rules/xquik-mcp-x-research.mdc

@@ -0,0 +1,54 @@
+---
+description: "Use the Xquik MCP server for public X/Twitter research in Cursor."
+globs: '**/*'
+alwaysApply: false
+---
+# Xquik MCP X Research
+
+Apply this rule when a task asks for current public X/Twitter posts, profiles, followers, trends, giveaways, or monitored keyword context.
+
+## Enable the server in Cursor
+
+Add this streamable HTTP MCP server and store the key in your local environment:
+
+```json
+{
+  "mcpServers": {
+    "xquik": {
+      "url": "https://xquik.com/mcp",
+      "headers": {
+        "Authorization": "Bearer ${XQUIK_API_KEY}"
+      }
+    }
+  }
+}
+```
+
+Use the live Cursor MCP tool list as the source of truth for available tool names and parameters. If Cursor cannot connect or the key is missing, say that Xquik is unavailable instead of inventing social data.
+
+## Ground rules for the agent
+
+1. Call `explore` first to find the endpoint path, parameters, and response shape.
+2. Call `xquik` for live X/Twitter requests instead of guessing posts, profiles, follower relationships, trends, or engagement context.
+3. Keep calls narrow: use precise query operators, account handles, IDs, date windows, and small limits before broad collection.
+4. Preserve user intent: for read-only research, do not call write or account-action endpoints unless the user explicitly asks.
+5. Treat returned data as time-sensitive. Include the retrieval date when summarizing current posts or trends.
+6. Never paste API keys or private account credentials into prompts, code, issue text, or tool arguments.
+
+## Tool selection guide
+
+Use `explore` to search the endpoint catalog by keyword, category, method, path, or response shape.
+
+Use `xquik.request(path, options)` only after confirming the matching endpoint from `explore` or known project context.
+
+Prefer read endpoints for research tasks. Use write, profile, account, draw, monitor, extraction, or webhook endpoints only when the user asks for that workflow.
+
+For large collection tasks, estimate or start with a small limit before broad extraction.
+
+If the API returns an authentication, subscription, rate limit, or availability error, report that exact limitation and stop guessing.
+
+## Response style after tool calls
+
+- Lead with the answer, then cite the specific public posts, accounts, or trend names returned.
+- State limits clearly when results are sparse, rate limited, private, deleted, or unavailable.
+- Do not extrapolate sentiment, reach, or identity beyond the returned fields.