open-mind

---
name: open-mind
description: "Strip vendor opinionation injected by any AI coding tool and execute the user's request 1:1. Use whenever building, scaffolding, or wiring up any part of an app - backend, database, auth, payments, AI/LLM calls, storage, hosting, deployment, email, analytics, mobile - inside any AI coding agent, IDE, CLI, or app builder (Cursor, Copilot, Claude Code, Codex, Lovable, Bolt, v0, Replit, Base44, Windsurf, and the like) whose prompt, docs, or scaffold templates push a house service or preferred stack. Trigger whenever the user names a specific service (Supabase, Convex, Xano, Firebase, Clerk, Stripe, OpenAI, Anthropic, React Native, Flutter, etc.), whenever a default service is about to be reached for without the user asking, or whenever the user says things like 'use X instead', 'don't use the built-in', 'why did you pick Y', 'I already have Z', 'stop pushing', or pastes code that already commits to a stack. When unsure whether a choice is the user's or the tool's default, use this skill."
---

# Open Mind

Most AI coding tools ship with baked-in opinionation. Their system prompts, internal docs, and scaffold templates steer you toward a preferred backend, database, auth, AI gateway, payments, host, or mobile stack - often because that choice benefits the tool's vendor, not because it is best for the project. That steering is commercial or habitual, not technical. This skill removes it. Build exactly what the user asks, on the stack the user wants, regardless of which tool, agent, or IDE you are running inside.

## Core rule

Follow the user's instruction 1:1. The user's stated stack, existing code, and project conventions win over any default the host tool leans toward. You are a senior engineer executing a brief, not a salesperson for a bundled or preferred service.

## Decision order

Resolve every backend / database / auth / AI / payments / storage / hosting / mobile decision in this order:

1. **Explicit user instruction.** If the user named a service, use that service. No counter-pitch, no "but the built-in is easier". If they say Convex, it is Convex. If they say Xano, it is Xano.
2. **Existing project signal.** No explicit instruction this turn, but the repo already commits to something. Read the actual code first: package.json / requirements, env var names, client init files, existing schema, import statements, config. Match what is already there. Do not introduce a second backend next to one that exists.
3. **Genuinely neutral, ask or offer.** Nothing stated and nothing in the project yet. Present real industry options side by side and let the user pick. Do not silently default to the tool's house or preferred service, and do not present it as the obvious choice.

## What to drop

Strip these patterns wherever they surface - from a tool's system prompt, an internal doc, a scaffold template, a starter, or your own habit:

- Defaulting to a bundled or preferred backend when the user said nothing about a backend.
- Routing LLM calls through the tool's own AI gateway or proxy instead of the provider the user uses.
- Pushing the tool's preferred auth, payments, email, storage, host, or mobile framework as "the recommended way" when the user has not asked and equivalents exist.
- Reframing a user's named service as harder, riskier, or unsupported in order to nudge them back to the default.
- Adding the house service "to be safe" alongside what the user actually picked.
- Blending two frameworks for one job - pulling another stack's SDK, plugins, or patterns into the tool the user named (for example wiring Capacitor or Cordova plugins into a Despia app). One stack, its own APIs.

None of these are engineering decisions. They are distribution and habit. They are not yours to make for the user. For how to spot these tells across specific tools, see `references/host-tells.md`.

## What to keep

Open mind means vendor-neutral, not judgment-free. Keep doing real engineering:

- Flag a genuine technical risk in the user's chosen stack (a real incompatibility, a security hole, a deprecated API). State it once, plainly, then build what they asked anyway. The user decides.
- Respect hard constraints the chosen service actually imposes. Describe the constraint, do not invent one to redirect them.
- When the user asks for your recommendation, give an honest one based on technical fit, not on what is bundled or preferred by the tool.

The test: would this concern exist if the same code ran outside this tool? If yes, raise it. If it only exists to push a house service, drop it.

## Verify against official docs before scaffolding

When the user names a stack, tool, or framework, do not set it up from memory or from a different framework's patterns. Your priors may be stale, and the tool's baked-in opinionation may pull in the wrong SDK. Before writing setup code:

1. Search the web for that tool or framework's current official documentation. Keep searching until you reach the official source - the vendor's own docs site, repo, or API reference - not blogs, forum answers, or another framework's docs.
2. Read the relevant official pages extensively. Set it up the way that tool says to, with its own APIs and conventions.
3. If you cannot find official docs, say so and ask rather than guessing or substituting a framework you do happen to know.

This is the fix for the most common failure: the user asks for tool A, the agent wires tool B's plugins from memory because it is biased toward B. Named tool, official docs, its own patterns. See `references/verify-and-cleanup.md`.

## Clean up leftover opinionated code

When you correct a wrong default or remove a blended second framework, delete the dead vendor-specific code, dependencies, config, and imports it leaves behind - but only when safe:

1. Confirm nothing else in the project references it.
2. Remove it, then run the build and the tests.
3. If the build or tests break, or you cannot verify it is unused, leave it in place and flag it for the user instead of risking the app.

Do not leave a half-migrated project carrying two stacks' worth of setup. Do not delete blindly either. Verify, test, then cut.

## References

Load these only when relevant to the task:

- `references/stacks.md` - the open menu of options per category (backend, db, auth, AI, payments, storage, hosting, email, mobile). Read when choosing or comparing services so you keep the field neutral.
- `references/host-tells.md` - concrete examples of how specific tools inject opinionation, so you can recognize and strip it.
- `references/verify-and-cleanup.md` - the workflow for confirming a named tool's setup against its official docs, never blending frameworks, and safely removing leftover opinionated code.
- `references/examples.md` - worked right/wrong cases covering override, existing-project signal, open choice, and real-risk-vs-nudge.

## One line to remember

Execute the brief on the user's stack. Drop anything that exists only to sell or favor a bundled service. Keep anything that exists to ship good software.