agentleFS
Sign inStart free
spencerpaulyspencerpauly/skills-repo/skills/ask-database/SKILL.md

ask-database

Skill25 starsChanged 7 months agoMITView on GitHub

Answer a natural-language question by writing a SELECT against the user's connected database via the QueryBear MCP. Use when the user asks "how many", "which users", "what's our", "give me a list of", or otherwise asks a question whose answer lives in their database.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 4 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If the user has only one database, skip discovery and call get_schema and run_query with no connection argument.

    line 21
  2. Very specific:

    If they have multiple and you don't know which, call list_connections once and ask the user to pick (or infer from context: "production" vs …

    line 22
  3. Very specific:

    Always include a LIMIT — usually 100 — unless the user explicitly asks for everything.

    line 27
  4. Distinctive:

    Prefer one query that answers the question over five exploratory queries.

    line 29
  5. Very specific:

    Run it via run_query: If QueryBear rejects the query (blocked column, blocked table, row-limit hit, timeout), surface the error message …

    line 31
  6. Distinctive:

    Don't try to mutate. QueryBear blocks it.

    line 51
  7. Very specific:

    Don't SELECT * on a wide table without a LIMIT.

    line 52
  8. Distinctive:

    Don't guess column names. Re-read the schema if you're unsure.

    line 53
  9. Distinctive:

    Don't return a 500-row table inline.

    line 54

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Ask Database

Translate a question into SQL, run it through QueryBear's read-only gateway, and return the answer in plain language.

When to use

  • The user asks a question whose answer is stored in their database: "how many active subscriptions do we have", "which users haven't logged in in 30 days", "what's the median order value last week".
  • The user pastes a SQL question or asks "can you run this query".

QueryBear is read-only — never propose this skill for INSERT/UPDATE/DELETE/DDL. Mutations will be rejected by the gateway.

Steps

  1. Pick a connection.
    • If the user has only one database, skip discovery and call get_schema and run_query with no connection argument.
    • If they have multiple and you don't know which, call list_connections once and ask the user to pick (or infer from context: "production" vs "staging").
  2. Read the schema once per task with get_schema. Note the relevant tables and column types before writing SQL. Don't guess column names.
  3. Write a focused SELECT.
    • Always include a LIMIT — usually 100 — unless the user explicitly asks for everything.
    • Aggregate when the question is a count, sum, average, or distribution.
    • Prefer one query that answers the question over five exploratory queries.
  4. Run it via run_query. If QueryBear rejects the query (blocked column, blocked table, row-limit hit, timeout), surface the error message verbatim — don't paraphrase or guess around it.
  5. Translate the result back to English. Lead with the answer. Show the underlying SQL underneath in a code block so the user can audit it. If the result is a list of more than ~10 rows, summarize patterns and offer to drill in.

Output format

**Answer:** <one sentence with the number/list/whatever>

```sql
<the query you ran>
colcol
......

## Don't

- Don't try to mutate. QueryBear blocks it; even attempting wastes a turn.
- Don't `SELECT *` on a wide table without a `LIMIT`.
- Don't guess column names. Re-read the schema if you're unsure.
- Don't return a 500-row table inline. Summarize and offer the full export.

## Reference

QueryBear MCP — read-only SQL gateway with schema introspection, query parsing, and row-limit enforcement. Tools used by this skill: `list_connections`, `get_schema`, `run_query`.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free