agentleFS
zazzcodezazzcode/zazz-skills/.agents/skills/sqlcmd/SKILL.md

sqlcmd

Skill4 starsChanged 3 months agoMITView on GitHub

Run ad-hoc SQL Server diagnostics safely from an agent shell. Use before invoking sqlcmd directly when the task needs schema inspection, read-only data checks, stored procedure execution, tSQLt runs, timing probes, or quote/env handling guidance.

  • Reads credentials

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 4 are distinctive, and 4 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.

  • 4

    Very specific

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

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

    Use sqlcmd only when a repository recipe does not already cover the diagnostic.

    line 8
  2. Distinctive:

    Prefer a test, development, or disposable database.

    line 12
  3. Distinctive:

    Use read-only queries unless the user or test recipe explicitly requires writes.

    line 14
  4. Very specific:

    Use -C only for trusted local containers or environments where the repo documents self-signed certificates.

    line 16
  5. Very specific:

    If the repo uses an env wrapper, place sqlcmd inside that wrapper instead of exporting secrets in your shell.

    line 33
  6. Very specific:

    Use SQL single quotes for string literals inside the batch: where Name = 'Example'.

    line 38
  7. Distinctive:

    Do not use shell-escaped double quotes as SQL string literals.

    line 39
  8. Distinctive:

    Run a tSQLt class:

    line 44

≈ “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

sqlcmd

Use sqlcmd only when a repository recipe does not already cover the diagnostic. Prefer repo-local commands such as just db-test, make test-db, migration recipes, or integration tests when they exist.

Safety Defaults

  • Prefer a test, development, or disposable database. Never run write or destructive diagnostics against production.
  • Load connection settings from the repo's environment mechanism; do not hardcode passwords, hosts, ports, or database names.
  • Use read-only queries unless the user or test recipe explicitly requires writes.
  • Include -b in scripts when SQL errors should fail the command.
  • Use -C only for trusted local containers or environments where the repo documents self-signed certificates.
  • Redact secrets from output.

Invocation Pattern

Adapt the variable names to the repo's .env, secrets manager, or wrapper script:

sqlcmd \
  -S "$DB_HOST,$DB_PORT" \
  -U "$DB_USER" \
  -P "$DB_PASSWORD" \
  -d "$DB_NAME" \
  -C \
  -Q "select @@VERSION"

If the repo uses an env wrapper, place sqlcmd inside that wrapper instead of exporting secrets in your shell.

Quoting Rules

  • Wrap the whole SQL batch passed to -Q in shell double quotes so environment variables can expand outside the SQL.
  • Use SQL single quotes for string literals inside the batch: where Name = 'Example'.
  • Do not use shell-escaped double quotes as SQL string literals; SQL Server may interpret them as identifiers.
  • For multi-statement or hard-to-quote probes, prefer a repo-local scratch file only when the repo allows temporary files. Delete the scratch file afterward.

Useful Recipes

Run a tSQLt class:

sqlcmd -S "$DB_HOST,$DB_PORT" -U "$DB_USER" -P "$DB_PASSWORD" -d "$DB_NAME" -C -b \
  -Q "exec tSQLt.Run 'test_ExampleProcedure'"

Return compact scalar output:

sqlcmd -S "$DB_HOST,$DB_PORT" -U "$DB_USER" -P "$DB_PASSWORD" -d "$DB_NAME" -C -h-1 -W \
  -Q "set nocount on; select count(*) from sys.tables"

Inspect object columns:

sqlcmd -S "$DB_HOST,$DB_PORT" -U "$DB_USER" -P "$DB_PASSWORD" -d "$DB_NAME" -C -h-1 -W \
  -Q "set nocount on; select c.name, t.name, c.max_length, c.precision, c.scale
      from sys.columns c
      join sys.types t on t.user_type_id = c.user_type_id
      where c.object_id = object_id('dbo.ExampleObject')
      order by c.column_id"

Time a query:

sqlcmd -S "$DB_HOST,$DB_PORT" -U "$DB_USER" -P "$DB_PASSWORD" -d "$DB_NAME" -C \
  -Q "set statistics time on; set nocount on; exec dbo.ExampleProcedure @ExampleID = 1"

Output

Report the command shape, target environment class, result summary, and any uncertainty about whether the diagnostic used the intended database.

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.